Below Station Set Elevation Observation 5756154: Bobcat-1 (46922)

Regarding Observation 5756154

My station is set to 20deg elevation due to surrounding buildings and trees but people seem to be able to do as they please and set observations below that threshold.

Why is this ??

Rgds
Karl.

2 Likes

There are two reasons for observation scheduled under the set horizon, in this case the second one applies.

  1. The TLE has been updated. Every couple of hours all the future observations getting update with the latest TLE of the satellite. If there is a significant change then it can affect the elevation.

  2. Special events and scheduling with custom horizon. There are cases like early deployments or near to re-entering that we schedule observations starting from 0 going to max and end up to 0. In these cases the TLE set we use is not accurate, so scheduling the whole pass giving us the flexibility if the satellite comes earlier or delayed to receive it and helping later to re-adjust and generate new TLE sets that will be more accurate. Another case for scheduling the whole pass is when we have events for known satellites with strong signal that sometimes can be received bellow the set horizon, an example is ISS SSTV events.

May i ask who your referring to when you say WE because i myself am unable to schedule observations below a stations set min elevation.

I get the fact that were all trying to help out make SatNogs better for all and supply a much needed service but if you give me an option to set a min elevation then i expect it to be adhered to and not over ridden by a certain select few.

Take for instance my other station which also has a Min Elevation of 20deg and running on a Yaesu G-5500. Are you implying you could also set an observation below it’s 20deg min elevation and potentially drive my antennas into my roof ridge line ?

2 Likes

The WE is all the users that have permission to schedule according to the permissions matrix:

https://wiki.satnogs.org/Operation#Network_Permissions_Matrix

You are right, the expectation is that scheduled observations should respect that setting. I can see two solutions on this, the one is to note/warn the user when the setting is set that this limit is a soft one and that there are cases that will be overridden. The other solution is to let the user decide if this will be a soft or a hard limit and change the scheduling code to respect that choice. Which one do you think is better?

By the way, I’ll open an issue tomorrow about it in the SatNOGS Network repository in order to implement one of the two solutions when we decide which one is better. From my point of view the second sounds better as it gives the choice to the station owner, but it will need some time to implement it. Maybe until it is ready we can add the note/warning of the first solution to inform station owners about it.

1 Like

Forgive me if I’m reading this wrong but I’m unable to find the place where it states certain users can over ride the elevation setting of a station they do not own in the Matrix you provided a link to.

The second option/solution you provided sounds the best to me as it should of been that way from the start.

Out of curiosity what other options can be over ridden on my station without my prior knowledge or permission.

Thanks
Karl.

The link is to see who are the people that can schedule and potentially override that setting. Sorry if it wasn’t clear on my previous answer, anyone with scheduling permission can change the minimum horizon in Network Observations New page by changing the advanced options.

:+1:

Nothing else.

Thanks Fredy that clears things up for me.

73

1 Like

Testing mode can be overridden by admins.

Did the programmers every make headway with this as i see people are scheduling observations set below the elevation 35deg I’m comfortable with so i have therefor turned OFF rotor control at my stations.

Thanks
Karl.

I don’t see anything posted on the issue that Fredy made for it so it may have not been worked on. Implement option for hard/soft limit of min horizon for stations (#841) · Issues · librespacefoundation / SatNOGS / satnogs-network · GitLab

1 Like