Data from File on command

GNU Radio
1

The current implementation:

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.

If the flow graph is already running using Auto T/R so that when I
finish sending a single command packet the USRP stops transmitting a
carrier, 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.

Basically what I need to happen is:

A. Either I edit the file used in the file source and then “jump
start” the flow graph to re-read the file source and repeat the
operational data path without actually stopping and restarting it.

B. Send the data directly to the packet encoder inside the flow
graph such that it follows the same operational path as the original
file source data so that the result is the same and the data is
packetized, modulated, and sent out through the USRP.

2

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