For the last several days most of the passes recorded by our station (#223) have been marked as “Failed”. This appears to be because the SatNOGS client is starting to process the pass about halfway through it and the resulting audio track is significantly shorter than the pass length. This occurs on every pass - the satnogs-monitor program shows the pass starting at the scheduled time but the journalctl log shows no activity until several minutes later. Can anyone help with this issue?
I think that I’ve the same issue here. Just updated my client, still v1.3.4 but after the first pass it should go to v1.4.
The journalctl still give some error’s…
We’ll see what happens.
Watched another pass - satnogs-monitor showed it starting at 21:42:28 yet the client didn’t start tracking until 21:56:41. It stopped tracking right at the end of the pass.
Is the station equipped with an RTL-SDR? Slow start may happen either due to back-to-back observations, wrong system time, or SDR device slow closing from the previous obs.
Ok, update…my station seem to work again.
After a few try’s performing the update nothing changed. Also still some python fault messages in the journal.
This morning I wanted to do a fresh install ( artifacts image) took some screenshots of my system settings and wanted to read the info behind the “about…Information about satnogs-config”.
Then a lot happened, there were some pip updates etc etc and after a reboot my system was up and running flawless.
Not sure what the problem was, hope this info is usefull.
So did you do a complete fresh installation or were you able to run the update within satnogs-setup to make it work?
I downloaded the Pi image and built a new installation on a new SD card on the same Pi. I also swapped the SDR. The same result occurs - the pre-observation process starts on time but the commands to start the SDR and rotator don’t start until 4 minutes (always 4 minutes) later. The observation stops at the correct time, though. Is there any information embedded in the pass schedule that might be causing this? We’ve eliminated almost everything else.
1 Like
What is the pre-observation process?
I don’t know what it does - it’s simply a line reported in the journal whose name suggests that it has something to do with the observation. It seemed notable because it started at the scheduled time but the other processes (starting the SDR and rotator processes) didn’t start until four minutes later.
I installed the previous SatNOGS SD card in another Pi configured for a different station (1130), removed the configuration in satnogs-setup and manually re-entered all of the parameters. This appears to have worked but needs additional testing. So it’s possible that the configuration somehow got messed up and copying over the localhost file to the new Pi image carried that corruption to it (although since it’s a text file that seems unlikely). Hopefully that’s the answer.
Just to finish off this issue, I found that the delay was caused by a program that was executing PRIOR to SatNOGS. Should have been obvious to me but I looked completely past it. Fixing that eliminated the problem.
1 Like
Also make sure the time on the machine is in sync? Have you enabled NTP and verified it is correct?