== 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 }}} || [[Image(​view_sync_sig.2.png, width=700px)]] || === Part 3: Select receiver by preamble ===