Forum: GNU Radio Problem in using connect(gr.file_source, usrp.sink_s)

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.
0e0d6f914c8fbae32c55d9a71cbc20ce?d=identicon&s=25 Eliane Hook (Guest)
on 2007-07-11 21:24
(Received via mailing list)
Hi,

I am a newbie with GNURADIO and USRP. I am trying to capture data that
comes
thru the USB cable from the USRP board and transmit it back to the USRP
board. I was reading thru the email archives and I came across this:

To log data from the USRP: usrp.source_c -> gr.file_sink(complex)
To replay data to the USRP: gr.file_source(complex) -> usrp.sink_c

and some more information like use the usrp_rx_cfile.py to capture data
from
the USRP. I am facing a problem in implementing 'gr.file_source(complex)
->
usrp.sink_c'.

output.dat in the code is the binary file that I got from running
usrp_rx_cfile.py with option 's' and 'f'. I am using the usrp.source_s
and
usrp.sink_s instead of usrp.source_c and usrp.sink_c. The code
implementing
the above is:

============================================================
class my_graph(gr.flow_graph):

    def __init__(self):
        gr.flow_graph.__init__(self)

        usage="%prog: [options] output_filename"
        parser = OptionParser(option_class=eng_option, usage=usage)
        parser.add_option("-R", "--tx-subdev-spec", type="subdev",
default=(0, 0),
                          help="select USRP Tx side A or B (default=A)")
        parser.add_option("-i", "--interp", type="intx", default=16,
                          help="set fgpa interpolation rate to INTERP
[default=%default]")
        parser.add_option("-f", "--freq", type="eng_float",
default=None,
                          help="set frequency to FREQ", metavar="FREQ")
        parser.add_option("-g", "--gain", type="eng_float",
default=None,
                          help="set gain in dB (default is midpoint)")
        (options, args) = parser.parse_args ()

        if options.freq is None:
            parser.print_help()
            sys.stderr.write('You must specify the frequency with -f
FREQ\n');
            raise SystemExit, 1

        # build the graph
        self.u = usrp.sink_s(interp_rate=options.interp)
        self.dst = gr.file_source(gr.sizeof_short, 'output.dat')
        self.connect(self.dst, self.u)

        dac_rate= self.u.dac_rate();

        if options.tx_subdev_spec is None:
            options.tx_subdev_spec = usrp.pick_tx_subdevice(self.u)
        self.u.set_mux(usrp.determine_tx_mux_value(self.u,
options.tx_subdev_spec))

        # determine the daughterboard subdevice we're using
        self.subdev = usrp.selected_subdev(self.u,
options.tx_subdev_spec)
        print "Using TX d'board %s" % (self.subdev.side_and_name(),)

        if options.gain is None:
            # if no gain was specified, use the mid-point in dB
            g = self.subdev.gain_range()
            options.gain = float(g[0]+g[1])/2

        self.subdev.set_gain(options.gain)

        r = self.u.tune(0, self.subdev, options.freq)
        if not r:
            sys.stderr.write('Failed to set frequency\n')
            raise SystemExit, 1


if __name__ == '__main__':
    try:
        my_graph().run()
    except KeyboardInterrupt:
        pass
=================================================================================

and when I run it, I see the following:
../python/usrp# ./txIQ.py -f 2.4G
Using TX d'board A: Flex 2400 Tx MIMO B
../python/usrp#
../python/usrp#

The script runs for a second or two and stops immediately.

The email archives are very useful but still I am not able to implement
what
I want. Looking for some help. I really appreciate any help and thanks
for
the email responses in the archive.
-- Eliane
0e0d6f914c8fbae32c55d9a71cbc20ce?d=identicon&s=25 Eliane Hook (Guest)
on 2007-07-12 17:29
(Received via mailing list)
Howdy,

I can pls get some pointers as to where I can start debugging. Is there
something wrong in connecting the file_source to usrp_sink to transmit
the
16-bit I and Q data? I am sure to be missing something.

Sorry for resending an email for the same problem but I am stuck at this
point.
I really appreciate any kind of help. Thanks
-- Eliane
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-07-13 17:13
(Received via mailing list)
Eliane Hook wrote:

> I can pls get some pointers as to where I can start debugging. Is there
> something wrong in connecting the file_source to usrp_sink to transmit
> the 16-bit I and Q data? I am sure to be missing something.

It's not clear from your email what the problem is you're trying to
solve.

It is correct to connect a gr.file_source to a usrp.sink_s.

You said the script "runs for a second or two and stops immediately."
Depending on size of the capture file and the interpolation rate of the
USRP, it may only take a second or two to transmit the samples to the
USRP.  The flow graph shuts down and the script exits when the EOF is
reached.

--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com
3d593de8acbe2510722af740d8668352?d=identicon&s=25 Eng. Firas (Guest)
on 2007-07-14 06:34
(Received via mailing list)
Hello Hook,

Make File source repeat =True as follows :

self.dst = gr.file_source(gr.sizeof_short, 'output.dat',True)


Firas


Eliane Hook wrote:
>
> the above is:
> default=(0, 0),
>         if options.freq is None:
>         dac_rate= self.u.dac_rate();
>         if options.gain is None:
>
> Using TX d'board A: Flex 2400 Tx MIMO B
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/Problem-in-using-connect%28g...
Sent from the GnuRadio mailing list archive at Nabble.com.
0e0d6f914c8fbae32c55d9a71cbc20ce?d=identicon&s=25 Eliane Hook (Guest)
on 2007-07-16 21:22
(Received via mailing list)
Thanks for the inputs. There was some issue with the hardware. I changed
the
USRP Board and this worked. But I still have a problem.

This output.dat file is obtained by running the usrp_rx_cfile.py at a
particular frequency that has some meaningful data being transmitted. So
the
I and Q data being captured by the usrp_rx_cfile has meaningful data.
Now,
when I run my current script that connects the file_source to usrp_sink
at
some particular frequency and I cannot recieve this data from another
radio
at the same frequency. Is this flawed conceptually?

Thanks again for any and all help.
-- Eliane
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-07-17 09:18
(Received via mailing list)
Eliane Hook wrote:
>
> Thanks again for any and all help.
> -- Eliane

Are you not receiving the data back, or are you receiving nothing at all
(power, distorted signal)? Is this a digital waveform? What are you
doing for frequency synchronization?

Tom
0e0d6f914c8fbae32c55d9a71cbc20ce?d=identicon&s=25 Eliane Hook (Guest)
on 2007-07-19 20:22
(Received via mailing list)
Thanks for the responses.

I have used twice the interpolation number as the decimation number that
is
used to record or receive the data.

I did not understand this part:
"Secondly, there is likely frequency offset between your original
transmitter and the USRP on receive, as well as between the USRP on
transmit and whatever receiver you're using.  Depending on what the
modulation is you're dealing with, it might not survive these."

I am using RFX2400 daughetr boards and am using 2.4G to transmit and
recieve
on the 2 boards. I am using gmsk modulation scheme.

To answer this:
"Are you not receiving the data back, or are you receiving nothing at
all
(power, distorted signal)? Is this a digital waveform? What are you
doing for frequency synchronization?"

I am not recieving the data back. I also used the oscope and checked the
signal. It jus looks like noise but anything with gmsk modulation looked
like noise to me.
I did not understand what is meant by frequency synchronization.

I really appreciate any help that I recieve.
Thanks!
--Eliane
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-07-25 01:08
(Received via mailing list)
Eliane Hook wrote:
> modulation is you're dealing with, it might not survive these."
> I am not recieving the data back. I also used the oscope and checked the
> signal. It jus looks like noise but anything with gmsk modulation looked
> like noise to me.
> I did not understand what is meant by frequency synchronization.
The USRP's run with different clocks, start at different times, etc.,
etc., so the clocks are not synchronized and often need to be with some
phase lock loop technique or other synchronization method (see the comm
books by Proakis, Sklar, Rhode, or Ziemer  that discuss this topic, or
Gardner's book on PLLs).

But that's beside the point because you're using GMSK, which doesn't
need this and the M&M block tracks the symbol timing. So, sorry, back to
the starting point.

You should try using usrp_fft.py to see if there is any power being
received when you're transmitting.

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