Re: [Discuss-gnuradio] Problem using benchmark_rx.py with XCVR2450 Transceivers

[Tom Rondeau]

On Wed, Sep 22, 2010 at 2:54 AM, Lebowski80 <address@hidden> wrote:
>
> Hello
>
> I'm trying to utilize benchmark_tx.py and benchmark_rx.py using 2 USRPs with
> XCVR2450 Transceivers. When I consider a bit rate equal or greater than 124k
> everything works well. With bit rates smaller than 124k only the
> ./benchmark_tx.py can run, while ./benchmark_rx.py can't receive any signal.
>
> Can someone tell me why?
>
> Thanks in advance!


The main problem is setting the interpolation and decimation rates in
the USRPs. Since they have limits on how low their sample rates can go
based on an upper bound of the interp/decim rates, that kind of limits
the bit rates you can use. This is somewhat gotten around by
increasing the number of samples per symbol in the
modulators/demodulators, but that's problematic for another reason. In
the current way of doing the digital demod, we use an M&M clock
recovery loop that doesn't like to work with large samples per symbol
(the parameters have to be hand-tuned...).

We've mostly fixed this issue in the newer code that will become the
default soon enough. If you are using the code from a git checkout,
look for the version 2 of the benchmark scripts. These run a different
receiver and the transmitter has an arbitrary resampler in it to
enable more sample rates. This _should_ perform better. I think I was
able to transmit and receive at something like 10 or 15 kbps.

Another thing to keep in mind is the frequency offset. When you're
bandwidth gets smaller, the frequency offsets in the two USRPs become
more problematic and maybe out of the bandwidth of the receiver and
frequency locking system. If you see that there is a large frequency
offset, you can try to manually tune the receiver to be closer to the
correct frequency. If that works, than you can try opening the
bandwidth of the receiver more to account for the large offset.

Tom