Regarding Observation 11595496 …
it says failed. why?
Currently there are two reasons for an observation to get failed status:
- No artifacts uploaded after some period, artifacts are any of the observation results, audio, waterfall, data.
- Audio artifact duration differs from the scheduled one more than 1 min.
In both cases there is a potential station issue, which could be temporary or need some care.
Obviously in this observation we don’t have the first case. Checking the audio duration you can see that it is around 3min, while the scheduled duration is around 6min. So we are on the second case.
Why audio can have sorter duration?
The short audio duration means usually that there are lost samples, this happens:
-
When the CPU can not process all the samples that are coming from the SDR aka overflow. This is visible in the logs of client noted with several big O’s, you may need to change the logs level to see them.
-
When there is underflow, in other words SDR doesn’t provide the right amount of samples to maintain the sample rate. This is visible in the logs of client noted with several small o’s, you may need to change the logs level to see them.
For the first case there can be several reasons, below are some of them we have experienced:
-
CPU Temperature:
In this case increased CPU temperature forces CPU to work at lower frequency to decrease the temperature, this lower frequency isn’t enough to allow processing of all the samples. Usually a CPU heat sink or fan or better ventilation can improve/fix the issue. -
Power Supply:
In this case the power supply isn’t enough to support CPU high frequency. Similarly to the temperature issue, the CPU works at lower frequency causing loss of samples. This can be solved by changing the power supply, after making sure that the current one doesn’t offer the necessary power. -
High Sample Rate:
In this case the sample rate of the SDR is set to a very high value, such that the CPU can not process. Solution is to set a lower sample rate.
For the second case to be honest I’m not very familiar so I let someone else to explain.
1 Like
@calligua Stephano…Fredy has nailed it.
From my experinece I had to leave the covers of my RPi’s to keep them cool. I see some guys use a small external fan blowing across them.
I also use a POE card with a fan to power the RPI. It is fed from a POE+ Switch. Very reliable. The fan also helps with cooling. RPi’s are very frustrating when the PS is not up to the load. Remember you are powering the RPi plus the SDR and probably a LNA all from from the RPI Power Supply…get a decent PS is the first rule of RPi’s.
Finally I am not sure what sort of SDR you are using but you can see the dropped samples if you use PiSDR and start GQRX from a terminal. You will see a series of O’s or U’s (I can’t remember which at the moment) if the SDR samples are over or underflowing the RPI. Play around with Sample Rates and Decimation to optimise it.
Hope you are learning heaps about SatNOGS, RPI’s and SDR’s. They are good fun!!!
John - VK4JBE
I have grafana data for the pass that we talking about.
http://localhost:3000/dashboard/snapshot/5fF0M2AjPhpm86J1FTTZfGZrUeWVoZJV
unfortunately I do not have power supply monitor but temperature seems ok
It clearly is above 80C which is pretty bad, it will start throttling at that point. Heatsink and maybe fan. I use the small metal chassis that acts as a heatsink as well, no fan needed usually.
for reference rpi thermal control.
1 Like