On Fri, 2009-07-24 at 15:37 -0700, Judah, Charles C CIV USAF AFMC 775
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
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
(The message passing architecture being developed for 3.3 will make this