Regarding Observation 8626660 …
This observation is marked as “Failed”, but the signal of HADES-D is clearly visible.
There is a large doppler error, as the TLEs asigned are incorrect.
Regards,
Pablo - EA4FUK
Hi @ea4fuk and welcome in the community!
As there is signal on the observation, I’ve vetted the waterfall as has signal and the observation turned its status to good.
Now about the failed status, 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 duration more than 1 min.
Obviously in this observation we don’t have the first case. Checking the audio duration you can see that it is around 4min and 20 seconds, while the scheduled duration is around 8min and 30seconds. So we are on the second case.
What does this mean and why it happens?
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 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 a lower frequency causing loss of samples. This can be solved by changing the power supply, after making sure that the current 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.
In the observation you linked and from the metadata and the good results of the station on other observations, probably none of the above happens. I checked also other HADES-D observations, and it looks like that there are several with the same issue and the common ground is that they use the transmitter with FSK 50 mode, so I suspect that this small baudrate (50) is causing the issue. @surligas or anyone else can verify this or any idea why this happens?
Hello, and thanks for the detailed replay.
I wasn’t aware that audio capture was used to set the status.
In any case, my point was that in this capture (and several others) there is a good signal in the spectrogram, but the doppler correction is wrong, and that could cause the “observer” to think that the signal is from another satellite, or just local noise.
That the short audio is related to the FSK 50 mode seems a good clue.
Regards,
It seems we don’t have yet a TLE to follow for HADES-D by space-track, so we need either to relay on ours or follow the closest one. I’m going later to look at it, It would be sooner but the other falcon 9 launch kept us busy.
By the way if someone wants to help in this process is more than welcome, but I would suggest join the satnogs matrix channel to coordinate with the rest people in order to avoid doing the same thing twice.
Hi Pablo:
Now I am ussing these TLEs and, at the moment, are working quite accuratly:
1 98981U 23340.47916667 .00000000 00000-0 33505-3 0 05
2 98981 97.4806 53.1571 0010356 179.7629 207.8184 15.14784274 02
73 de David EA4SG