Hi David, Thanks for your response. Mark VK5QI and I did some playing around and he figured out that the mask estimator works significantly better than the peak estimator for our use-case - it's decoding every packet consistently, even when allowing 0 bit flips in the preamble.
One thing of note is I found that the FSK demodulator has a burst mode setting, but it actually behaved slightly worse than the default settings. Thanks, Stephen david <da...@rowetel.com> writes: > Hi Stephen, > > The FSK modem has been used for burst applications (e.g. the FSK raw > data mode). It's true that in general burst modem acquisition is more > challenging than for continuous streaming data. > > It's difficult to comment on your specific case, as so many things are > unique to a specific implementation - and many things that can go > wrong. > > If you can reproduce your problem using the command line fsk_xxx tools, > feel free to post command lines here to demonstrate the problem. > > - David > > On Tue, 2024-01-30 at 19:50 -0400, Stephen Downward wrote: >> Hello all, >> >> I'm using the FSK demodulator from codec2 in a side project of mine. >> I have a 9600 >> bps stream running at 4.8KHz deviation. Packets have 32 bits of >> preamble, followed by a 32 bit sync word and then the actual data. >> >> I believe the FSK demodulator is having trouble locking on, and it's >> causing some of the initial bits to be flipped. My reasoning is as >> follows: >> >> - I captured a sample of about a hundred packets, with 10 seconds of >> nothing between each packet, and a few ms of transmission time per >> packet >> >> - If I allow, say, 10 flipped bits in the sync word, every packet >> decodes >> properly. >> >> - If I allow only 5 flipped bits in the sync word, the decode rate >> drops, >> and continues to drop as I lower the allowed number of flipped >> bits. >> >> - When I only allow 5 flipped bits, suddenly the modem is super >> sensitive to parameters such as n_sym and the upper/lower frequency >> estimation limits. For example, changing n_sym from 38 to 39 may >> cause >> the decode rate to fall by 10% or more. However, different n_sym >> values seem to work better for different packets. If I capture two >> samples of a hundred packets each, each sample may have a different >> n_sym where the maximum number of packets are decoded (at 5 allowed >> bit flips) >> >> - 5/32 bit flips would be enough to mangle many packets, if that >> error >> rate was maintained for the entire duration of the packet. Thus, >> the >> error rate must be dropping shortly after the sync word >> >> Initially I thought it might be an issue with a slow AGC on the >> RTL-SDR. After turning off AGC, I'm still getting the same >> behaviour. This makes me think it's a problem with the FSK >> demodulator >> itself. >> >> As far as I can tell, the FSK demodulator is primarily used in >> projects >> that send many packets in quick succession. I am wondering if it's >> poorly optimized for my use-case of having long periods between >> packets. >> >> Thanks, >> Stephen >> >> >> _______________________________________________ >> Freetel-codec2 mailing list >> Freetel-codec2@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
