bladeRF loopback PSK testing/pulse shaping

Having issues with the site, hardware, source code, or any other issues?
Post Reply
Noble713
Posts: 5
Joined: Tue Jul 15, 2014 4:53 am

bladeRF loopback PSK testing/pulse shaping

Post by Noble713 »

Ok, I've taken a look at these two threads as well:

https://nuand.com/forums/viewtopic.php?f=9&t=3497
https://nuand.com/forums/viewtopic.php?f=4&t=3802

I modified the flowgraph that jynk posted and I've already solved a few of my problems. I'm running the latest development versions of GNURadio (3.7.10), gr-osmosdr, and bladeRF-cli, all compiled from source. I've done the automatic DC/IQ calibrations. I've attached the two flowgraphs I'm using: one closely based on jynk's original WX GUI graph, and another with additional blocks based on the GNURadio PSK Recovery tutorial that uses QT GUI.

Code: Select all

  bladeRF-cli version:        1.3.1-git-35802e3
  libbladeRF version:         1.5.1-git-35802e3

  Firmware version:           1.9.0
  FPGA version:               0.5.0

My current testing is for BPSK signals in a 50kHz bandwidth. I know (now) that the bladeRF's minimum bandwidth is 1.5MHz, and adjusted my sample rates and samples/symbol up accordingly. I've also been using gr_filter_design to help get the pulse shape roughly within 50kHz (why? explained below).

Here are my outstanding issues/questions:

1. I understand that since I'm using the RF_LNA1 loopback mode the received samples != tx samples. However, the power is dropping from -10dB to -50dB, and the constellation is either a unit circle or only around ONE of the two constellation points. Is this normal? What are the best ways to correct these two problems, given my setup?

2. Why is the received signal so "peaky"? There is no flat "passband" shape like the transmitted signal at all.

3. Are there other methods for narrowing my pulse shape (on the Tx side) to get it closer to 50kHz bandwidth besides constantly fiddling with the sample rate/symbol rate/roll-off factor?

Why 50kHz:
I'm building a frequency-hopping spread spectrum system. The intention is to use 25MHz of total bandwidth with 500 x 50kHz sub-channels. A little bit of spillover/noise is tolerable but I don't want the signals bleeding across 2-3 adjacent channels if I can avoid it. Then I'll use a variety of DSP blocks to filter out the 25MHz bandwidth and downsample just the particular 50kHz channel that I'm interested in during a particular hop...

Thanks for any assistance.
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: bladeRF loopback PSK testing/pulse shaping

Post by bpadalino »

I am going to try to answer your questions, but I am not sure I quite understand some of the issues.

1. In the graphs I see attached, there's a lot of stuff going on with the Constellation Sink, Costas Loop and CMA Equalizer. I recommend taking out the device and just running as a high SNR simulation first. When running the simulation and taking the device out of the loop, the graph doesn't seem to really get 2 nice points and instead are 2 clouds. Something is weird with the configuration of the loop bandwidth of the equalizer I believe.

2. When you use BPSK, you are really only changing the I component of the signal and keeping the Q component at 0, so you get an alphabet of [1+0j, -1+0j]. When you transition between them, you will pass through 0+0j, so this peakiness is expected with BPSK.

3. I'd stick with the RRC filtering. Other forms of pulse shaping come with lots of ISI and are harder to receive. Your OBW should be able to be estimated pretty well with the excess bandwidth and sample rate.

How much rejection do you want in your adjacent channel, and what are you considering your channel size? Do you want complete rejection by +/-25kHz from your center frequency?

Sorry if this wasn't too helpful.
Noble713
Posts: 5
Joined: Tue Jul 15, 2014 4:53 am

Re: bladeRF loopback PSK testing/pulse shaping

Post by Noble713 »

bpadalino wrote:I am going to try to answer your questions, but I am not sure I quite understand some of the issues.

1. In the graphs I see attached, there's a lot of stuff going on with the Constellation Sink, Costas Loop and CMA Equalizer. I recommend taking out the device and just running as a high SNR simulation first. When running the simulation and taking the device out of the loop, the graph doesn't seem to really get 2 nice points and instead are 2 clouds. Something is weird with the configuration of the loop bandwidth of the equalizer I believe.

2. When you use BPSK, you are really only changing the I component of the signal and keeping the Q component at 0, so you get an alphabet of [1+0j, -1+0j]. When you transition between them, you will pass through 0+0j, so this peakiness is expected with BPSK.

3. I'd stick with the RRC filtering. Other forms of pulse shaping come with lots of ISI and are harder to receive. Your OBW should be able to be estimated pretty well with the excess bandwidth and sample rate.

How much rejection do you want in your adjacent channel, and what are you considering your channel size? Do you want complete rejection by +/-25kHz from your center frequency?

Sorry if this wasn't too helpful.
Actually, this does help. Some of these were solutions I found in parallel to your own efforts. ^_^ Especially testing without the radio, and just a simulated channel. That's a good point about the transition between the symbols, I didn't consider how that would affect the spectrum/peakiness. I ran some more tests and started picking apart every variable/setting....and my eyes drifted to the gain on the CMA Equalizer. All of the PSK examples/tuts I had with a CMA Equalizer had a gain setting of 1.0. but I knew turning down the gain in other blocks often had serious effects on the received constellation so I dropped it to 0.1.....viola....much clearer constellation with low noise at the 2 points. But this is what drives me nuts about GNU Radio and the state of my knowledge of DSP...I have no idea WHY certain settings cause certain effects like this that seem to contradict the tutorials.

This message on the mailing list helped: https://lists.gnu.org/archive/html/disc ... 00062.html

But IMO stuff like "Hey this variable should be a small positive number between 0 and 1....determine experimentally" should be in the documentation directly.

Re: channel width and rejection. I could actually relax any rejection requirements. Due to the frequency hopping, and the absence of overlapping networks/hopsets in my current simulations, interference on adjacent channels is unlikely at this stage.

Attached an updated GRC flowgraph.
Post Reply