Over the last few days our SatNOGS station has occasionally begun to flag all passes as “Failed”. This occurred last night during several ISS passes, which is particularly annoying since our SatNOGS-dedicated 20-element yagi does a great job of pulling in these passes. For those passes there’s no waterfall or audio. A reboot of the Pi cured the problem but it reoccurred this afternoon. This time was quite strange - the pass would initially be marked as “Unknown” and then a few minutes later would be marked as “Failed”. For these passes the waterfall was present and the audio file could be played from the portal. I’m in the midst of upgrading the SatNOGS client to the current version but would like to resolve this issue quickly so that I can capture the remaining ISS SSTV passes this week. Any suggestions?
The first issue (failed without waterfall/audio) probably is because either something crashed on your station or the memory was full at that time. If it is the second case, it may be a result of an known issue for the SSTV decoder that is fixed in the latest version, so an update should fix this. The next time you see such a behavior check the logs and if there is free memory.
The second issue (failed with waterfall and audio) happens when audio file duration is more than 1 minute different from the scheduled duration, for example in https://network.satnogs.org/observations/3373636/ scheduled duration is 9m and 19s and the audio duration is 5m. Not 100% sure what causes this difference, sometimes could be something on sdr, or the cpu of the RPi. I suggest you update and watch if the issue insists.
That’s interesting… have you updated to the latest version? If not please try to and let us know if you still get this message. If you have updated, could you share here the result of Advanced -> Support in sudo satnogs-setup (note: the first time you run it, it may take some time to be generated).
Possibly not. I did that a few minutes ago and then rebooted. Now the journalctl on the SatNOGS client is giving me these messages for the current pass. Will check the result after the pass is done in a few minutes. It might be OK now - will see.
Still getting the initial error - flagged as failed but get waterfall and data. Looks like the client is starting reception and rotator movements several minutes after the pass starts - don’t know why. For now I care mostly about the ISS passes - will probably loop back to deal with this issue in another day or two.
Still getting the passes marked as Failed. I think the cause is that the client isn’t starting the receive function (based on the journalctl entries) until the satellite is about halfway through the pass. The satnogs-monitor functions shows the satellite moving through the pass properly but the client isn’t starting on time. Based on your comment above (that the audio track is significantly shorter than the pass length) it’s probably failing for that reason. Is there some parameter that’s wrong that would cause the scheduler to skip the first half of the pass?
