USRP B210 BPS modulation and demodulation BER problem

[aster_yeyo]

Hello all,

I have USRP B210 and I am using it with Labview. I am simulating niUSRP EX PSK Tx/Rx.vi examples. I have also used MT Calculate BER.vi block to calculate BER of PN sequences. I am using BPSK and using 6 samples per symbol. The problem is that my BER output is switching 1 and 0 when the reset switch is True. I think it should be 0 or close to zero. it is showing zero but I dont know why it is showing 1 sometimes.

Another problem is that if use 8 samples per symbol BER is always 1.

I also want an example program for detecting PN sequence on Rx side, I am using cross correlation  technique but I am not getting the correct results.

Thank you.

[Case_in_Point]

Hi aster,

First, I saw where you have a duplicate post in the USRP forum, which is definitely going to be a better place. Off the top of my head, if you're getting a BER output of 1 then it probably means you aren't actually finding your trigger. If it only happens when Reset is true, then you should check the Trigger Found output as well. I'd guess you're getting the synchronization in the beginning but not reliably every time, and all your 1.0 outputs are the times when it didn't. If you're changing your sample/symbol and then your BER starts failing every time, there's something up with your synch parameters. 

It still makes much more sense to have this discussion on the USRP board, though,

Regards,

Cason

NI Applications Engr.

[aster_yeyo]

Thank you so much for your reply. 

The problem is that I am getting BER =0/1/0/1..... I think it is because it calculates the BER after it detects the trigger. So until it detects the trigger it shows BER=1. I think it is like that but I am not sure. If you have any idea how to solve this issue then please do share it here. it also happens when I cross-correlate received PN sequence with local PN sequence. The output of correlation shows peak/nopeak/peak/nopeak.... like that

I have attached a file of cross correlation of PN sequence. I just want to confirm that is this the correct way to check correlation? and I should see the same output like this when I use this technique in my main USRP Rx code to detect correlation?

[Case_in_Point]

Hi aster,

What do you mean by BER = 0/1/0...? Are you talking about successive runs, so every other run comes back with BER=1? Or are you somehow getting multiple BER results per data set? Are you sending the same sequence on every run, or is it a changing packet? It's at least exactly right that if the algorithm doesn't detect a trigger you'll get a BER of 1 every time. Have you looked at your raw data for each run to make sure you're transmitting what you think you are? For that matter, are you actually transmitting data, is this in loopback, or is this all in software?

For the cross-correlation question, are you again saying that in one run you get a properly correlated result, and in the next you get a flat line? Could you post some screenshots of your correlation results? If you're expecting the received and local PN sequence to be identical but your correlation is wrong, then the sequences must be different.

Regards,

Cason

NI Applications Engr.

[aster_yeyo]

I am sending the PN sequence in a loop (niUSRP EX PSK Tx example). I am sure that it sending the sequence again and again. After sending 1st time it again sends the same sequence.

Yes I am getting the trigger found thats why it showing 0. I think that the problem is it shows BER = 1 after previous trigger found and before current trigger found. So I want to correct this problem. 

I have attached a video in this email. You can open it with windows media player. Have a look of receiver side.

I am cross correlating the same sequence on the reciever side. I dont know if this correlation is correct or not. I think the same problem occurs here. when transmitter sends the sequence again the output of cross correlation resets. You can easily see that in the video.

[aster_yeyo]

open chrome or any other browser then press ctrl+o to open this video file on browser

Please send me your email address so that i can send you the video. Video is unable to attach here

[Case_in_Point]

I'd rather not post up an email address, partly because if we go that route then nobody else can see your info and take part in the discussion. Can you put it in a zip or host it somewhere publically viewable? 

Just to be clear, if you have Reset set to True, then the Calculate BER VI is going to completely disregard anything about previous sequences. Literally all of the data that comes from previous iterations is specifically neglected if Reset is True. There's also no real thing the Calculate BER VI's going to do "after the previous trigger and before the current trigger." It tries to find a trigger, and if all the logic comes back OK then it calculates the BER. Then on the next call, with reset True, it's going to throw out all the bitstream from the last call and start over with just what you send into it the second time.

You should probe the input bitstream going to Calculate BER and see if it ever changes at all. Since you're sending the exact same data every time, it should be really easy to make sure that the same thing is going into that block every iteration as well. 

Cason

NI Applications Engr.

[aster_yeyo]

BER =1 when the calculate BER  do not find any trigger. As you can see in the video. if the Reset is False it shows BER=0.45 bla bla. and also accmulated BER changes. I think for my case Reset should be True because I want to track the BER (I am taking values at multipe locations).

[Case_in_Point]

I reproduced this behavior on a USRP here, with two separate VIs for the Tx and Rx. I think the problem is that there isn't any synchronization between the two sides. When I have Reset on False, for instance, I always have my accumulated BER converge to 0.5, or 50%, which means it's just completely random. Furthermore, when I turn up the # of samples per symbol I stop getting any triggers at all, which makes sense if the triggers found with the lower sample/symbol count were erroneous triggers due to noise.

I believe, in order for the Calculate BER to actually be used, you need to implement sync and guard bits in your packets. Since the two sides aren't synchronized at all, when you have Reset on True, you're just randomly seeing the Rx side sometime synch up and then desync again. Thus you get alternating values of 0 and 1. When it happens to line up, you get a BER of 0, but much of the time it's not lining up at all and there's no trigger. If I turn Samples/symbol up to 16, though, I never get a trigger on my end. Since increasing the samples per symbol stops the trigger from ever being found, we can be confident it wasn't ever a real or good trigger in the first place.