# Re: Running tunnel.py/benchmark\_tx.py (OFDM) with XCVR2450? **URL:** \ **Category:** GNU Radio\ **Created:** [January 31, 2012, 2:29pm UTC](https://www.ruby-forum.com/t/re-running-tunnel-py-benchmark-tx-py-ofdm-with-xcvr2450/216272 "2012-01-31T14:29:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [January 31, 2012, 2:29pm UTC](https://www.ruby-forum.com/t/re-running-tunnel-py-benchmark-tx-py-ofdm-with-xcvr2450/216272/1 "2012-01-31T14:29:38Z")
> 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? ---
**Author:** ![Florian\_Schlembach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecae2f/32.png) [@Florian\_Schlembach](https://www.ruby-forum.com/u/Florian_Schlembach)\ **Post date:** [January 31, 2012, 2:32pm UTC](https://www.ruby-forum.com/t/re-running-tunnel-py-benchmark-tx-py-ofdm-with-xcvr2450/216272/2 "2012-01-31T14:32:44Z")
On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 ---
**Author:** ![Florian\_Schlembach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecae2f/32.png) [@Florian\_Schlembach](https://www.ruby-forum.com/u/Florian_Schlembach)\ **Post date:** [January 31, 2012, 2:50pm UTC](https://www.ruby-forum.com/t/re-running-tunnel-py-benchmark-tx-py-ofdm-with-xcvr2450/216272/3 "2012-01-31T14:50:40Z")
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 > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.