You are not logged in.
The received vector size is currently limited to 16383 samples. I wanted to know what my options are, if I want to capture more samples. What is the upper limit?
One way I have done this is by repeatedly running the matlab script, but then that introduces a delay when the transceivers are enabled and disabled.
Also, I was looking for the the definitions of the following initialization functions in warplab_mimo_4x4.c
warplab_mimo_4x4_WriteReg_CaptOffset(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_DoneReading(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 1); // Cycle Done Reading signal warplab_mimo_4x4_WriteReg_DoneReading(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_StartCapture(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_TxLength(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, (unsigned int)16383); warplab_mimo_4x4_WriteReg_RADIO1TXBUFF_TXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO2TXBUFF_TXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO3TXBUFF_TXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO4TXBUFF_TXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO1RXBUFF_RXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO2RXBUFF_RXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO3RXBUFF_RXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0); warplab_mimo_4x4_WriteReg_RADIO4RXBUFF_RXEN(XPAR_WARPLAB_MIMO_4X4_OPBW_0_BASEADDR, 0);
Is there an API where these are defined?
Thanks,
Arijit.
Last edited by arijit (2008-Jul-29 14:18:40)
Offline
The current buffer sizes are due to two limitations:
-The shared memory support in sysgen2opb only supports blocks with 2^14 32-bit words.
-The FPGA itself has a limited amount of on-chip memory. There's enough for 2x2 with 2^14 samples of I/Q and RSSI. In 4x4, we had to remove the RSSI buffers in order to keep 2^14 samples of I/Q for each antenna.
We're working on a version of the WARPLab core built in Sysgen 10.1, which has new support for shared memories and registers without requiring sysgen2opb. I don't know the maximum size of its shared memory block yet. We're also considering a version that would use the off-chip SRAM (instead of on-chip BRAM) for the sample buffers. This is trickier, since the SRAM is single-port and would need to be shared between the Sysgen core and PLB46 bus.
arijit wrote:
Also, I was looking for the the definitions of the following initialization functions in warplab_mimo_4x4.c
Those macros are defined in the C header generated by sysgen2opb. This file is copied to the drivers folder of the EDK project. Each macro is just a wrapper for a memory access of a given address, defined as an offset relative to the core's base address.
Offline
Thanks.
I had three small questions:
1) Is it possible to do process the 32 bits long raw data in the FPGA itself and then buffer this processed data, thus enabling storage of more samples? Is yes, are there any negative consequences?
2) I am doing an experiment for which I need many more samples than 2^14. For this I follow the following simple algorithm:
i. Enable the Tx and Rx radio boards and buffers
ii. Send and receive the sync packet
iii. Disable the Tx and Rx buffers
iv. loop n times
Enable the Tx and Rx buffers
Transmit and receive 2^14 samples
Disable the Tx and Rx buffers
End loop
v. Disable the Tx and Rx radio boards
So how different is this from a hypothetical situation where I would be able to capture n times 2^14 samples all at one go in the buffer? (I guess
in the time spend enabling and disabling the txrx buffers we miss some of the action in the wireless channel)
3) What exactly do you mean by shared memory support in sysgen2opb?
Answers/thoughts on any of these questions will be much appreciated.
Arijit.
Offline
1) Definitely. The 32-bit data is really two 14-bit samples (I and Q) plus two bits indicating out-of-range at the ADC. These four components are disassembled by warplab_processRawRxData, which reconstructs the original I/Q/I_OTR/Q_OTR vectors.
Now, if you want to process I/Q samples in the FPGA, you're essentially designing parts of a PHY. We've used WARPLab like this before; in fact, we intend for WARPLab to be a framework for extensions just like this.
2) Are you sending the same sequence repeatedly, or downloading unique values per Tx/Rx cycle? If it's the same data, you can download those samples once, then read back just the received samples per cycle (i.e. halving the overhead by only writing the Tx samples once). You can also use continuous transmit mode, where one node cycles through the 2^14 samples non-stop.
As you noted, the only drawback is the low duty cycle. Every over-the-air access is real-time, but the channel is actually used just a fraction of the time overall.
3) The Tx/Rx buffers are realized as dual-port RAMs in the FPGA fabric. One port is tied to the OPB (in the current design; it'll be PLB46 someday soon); the other port is tied to the WARPLab core (which interfaces to the radios). Sysgen2opb creates the bus interface for these buffers using its shared memory mode.
Offline
1. So basically we would be able to save 4 bits of buffer memory per sample by processing the Raw data in the FPGA right?
2. a) Yes I am sending the sameTx vector over and over n times, and have just saved it in the transmit buffer only once. But I still need to enable and
disable the Tx buffer from MATLAB in order to tell the Tx side when to send data right?
b) How long does the buffer enable/disable operation take in terms of clock cycles?
Thanks.
Offline
1) You would still have to package the samples up for transmission over Ethernet. You could pack them without filler zeros to save space, but the bookkeeping in MATALB would get tricky (since samples would span multiple bytes in the received UDP frame). It's entirely possible, just not part of the standard design.
2a) You can use continuous transmit mode to leave one node transmitting non-stop; it will just cycle through its Tx samples over and over without any triggers from MATLAB. This will only be useful if your receiver processing can handle a capture with an arbitrary cyclic shift relative to the original transmitted sequence.
2b) I don't know exactly, but I would guess hundreds of microseconds. Melissa will know better, when she gets back next week.
Offline
In the version 3 of the WARPLAB exercises, the TxLength has been modified in warplab_siso_example_TxRx.m, to
TxLength = 2^14-1-CaptOffset;
Earlier in warplab_example_TxRx.m, it used to be
TxLength = 2^14-CaptOffset;
Is there any specific reason for the additional "-1" in the presnt version?
If I want to change back to the earlier format, do I need to change anything other than the matlab script and the c program?
Last edited by arijit (2008-Aug-04 01:43:34)
Offline
This is another good question for Melissa (she'll be back any day now). I suspect it should have been -1 the whole time, and that it was missing was a bug in the early releases.
Offline
There is no additional "-1" in the new version. Notice that in the warplab_example_TxRx.m code there is also a "-1", this "-1" is added when defining the options vector :
optionsVector = [CaptOffset TxLength-1 (RxGainBB + RxGainRF*2^16) (TxGainRF + TxGainBB*2^16) CarrierChannel];
Offline
I see.
In regards to the discussion earlier in this thread, my other question was how long does the buffer enable/disable operation take in terms of clock cycles?
Offline
You can measure this time using MATLAB's tic and toc functions. I did this about a year ago and I think the time was ~1ms but I may be wrong.
Offline
I was wondering how the tx and rx gain values were set in the warplab experiments
Node1_Radio2_TxGain_BB = 3; % Tx Baseband Gain. In [0:3] Node1_Radio2_TxGain_RF = 40; % Tx RF Gain. In [0:63] Node1_Radio3_TxGain_BB = 3; % Tx Baseband Gain. In [0:3] Node1_Radio3_TxGain_RF = 40; % Tx RF Gain. In [0:63] Node2_Radio2_RxGain_BB = 13; % Rx Baseband Gain. In [0:31] Node2_Radio2_RxGain_RF = 1; % Rx RF Gain. In [1:3] Node2_Radio3_RxGain_BB = 13; % Rx Baseband Gain. In [0:31] Node2_Radio3_RxGain_RF = 1; % Rx RF Gain. In [1:3]
Offline
Each radio has a transmit and a receive path and both paths have a Baseband (BB) and RF gain. The gains should be set such that the received signal doesn't saturate and spans almost the full range of the I/Q ADCs. The signal stored in the receiver buffer is the output of the I/Q ADCs, the ADCs output is fixed point 14_13. The I/Q samples rail at -1 and +1, we recommend that you set the gains such that when you plot the received signal in MATLAB the I/Q samples have a magnitude of around 0.8. We usually set Tx gains at a high value (as in the code that you posted) and then choose appropriate values for Rx gains.
The possible values for the gains are in the code that you posted above. The increment for each value is as follows:
TxGainBB: 1.5dB/step

TxGainRF: ~1dB/step

RxGainBB: ~2dB/step
RxGainRF: 15dB/step
Offline
The I/Q samples rail at -1 and +1, we recommend that you set the gains such that when you plot the received signal in MATLAB the I/Q samples have a magnitude of around 0.8. We usually set Tx gains at a high value (as in the code that you posted) and then choose appropriate values for Rx gains.
l
If I am interested in just studying the noise in the environment, and nothing is being transmitted, how do I decide what gains to use?
As an aside question, why isnt there an AGC in WARPLAB?
Offline
Try setting the gains so that the Rx I/Q are (mostly) in +/- 0.2. This is the input level that maximizes the MAX2829's own noise performance. See the MAX2829 datasheet for more detailed performance specs.
An AGC-enabled WARPLab is tricky; AGC requires a particular signal at the beginning of every transmission in order to estimate Rx power accurately. In WARPLab, the transmitted signal is completely arbitrary (i.e. no preamble, like in the real-time PHY).
Offline