Example: A Simple Wireless Data Transfer via SDR

Here is an example of a Quick and Dirty Radio (QDR) to transfer low data rate packets over the air using USRPs. For simplicity this QDR does not utilize any form of correction techniques or feedback for packet retransmission.

We'll use two nodes on the grid: node14-7 as the transmitter and node1-20 as the receiver. Load the nodes with 'baseline-sdr-uhd-003.009.003.ndz'.

Two applications are being utilized: 1) rf_hw_intf - configures radio, sets frequency channel, samples rate, gain, reads / writes samples to / from radio front end to circular buffer. 2) qdr - the sample processing application accesses circular buffer for processing sample data to / from packets.

Part 1: Run the applications for file transfer

On node1-20, run the following commands to start the receiving process.

node1-20> taskset 0x1 (rf_hw_intf —freq 950e6 —gain 0 —rx-only &)

node1-20> taskset 0x2 qdr —func rx —ftp-data file

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-unknown

Creating the usrp device with: addr=192.168.10.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N210r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: SBXv3 RX
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: SBXv3 TX

Setting RX Rate: 5.000000 Msps...
Actual RX Rate: 5.000000 Msps...

Setting RX Freq: 950.000000 MHz...
Actual RX Freq: 950.000000 MHz...

Setting RX Gain: 0.000000 dB...
Actual RX Gain: 0.000000 dB...

waiting for ready signal...
Checking RX: LO: locked ...
Setting TX Rate: 5.000000 Msps...
Actual TX Rate: 5.000000 Msps...

Setting TX Freq: 950.000000 MHz...
Actual TX Freq: 950.000000 MHz...

Setting TX Gain: 0.000000 dB...
Actual TX Gain: 0.000000 dB...

Checking TX: LO: locked ...
Recv proc started...

Preamble: 1
Feedback: 0
Return Acks: 0
FEC: 0
BC: 0 CC: 0 TC: 0
Fast Walsh: 0
Interleave: 0
waiting for ready signal...
SPB(SHM) = 256
[3175.03] 0 0
nf - - - - - - - - - - - - - - -

Similarly on node14-7, start the transmitting process to send an audio file.

node14-7> taskset 0x1 (rf_hw_intf —freq 950e6 —gain 20 —tx-only &)

node14-7> taskset 0x2 qdr —func tx —ftp-data SimpleMinds.wav —intv 1000

Creating the usrp device with: addr=192.168.10.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N210r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: SBXv3 RX
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: SBXv3 TX

Setting RX Rate: 5.000000 Msps...
Actual RX Rate: 5.000000 Msps...

Setting RX Freq: 950.000000 MHz...
Actual RX Freq: 950.000000 MHz...

Setting RX Gain: 20.000000 dB...
Actual RX Gain: 20.000000 dB...

Checking RX: LO: locked ...
Setting TX Rate: 5.000000 Msps...
Actual TX Rate: 5.000000 Msps...

Setting TX Freq: 950.000000 MHz...
Actual TX Freq: 950.000000 MHz...

Setting TX Gain: 20.000000 dB...
Actual TX Gain: 20.000000 dB...

Checking TX: LO: locked ...
Xmit proc started...
UDP receive proc started
Receiver ready on port: 1339
L

Preamble: 1
Feedback: 0
Return Acks: 0
FEC: 0
BC: 0 CC: 0 TC: 0
Fast Walsh: 0
Interleave: 0
SPB(SHM) = 256
root@node14-7:~/RTX_LOOPBACK#

While the file is being received, verify that the file size is incrementing. The receiving file name should be the original file name (from the transmitter side) prefixed with "rx_". So look for the file name 'rx_SimpleMinds.wav'

Since the file is a .wav audio format we should able to listen to the file as it is downloaded. Start a simple http file server on the receiving node (tunneling is required)

node1-20> python -m SimpleHTTPServer 7000

Use Chrome to access the server and click on the .wav file being received for playback.

Once the transfer is complete, compare the file checksum.

node14-7> sum SimpleMinds.wav 03167 10205

node1-20> sum rx_SimpleMinds.wav 03167 10205

If the check sums are different then at least some packets were demodulated incorrectly. The incorrect packets will result in distortion in the audio playback.

Part 2: View signal before demodulation

Let's slow down the transfer process and look at the signals as they are being received. In order for packet demodulation, the receiver must know where the signal starts. The signal detection starts with the detection of a known sequence of patterns; in this case it is a dual tone signal. On possible detection a simple FFT based correlation is performed to find a start offset. The sample processing application can send a few buffers to octave for viewing pleasure, debugging or verification.

Demodulation is carried on from this offset to convert the signal into formatted packets.

Rerun the qdr application for raw data processing: node1-20> qdr —func rx —pdu-data —port 1337 —addr 10.10.0.10 node14-7> qdr —func tx —pdu-data —intv 2000000

From the grid console, run the script below to view signaling:

if (exist("rcv_sck","var") == 0)
  rcv_port = 1337;
  rcv_sck = fUDP_open_rx(rcv_port);
  printf("Recv UDP pkts on port %i\n", rcv_port)
endif


  while(1),
    [recv_data, recv_count]=recv(rcv_sck,4000,MSG_WAITALL); y1 = typecast(uint8(recv_data), 'single complex');
    sleep(0.1)
    [recv_data, recv_count]=recv(rcv_sck,4000,MSG_DONTWAIT); y2 = typecast(uint8(recv_data), 'single complex');
    sleep(0.1)
    [recv_data, recv_count]=recv(rcv_sck,4000,MSG_DONTWAIT); y3 = typecast(uint8(recv_data), 'single complex');
    sleep(0.1)
    [recv_data, recv_count]=recv(rcv_sck,4000,MSG_DONTWAIT); y4 = typecast(uint8(recv_data), 'single complex');
    sleep(0.1)

    S1 = fft(y1);
    S2 = fft(y2);
    S3 = fft(y3);
    S4 = fft(y4);
    plot( [abs(S1) abs(S2) abs(S3) abs(S4)] )
  endwhile

Part 3: Select receiver by preamble