Re: [Discuss-gnuradio] odd behavior on new ofdm_benchmark_* code

[Tom Rondeau]

Dev Ramudit wrote:
> Hello all,
>
>     Running the new ofdm benchmark code doesn't seem to be working 
> quite right. I only receive packets when I start the rx side while the 
> tx side is already running, and even then I receive:
>
> on one:
> $ python benchmark_ofdm_tx.py -f 907M
>
> on the other:
> $ python benchmark_ofdm_rx.py -f 907M
>
> ok: False        pktno: 69       n_rcvd: 1       n_right: 0
> ok: False        pktno: 79       n_rcvd: 2       n_right: 0
> ok: False        pktno: 83       n_rcvd: 3       n_right: 0
> ok: False        pktno: 97       n_rcvd: 4       n_right: 0
> ok: False        pktno: 111      n_rcvd: 5       n_right: 0
> etc...
>
> Restarting the tx side yields more received packets. However if the rx 
> side is ever started when the tx side is not running, nothing ever 
> gets received. Benchmark_loopback, the old benchmark_ofdm_* code and 
> the new and old digital benchmark_* programs all run perfectly with 
> these two computers/usrps. Any suggestions?
>
> Thanks,
> Dev Ramudit
Dev,

We're still working on this code. I don't have much time to work with 
two USRPs where I am right now, so I've only been working in the 
loopback case and not over the air. In loopback mode, things look good 
under various SNRs, frequency offsets, and multipath conditions. There 
is a problem with the reciever locking up under certain conditions 
because of the peak detector. In loopback, this is with a low SNR, so no 
signal would probably trigger this pretty quickly. We have a possible 
solution for this, but I don't know when I'll have time to work on it.

The other things to look at is the transmit power, decimation rate, and 
interpolation rates. Scale the power so you have enough signal strength 
at the receiver but not so much that you start clipping (remember the 
high peak to average power ratio in an OFDM signal). I think we found 
~2000 for --tx-amp was ok.

Tom