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).
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
