WARP Project Forums - Wireless Open-Access Research Platform

1) We want to reculculate the backoff number (depends on some parameters we set, not necessary random) every time the WARP receives a non-ACK packet.
In wlan_mac_dcf_hw.mdl, it says

"Software-initiated backoff gets priority. But any "start backoff" is ignored if a previous backoff is still active."

How can we reset the backoff from software, so the "start backoff" is not ignored if a previous backoff is still active?

In the current (v0.92) implementation the backoff counter value can only be changed when its value is zero. When the counter has a non-zero value (i.e. a backoff is still pending), any attempts to change the counter value will be ignored. This behavior is our implementation of the 802.11-2012 section 9.3.3 requirement:

"After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff period (defined by Equation (9-1)) for an additional deferral time before transmitting, unless the backoff timer already contains a nonzero value, in which case the selection of a random number is not needed and not performed."

We are planning to add a software reset for the backoff counter in the next release of the reference design. This will enable explicitly changing the backoff counter value, even if its current value is non-zero.

2) We also want to detect collision in wlan_mac_dcf.c.
Could we use the RX_MPDU_STATE_FCS_GOOD or RX_MPDU_STATE_FCS_BAD as an indicator of the collision in physical layer?
Is PHY_RX_FCS_GOOD_IND the same as  RX_MPDU_STATE_FCS_GOOD?

PHY_RX_FCS_GOOD.IND is a 1-bit signal driven by the Rx PHY into the MAC core. This signal indicates the checksum status when a reception is complete. This signal is only valid when the PHY_RX_RX_END.IND signal is asserted.

The RX_MPDU_STATE_FCS_GOOD bit in the MAC status register captures the PHY FCS signal at the end of each reception and retains the value. This allows the MAC software to read the status at any time after the reception completes.

The FCS status only indicates whether the packet payload bytes were received without error. An FCS error indicates at least one bit error. This could be due to collisions, other interference, low SNR (i.e. noise), or PHY errors (poor AGC gain selections, bad CFO estimate, noisy channel estimates, etc.). Any post-decoder bit error will cause an FCS error.

One option for observing collisions is to run your experiment with multiple WARP nodes, retrieve the log files from each node and analyze their Tx/Rx events. Collisions will be apparent when two nodes record Tx events that overlap. You can also observe what non-transmitting nodes receive in these instances (i.e. capture effects when the SNRs of colliding packets are asymmetric).

We're working on new examples to demonstrate this sort of analysis. An early example is the Characterizing Collisions section in the multi-flow app note, where we used a Python script to calculate the time delta between colliding transmissions.

We're also working on an app to interactively visualize Tx/Rx logs. It looks like:


This is a zoomed-in view of ~5msec from the three-node experiment in the multi-flow app note. The X axis is time (increasing to the right). Each color is a flow (same colors as the app note plots). The "Tx" bars show the timing and duration of Tx events. Taller bars indicate re-transmissions. The "Rx" bars show the timing of receptions. The darker colors (like the dark green Rx event in the middle) indicate bad FCS receptions.

This 5msec view shows two collisions (red-blue and green-orange), plus a bunch of successful Tx/Rx events.

Here's a wider view -- same log file, zoomed out to 500msec:




We're hoping to post the first beta of this app soon. The current version is native to Mac OS X. We'll probably build a simpler (less interactive) version for Python too.

Really appreciate for your detailed reply!

1)Do you know the expected time for the next release?
If it might take a long time, or if you finally decide not to implement this feature, is it possible for us to implement it by ourselves?
If yes, could you give us some hints to implement this feature? Or, just conceptually tell us how to do it?

2)Thank you for illustrating the difference between PHY_RX_FCS_GOOD_IND and  RX_MPDU_STATE_FCS_GOOD.
Since we do not need to distinguish collision from all possible packet errors (we actually want all of them), RX_MPDU_STATE_FCS_GOOD is exactly what we want.
And thank you for providing a better way to detect collision; it will be very useful for our future examination.
The new app that interactively visualize Tx/Rx logs is pretty cool! Looking forward to its python version.