I wrote a simple transceiver class for the USRP1 (GNURadio) using the new UHD interface.<\/p>\n
The class allows you to send and receive data. \u00a0What you fill in for the data is up to you. \u00a0Currently, the class performs simple energy detection (sends a 100 sample burst with constant envelope) and works when you hook the RX up to the TX on the Basic RX\/TX boards (make sure you have proper\u00a0attenuation\u00a0as to not break the daughterboards). \u00a0But, with some simple modification, you can have it do more sophisticated processing.<\/p>\n
The class creates two queues and three threads.<\/p>\n
One queue is the TX queue and the other the RX queue.\u00a0The TX queue is a vector of pointers to complex float vectors (variable length) and are waveforms to be transmitted.\u00a0The RX queue is a vector of pointers to complex float vectors (const size) and are the data blocks received from the radio.<\/p>\n
The three threads are the TX thread, the RX thread, and the processing thread.<\/p>\n
The TX thread wakes up every 100ms and looks at the TX queue and sends any waveforms that are present. \u00a0The RX thread runs\u00a0continuously\u00a0and receives datablocks from the radio. The processing thread checks the RX queue and processes any blocks that are present on it. \u00a0Having an RX queue, RX thread, and processing thread allows the software to\u00a0continually\u00a0receive data without dropping packets and leaves the choice up to the software as to which packets to process. \u00a0For example, if the processing thread runs slower than the samples coming in (slower than real time), it may choose to intelligently process the remaining blocks instead of dropping data on the floor. \u00a0This would allow the processing thread to “catch up.”<\/p>\n
The TX thread can be modified as to send the waveforms out\u00a0immediately instead of on a queue for servicing.<\/p>\n
I hope all this makes sense.<\/p>\n