You are not logged in.
hi
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 ?
thanks
Sadia
Offline
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.
Offline
So ,
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?
Offline
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 ?
Offline
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...
Offline
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.
LTF_T(64)=0
csi = fft(LTF_stored). *fft(LTF_T).
I am not sure if this is happening in reality or this is an artifact of Simulink
Offline
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.
Offline