Forum: GNU Radio Interpretting results from usrp_rx_cfile.py

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bahn William L Civ USAFA/DFCS (Guest)
on 2007-01-18 01:39
(Received via mailing list)
I have a function generator outputting a sine wave into the RX-B
connector of the BasicRX board connected to the RX-B side of a USRP. I
am trying to capture the waveform and store it to a file.

Here are the commands I tried:

# ./usrp_rx_cfile.py -R B -d 256 -f 1000 sine_1k1.dat
# ./usrp_rx_cfile.py -R B -d 256 -f 10000 sine_1k10.dat
# ./usrp_rx_cfile.py -R B -d 256 -f 15000 sine_10k15.dat

The function generator was producing a 1kHz sine wave for the first two
and a 10kHz sine wave for the third.

Each time I captured a few seconds worth of data. I then took the data
files and extracted two streams of single precision floats for each of
the first ten thousand 8-byte groups in the file and plotted them. The
results were very similar regardless of the frequency specified on the
command line (and I have no idea what that frequency is for) or the
actual frequency of the signal that was applied to the inputs.

What I got in all cases was basically a flat line (-3 to +3) except for
in the vicinity of sample #530, which looks like an inverted sinc pulse
with a peak amplitude of about -10000 (the first stream, which is made
up of the first float value in each sample pair), and what looks like an
extremely heavily damped sine wave (the second stream) with a peak
amplitude of about 20,000 and roughly centered at the same place as the
sinc pulse.

This makes absolutely no sense to be whatsoever. Can anyone shed any
light on this?

Thanks
Eric B. (Guest)
on 2007-01-18 01:42
(Received via mailing list)
On Wed, Jan 17, 2007 at 04:37:58PM -0700, Bahn William L Civ USAFA/DFCS
wrote:
> The function generator was producing a 1kHz sine wave for the first two
> in the vicinity of sample #530, which looks like an inverted sinc pulse
> with a peak amplitude of about -10000 (the first stream, which is made
> up of the first float value in each sample pair), and what looks like an
> extremely heavily damped sine wave (the second stream) with a peak
> amplitude of about 20,000 and roughly centered at the same place as the
> sinc pulse.
>
> This makes absolutely no sense to be whatsoever. Can anyone shed any
> light on this?
>
> Thanks

The Basic RX only passes signals > 100kHz.

Eric
L. Miguel Bazdresch Sierra (Guest)
on 2007-01-18 16:13
(Received via mailing list)
Bahn William L Civ USAFA/DFCS, el 01/17/07 17:37:
> What I got in all cases was basically a flat line (-3 to +3) except for
> in the vicinity of sample #530, which looks like an inverted sinc pulse
> with a peak amplitude of about -10000 (the first stream, which is made
> up of the first float value in each sample pair), and what looks like an
> extremely heavily damped sine wave (the second stream) with a peak
> amplitude of about 20,000 and roughly centered at the same place as the
> sinc pulse.
>
> This makes absolutely no sense to be whatsoever. Can anyone shed any
> light on this?

I can't, but I also see a similar spike:

http://lists.gnu.org/archive/html/discuss-gnuradio...

I haven't figured it out, but it seems to be harmless, in the sense that
I was
able to process my data without any apparent ill effects. I haven't had
a chance
to look into it beyond that.

--
Miguel Bazdresch Sierra
Lamar Owen (Guest)
on 2007-01-18 18:47
(Received via mailing list)
On Wednesday 17 January 2007 18:37, Bahn William L Civ USAFA/DFCS wrote:
> The function generator was producing a 1kHz sine wave for the first two
> and a 10kHz sine wave for the third.

> This makes absolutely no sense to be whatsoever. Can anyone shed any
> light on this?

The BasicRX lower frequency cutoff is around 100kHz; lower frequencies
don't
pass the input transformers.  You need an LFRX to go below 100kHz.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu
Bahn William L Civ USAFA/DFCS (Guest)
on 2007-01-19 18:50
(Received via mailing list)
// SIGNED //
William L. Bahn
Instructor of Computer Science
United States Air Force Academy
e-mail: removed_email_address@domain.invalid


> -----Original Message-----
> From: Eric B. [mailto:removed_email_address@domain.invalid]
> Sent: Wednesday, January 17, 2007 4:45 PM
> To: Bahn William L Civ USAFA/DFCS
> Cc: gnuradio mailing list
> Subject: Re: [Discuss-gnuradio] Interpretting results from
> usrp_rx_cfile.py
>
> On Wed, Jan 17, 2007 at 04:37:58PM -0700, Bahn William L Civ
USAFA/DFCS
> wrote:
> > I have a function generator outputting a sine wave into the RX-B
> > connector of the BasicRX board connected to the RX-B side of a USRP.
I
> > am trying to capture the waveform and store it to a file.
> >
> > Here are the commands I tried:
> >
> > # ./usrp_rx_cfile.py -R B -d 256 -f 1000 sine_1k1.dat
> > # ./usrp_rx_cfile.py -R B -d 256 -f 10000 sine_1k10.dat
> > # ./usrp_rx_cfile.py -R B -d 256 -f 15000 sine_10k15.dat
> >
> > The function generator was producing a 1kHz sine wave for the first
two
> > and a 10kHz sine wave for the third.
> >
> > Each time I captured a few seconds worth of data. I then took the
data
> > files and extracted two streams of single precision floats for each
of
> > the first ten thousand 8-byte groups in the file and plotted them.
The
> > results were very similar regardless of the frequency specified on
the
> > command line (and I have no idea what that frequency is for) or the
> > actual frequency of the signal that was applied to the inputs.
> >
> > What I got in all cases was basically a flat line (-3 to +3) except
for
> > in the vicinity of sample #530, which looks like an inverted sinc
pulse
> > with a peak amplitude of about -10000 (the first stream, which is
made
> > up of the first float value in each sample pair), and what looks
like an
> > extremely heavily damped sine wave (the second stream) with a peak
> > amplitude of about 20,000 and roughly centered at the same place as
the
> > sinc pulse.
> >
> > This makes absolutely no sense to be whatsoever. Can anyone shed any
> > light on this?
> >
> > Thanks
>
> The Basic RX only passes signals > 100kHz.
>

That helped quite a bit. When I raised the frequency to 200kHz and
looked at the data, I now saw related data in the captured file after
the large transient event. The data looked strange, but appeared to have
a quadrature-like pattern to it. So that suggested to me that the
frequency specified on the command line is the frequency for the
oscillator of a sin/cos mixer. Changing the frequency to zero then
produced a cosine waveform and a flatlined-waveform, which makes sense.

As for the spike at about sample 530, I am now of the opinion that this
is a switching transient as the board configures the hardware.

I only see data when the signal is applied to the RX-A input, not the
RX-B (here I am referring to the two inputs on the daughterboard, not
the daughterboard slots on the USRP. I am still trying to figure out how
to get data from the other input, but that is fairly low priority.
Martin D. (Guest)
on 2007-01-19 19:25
(Received via mailing list)
Bahn William L Civ USAFA/DFCS wrote:
>>From: Eric B. [mailto:removed_email_address@domain.invalid]
>>wrote:
>>># ./usrp_rx_cfile.py -R B -d 256 -f 1000 sine_1k1.dat
>
>>>results were very similar regardless of the frequency specified on
>>>in the vicinity of sample #530, which looks like an inverted sinc
>
>>>Thanks
> oscillator of a sin/cos mixer. Changing the frequency to zero then
> produced a cosine waveform and a flatlined-waveform, which makes sense.
>
> As for the spike at about sample 530, I am now of the opinion that this
> is a switching transient as the board configures the hardware.
>
> I only see data when the signal is applied to the RX-A input, not the
> RX-B (here I am referring to the two inputs on the daughterboard, not
> the daughterboard slots on the USRP. I am still trying to figure out how
> to get data from the other input, but that is fairly low priority.

This is determined by the rx_mux setting uf the usrp.
In most examples this is determined automatically using the parameter
you specify for rx_subdevice_spec with the -R parameter of the example.
(Note that most/all examples only use one ADC if you use the basic_RX)

A gives you channel A of daughterboard A
A:1 gives you channel B of daughterboard A
B gives you channel A of daughterboard B
B:1 gives you channel B of daughterboard B

The magic happens in the line:
self.u.set_mux(usrp.determine_rx_mux_value(self.u,
options.rx_subdev_spec))

It is also possible to use both ADCs as a complex (quadrature) input.
For this you have to determine the muxvalue yourself.

I use this peace of code to use the basic_RX as complex device (use both
ADCs as a quadrature input):
        self.side = options.rx_subdev_spec[0] #if RX_A 0, if RX_B 1
        if 0==self.side:
          self.rx_mux_value=0x00000010
        else:
          self.rx_mux_value=0x00000032
        self.u.set_mux(gru.hexint(self.rx_mux_value)) #set basix_RX as
complex device in stead of singlechannel

The documentation of usrp.set_mux(int muxvalue) (see
usrp/host/lib/usrp_standard.h and usrp/host/lib/usrp_basic.h ):
/*!
   * \brief Set input mux configuration.
   *
   * This determines which ADC (or constant zero) is connected to
   * each DDC input.  There are 4 DDCs.  Each has two inputs.
   *
   * <pre>
   * Mux value:
   *
   *    3                   2                   1
   *  1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
   * +-------+-------+-------+-------+-------+-------+-------+-------+
   * |   Q3  |   I3  |   Q2  |   I2  |   Q1  |   I1  |   Q0  |   I0  |
   * +-------+-------+-------+-------+-------+-------+-------+-------+
   *
   * Each 4-bit I field is either 0,1,2,3
   * Each 4-bit Q field is either 0,1,2,3 or 0xf (input is const zero)
   * All Q's must be 0xf or none of them may be 0xf
   * </pre>
   */
  bool set_mux  (int mux);


I hope this helps,

Martin
This topic is locked and can not be replied to.