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
On Tue, Apr 24, 2012 at 5:13 AM, Alick Z. [email protected] wrote:
666), which means no more than 2/3 of the packets can be received.
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
On Tue, 24 Apr 2012 07:52:09 -0700, Nick F. wrote:
with dbpsk, I find the performance is quite degraded. I have not seen
he once worked with GNU Radio 3.2 and the same hardware but he didn’t
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
On Wed, 25 Apr 2012 12:01:33 +0800, Alick Z. wrote:
bounds and being handled appropriately. Verify that clock recovery is
keeping a lock on the incoming data.
–n
I also make some plots with the logged data. I can see that consecutive
1000 points of data after freq_recov or time_recov are distributed
around the unit circle. I think the freq/time recovery may not work
well. Given static indoor environment, the coherence time should be
long. I’d expect that the constellation points after timing recovery
should stay around two certain points for some thousands of samples. Is
it so?
If the problem is with the recovery loop, I wonder how I can adjust the
parameters of the loop. I have read Tom’s post about loop gain
values[1]. It seems that damping factor (0.707) should not be changed,
and loop bw is somewhere around pi/100 to 2*pi/100. So I find little
change can be done.
By plotting data directly output by usrp source I find that the
constellation points are disperse too. But I think it is due to lack of
synchronization between tx/rx. Am I wrong about this?
[1] Control Loop Gain Values — Rondeau Research
–
alick
Fedora 16 (Verne) user
https://fedoraproject.org/wiki/User:Alick
