Hi Tomas, Yes fsk_demod_sd() outputs a SD, calculating LLRs is another step. here is how we do if for 2FSK:
https://github.com/drowe67/codec2/blob/dr-lockdown/src/mpdecode_core.c#L569 The FSK demodulator has been used on many projects for 5 years and has proved very reliable. We have verified it's performance in simulations with a battery of ctests (you can run these yourself), as well as some pretty impressive on-air use (README_fsk.md). Can you please explain how you have determined the demodulator is "losing bits"? Can you please send me instructions to reproduce the problem using a stored sample file, and a command line version of the demodulator? Looking forward to seeing a PR :-) Cheers, David On 29/5/20 9:21 pm, Tomas Härdin wrote: > Hi > > Yes, I am using fsk_demod_sd(). The problem is that it outputs power > differences, not ratios. So if you double the power and the noise power > density then its output values will be doubled. This doesn't mesh very > well with an Eb/N0 and LLR way of thinking. > > I've been testing a bit more, and I'm able to verify that the > demodulator is losing bits every now and then. I think the reason is > that it's running frequency estimation for each call, not just whenever > a new transmission is detected. This needs to be fixed. Or maybe using > burst mode is enough? > > I want to get the modem into a state where it can look for and > demodulate multiple transmissions in the same sample stream. That or I > channelize in gnuradio beforehand. Multiple overlapping subbands, each > with their own demod thread. > > I guess I should get some attenuators in my next Farnell order so I can > do some over-the-coax tests. > > I can create a branch/PR for this, just need to clean things up a bit > and rebase. > > /Tomas > > fre 2020-05-29 klockan 07:36 +0930 skrev David Rowe: >> Hi Tomas, >> >> These experiments are great - well done. I am interested in developing >> a turn key system that provides IP links over VHF/UHF for >> Ham/Emcon/developing world applications. I think we have many of the >> pieces. >> >> You can get soft decisions from the FSK demod using fsk_demod_sd() - we >> have used that with the Wenet SSTV system to interface to a LDPC >> decoder. We could easily add some FEC to your data mode, many of the >> codes and utilities to use them are in the codec2 repo. >> >> I'd like to try some bench (over the cable) as well as over the air >> tests to verify the system. Very easy to get some small detail wrong. >> However, when you get them right - magic occurs. We get 100 kbit/s over >> 100km using Wenet, on 50mW or so tx power, albeit on a perfect line of >> site path. >> >> -/- >> >> Tomas - can you pls raise a PR for this work with some >> software/scripts/notes on how to set it up? Can be your account or a PR >> against codec2 - your choice. Don't worry if it has some rough edges, >> we can work together to fix that. Then we can all start playing :-) >> >> Jeroen - I'd be interested to hear your thoughts and how your VHF packet >> mode can map to this work ... I'm a just "the physical layer guy" :-) >> >> Cheers, >> David >> >> On 28/5/20 10:49 pm, Tomas Härdin wrote: >>> Hi >>> >>> I've been experimenting with using the FSK modem to send IP traffic >>> over the air, using a program that creates a TUN device which modulates >>> packets sent to it and sends the resulting IQ stream to other programs. >>> There's also a demodulation part in it, which is where my question >>> comes in; >>> >>> In fsk_demod_core() in 2FSK mode, sd_bits are computed from the >>> difference in received power in the 0 and 1 frequency bins. I've been >>> reading Sklar's Digital Communications Fundamentals lately, and what is >>> most often used are log likelyhood ratios (LLRs) which derive from the >>> ratio between the received powers. Does anyone know why the current >>> implementation uses a subtraction instead of a division? >>> >>> Some results from my current tests using rpitx and an RTL-SDR RX: >>> 144.700 MHz, 64 kbps 2FSK -> packets detectable 300m away >>> 144.700 MHz, 256 bps 2FSK -> packets detectable 1500m away >>> >>> For the 256 bps test me and a friend were driving around with my car, >>> with the transmitter being on my balcony. The car has a Diamond VHF/UHF >>> monopole and the balcony has a 5/8 monopole. This test also made use of >>> soft bits in the decoder, after I changed fsk_demod_core() to output >>> power ratios instead of differences. The unique word is located in a >>> maximum likelyhood fashion, and the packet length is error corrected in >>> a "majority of three" kind of way. Its one's complement is also >>> transmitted, for checking. >>> >>> Here are decoded packet lengths and accompanying EbN0 estimates, when >>> sending 0-byte pings (28 B IP packet size), starting at just over 1500 >>> meters from the transmitter and ending up just outside my apartment: >>> >>> length= 3, EbN0=5.17 >>> length= 28, EbN0=4.67 >>> length= 28, EbN0=3.29 >>> length= 28, EbN0=2.09 >>> length= 28, EbN0=4.87 >>> length= 28, EbN0=4.65 >>> length= 28, EbN0=4.36 >>> length= 28, EbN0=3.68 >>> length= 28, EbN0=1.36 >>> length= 28, EbN0=0.43 >>> length=1038, EbN0=7.89 >>> length= 28, EbN0=5.13 >>> length= 28, EbN0=1.14 >>> length= 28, EbN0=11.28 >>> length= 28, EbN0=6.21 >>> length= 28, EbN0=17.00 >>> length= 28, EbN0=10.75 >>> length= 28, EbN0=9.12 >>> length= 28, EbN0=8.45 >>> length= 483, EbN0=3.62 >>> length= 28, EbN0=8.22 >>> length= 28, EbN0=5.39 >>> length= 28, EbN0=0.29 >>> length= 128, EbN0=5.99 >>> [snip] >>> length= 28, EbN0=12.93 >>> length= 28, EbN0=25.47 >>> length= 28, EbN0=26.93 >>> >>> /Tomas >>> > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
