I am using the "esp_wifi_80211_tx" function to send a packet that looks like one of the valid acceptable 802.11 frame types, but with a custom payload. The transmitter does this at 20ms intervals. after about 8ms of each transmission, I use the "esp_wifi_set_channel" to change between channel 1 and channel 13, once per transmission. I used a spectrum analyzer and indeed the transmitter is able to transmit on channel 1, or channel 13, or hop between both channel 1 and 13. Bandwidth is forced to 20 MHz using "esp_wifi_set_bandwidth(WIFI_IF_AP, WIFI_BW_HT20);"
Important to note that my payload contains a salted checksum, a sequence number, the channel it was actually sent on, and other helpful metadata.
On the receiver, promiscuous mode is enabled, "esp_wifi_set_promiscuous_filter" is used to filter the frame type I am masquerading as, "esp_wifi_set_promiscuous_rx_cb" hooks up a handler, and the handler checks the payload of the packet to see if the checksum indicates that it was sent by my own transmitter, it also checks the sequence number to reject duplicate transmissions. If needed, the receiver frequency hops in-sync with the transmitter.
The receiver keeps track of statistics: valid packets, missed sequence numbers, invalid packets (basically all callbacks that don't result in a valid packet), etc.
This setup works fine when I configure the transmitter to transmit at 50 packets per second and frequency hopping between channel 1 and 13. If I disable frequency hopping and transmit at 100 packets per second, I drop about 30% of packets. If I enable frequency hopping and transmit at 50 packets per second, I drop about 50 % of packets.
In an attempt to investigate, I toggle GPIO pins after calling "esp_wifi_80211_tx", another pin after "esp_wifi_set_channel", and another pin after the promiscuous handler detects a valid packet. I use a logic analyzer to see the timing of the transmission vs timing of the reception. Two receivers are placed in non-hopping mode, so one receiver is listening only on channel 1 and the second receiver is only listening on channel 13. What I expect to see is the transmission-indicator toggling very fast, and two reception-indicators toggling half as fast and out-of-phase with each other.
At 50 pkt/sec with frequency hopping enabled, I observe the following
- e32rcrad_freqhop_logic_50hz.fw.png (430.11 KiB) Viewed 1145 times
What this indicates is that calls to "esp_wifi_set_channel" does not happen immediately, perhaps there is a queue of packets to be transmitted before the channel is changed.
At 100 pkt/sec with frequency hopping, I observe the following
- e32rcrad_freqhop_logic_100hz.fw.png (374.99 KiB) Viewed 1145 times
This is bad, too many losses
At 100 pkt/sec with frequency hopping, I observe the following
- e32rcrad_nohop_logic_100hz.fw.png (348.2 KiB) Viewed 1145 times
This is extremely interesting because it seems like either the transmitter is transmitting on a scheduler, or the reception is calling the callbacks on a scheduler.
Now, to help me, what I need is basically a way to determine if "esp_wifi_80211_tx" has completed a transmission (or a blocking version of "esp_wifi_80211_tx"), and also I need a way to determine if "esp_wifi_set_channel" has finished actually changing channels. Hopefully maybe there's some low level registers with some flags that can be checked?
Alternatively, if there's a way to override the scheduler of the transmission so that it's faster and not bursty, it'll help.
Thanks
(yes I am aware of the existence of ESP-NOW, I have reasons not to use it, I have reasons not to use Wi-Fi as-is, I also have this project going on a nRF52840 already so that's my fallback, but I still prefer ESP32 since I can run a web gui to do some configuration stuff without writing an android app)