projecthorus / radiosonde_auto_rx

Automatically Track Radiosonde Launches using RTLSDR
GNU General Public License v3.0
477 stars 124 forks source link

FSK Decode Chain (part 2) #288

Closed rs1729 closed 3 years ago

rs1729 commented 4 years ago

cf. https://github.com/projecthorus/radiosonde_auto_rx/issues/104

Compared fsk_demod and the decoder-built-in --IQ (--lp) demodulation using the test samples. (For DFM, M10, LMS6-403, fsk_demod is not much worse, but I didn't investigate it in detail.) With RS92 and RS41 some differences can be observed.

RS92: The frame error rate of the fsk_demod chain is approx. 1dB worse than the built-in --IQ demodulation, however for lower SNR the gap is getting larger, fsk_demod is getting into trouble because there are not only isolated bit errors, but it seems like bits are lost or added, i.e. the sync/timing is lost and then the rest of the frame is affected (and that's not good for error correction). fsk_demod has no information on sync words such that it could use that timing for the whole frame. The modulation index and also the pulse shaping may contribute to wrong timing when there is more noise. The bit error rate (and byte error rate) can be estimated when comparing the original raw frames to the raw output without error correction of the generated dB-test-samples. For fsk_demod I could only compare the BER for the frames that did not have the "catastrophic" (i.e. rest of the frame is affected) sync errors.

The test samples are generated with baud=4800. RS92 has Manchester coding, 2 symbols for 1 bit improve the demodulation BER by about 1.5dB (I guess), if the soft symbol scores are compared. (Not as much as integrating over twice the symbol length, i.e. half the baud rate without Manchester.) The fsk_demod version of master/testing branch behave similar.

rs92comp

RS41: Here the sync/timing problems started already at 10dB, so there are many frames where a demodulation error affected the rest of the frame, bits were shifted. (I remember this problem from zero-crossing demodulation of the FM-audio.) So the error correction is not of much help. There is a much greater gap between --IQ --lp demodulation and fsk_demod of about 2dB. I believe RS41 has about the same pulse shaping as RS92, though the modulation index is lower. The RS41 does not transmit a continuous signal, though the frame preamble should be long enough for sync. However there is a difference between the master and testing version of fsk_demod, the new testing-version decodes only half the frames of the master-fsk_demod-version.

rs41comp

For the FER output the follow decoding/demodulation commands were used (e.g.):

./rs41mod -r -v --ecc --IQ 0.0 --lp - 96000 32 rs41_96k_float_10.0dB.bin | grep OK | wc

cat rs41_96k_float_10.0dB.bin | csdr shift_addition_cc 0.125 2>/dev/null | csdr convert_f_s16 | ./tsrc - - 0.500 | ./fsk_demod --cs16 -b 1200 -u 24000 -s 2 48000 4800 - - | ./rs41mod -r -v --ecc --softin -i | grep OK | wc

For RS41 the option --ecc can be omitted. For the BER estimates no error correction is used, the error correction has to be turned off in rs41mod.c (it is turned on by default).

Remark: The dB estimates of the test samples may not be the same as in other (theoretical) plots for coherent/non-coherent FSK demodulators (with certain FSK parameters).

EDIT/REMARK: You can include shifting/resampling by csdr/tsrc in both commands above such that only fsk_demod makes the difference:

cat rs41_96k_float_10.0dB.bin | csdr shift_addition_cc 0.125 2>/dev/null | csdr convert_f_s16 | ./tsrc - - 0.500 | ./rs41mod -r -v --ecc --IQ 0.25 --lpbw 7.0 - 48000 16 | grep OK | wc
darksidelemm commented 4 years ago

I guess the main reason I've been sticking with fsk_demod for now is the usefulness of the SNR output, and the frequency offset estimation. The SNR estimation in particular is very useful for testing decoding setups!

By your comment "the new testing-version decodes only half the frames of the master-fsk_demod-version", i'm guessing you mean at low Eb/N0 values? I did have to make some tweaks to the frequency estimator so that it hangs on over the gaps between packets, but I'm guessing the timing estimator is also going to have issues locking on when the signal is very weak.

As for RS92 decoding, I don't think that's so important anymore... RS92s are becoming more and more rare now....

rs1729 commented 4 years ago

The frequency correction can be really helpful for radiosondes like DFM-09, LMS6-403, also M10. There the differences did not seem to be so obvious, but for RS41, maybe the fsk_demod can be improved. Perhaps it is not so easy to have a general purpose demodulator that can cover all the different FSK parameters, independent of a particular frame structure or adjustments to sync words or preambles. Maybe some more lowpass filtering of the IQ data could also help. But I don't really know fsk_demod. Depending on the data and coding, the timing can be more or less important.

You mentioned you tweaked the testing-fsk_demod for the RS41-gaps. That's why I was surprised. I tested only from 10.0dB down, number of OK-frames for 10.0, 9.5, 9.0, 8.5 dB: fsk_demod-master: 89, 38, 2, 0. fsk_demod-testing: 43, 12, 0, 0.

The RS92 results were a little bit better with the testing-version, only the lowest SNR that gave a valid frame was a bit worse then the master version. RS41 starts to produces errors earlier, maybe there is a turning point for the testing/master-version.

Yes, RS92 is not so important anymore, but for comparison with RS41 it is a good reference, to get some ideas where the problems could be.

darksidelemm commented 3 years ago

I think we're at the point where the fsk_demod is working OK so I'm going to close this one.