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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
