Guys, Making LLRs by scaling SDs applies to BPSK and QPSK and assumes additive Gaussian noise. I can not see this will be the case for 2FSK - so it's good that the current code works, but I expect it's not optimum.
I haven't worked through all the code in fsk_demod_core, but note the comment /* TODO: Find a soft-decision mode that works for 4FSK */ Anyway, to tackle this we need to see the PDFs of 4FSK SDs (say near the decoder threshold region). Cheers, Bill > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freetel-codec2 digest..." > Today's Topics: > > 1. FSK modem LLRs (David Rowe) > 2. Re: FSK modem LLRs (Tomas H?rdin) > 3. Re: sd_bits in fsk_demod_core() are power difference instead > of power ratio or LLR? And some TUN/TAP experiment results > (Jeroen Vreeken) > > > > ---------- Forwarded message ---------- > From: David Rowe <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Sat, 30 May 2020 05:52:53 +0930 > Subject: [Freetel-codec2] FSK modem LLRs > 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 > > > > > > > > ---------- Forwarded message ---------- > From: "Tomas Härdin" <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Fri, 29 May 2020 23:34:02 +0200 > Subject: Re: [Freetel-codec2] FSK modem LLRs > Ohhh! The output SD's can't be used as-is but are part of a larger > system. That makes a whole lot more sense. So if I understand this > right they're used to form a vector in n-dimensional space? And then > normalized to be in relation to an n-sphere with a radius on the order > of the variant of the n SD's.. > > The way I'm determining lost bits is by printing the footer of each > packet that has the expected length. The resulting shifts are > noticeable by eye. I tossed away the buffer I had an example in. I can > recreate it when I get back to my apartment. I'll try to record an IQ > file. > > I was out doing some work and I have to sleep soon, hopefully I should > get the code in order tomorrow. I spent some time today getting a > README done. > > /Tomas > > lör 2020-05-30 klockan 05:52 +0930 skrev David Rowe: > > 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 > > > > > > > ---------- Forwarded message ---------- > From: Jeroen Vreeken <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Sat, 30 May 2020 12:23:57 +0200 > Subject: Re: [Freetel-codec2] sd_bits in fsk_demod_core() are power > difference instead of power ratio or LLR? And some TUN/TAP experiment > results > > On 05/29/2020 12:06 AM, David Rowe wrote: > > Hi Tomas, > > 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" :-) > > > > Actually it is pretty close. On the API side it provides an ethernet > like layer so I use a TAP device instead of TUN. > So just one layer below, this is mainly done to have a place to store a > callsign as identification. > (By accident the first packets our repeater transmitted were ipv6 router > solicitations....) > > On the modem side it might map perfectly, or not.... > I don't know what Tomas used to create 'packets'. Traditional packet > systems use variable packet lenghts recognizable by some preample > (ethernet) or flags (ax.25). > The FreeDV modes all work on fix sized frames (which makes perfect sense > if you are transmitting fixed size codec frames) and the VHF packet mode > knows how to handle it. > It gets chunks of data (6 or 8 bytes per frame and a few control bits) > and re-assembles a packet if all frames are in. > It does know how to use different sized chunks though: 6 (800XA), 8 > (2400A/B) and in case of my own mode 6000 experiments 8 or 81. > > Basically it can be used on pretty much any thing that can provide a > bunch of demodulated bits (mode 800XA with only 56 bits is pushing it > though) at a time. It leaves the 'nasty' stuff like syncing, FEC to the > modem. It just has a CRC per packet to make sure a frame is intact. > > Regards, > Jeroen > > > > _______________________________________________ > 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
