Problems and questions about the framesync64_example

[righthalfplane]

I tried the framesync64_example and everything worked Ok. So, I tired to actually use it to transmit some data. It says that it has a spectral efficiency of 0.8000 b/s/Hz which seems to mean with a 10,000 hz bandwidth - it should be able to send 9000 bits per second. It is not clear how the data should be packed for transmission - so I just interpolated the data to fill a 40,000 hz sample rate buffer and send it. This ran into some problems. I just started sending blocks of data - it filled up all of the send buffer blocks and then it started timing out and finally it crashed. I got the transmit to work by putting in some sleep statements after each data block transmission. On the receive end, about every ten blocks - it called the callback routine and it said about it had about a 50 percent error rate, but looking at the data it was nearly a 100 percent error rate. It is also very strange that as I lower the sample rate - the actual bandwidth of the signal increased. I also tried encoding the data as a FM signal and that did not works. So, That is what I tried - what should I really be doing ?

[jgaeddert]

Interesting. What is your sample rate? 10 kHz? It should be the same on the transmitter and receiver.

[righthalfplane]

It turns out that 10 KHZ was the last sample rate that I tried, but if I look at the frequency spectrum it is about 20 KHZ wide. The signal is pulsing and it pulses faster as I decrease the band width - that is what I think is increasing the spectrum bandwidth. I have never, before, seem a transmitted signal exceed the transmitted bandwidth ? If, I expand and decimate the data and do everything expect transmit and receive the data - it works. The only thing missing is when you receive a signal you normally mix it with the offset frequency to center it at zero frequency, but that does not seem to be necessary here. It seems that it could be a problem with needing to put the sleep step in to slow it down, but when I do the same thing with broadcast Narrow Band FM - the sound is perfectly OK. The sound is similar to other digital signals that I have heard.

[righthalfplane]

I just remembered that the Transmitter and the Receiver can only run at certain sample rates. I set the sample rates and enquired as to what they were and SoapySDR said everything was Ok, but when I tested it by sending and receiving data it actually was not working. The lowest common working sample rate is 250,000 samples per second - kind of inefficient but what the heck I gave it a try. Now, It is still almost a 100 percent error rate , but the call back routine is called for every block instead of every 10 blocks.

[righthalfplane]

I been play with it and I started to send the data in 1/10 of a second blocks. It gets any where from one to 40 of the 64 bytes correct. The problem may be that when it gets ten block of data - it calls the call back routine, but is there any guarantee that the ten blocks actually correspond to the same one second data block.

[righthalfplane]

I found part of the problem - I use msresamp_crcf_execute to expand and decimate the data. I tested the expansion and decimation of the data with out transmitting it. After the first pass thru msresamp_crcf_execute, the data is 100 percent correct. For subsequent passes thru msresamp_crcf_execute, there are always two or three errors in the decoded data. If I pass the data once thru msresamp_crcf_execute and send it many times it is always correct.

[jgaeddert]

What are the interpolation and decimation rates you're setting in msresamp?

[righthalfplane]

Normally when transmitting and receiving, you do it in two steps - to a intermediate frequency and then to the final frequency. In this case, no intermediate frequency was required so I did it in one step with ratios of 153.2 and 0.00656.

I ran some more test - it now works at 100 % when encoding and decoding on the same machine. On the receiving end I was doing a msresamp_crcf_create and msresamp_crcf_destroy for every block of data. Doing a msresamp_crcf_create only once got rid of the 2 or 3 byte errors per block. On the transmit end, I was doing a msresamp_crcf_create only once - so I decided to try it on the receive end and it worked. When I do the actual transmit and receive, It now gets as many as 60 of the 64 bytes correct, but it bounces around 50, 55, 40, 60, 0, 15, 10, 9, 20, ... It gets high numbers for awhile and then it gets low numbers for awhile.

[jgaeddert]

It's hard to debug your issue from here, but I can suggest a few things. To begin with, the sample rates must be exact to within a fairly small margin. The numbers you gave for resampling ratios were close to matching but weren't exact. In fact, 153.2 * 0.00656 = 1.005. This means that at the receiver if you start on time, after just 100 symbols you'll be off by half a symbol.

I might suggest that you start with an interpolation rate of exactly 100 and a decimation rate of exactly 0.01.

[righthalfplane]

I was actually using 152.439024390 and 0.00656 and I have tried many different combinations. It works down to a bandwidth of 1000 Hz. At 500 hertz, It starts generating errors with the one machine test. If I do every thing except transmit on the same machine using the HackRF One, it works. It appears that the 20 PPM accuracy of the HackRF One just is not good enough for your algorithm. The SDRplay RSP2 receiver has a 1 PPM accuracy.

[jgaeddert]

Yeah, that's a very low sampling rate. The frame64 length is 1440 samples, so at 500 Hz that's almost 3 seconds per packet, if I understand correctly. The algorithm for carrier recovery assumes a constant frequency offset over the duration of the packet. I'm guessing that if the frequency is non-linear (e.g. it is drifting due to the oscillator's PLL bandwidth) then it might not be able to recover the payload. At a sample rate of 1000 Hz the oscillator is probably not drifting as much over the shorter packet duration.

[jgaeddert]

Any more luck with this?

[righthalfplane]

Actually, I think that I just found a bug in msresamp_crcf_execute that may play into this.

I used msresamp_crcf_execute to cut the sample rate in half. I wanted to double the distance between the lines in the waterfall. The bottom is the original image. The top is the down sampled image. If you look at the top image and compare it to the bottom image everything below 7.060 MHZ looks pretty good. If you look just above 7.060 MHZ in the origin image there are very few lines, but the top image shows quite a few lines. Those extra lines correspond to the region in the original image just below where the top image ends. It seems to be mapping the wrong region to the region above 7.060 MHZ.

This would like cause problems for the framesync64_example.

writeIQfile.c.zip

[righthalfplane]

Where are the two plotted to the same scale. They are in almost perfect agreement until 7.010 Mhz.

I shifted the center frequency to make things easier to see.

[jgaeddert]

Is this the exact same input just one with and the other without the msresamp? I'm honestly having a hard time determining what the problem is.