Re: [Discuss-gnuradio] USRP: is performance degradation of PSK OK?

[Alick Zhao]

On Tue, 24 Apr 2012 07:52:09 -0700, Nick Foster wrote:

> On Tue, Apr 24, 2012 at 5:13 AM, Alick Zhao <address@hidden> wrote:
> 
>> Hi list,
>>
>> I am experimenting with narrowband benchmark_tx/rx in real indoor air
>> interface. The software is GNU Radio 3.5.3.2 and the hardware available
>> is USRP with RFX2400 daughter boards.
>>
>> When I use gmsk modulation to transmit and receive, the performance is
>> quite good - very few packets are lost or received wrongly. However,
>> with dbpsk, I find the performance is quite degraded. I have not seen
>> better results than the case with (ok, rx, total) is about (407, 470,
>> 666), which means no more than 2/3 of the packets can be received.
>> Besides, I got some OOO in the receiver side and this tell me overrun
>> happens. This is also not the case with gmsk. The current bitrate is
>> 125kHz and samples per symbol is set to 2, and I find this results in
>> the lowest sample rate for USRP. So it is impossible to lower down the
>> sample rate :(
>>
>> Is the performance degradation with psk normal? Does anyone experience
>> the same issue? Can it be improved in some way? One labmate told me that
>> he once worked with GNU Radio 3.2 and the same hardware but he didn't
>> see such performance with psk. So is the new UHD interface/driver
>> related?
>>
> 
> Alick,
> 
> You will have to instrument your flowgraph in order to find out. Add file
> sinks to different stages in the transmitter and receiver to verify that
> the data looks as expected. You can use MATLAB or Octave to visualize the
> data. There are scripts in gnuradio-core/src/utils which will aid you in
> loading sample data into MATLAB. Verify that the frequency offset is within
> bounds and being handled appropriately. Verify that clock recovery is
> keeping a lock on the incoming data.
> 
> --n

Thanks Nick for your guidance, but I am not sure how much offset in
freq/timing is within bounds. Could you give some empirical value or
something?

I now add some code into benchmark_rx.py to make it output freq
offset, timing offset just as digital_bert_rx.py does. Here is a snip of
the output of one run with tx freq 2.4400065G, rx freq 2.44G, dbpsk
mod/demod, two USRPs ~3m apart. (I attach the full log if it helps.)

H: 0.17e(j6.39deg)  Freq. Offset:    82 Hz  Timing Offset:    26936.2 ppm
H: 0.20e(j-15.52deg)  Freq. Offset:    56 Hz  Timing Offset:    32088.3 ppm
H: 0.21e(j-73.59deg)  Freq. Offset:   108 Hz  Timing Offset:   -12522.0 ppm
H: 0.22e(j62.82deg)  Freq. Offset:   117 Hz  Timing Offset:   -57538.1 ppm
H: 0.22e(j62.82deg)  Freq. Offset:   -18 Hz  Timing Offset:   -24022.2 ppm
H: 0.22e(j-41.16deg)  Freq. Offset:  -289 Hz  Timing Offset:    28046.4 ppm
H: 0.14e(j44.06deg)  Freq. Offset:  -278 Hz  Timing Offset:    62429.5 ppm
H: 0.14e(j44.06deg)  Freq. Offset:   -52 Hz  Timing Offset:     6915.0 ppm
H: 0.20e(j-15.17deg)  Freq. Offset:   -23 Hz  Timing Offset:   -11427.6 ppm

You can see that the freq offsets are mostly less than some hundred Hz,
and timing offsets are mostly at 10^5 ppm. Also the signs of offsets
look random. Is this OK or not? The packet number of (ok, rx, total) is
(230, 338, 666) in this run.

PS: The H is the estimated channel (I hope it will be). It won't make
sense if the freq/timing is not locked.

alick

rx_chn_est.log
Description: Text Data