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
