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
