Regarding Observation 4794032 …
Hi all,
This observation looks perfectly correct to me.
Why has it been flagged as “failed” by -1000 ?
73,
N5FXH,
It is marked automatically as failed because the audio file duration is 5m 34s which is more than 1 minute different from the scheduled one which is 8m 36s. Vetting the waterfall with signal will change the status.
Short audio is usually a result of lost samples, due to CPU not able to handle the sample rate. Two scenarios that happen often:
- Sample rate is too high for CPU to handle it in normal conditions. This is solved by reducing the sample rate in settings.
- Sample rate is ok but due to temperature, CPU drops to lower clock speed (lower Hz) and can not handle all the samples. This can be solved by reducing the CPU temperature, for example with a heatsink or a fan.
1 Like
Hi Fredy,
Thank you for your answer.
The computer hosting SatNOGS has another CPU intensive task, so the configuration may not be ideal.
I have seen multiple marks on failed observations: -1000, -100.
Is it a indicator of the number of lost sample ?
Would it improve the situation to lock the process on one particular core (with taskset) ?
73’,
N5FXH,
Nope these numbers are a scores for saying if an observation is bad or failed or good etc… Currently the score of an observation is fixed value but in the future would be calculated from different parameters.
For checking list samples, you can check the logs of SatNOGS Client and search for multiple O’s or o’s which indicate issues with the buffers.
Hm… I don’t have the knowledge to answer that, maybe @surligas or @Sleepwalker. From my generic knowledge I would say it depends on the CPU power, but also I know that GNU Radio scripts use multiple cores, so limiting it into one maybe it will be worse. Anyway you can experiment and see the results. 
1 Like
One possible quick and dirty solution is to reduce the sampling rate of the SDR 
2 Likes