Just noticed that all the passes I’m vetting today at my two stations do not go “horizon to horizon”. My elevation minimum is (and has been) set at 10 degrees for both stations, and I’m wondering if a system update has been pushed through to ignore the first and last 10 degrees of the pass (this is a very good thing, by the way - no sense in publishing a bunch of dead air).
–Roy
K3RLD
The latest update of the network brought some refactoring and some features in scheduling. One of the changes is that now by default calculated passes respect the minimum horizon of the station.
So, passes start and end at the minimum horizon of the station. If you need all your observations start and end at 0 degrees then you’ll need to change the minimum horizon of your station to 0.
In case that you want only some observations to start and end at 0 degrees then in observations/new page there is an option in the advanced settings that allows you to set a custom minimum horizon and calculate passes with this.
I’d like to add that we plan to implement a way to set in more detail the horizon of a station and not just with one number.
Hi,
Sorry for the late reply, but I just noticed this change and to me it is a bit confusing.
I have set the minimum horizon parameter for the station according to “I want satellite passes to come at least this high” before they are interesting, let’s say 10 degrees. So, now the scheduler will start and end the pass at 10 degrees elevation, right? But what if a pass has max elevation 11 degrees? Will I get a 1 minute pass 10->11->10 degree elevation?
Personally, I would prefer passes to always be horizon to horizon, so I think a second parameter is needed for this option. And there should probably be at least 5 deg difference between the two limits.
+1 on this.
In my mind the minimum elevation pass is an indication to the schedule of what passes are likely to give useful results from my station.
It should not be considered a hard cutoff, below which there is no useful data received. In many cases I can receive useful data down to the horizon, but it doesn’t mean I would want my minimum elevation setting to be 0 degrees.
We have a minimum observation time (which is currently 2 mins) but could also be exposed as a parameter.
You can already override and select horizon to horizon on the New observation page (check the advanced options) :
Why not have the time being a determination on that? That way we are agnostic to various orbits.
Thanks for the clarification.
I agree that using the time is better.
I just checked the station horizon option, and realized that the 90deg custom option is probably not necessary, no?
I tried using the slider on the new observation page and I got a pass where max elevation was 1 degree:
https://network.satnogs.org/observations/460416/
Perhaps we misunderstand each other… I would like a horizon to horizon observation where the satellite comes at least 10 degree above the horizon during the pass.
I think what you are saying is, the pass is ALWAYS recorded from horizon to horizon, provided that it’s TCA elevation is above the “min horizon” setting, correct?
[edit] Before today I would have said that I wouldn’t need that option, but the ISS SSTV (and I assume voice contacts) are so strong that I can pick them up down to almost 0 degrees. May have to rethink my stations “min horizon” setting.
In this case, you set your min horizon in station page at 0 and when scheduling observation you filter the calculated ones (on both station and observations/new pages) with moving max elevation to be at 10 degrees.
However this means that all the people should know and follow this on your station, so I agree that an option that can force this to all observers is needed.
This is why we added the option to change the horizon to a custom one. In my observation of ISS event passes I use it.
Yes, that is correct.
is there a chance to determine and setup the min horizon level at station side as well? I notices since the change the sudden death of rotation via hamlib tcp connection linked to pstrotor. since it was working with level zerro pretty well i would like to debug the station with the old value behaviour.
Also a defined obstacle pattern would be fine to have for the station. since i know my trees around this might help to make it more efficient…
