You are not logged in.
Hi,
It is regarding to the ofdm_txrx_mimo simulink model. Is is possible to verify the sent packet payload at the receiver??
Thank you very much!
Offline
Both the Tx and Rx subsystems implement checksum calculations. The Tx PHY automatically appends a 32-bit CRC to the end of each packet. The Rx PHY knows this, and compares its CRC output with the CRC is receives over-the-air. If they match, the Rx raises the good packet interrupt. If they don't, the bad packet interrupt is asserted. In simulation, you can watch these signals to monitor good vs. bad packets. Also (and only in simulation), the Rx BER calculation block is pre-loaded with the transmitted packet, so you can monitor exact BER per-packet. These are the numbers printed out to the Simulink displays at the root of the Rx block.
Offline
Hi,
If I wanted to inject my own packet into the Tx block, and verify that I received the same packet on the Rx side, how can I do this? We wanted to confirm the data at various stages of a known packet in simunlation that we're sending in the real hardware. Is this possible?
Thanks!
Offline
Sure. In simulation, the Tx packet contents are defined in the ofdm_tx_mimo_init.m script. Look for the line:
packet = [packetHeader 1:(pkt_numPayloadBytes-length(packetHeader)-4)];
By default, the packet is composed of the standard header, then sequentially increasing values. You can replace these values with whatever bytes you want.
Offline
On the Rx side, how should I view the packet?
Thanks!
Offline
You can look at the Rx bytes using the scopes hooked up in the Rx packet buffer. Look at the scope in the subsystem 'OFDM Rx MIMO/Equalizer & Packetizer/Data Buffer/Descrambling & Pkt Buffer'. Alternatively, you can add a To Workspace sink to drop the Rx bytes to the workspace. Remember that new bytes arrive every few clock cycles - not every cycle. This is why some bytes appear to "last" longer; they're written to the packet buffer just once, using the 'We' signal coming out of the de-scrambling block.
Offline
Just to be clear we have downloaded and are running the reference design v4 from the warp repository. The packet we generated by default is:
packet = [242 179 243 152 214 112 213 132 5 95 229 109 1 0 145 68 2 5 0 50 77 137 232 133 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 219 124 183 93]
The first few samples/bytes that we are observing at the point indicated in your post above are [173 19 62 233 202 94 ....] (sampled at every WE). These values are not in the transmitted packet. We also do not see incrementing values as in the generated Tx payload. Are these values expected, and shouldn't we be seeing the matching payload somewhere? Please let us know what we are missing....
Thanks for the help!
Offline
Two clarifications that should help:
a) You need to look at the bytes at the output of the de-scrambling block; you may need to hook up the scope to observe the outputs instead of the inputs. This block inverts the pseudo-random scrambling implemented in the transmitter. The scrambling process helps prevent cases of long constant-valued patterns in the modulated payload (which produce spikes in the time domain waveform) by XOR-ing the payload bytes with a sequence pseudo-random integers known to both the Tx and Rx.
b) The byte order in the model is endian-swapped in groups of 8 bytes. This mimics the behavior of the real PLB packet buffer interface, but has the unfortunate consequence of reordering bytes in simulation. So if the transmit payload in the init script starts [242 179 243 152 214 112 213 132], the sequence of bytes you should expect at the output of the de-scrambler is [132 213 112 214 152 243 179 242].
Offline
Thank you very much!! It helps a lot. We now can see the contents of the transmitted packet at the output of the de-scrambling block. By default, the packet is composed of the standard header, then sequentially increasing values. We replaced the payload with 3 byte data: 0x41, 0x42 and 0x43. In ofdm_tx_mimo_init.m We also change the pkt_numPayloadBytes to 3. However when we started the simulation we get an simulation error: value on the selection line exceeds the number of ports in the mux in the block ofdm_txrx_mimo/OFDM_RX_MIMO/Equalizer & Packetizer/Packet_Constructor/Hard Decision/Mux2.
Is there any other settings that we need to modify to make it work?
Thanks for the help!
Offline
Nevermind I think I figured it out. I looked into the source code and I see pkt_numPayloadBytes should be equal to (24 + data length + 4). Does the 4 correspond to CRC??
Thanks!
Offline
Yes, exactly. We use 24 bytes (2 full OFDM symbols with 48 QPSK modulated subcarriers each) for a header and a 4-byte CRC appended at the end. The user code (the m script in simulation, C in hardware) has to allocate the 4 extra bytes when setting up the PHY, but the PHY itself fills them in with the CRC values.
Offline
Thanks!
After various tests, we tried sending 9 bytes of data. We observed that the first 8 bytes are received correctly but the last byte is not valid. Is there a constraint on the data to be multiples of 8 bytes long?
Thanks for your help!
Offline
Are you trying to send 9 bytes total, or 9 payload bytes after the 24-byte header? The 9+24 scheme works in simulation for me. For the 9-byte case, that's a really short packet. I wouldn't be surprised if the PHY acts strangely trying to process a packet with just one OFDM symbol.
Offline