Re: [Discuss-gnuradio] Data from File on command.

[Johnathan Corgan]

On Fri, 2009-07-24 at 15:37 -0700, Judah, Charles C CIV USAF AFMC 775
TS/ENV wrote:

> I am trying to send various commands to a UAV. The system uses a file
> source, packet encoder, dpsk modulator, throttle, multiply by
> constant, and USRP sink using RFX400 daughter boards.  The flow graph
> (connections) happen in the order stated. 

Ok.  You don't need the throttle, as the USRP acts as the rate limiting
block anyway.

> how do I send more data over the same flow graph without restarting
> it? I have been searching for 3 days in an attempt to find a
> functional solution for this. 

Conceptually, you need to change from injecting your data into your TX
flowgraph via a file source to injecting data into your flowgraph using
a message source.

Then, in a separate thread outside GNU Radio, periodically drop file
contents to be transmitted into the msg source.

In practice (with current GNU Radio), it is easier to do this just
before the modulator, and handle the packetization using regular Python
instead of inside the flowgraph.

We do it exactly this way in our digital packet radio example.  There is
a lot of code to review, as it is a complex example, but essentially,
when IP packets from the operating system need to be transmitted, we
packetize them in pkt_utils.py and then drop them into the flowgraph by
queuing them into a message source created in blks2.mod_pkts.

In your case, your strategy would be to have a TX flowgraph of a
gr.messsage_source, dpsk modulator, amplitude scaler, and USRP sink.  In
a separate top-level thread, generate your commands, packetize them into
whatever frame format you are using, then drop them into the queue.
There are caveats about padding your data to the right length to ensure
it forces a transmit over the USB to the USRP as well.

(As an aside, it is almost *never* correct to start/stop a flowgraph
except at the beginning and end of a program.  Anyone tempted to do so
should think hard about why they would need to.)

I'd recommend you do a thorough review of the digital example.  Since it
has a generalized architecture, there are a lot of layers of
abstraction, multiple files, parts in gnuradio-core and parts in
gnuradio-examples, layered command line argument handling, etc., but
that's just the reality of software engineering for modularity and
generality.  If you can see past that to the parts that implement the TX
and RX flowgraphs, and understand the difference between a GNU Radio
flowgraph and 'generic' Python code running in its own thread, you'll
get it.

(The message passing architecture being developed for 3.3 will make this
somewhat easier.)

Johnathan