You are not logged in.
I wanted to visually confirm the output of the Rx's payload, rather than just relying on the BER calculation as a sanity check. So I have been looking at the 8 ROMs in ofdm_txrx_mimo/BRAM interface/PLB Pkt Buffer that hold the packet defined in the Matlab script by RAM_init_values. I've been trying to find the location in the receiver side that matches that of the tx side. I thought the scope called Rx Bytes in OFDM Rx MIMO/Equalizer & Packetizer/Packet_Constructor/Data Buffer1 that looks at the Data ouput of the Descrambling & Pkt Buffer1 module would match up with the data in the ROMs of the receiver mentioned earlier. Am I looking at the wrong location in the Receiver, or does there need to be more work done on the Data (UFix 8_0) output of the Descrambling & Pkt Buffer1 module in order to match up with that of tx side? I understand that the the ROMs mentioned earlier in the transmitter contain the 32 byte packet header, followed by a 117 byte payload and 4 byte CRC, and hoping that one could easily see the corollary on the receive side.
Offline
Keep in mind that the /BRAM Interface/PLB Pkt Buffer/ subsystem is not used in hardware. The PLB packet buffer is instantiated in XPS directly; the Sysgen core connects to it directly via the BRAM_* ports. The /BRAM Interface/PLB Pkt Buffer/ subsystem is used only for simulation.
The packet bytes specified in the ofdm_tx_mimo_init.m script can be seen on the Rx_Bytes scope, but the byte order is endian-swapped. For example, the first eight bytes specified in the M script will appear in reverse (if packet=[1 2 3 4 5 6 7 8], the scope will show [8 7 6 5 4 3 2 1]).
Also, the wireless MAC header is 24 bytes. And the checksum is calculated in hardware and appended to the packet automatically. The checksum calculation in the init script isn't actually used anywhere. It's leftover from when the BER calculator included checksums. I updated it a while ago to ignore the CRC bytes (so the BER packet can be reloaded without having to manually calculate a CRC).
Offline
In the simulink model, the a ramp payload signal is transmitted. I was expecting a reserved paylaod ramp signal at the receiving side due to the endian-swapped. But the received payload seems to be totally unrelated to the transmitted payload.
Offline
The bytes are correct. Remember that on the Rx Bytes scope, that the data value is only valid when the Vout signal is high (the top signal). For a better view of the received bytes, look at the BER scope (Equalizer & Packetizer/Packet_Constructor/Data Buffer/BER Calc/BER). The data bytes shown here are gated by the Vout signal, so they better display the endian-swapped ramp pattern of the data bytes.
Offline
In the simulink model, the RX Byte signal in BER scope is a ramp signal which is matching the transmitted signal. I do not see the received ramp signal being reversed due to the endian-swapped you mentioned. However the received signal in our hardware is not a ramp pattern signal.
As you have probabily known, in our hardware setup, we have used your TX simulink model to generate OFDM packets. The OFDM packets are uploaded to Agilent signal generator, then the OFDM packets are converted to the RF signal which is outputed to our own hardware platform. Our hardware is loaded with your RX design.
The RX Byte signal is pulled out and monitored in our hardware, but the RX Byte is not a ramp signal. All registers are loaded according to WARPMAC.c. Any idea why the RX can not get a ramp signal? I will be really appreciated with your help.
Offline