You are not logged in.
Hello,
I am interested to know when exactly the start of a frame is received by the WARPv3 receiver. I have edited the wlan_mac_hw.mdl to add a timer which is paused (value captured in register) on rising edge of dbg_PKT_DET_OFDM (from rx phy). If the FCS is good then this value is taken as the true frame start time. However, I have questions:
1) The timer/counter in wlan_mac_hw has no inputs. This core is clocked at 160MHz so the timer is too?
2) The wlan_phy_rx core is also clocked at 160MHz but the samples arrive from ADCs at 40MHz?
3) Does this mean dbg_PKT_DET_OFDM will be quantized to the nearest 40MHz period. So the resolution of arrival time is no better than 25ns? Even if using the 160MHz counter?
4) Is there any better signal to give more accurate frame arrival time.
p.s. I realise you implement a microsecond counter for this purpose but I require something more accurate.
Thanks
Offline
The Rx packet detection logic will assert over a wide range of sample indices relative to the actual first sample of a received waveform. The auto-correlation packet detection block looks for periodic-in-16 sequences (the preamble STS) whose auto-correlation exceed a minimum threshold relative to their received amplitude. The timing of the assertion of the detection output will vary with Rx power, channel frequency response and with noise. In short, the packet detection subsystem is not a reliable source of sample-accurate timing for receptions.
The Rx PHY uses the LTS correlator to establish sample-level timing. The LTS correlator searches for two peaks indicating reception of the 2 LTS in the preamble. These peaks are typically accurate to ±0.5 sample periods. Due to sample phase/frequency offset there is still some ambiguity- one "peak" might be spread across two sample periods in the receiver. The Rx PHY selects the first pair of peaks separated by 64 Rx samples which exceed the static correlation threshold. The LTS correlator establishes all timing for the Rx pipeline. The correlation peaks sets the sample index of the first FFT with all subsequent FFTs following it.
The 802.11 standard defines an RX_START event which the PHY sends to the MAC when a reception is underway. Our PHY implementation asserts this RX_START signal after it decodes the SIGNAL field in a received packet. This event occurs a fixed time after the third FFT (first/second FFT are LTS, third is SIGNAL field), which means it occurs a fixed time after the LTS correlation peak. Thus, RX_START is your best bet for a sample-accurate indication of the timing of a given reception.
The MAC core captures the microsecond timestamp when the RX_START event occurs. This value is recorded by the MAC software in the rx_frame_info when the reception is processed by code. You're right that this process quantizes the sample-accurate RX_START to a 20-sample bin (20 samples/microsecond). You could use a 20MHz counter to get a more accurate RX_START value. A counter running faster than the sampling frequency won't provide any additional accuracy.
Offline
Yes, sorry I thought the IQ sample clock is 40MHz but I see now it is 20. This would give a 50ns resolution arrival time.
Thank you for the explanation. I suppose if RX_START was used then it would be accurate to extrapolate backwards and assume the first sample of the frame was received 4+8+8=20us prior.
You're right that this process quantizes the sample-accurate RX_START to a 20-sample bin (20 samples/microsecond).
Surely it quantizes this to a 160 sample bin as the usec counter is running at the system clock frequency of 160MHz (160 clks/usec)?
Offline
Surely it quantizes this to a 160 sample bin as the usec counter is running at the system clock frequency of 160MHz (160 clks/usec)?
The MAC and PHY core clocks run at 160 MHz, 8x the 20 MHz sample clock. The microsecond counter increments every 160 cycles of the core clock, equivalent to 20 cycles of the sample clock.
Offline
I see, ok thanks
Offline
Thank you for the explanation. I suppose if RX_START was used then it would be accurate to extrapolate backwards and assume the first sample of the frame was received 4+8+8=20us prior.
Sorry, I overlooked this question Friday. The RX_START event occurs about 25 usec after the first sample of a received waveform. This delay comes from the duration of the preamble (16 usec) and SIGNAL field (4 usec), and the demod/decoding delay for the SIGNAL field. I'm not sure what the precise number of sample periods is from waveform start to RX_START; you could figure this out pretty easily by simulating the Rx PHY model in System Generator. The RX_START event has a dedicated gateway out in the top-level "MAC Outputs" subsystem.
Offline
Thanks for the extra information. I have done this simulation in Sys Gen for each MCS mode and exported the time OFDM_RX_SIGNAL_VALID becomes high and also the time at which byte 16 is available to the MAC. The time for each mode in terms of samples is:
mcs rx_start byte16 0 3743 8887 1 3743 7579 2 3743 6351 3 3743 5711 4 3743 5167 5 3743 5119 6 3743 4672 7 3743 4672
I understand that the rx_start event always occurs at the same time, regardless of MCS mode since up until that point the frame structure is the same (preamble + MCS0 SIGNAL).
Is there anyway to reliably predict the time at which byte 16 will become valid? This is obviously dependent on the MCS mode but also the flow through the RX PHY. Is the decoding delay different depending on MCS?
The OFDM symbol index signal sym_ind in block FFT>Sym Count, is this zero for the SIGNAL field or one? Or perhaps does the first DATA symbol have ofdm index 1?
Thanks
Offline
Is there anyway to reliably predict the time at which byte 16 will become valid? This is obviously dependent on the MCS mode but also the flow through the RX PHY. Is the decoding delay different depending on MCS?
The overall demod/decoding delay for the packet payload (i.e. all post-SIGNAL symbols) is dependent on MCS. This is due to each MCS loading one OFDM symbol with a different number of bits, and the Rx PHY needing to operate on all the bits in a given OFDM symbol in the de-interleaver, then process symbols and bits serially thereafter. In the current Rx PHY implementation there are no iterative processing steps; the decoding delay for a given byte won't depend on Rx power or channel conditions. The delay for a given payload byte will change with MCS but will be the same for a given MCS across receptions. Your measurements above should suffice to reliably predict the decoding delay for byte 16 for each MCS.
You can also monitor the current decoded byte index from the MAC code using the wlan_mac_get_last_byte_index() function. We use this in wlan_mac_dcf.c to begin parsing the MAC header while the PHY is still receiving payload bytes.
The OFDM symbol index signal sym_ind in block FFT>Sym Count, is this zero for the SIGNAL field or one? Or perhaps does the first DATA symbol have ofdm index 1?
That sym_ind signal counts FFTs; symbols 0,1 are the LTS, 2 is SIGNAL, 3...N are payload.
Offline