FSK modulating then demodulating a signal don't give the same bit sequence

[franchenstein]

Hi,

I am trying to use the Modulation Toolkit FSK modulation/demodulation blocks for a project. I decided to learn how to use and configure them by doing a simple example, generating a random bit sequence, FSK-modulating it and then demodulating the waveform to obtain a received bit sequence. Just that, without any channel simulation that would include noise or interference.

I have taken a look at the USRP FSK example and tried to follow its steps, but doing in my own way, so it would be easier to integrate those blocks in my project.

The problem is that the recovered signal is completely different from the transmitted bit sequence. I get an average of 50% bit-error rate. As I'm not using any channel model, I guess I probably configured something wrong, but I'm not sure which parameter would cause such a big BER.

Attached to this message is my implementation.

Thanks in advance.

Edit: I included a correlation plot between the modulated and the recovered signal that show that both have a strong correlation, as can be seen from their shape. They have an overall identical shape, but with slightly different values (which can be seen in the Y values of the complex waveforms). This slight difference is enough to give a completely wrong bit sequence. I have updated the attachments.

[franchenstein]

I tried editing again, but the option is not showing up. Sorry for the double post.

I did some other changes, separating the magnitude and phase of the complex waveforms. It can be seen that the envelope is pretty constant, while the phase changes, which is expected from FSK. But it is possible to see that the recovered waveform has a transient and the correlation shows that there is a really weird correlation in the phases, which explains the incorrect received signals. But I'm not sure which parameter would lead to this result. 

[JÞB]

Make everything a default value after you run the vi and attach it again. 

[franchenstein]

When I try to use all default values, I get an error from the Generate Synchronization block, complaining that there are no sync bits (Error #-21804). But if I try to append even a simple 2-bit barker code to the key bit sequence and use that value as the sync bits parameter in that block, I get completely wrong results: a bit stream with a shorter length and always the same bit value for every bit. I then tried using a longer Barker sequence and I got a longer output bit stream, but- again- always with the same bit value.

So I guess I'm getting this sync bit part wrong, but I don't understand what exactly is wrong here.

I attached this simpler version, using a 7-bit barker sequence and doing some fiddling with the last bits, as I found out that sometimes, the last bits of the output sequence are the first ones of the input. But it always skips something like 4 to 6 bits of the original sequence.

[dbell0971]

Hi Franchenstein,

I think Jeff was saying that you should select "Make Current Value Default" for each of the controls on the front panel for your original "Test.vi".  Right now, we're unsure as to what you have set all of the modulation parameters to be.

Using the fsk_test.vi, I see what you are seeing: the output stream is shorter and has all of the same bits.  I haven't had a lot of time to look at this, I'll probably take a longer look at it tomorrow.  My first thought is that we could be having trouble with the number of samples per symbol; it looks like the number of samples per symbol and the number of bits per symbol are unspecified.  However, that may not be needed as we're not actually transmitting.  If you tinker around with these settings, does it change anything?

David B

National Instruments

Applications Engineer

[JÞB]

David, franchenstein,

One thing to bear in mind as you go though this is the IIR filters deep down in the guts of the MTK.  The tool kit appears to be designed for contineous operation and when the IIR filters are reset (to 0) there is a nasty impulse as the filter responds.  Putting the FSK Modulate vi in a for loop with an autoindexed array [T,F] wired to Reset is a dirty but effective way to avoid that spike.

[franchenstein]

David,

I tried making the number of samples per symbol a control and then tinkering with it. For low values, all results were wrong, all the time. But using values as 16 or higher the result is the same. Some times I get a 0 BER, missing some bits in the end and some times it's all 0's or all 1's. I have a feeling that with higher values, the number of bits lost at the end is smaller, but I don't have any statistics to prove that. And even with values as high as 64 or 128, There are still bits missing.

I also included the plots of magnitude and phase of the transmitted and recovered signals. I obsorved that sometimes the phase spectrum of the recovered signal is the transmitted phase spectrum multiplied by a linear phase. Still, in this case the final recovered bit stream is all 0's or all 1's, depending on the multiplied linear phase's slope.

Jeff,

I understand what you say about the impulse messing with the final results, but I'm not sure if I understood the quick fix you suggested. I tried including for loops around the FSK mod/demod blocks that looped 2 times. I created a boolean array [T,F] and autoindexed it to the Reset? terminal of those blocks. For all other inputs I disabled auto-indexing and for the outputs I chose to use the last value. I will attach this new version.

In the end, the result was not much better. Sometimes I noticed that the recovered phase seemed to be a delayed transmitted phase with what I assumed to be the end of the phase of the previous iteration. Still, the end result is that almost all the time, all I get is 0's or 1's.

[franchenstein]

Sorry for double posting again.

First of all, I have to correct myself. The recovered phase is not multiplied, but added to a linear phase response. When the recovered phase seems to be purely linear it is because the transmitted phase is so small in comparison to the phase response, but zooming in it is possible to still find the original phase in the recovered one.

So it probably has something to do with what Jeff said. Some filter in demodulator has a linear phase response that is deeply disturbing the recovered signal. Is there any configuration that can correct this or should I try to add another filter to compensate this effect?