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

We have now extended our tests to the tests with two USRP2s with
daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
receiving any packets. We checked the spectrum and tuned the gains as
well.
(OFDM)

Now, we played with the benchmark files and tunnel.py located in the
narrowband folder and therefore changed the modulation scheme from BPSK
to
GMSK and ultimately receiving all the packets!! That’s strange.

Does anybody knows what code be the problem that we can’t establish any
connection using higher order modulation schemes? Could it possibly be
our
slightly outdated UHD version?

We are totally clueless, so we appreciate any idea/help!
Am 25.01.2012 18:02 schrieb [email protected]:

On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:

connection using higher order modulation schemes? Could it possibly be our
slightly outdated UHD version?

We are totally clueless, so we appreciate any idea/help!

This won’t really help, but I remember we had exactly the same troubles
here.
This was before UHD was even released, so I doubt that’s the reason.
Unfortunately, I can’t remember how (or: if) we fixed it :frowning: but I’ll
keep you updated if my memory comes up with something.

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?).

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Mon, Jan 30, 2012 at 11:12 AM, Martin B. [email protected]
wrote:

ultimately receiving all the packets!! That’s strange.
This was before UHD was even released, so I doubt that’s the reason.
Unfortunately, I can’t remember how (or: if) we fixed it :frowning: but I’ll
keep you updated if my memory comes up with something.

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?).

MB

The benchmark OFDM scripts were made as simple examples of OFDM and were
not made very robust. I can get them working within an office space
fairly
easily, but I seem to be the only one. When I moved everything over the
using the UHD interface, I tested everything OTA successfully, so they
do
still work.

One thing that I noticed was that the --tx-amp=0.8. That’s very high for
OFDM with it’s large PAPR. Try backing off on that (to around 0.2 - 0.3)
and try again. You won’t get much range from this signal, though.

Tom

One thing that I noticed was that the --tx-amp=0.8. That’s very high for
OFDM with it’s large PAPR.

I’m thinking that too, there really should be some kind of warning when
you
drive the DAC to saturation.

If you need more range use an external amp.

On 31/01/12 08:37 AM, Andrew D. wrote:

One thing that I noticed was that the --tx-amp=0.8. That’s very high
for OFDM with it’s large PAPR.

I’m thinking that too, there really should be some kind of warning
when you drive the DAC to saturation.
It’s not the DAC that’s typically the problem, it’s the final RF
amplifier on the daughter-card, and
that’s not precisely predictable from the software side.

That’s kinda odd now that I think about it, I had a similar problem and
on
an oscilloscope it looked like DAC clipping, but I could have been
non-linearity in the final amp, what kind of problems do XCVR2450 have
at
high outputs?

On 01/31/2012 08:21 PM, Andrew D. wrote:

That’s kinda odd now that I think about it, I had a similar problem
and on an oscilloscope it looked like DAC clipping, but I could have
been non-linearity in the final amp, what kind of problems do
XCVR2450 have at high outputs?

All amplifiers will have non-linear operating regions up near their
maximum output power. Clipping in the DAC shouldn’t be approached until
the signal magnitudes approach +/- 1.0.

I don’t believe the XCVR2450 is special in this regard.

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