> -----Original Message----- > From: Eric Blossom [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 20, 2006 11:16 PM > To: Bahn William L Civ USAFA/DFCS > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] What is the simplest way to get data > to/from the USRP > > On Wed, Sep 20, 2006 at 06:31:54PM -0600, Bahn William L Civ USAFA/DFCS > wrote: > > Assuming that I am ever able to actually establish communications with > > the USRP, what is the simplest way to get raw data to/from the USRP? > > > If you haven't already, I suggest starting with "Exploring GNU Radio" > http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html >
I've read that and got the dialtone example to work (with the soundcard). > > > I am envisioning something really, really simple. Initially it can even > > be a brute force polled system that operates along the lines of the > > following: > > If you want to capture data from the front end and put it into a file, > the easiest way is to use gnuradio-examples/python/usrp/usrp_rx_cfile.py > I'm looking that one over. For parts of what I need to do initially, that should suffice provided I capture a sufficiently long uninterrupted stream of data. > > I have two memory buffers, one for input from the receiver and one for > > output to the transmitter. > > You're trying to operate at a _much_ lower level of abstraction than > we usually work... > > If want to work at that low level, you could consider using > the C++ interface to the USRP (same one that GNU Radio uses internally). > > See usrp/host/lib/usrp_standard.h and usrp_basic.h for the interface. > Note however, that if you work at this level, you lose the advantage of > all of the (python) code that knows how to talk transparently to the > 11 kinds of RF daughterboards that are supported. I wouldn't > recommend this path. I'm including it for completeness. The basic > i/o methods are called read and write. > Thanks - that is probably where I will end up working for at least some things. > > I would like/hope/pray that there is some kind of construct that allows > > me to see if the USRP receiver has data for me and also whether the USRP > > transmitter can accept data from me. > > It just streams data to and from you. Fundamentally GNU Radio is a > data flow architecture. > > For something somewhat similar to what you're trying to do, take a > look at gnuradio-examples/python/audio/spectrum_inversion.py > It uses an audio card for i/o, but the same idea applies to the USRP. > > Spend some time with "Exploring GNU Radio" and take a look at > gnuradio-examples/python/usrp/usrp_wfm_rcv_nogui.py for one of the > simplest programs that actually does something interesting. It's a > wideband FM receiver. > > > If you're looking for something that moves packets of data across the > air, take a look at gnuradio-examples/python/gmsk2/tunnel.py. Among > other tricks, it can send IP packets between machines using the USRP. > Will look at all of these. > > > For what I am eventually planning to do, this is the equivalent of > > Hello World. > > If you tell us what you're really trying to do, someone may be > able to suggest a suitable approach. Fair enough. Unfortunately I'm really not in a position to disclose too much about the end goals (nothing hush, hush secret or anything, just a matter of obligations to release details in the proper order to the proper people first to make the folks paying the bills happy). We actually have a couple of separate approaches we are hoping to demonstrate using SDR. One would involve a sender using spread spectrum to send a message but where the message is encoded via the sequence of spreading codes that are used. The data is really just a marker and would most likely be pseudorandom (or perhaps even truly random) noise. The sender would broadcast the marker using the first code in the sequence (or perhaps simultaneously transmit using the first N codes in the sequence) and then, after a certain amount of time, shift to the next code(s) in the sequence. The receiver is simply trying to determine if the sender is sending something on one or more of a list of potential spreading codes. Based on which codes are in use, the receiver can determine a new list of codes to listen to for the next marker. So they need to be able to listen to many codes (at some point, potentially a few thousand) "simultaneously". It's fine to capture a data stream and then sequentially examine it to see which codes are in use, although eventually a highly parallelized system would be highly preferred. The protocol can accommodate this by adjusting the marker's transmit duration to permit adequate receiver processing time. Another, completely different, approach is for the transmitter to send out a sequence of very short chirps (bursts of noise) where the time location of the chirps encodes the message. The receiver then determines what those time locations are and, from that, reconstructs the message. The last one is the one we want to implement first, but it lends itself more to an Ultra Wide Band approach. To demonstrate the basic concept using the USRP, I am thinking of two approaches. The first is to using the BasicTX and BasicRX boards wired together to send chirps directly from one system to another. But we also want to demonstrate that wireless communication is actually possible using this protocol and so what I am thinking of there is to use CW-OOK (essentially Morse code) to emulate the chirps. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
