Over the last week or so, I have noticed a bug with scheduling. Random observations that I will schedule will end up producing results (lists of available stations and times) that are much less than normal.
For example, this morning I went to schedule FalconSat-3 observations on my own UHF station, but the results after “calculating” showed only about half the number of available stations as usual. The last time this happened (For Fox-1B yesterday or the day before), same results. Only half the normal amount of stations came up, and my station wasn’t even listed even though it was available for the observation. Then, the next day, if I run the same observation query, it allows me to schedule the observations that were missed.
I have noticed this too! Initially, I thought this was because my station was already busy at the time of the passes; however, going to the station page that lists the upcoming passes for the next 24 hours showed otherwise.
Sure. Below is an example of what happened this morning.
At about 12:30z (2019-01-02), I tried to schedule Falconsat-3 (only one transmitter available) for the next two days. Usually I am presented with about 30 available stations, including my UHF station (187). However I was only presented with about half of those stations, and mine wasn’t one of them.
I tried again later (15:47z), and all then appeared normal, including my station being listed, with three available passes to schedule (shown below).
Interesting! Checking a bit the specifics of your example @K3RLD Flaconsat-3 is on a relatively low inclination and your station would be getting low passes for it. Maybe something with the minimum horizon calculations? If you can point specifics of another example we can look into that more.
No, that’s not it. I get 2 or 3 good passes of FalconSat-3 every day. And in this specific case, I tried to schedule the passes 48 hours in advance, but couldn’t. When I tried a few hours later, voila - there they were (they were ALWAYS within the 48 hour window). So this had absolutely nothing to do do with station elevation minimum.
Ok, new example. Go to set ISS voice observatons (at 12:10z today, the 4th) for the next 48 hours (first 24 hours are already scheduled from yesterday).
My station (272) is not listed. There are several passes on the 5th and 6th that are WELL above my 10° minimum, but still they are not listed in the query results. Checked scheduled observations for station 272 and there are NONE in that time frame, so unavailability of the station is not an issue.
This is a bug, I think.
–Roy
K3RLD
[edit] appears to be same problem with SO-50, time right now is 12:29z, station in question is 187
That’s exactly the problem as I’ve described above. You try it once and it won’t list the station as available. Try it a few hours later (or the next day), and voila - they are there.
I’ll try to check it randomly during the day, hopefully I’ll hit it.
Have you tried hit calculate again when this occurs? Just in case you haven’t please try it the next time you face this bug and let me know if the result changes.
Yes, many times. Even tried switching satellites, calculating, switching back and recalculating. Time is the only thing that seems to fix the problem, and it appears that it is only minutes to a couple of hours required.
I can confirm the strange behaviour. I wondered why my station didn’t appear in the list of stations for scheduling observations. Clicking the “calculate” button once again didn’t help. Half an hour later or so the process worked as expected
So, I finally managed to find the issue and fix it… it will be merged soon into production.
The problem was a combination of a known issue of pyephem and a regression which was stopping calculations of next observations when the issue was hit.
This was fixed in the past but due to the recent refactoring it came back. Thanks @K3RLD for pointing out this and @csete and @MasterJ for confirming it.
More details:
When you ask pyephem for a next pass of a satellite, if the start time, that is set, is inside a pass of this satellite then it returns a pass with the end of the current pass and the start of the next pass.
If you move the start time outside the current pass, after the end, which is the fix we implemented, then it returns the right next pass and the calculations continue, instead of stopping.
This is the reason that you were able to see and schedule the passes after some minutes, as your new start time was after the current pass.
The TLE for satellite 43772/Range-A in Observation 399777 was updated at 2019-01-08 09:32:34, which was only ~75 minutes before the start of the observation. When updating TLEs in SatNOGS the observation start&end times aren’t adjusted (personally I’m not a fan of this current behavior, but tbh it doesn’t produce problems most of the time). If the observation was scheduled using an old TLE which differed strongly from the new one the pass might not happen during the observation. This seems the case here.
Using GPredict I just verified that the polar plot is correct, with the given TLE there is no pass at the given timeframe (to do this, I wrote a small script to import a SatNOGS ground station into GPredict: https://gitlab.com/snippets/1795975).
I confirm that I’ve changed norad ids for RANGE-A and B yesterday night (UTC) to the ones that were suggested in celestrak. The norad id that RANGE-A followed before was totally different from the new one, as it was originally confused for other satellite.
