07-22-2013 05:41 PM
Hi,
I have been trying to create an OOK/FSK modem using the USRP and I got lots of problems and decided to stick with the simplest case, OOK. I first tried using the NI Modulation Toolkit and things worked in simulation, but didn't do too well using the USRP. I thought it was something wrong with the modulation toolkit, as I was getting some problems with its synchronization block.
So I decided to create my own blocks to convert bits to complex symbols, shape their pulses, oversample them and then transmit. On the receiver side I did matched filtering, used an early-late gate to synchronize and then a sliding correlator to detect the beginning of the frame (using a 1010...10 preamble with user-defined length). In the simulations I added white noise and delay to the transmitted signal and it did pretty well for a bad modulation scheme such as OOK.
Then I tried implementing it on hardware in two ways: just doing as the USRP examples and plugging all USRP driver blocks together and using my TX and RX blocks as sources/sinks. But that does not work. The receiver seems to just detect garbage and, when 500 random were transmitted, 20 '0' bits are recovered.
The other solution was based on the code used in Robert W. Heath's Digital Communications book. The receiver in that code had a trigger feature, which should guarantee that the capture only starts when a considerable power is detected in the receiver antenna. But the receiver simply doesn't capture nothing at all. Even with the antennas close together and low capture time and trigger level. The weird part is that I could get that code to work when working with the book's lab experiments. I managed to do all the lab practices listed in the book using that code.
I have been fiddling with this for quite a while and it has been frustrating. I have no idea of what I should do to make this USRP code work. I think the transmitter is working quite well, but the receiver is just a big headache.
In the files, approach 1 is the first approach I mention here, and the approach 2 is the second. For approach 1, the top usrp blocks are rx_v2_usrp and tx_v2_usrp. For approach 2, they are called top_rx and tx_top. There is also a simulation folder.
07-23-2013 03:07 PM
I realized that the hw parameters control is missing from the previous files. I'm attaching them here.
07-25-2013 06:26 AM
07-25-2013 10:39 AM
I tried running this example, but, even using 2 USRP 2920, I couldn't make it work. I'm clearly doing something wrong, but I have no idea what it is.
07-30-2013 04:38 PM
Dan,
Could you include pictures of errors or more information about what doesn't seem correct? That will help me provide better suggestions. Thanks!
07-31-2013 10:13 AM
Sorry for the lack of information. I have attached some pictures of how I configured the front panels for the packet transmitter and receiver. I changed very little: basically the device addresses, the carrier frequency (I'm using 433MHz as I have antennas for that frequency) and the acquisition time is now 80m (but I tried with 40 too).
What happens is shown in packet_receiver_message and packet_receiver_debug: simply no signal is detected. I tried plugging the USRP in an oscilloscope and I could verify that I'm really transmitting. The antennas are very close and I even tried changing the gain, but none of that helped: the receiver still sees nothing.
08-01-2013 03:18 PM - edited 08-01-2013 03:19 PM
Dan,
Have you been able to successfully receive with this device before? Have you tried running a basic FM Demodulation Example to test the receive function of that device? You might try going to Start>>All Programs>>National Instruments>>NI-USRP>>Examples>>LabVIEW. A new window will pop-up. Open the ModulationToolkitExamples and choose the niUSRP EX FM Demod Sound Card (Queue).vi.
08-02-2013 12:34 PM
Your "packet_receiver_debug.png" image has a "Signal and Noise Power tracking graph indicator of exactly zero. I would suspect that this USRP is not actually receiving data at all.
Ensure your USRP IP really is 192.168.10.26
Add an Error out indicator just after your "niUSRP Fetch Rx Data" VI and make sure it's not causing problems.
Start with the Fetch Rx data VI, then work your way down the chain to where the data gets consumed.