Hi, I’m interested in receiving NOAA transmissions and when I schedule a pass its typically of the order of several minutes. The received waterfall and audio clip that I get see are typically 40 seconds. Why might this be? Is there a squelch level that is perhaps not been broken outside these 40 seconds?
There can be many reasons. Please provide a link to a specific observation where this occurs.
Judging from the audio recording, the sample rate is much lower than what it should be. Perhaps the RPI can’t keep up or there is power supply issue.
Ok, it is an original first generation PI. I’ll try a PI3B I’ve got and see if it makes any different. The power supply should be fine at 2A.
Oh, you definitely need the newer multi-core processors!
I’ve set it up with a Pi2 quad core I have and will see what happens. I ran rtl_test and didn’t see any dropped audio samples. Thanks for your help 
I would strongly recommend the PI3. I think that’s also what the SatNOGS project recommends. rtl_test doesn’t do any DSP so CPU load will increase significantly when satnogs-client starts running DSP software.
Ok, thanks for the advice. I’ve scheduled a bunch of task for this afternoon and evening. Is there any logging I can examine that satnogs-client produces that would indicate if the processor can’t keep up? I am able to decode FT8 and WSPR using jtdx without problems on a Pi2. I appreciate that a PI3 is recommended but the shops are closed on Sunday!
https://network.satnogs.org/observations/526085/
This observation would at least indicate that the problem of flyover versus audio clip length seems to have been solved by not using a single core raspberry pi.
Yep The single core just can’t manage it.
I did an experiment a year or two ago to try and use a Pi 1 B I had. And it just failed with only 2 min long observations.
I currently use my X86-64 desktop I normally use for my ham stuff for my station. Because generally its not being used and has no load at all.