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 _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
