[Discuss-gnuradio] usrp_* gains on Mac OS X fixed

[Jonathan Jacky]

On Fri, 23 Dec 2005, Eric Blossom wrote:

> There is a usrp_bytesex.h include file which includes
> fast implemenations of host_to_usrp_short and usrp_to_host_short.
>
> The fix probably ought to go in
> usrp1_sink_{c,s}::copy_to_usrp_buffer
> and in usrp1_source_{c,s}::copy_from_usrp_buffer.

This fix works.  See the PS below for diffs of the code, and the
PPS for details on the gains before and after the fix.

I only fixed the _c versions, not the _s versions.  I'm not sure
what program I could use to test whether the _s versions were working
properly.  Doesn't the USRP always process complex inputs and outputs?

I only fixed the s16 case in usrp1_source_c.cc, not the s8 case.
Could the s8 case be fixed just by reversing the order of the 2*i+0 and
2*i+1 arguments?  What program tests this?

> The AC_C_BIGENDDIAN test will need to be added to configure.ac to
> define the stuff that the usrp_bytesex.h include needs to work
> properly.

I have not yet begun to deal with this.  As you can see from the
diffs, I just hard-coded #define WORDS_BIGENDIAN 1 into both source
files, right before #include <usrp_bytesex.h>.  I understand this is
not a general solution - it is just the most expedient way I could
think of, to check that swapping the bytes here would solve the gain
problem.

Eric, would you prefer to take it from here, or shall I revise the _s
files also and make an attempt at revising configure.ac etc.?

Incidentally, it appears this byte swapping is already handled
properly in the usrp module.  I find that AC_C_BIGENDIAN already
appears in my usrp/configure.ac, #define WORDS_BIGENDIAN 1
already appears in my usrp/config.h and configure, and 
#define <usrp_bytesex.h> already already appears in several programs 
in usrp/host/apps, including usrp_test_usrp_standard_{tx,rx}.

Jon Jacky

PS - here are the diffs, as reported by cvs diff

diff -r1.5 usrp1_sink_c.cc
30a31,33
> #define WORDS_BIGENDIAN 1 // so usrp_bytesex does the right thing
> #include <usrp_bytesex.h>
84,85c87,88
<     dst[2*i + 0] = (short) real (in[i]);      // FIXME saturate?
<     dst[2*i + 1] = (short) imag (in[i]);      // FIXME saturate?
---
>     dst[2*i + 0] = host_to_usrp_short((short) real (in[i])); // FIXME saturate?
>     dst[2*i + 1] = host_to_usrp_short((short) imag (in[i])); // FIXME saturate?

diff -r1.6 usrp1_source_c.cc
30a31,33
> #define WORDS_BIGENDIAN 1 // so usrp_bytesex does the right thing
> #include <usrp_bytesex.h>
104c107,108
<       out[i] = gr_complex ((float) s16[2*i+0], (float) s16[2*i+1]);
---
>       out[i] = gr_complex ((float) usrp_to_host_short(s16[2*i+0]),
>                            (float) usrp_to_host_short(s16[2*i+1]));


PPS - Here are details on gains before and after the fix

When usrp_siggen.py is built with the new usrp1_sink_c.cc that calls
host_to_usrp_short, the gain on OS X is the same as on Linux.  For example,
 ./usrp_siggen.py -i256 -f15e3
with no -a switch results in about 125 mV pp sine wave output on TX-A
(connected to a high-impedance scope input), the same amplitude as
with -a16000.  On OS X without the fix, the output with no -a switch is a
complicated modulated waveform, and -a75 produces a 125 mV sine wave.

When usrp_oscope is built on OS X with the new usrp1_source_c.cc that
calls usrp_to_host_short, the gain is the same as on Linux: a 22 mV pp
input signal on RX-A results in a scope trace that ranges over -/+ 120
counts.  Without the fix, the same input signal ranges over -/+ 30000,
and larger inputs cause the scope trace to wrap around.  The largest
signal my signal generator will put into RX-A without distorting is
about 500 mV pp, this results in about -/+ 2500 counts on the scope
trace (in the fixed code).