You are not logged in.
Hello, we are currently investigating the PHY timing parameters of the 802.11 reference design, version 1.4. Specifically we are interested in the actual value of the SIFS time and the value described in the standard as aPHY-RX-START-Delay.
We have used a high speed oscilloscope to capture the RF waveform and also some digital debug signals from the board. Our configuration is roughly as here. Digital and RF cables add a negligible 1ns propagation delay.
The test is a single 10 byte frame at mcs0 transmitted from a warp STA to a warp AP. We trigger the scope on the dbg_tx_running signal (pin 0 on the debug header v1.4) of the STA. We use the scope to capture the entire sequence from STA TX through AP TX of the ACK. The STA is unmodified, other than minor sw changes to cpu high for frame generation. The AP has modified hw to allow extended debugging. Specifically we have added three internal signals to the debug header. These are the Status_Tx_PHY_Active and Status_Rx_PHY_Active signals from the wlan_mac_hw pcore and Status_PostRx_Timer1_Running.
Here are screen shots of our results. Here for an overview. Yellow is the RF. Blue is the dbg_tx_running from the STA. Red where shown is the 80MHz sample clock. The seven outputs from the modified AP debug header are shown at the top of the screen and represent these seven signals in the .mhs file:
dbg_timer_running & dbg_tx_active & dbg_rx_active & dbg_pkt_det_ofdm & dbg_dsss_rx_active & dbg_ofdm_rx_active & dbg_tx_running, DIR = O....
We've seen the thread here and your earlier study but how do we get an accurate value for aPHT-RX-START-Delay? We're fairly certain it ends at the RX_START_IND signal, i.e rising edge of dbg_rx_active. But where does it start? Should we take the first sample, or dbg_tx_running (from STA) or perhaps the pkt det signal at the auto correlation?
If you simulate the rx phy in matlab simulink with the same signal, the time from first sample to RX_START_IND is 3743 clock cycles, 23.4us. Should this exactly represent what we see on the scope?
Similarly for the SIFS period. Where should we measure from? From what appears to be end of STA samples to start of AP samples gives exactly 16us. The timer runs for 7.8us.
For our application we aim to decrease the frame detection time (to valid SIGNAL) so aPHY-RX-START-Delay is of most importance to us and hence why we are trying to characterise it precisely.
Thanks
Last edited by horace (2016-May-22 09:34:43)
Offline
The value of aPHY-RX-START-Delay is determined by:
-Duration of the waveform from first sample to end of SIGNAL (16 + 4 µsec for preamble + SIGNAL symbol)
-RF/analog circuit latency (antenna port -> LNA -> mixer -> VGA -> ADC)
-Rx PHY SIGNAL demod/decoding latency
None of these are tunable. The only way to reduce aPHY-RX-START-Delay would be to shorten the preamble or speed up the Rx PHY. One way to effectively reduce the preamble duration is to increase the sampling rate. The v1.5 design supports a double-clocked 40MSps mode which cuts the preamble and OFDM symbol duration in half. This is definitely a non-standard waveform.
If your goal is to reduce the DATA-ACK turnaround it is possible to reduce the SIFS duration. The limiting factor here is the latency of the lower MAC software enabling Tx controller B for transmitting the ACK. In wlan_mac_dcf.c : frame_receive() this is the code between wlan_mac_hw_rx_finish() and wlan_mac_tx_ctrl_B_start(1). This code executes during the first part of the SIFS interval, which starts at RX_END. We characterized this "SIFS slack" a few releases ago and found we had many µsec margin from software enabling tx_ctrl_B to the actual ACK Tx. You could characterize this in your setup by asserting a GPIO after wlan_mac_tx_ctrl_B_start(1) and comparing it to the Tx PHY status.
P.S.- I'm very envious of your oscilloscope- those are *really* useful visualizations of the MAC/PHY/RF timing relationships.
Offline
One followup to murphpo's comment about reducing the SIFS. The frame_receive() context in the DCF uses the packet length to figure out whether or not it has time to do some Rx processing before waiting on an FCS decision and setting up the tx_ctrl_B system for ACK transmission. It compares this length to a threshold called "RX_LEN_THRESH," which defaults to 200 bytes in the Reference Design. If the length is longer than this value, the code knows that it will be a while before it gets to the SIFS region where it needs to set up tx_ctrl_B. If it's shorter, it prioritizes setting up tx_ctrl_B before doing any extra processing.
If you want to reduce the SIFS, I'd recommend raising the value of RX_LEN_THRESH to the maximum packet size you'd ever receive so that everything is treated as a "short packet" and tx_ctrl_B gets set up as quickly as possible.
Offline
Thanks for the info on SIFS, however, reduction of SIFS is not really possible for our application. We are more interested in the behaviour of a device regarding it's ACKTimeout period. This is comprised of ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay.
We have found that aSIFSTime varies based on the device/chipset. The warp is exactly 16us but in commercial devices it can vary in the order of micro seconds.
aPHY-RX-START-Delay seems poorly defined since the standard sets it to 24us(g), 25us(a), 33us(n) but it's actual value varies since, from the boards perspective it's difficult to know when the first sample arrives.
In v1.4 it appears to be less than 25us but only just. Like you say, this is dependent on the fixed values of preamble/SIG + RF components and the SIGNAL decoding latency. This decode latency is dependent on the PHY clock speed/PHY architecture so will be dependent on device/chipset.
Therefore the per implementation value of ACKTimeout varies on aSIFSTime and aPHY-RX-START-Delay. If a device detects a waveform and computes the SIGNAL in less than 24/25/33us, should it wait until the standardised value of aPHY-RX-START-Delay until it asserts PHY_RX_START_IND? Therefore it will be standard across all devices.
Sadly non-warp boards don't provide a debug output for PHY_RX_START_IND, so it's tricky to calibrate them...
Also - what is going on here? Is this time between last sample and the PA powering down? Where should the SIFS value start in this case?
Offline
Also - what is going on here? Is this time between last sample and the PA powering down? Where should the SIFS value start in this case?
I think that is the radio's transition from Tx mode to standby (then to Rx, not visible here). The Tx PHY controls the radio's Tx/Rx/standby state. The Tx PHY holds the radio in Tx mode for a programmable period after the PHY has driven the last sample to the DACs. This delay is required to allow the last sample to propagate through the DACs and RF circuits. The delay is configured via the wlan_phy_tx_set_txen_extension() function in units of sample periods (hence being used in set_phy_samp_rate()). Your plots indicate we could safely reduce the txen_extension by ~1 usec at 2.4GHz.
Therefore the per implementation value of ACKTimeout varies on aSIFSTime and aPHY-RX-START-Delay. If a device detects a waveform and computes the SIGNAL in less than 24/25/33us, should it wait until the standardised value of aPHY-RX-START-Delay until it asserts PHY_RX_START_IND? Therefore it will be standard across all devices.
It's an interesting question - I'm not sure how commercial devices handle it. Our Rx PHY implementation will assert RX_START as soon as possible during a reception. We use the spec's definition of aPHY-RX-START-Delay to define the timeout window. As long as our PHY's actual RX_START delay is less than the spec's aPHY-RX-START-Delay, we can trust the absence of an RX_START event during the timeout window to indicate the absence of an ACK.
Every device should use the same value for aPHY-RX-START-Delay when computing the timeout duration so that every device has a fair chance of regaining control of the medium for their re-transmission. This is analogous to all devices starting their DIFS windows at the same instant so their backoff slots are aligned and collisions only occur when nodes draw the same random number of slots. Our current code doesn't handle this perfectly- we use 'gl_mac_timing_values.t_phy_rx_start_dly' to both define the timeout duration and to adjust RX_START timestamps to align with TX_START timestamps. The latter should have its own empirical param ("RX_START_TIMESATAMP_LATENCY" or similar); we'll enqueue this for the next release.
One parameter that will affect our PHY's RX_START timing is the "FFT Window Offset" set by wlan_phy_rx_set_fft_window_offset(). This parameter controls where the Rx PHY sets its window for selecting 64-in-80 samples, controlling (on average) how many cyclic prefix samples are consumed by the FFT. A larger offset provides more tolerance for synchronization errors in the LTS correlation but reduces the PHY's delay spread tolerance.
We define RX_END as N OFDM symbol intervals after the assertion of the LTS correlator so that RX_END (and things derived from it, like the start of DIFS/SIFS) don't depend on our demod/decoding latency. This also allows the Rx PHY to assert a proper RX_END for unsupported waveforms.
We have found that aSIFSTime varies based on the device/chipset. The warp is exactly 16us but in commercial devices it can vary in the order of micro seconds.
We observed the same thing early in our design when working with some Wi-Fi devices. We were surprised to see how much the ACK Tx time varied relative to the DATA Tx time, definitely more than the ±10% T_SLOT allowed by the spec.
Offline