Hello, I agree with you, I see exactly the same problem for my station 458. https://network.satnogs.org/observations/3849097/
The waterfall duration is about 8 min, but audio is 5 minutes only.
Rasperry is connected thru Wi-Fi and I know I’m loosing some packets,
but for me, this observation should be rated as Good.
My latest logfile shows also a lot of ‘drops’.
Anyway, I’m waiting the investigation and see how we can improve that case…
Thanks and regards,
73’s de ON5FB ON4LS ON3ZZT
root@SATNOGS-458:/# journalctl -f -u satnogs-client.service
– Logs begin at Thu 2019-02-14 10:11:59 GMT. –
Mar 27 09:39:41 SATNOGS-458 satnogs-client[330]: Found Rafael Micro R820T tuner
Mar 27 09:39:41 SATNOGS-458 satnogs-client[330]: [R82XX] PLL not locked!
Mar 27 09:39:41 SATNOGS-458 satnogs-client[330]: [INFO] Using format CF32.
Mar 27 09:39:41 SATNOGS-458 satnogs-client[330]: Allocating 15 zero-copy buffers
Mar 27 09:47:57 SATNOGS-458 satnogs-client[330]: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOsOFound Rafael Micro R820T tuner
Mar 27 09:47:58 SATNOGS-458 satnogs-client[330]: [INFO] Opening Generic RTL2832U OEM :: ppm+0…
Mar 27 09:47:58 SATNOGS-458 satnogs-client[330]: Found Rafael Micro R820T tuner
Mar 27 09:47:58 SATNOGS-458 satnogs-client[330]: [R82XX] PLL not locked!
Mar 27 09:47:58 SATNOGS-458 satnogs-client[330]: [INFO] Using format CF32.
Mar 27 09:47:59 SATNOGS-458 satnogs-client[330]: Allocating 15 zero-copy buffers
The lost samples is due to full cpu load, my suggestion would be to try lower sample rates. To find which ones are supported check this guide.
The initial concept about failing an observation when audio duration has a “big” difference from the scheduled duration, was that in this way we can spot if something goes wrong with the station and the flowgraph that it runs. To be honest this has revealed some issues and I think it led to some fixes, so station can perform better.
However low duration doesn’t always mean 100% failed observation, so this is why you have the ability to vet the waterfall if there is signal or not. If there is, like in the case of the observation you linked, then the observations status changes to good.
If there isn’t then the “no signal” in waterfall, it can be 2 things, either that satellite wasn’t received or that station has issues, so in this case we chose the observation status to remain “failed”. There is a hack to turn the observation to be “bad” by vetting it first as good and then as bad but I don’t suggest it.
By the way to find all the observations that don’t have their waterfall rated you can use the “Rated Artifacts” filter in observations page, for example these are the good and failed observations without rated waterfall.
These vetting changes weren’t complete but it was a first step for moving forward to a better process that will be more useful. Unfortunately other tasks got in the middle and the change hasn’t been completed but it is high in the priority list, so stay tuned.
During lunch time, I changed parameter ‘SATNOGS_RX_SAMP_RATE’ and decreased value from 2.048e6 to 1.024e6 and problem was solved !
When looking at the logfile, no more packet is dropped.
I forgot to mention that I’m using a USB device Nooelec NESDR SMArt RTL2832U.
