You are not logged in.
In the 802.11a reference design the RATE parameter has bits flipped , according to the standard the bits should be flipped for length alone not for RATE , is this an oversight ?
The RATE and LENGTH fields are constructed correctly by the PHY hardware in the outgoing waveform, but do get flipped in a few places for easier interpretation by other blocks and in the MAC code. That said it's entirely possible there's an extra flip/unflip at some point in the design.
My simulator can now decode the Simulink Tx by doing the flip whats interesting is the over the air waveform appears to be correct and I dont have to bodge my simulator for it to work. perhaps its just in the Tx simulink part not MAC?
Also the simulink Simulator output wlan_tx_out has the last sample of LTF training field set to zero , this will have adverse effects in frequency domain on csi estimation. IS this also just simulator problem and has been fixed in hardware ?
Interesting... I think I see what you're talking about, where the first sample of the first OFDM symbol lags the last sample of the preamble by a cycle. Thanks for pointing this out. I'll dig into the model to figure it out...
No I dont think there is a lag , its just that the last sample of the training field is set to 0 (timing wise its correct) but data itself is incorrect.
so if now I use this and do a convolution to compute the CSI , its not going to be smooth.
csi = fft(LTF_stored). *fft(LTF_T).
I am not sure if this is happening in reality or this is an artifact of Simulink
Then I'm confused- can you provide more detail where you're observing the malformed LTS? On a scope in the Simulink/Sysgen simulation of wlan_phy_tx_pmd?
Edit: never mind, I found it. The last sample of the transmitted LTS was 0, due to a mis-alignment of the last preamble sample and first payload sample. This is fixed as of ref design version v0.6-beta.