Re: Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

But fiddling with gain values is often useful; even if you’ve already
done that I recommend trying again, by reducing tx-amplitude and the
actual gain values, shifting the terminals around (perhaps they’re too
close?).

We have now found out that we need a sampling rate of at least 2Msps
which means we have to set the bandwidth to at least 2MHz (I read sth
about that the USRPs have problems with higher decimation rates):

./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M
./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M

The OFDM (bpsk) example is now working and all packets seems to be
transmitted. Unfortunately, not all of the packets could be
demodulated correctly as they are marked as “ok: False” - lets say a
quarter of them. This would yield a really bad performance in terms of
a reliable transmission. We also played around with the distance and
the alignment of the omni antennas but ultimately, we could not get
rid of the false packets.

Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?

On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach <
[email protected]> wrote:

./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M
Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?

There is not channel coding on the packets. A packet of 1500 bytes is is
12000 bits. If a single bit is incorrect, the CRC check will fail and
the
packet is marked as bad.

You’ll have to take the OFDM basic examples and extend them with error
correcting codes to get anything like reliable performance from it.

Tom

On 31/01/12 08:28 AM, Florian Schlembach wrote:

./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M
Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?


Frequency offset is the usual cause of such problems.

The master oscillators on a USRP vary between about 10PPM and 20PPM,
which at higher frequencies
means on offset of several kHz. A narrow-band signal suffers much
more from frequency offset issues
that a wideband one–the frequency error constitutes a larger fraction
of the overall signal.

Frequency offset errors are normal in any radio communications
system–since master oscillator frequencies
are never perfect. Real-world systems typically have an FLL or AFT
somewhere in the receive
chain to compensate.

This is why the last IF filter on a narrowband FM receiver is usually
wider than would be suggested by
the modulation bandwidth, and why there’s usually some kind of AFT
feedback.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs