WARP Project Forums - Wireless Open-Access Research Platform

hi sir my aim is to send raw data(BASE BAND) from the transmitter section and to receive the data from the warp receiver board and to calculate the channel response from the data available that means without sending preamble please send me the information related to it.

thank you sir

A channel estimate will reflect all changes in magnitude and phase between the Tx baseband and Rx baseband. Many of these changes vary with time (propagation channel coefficients, carrier frequency offset, sampling frequency offset, etc.). When transmitting over-the-air with standalone Tx/Rx kits, you cannot expect the received waveform to be a scaled version of the transmitted waveform with no time-varying changes. There are many sources of phase and amplitude variation along the Tx -> Rx path. Your Rx processing must handle these offsets. This typically requires your Tx waveform to include a training sequence the receiver can use to calculate effective channel estimates. The WARPLab wl_example_siso_ofdm_txrx.m script provides one example of a complete Tx -> Rx implementation. If you want a totally blind receiver, you will need to figure out how to estimate and compensate for the various phase/frequency/magnitude offsets in your Rx implementation.

hi sir,
for operating two warp v3 nodes and in which one  act as transmitter and another one act  as receiver and to transmit and receive the data from nodes whether the nodes will need any synchronization modules kindly let me know the information related to this issue.

why warp lab 7.6 basic transmission program does not use preamble for its transmission is there any reasons please let me know

In WARPLab 7.5.1, the simplest example was wl_example_siso_txrx.m.  From a teaching / introduction to WARPLab standpoint, that example was quite complex.  Therefore, for WARPLab 7.6.0, we decided to create the simplest example that we could for WARPLab.  This included only using manual gains for transmission and reception.  Since we were no longer using the AGC, that allowed us to simplify the waveform and only transmit a complex sinusoid.  As you can see in the new example, it is extremely "basic" and much easier to understand from an introductory standpoint.

If you need to a real-time wireless link between WARP nodes, I would suggest the 802.11 Reference Design.

The 802.11 Reference Design documentation explains in detail how to use the design. For your video application, you probably want one board programmed with the AP bitstream and the other board programmed as a STA.

You need to tell us more about your setup. What version of WARP hardware? What version of WARPLab? Are you using Ethernet triggers to both nodes? Or do your nodes share triggers with a wire? How do you observe the 50-60 sample delay?

The Rx waveform arriving after the Tx waveform makes sense. There are non-zero latencies through the Tx buffers, Tx DAC, Tx RF circuits, propagation channel, Rx RF circuits, ADC and Rx buffers. It is also likely that your Rx node is receiving the broadcast trigger after the Tx node. We use broadcast Ethernet packets to send triggers. However most Ethernet switches do not implement simultaneous-to-every-port broadcast. Instead most implement transmission on each port in some order. You can observe this effect by swapping the Ethernet ports to which your WARP nodes are connected.

The unknown delay from Tx to Rx is why real communications systems implement some kind of synchronization in their Rx waveform processing. For example our OFDM script for WARPLab uses a complex correlator to location the long training symbol in the preamble of the received waveform. The correlation peak is used to set the FFT windows for the rest of the Rx flow.

Longer distance means higher path loss. The actual path loss depends on the frequency and propagation environment. The WARP nodes don't control the path loss. You can estimate the Rx power in your experiment to understand how much path loss your signal experiences, and how much more loss your system can tolerate. There are many threads on these forums about estimation Rx power. I would also encourage you to read more about link budgets and path loss to understand what to expect when increasing the distance between the Tx and Rx nodes.

We cannot debug your PHY design for you. In general 64-QAM requires higher SNR and better synchronization (channel estimation, equalization, CFO correction, phase error correction, etc) than lower-order modulation schemes. You will need to isolate the various sources of error in your system and investigate whether you can improve them. Replacing antennas with a cable+attenuators (always >30dB attenuation between Tx and Rx) is a good way to control SNR. Sharing clocks between Tx and Rx nodes is a good way to control phase/frequency synchronization. You can also explore these issues in simulation - introducing noise, fading, phase and frequency offsets is straightforward in m code. You should see your entire PHY design work in simulation with realistic (simulated) degradations before hoping to see it work in hardware.