802.11g Radio time to transmit

[SoftwareSamurai]

Out of curiosity, does anyone know how long it takes the radio to transition from listening to transmitting?

I'm testing the 802.11g OFDM 54 Mbps mode, so theoretically 1500 bytes should take about 212 microseconds to actually transmit. However, after timing the performance of the system, it appears to be taking well over 1200 microseconds from the time I call for a WiFi data packet to be transmitted until it actually completes. I'm trying to figure out if this large delay is mostly due to the internal firmware/libraries, or if perhaps the hardware itself is taking a rather long time to switch the radio from listening to transmitting mode, transmit the data, then switch back to listening mode.

[WiFive]

Probably it depends on wifi mode, api you are calling, context switching, and cca.

[SoftwareSamurai]

After a more detailed inspection, it appears that the radio time to transmit is sub-millisecond, but only when there's nothing else queued up for transmission. The large delay I was initially finding was only after several packets were queued up. I'm suspecting that there's possibly a delay between the end of one transmission and the start of the next one.

Does anyone know, or is it documented anywhere, exactly how the radio gets the outgoing packet data? I'm curious to find out where the delay is coming from between outgoing packets.

---
EDIT: I decided to put my my o-scope on my ESP32 and get some definitive timing stats. I've got my routine sending out a data packet 10x per second (every 100 ms).

Most of the time the radio transmits within ~150 us of queuing up the packet. This tends to jitter by +/- 25 us - not too bad. However, occasionally I'm seeing a more serious delay, anywhere up to 5 ms. Seems to happen randomly between 1 - 5 times per second. I'd like to find out what's causing these timing hiccups.

[ESP_Angus]

Most of the time the radio transmits within ~150 us of queuing up the packet. This tends to jitter by +/- 25 us - not too bad. However, occasionally I'm seeing a more serious delay, anywhere up to 5 ms. Seems to happen randomly between 1 - 5 times per second. I'd like to find out what's causing these timing hiccups.

Is it possible these are 802.11 frame retransmits (of either the frame you are sending or another queued frame)?

It's also possible the access point is playing some part in this. (Either taking some to acknowledge or doing something else on the channel.)

The best way to further dig into this will be to get a USB Wifi dongle which is capable of Monitor Mode and run a raw 802.11 traffic capture on the same channel as the ESP32. Wireshark gives quite good results for this.

[SoftwareSamurai]

Is it possible these are 802.11 frame retransmits (of either the frame you are sending or another queued frame)?

My scope clearly shows all packets transmitted by the ESP32 on my desk, and I don't see any extra transmissions - only occasionally delayed ones.

I'm toggling a GPIO pin every time I send a packet, so I can put one probe on that pin and connect the other probe directly to the antenna. Running a loop that transmits packets on a regular basis (such as 100/sec, or 10/sec, etc) I can easily see the timing between the GPIO pin pulse and the WiFi packet transmission. The GPIO pin pulse is perfectly accurate, precise, and exactly on time. The pulse for the transmission is clearly jittering around as I mentioned before.

It's also possible the access point is playing some part in this. (Either taking some to acknowledge or doing something else on the channel.)

I'm not connected to an AP. I'm in promiscuous mode w/ esp_wifi_set_mode( WIFI_MODE_NULL ); and I'm using esp_wifi_80211_tx(...) to send the packets.

The best way to further dig into this will be to get a USB Wifi dongle which is capable of Monitor Mode and run a raw 802.11 traffic capture on the same channel as the ESP32. Wireshark gives quite good results for this.

You're right, that would be the best way to verify the transmissions. I'll look into getting one of those.

But for now, I've actually got 2 more ESP32s running on the desk next to me, both doing nothing but listening for packets on the same channel. They appear* to be receiving only my transmitting ESP32. I'm only sending 802.11 DATA frames, and the only DATA frames these two listening ESP32s are reporting are from my transmitting ESP32.

* I say "appear to be" since promiscuous mode now filters certain types of packets, so I can't be absolutely sure of course.