Timestamp accuracy in wifi_promiscuous_pkt_type_t
Posted: Mon Jun 11, 2018 9:55 am
Hi all,
I have some technical questions about how esp32 puts timestamps to receiving packets, RTC accuracy and wifi in general.
I need to estimate packet reception times for an experiment and I use esp_wifi_set_promiscuous_rx_cb for this. I would like to be as accurate as possible or at least be able to assess inaccuracy. I don't have any unrealistic expectations either and I don't expect a gigantic accuracy. It would already be beautiful if I could reach an accuracy of about 20ppm.
I started using the micro() method at the beginning of my callback but I'm afraid that different elements will disturb the accuracy of my measurement (especially buffers if they exist). I couldn't find the accuracy of the esp32 internal clock in ppm. But I imagine it's in the order of 40ppm or more. For this reason, i use a 2ppm RTC and the pps pulse of a GPS to maintain a supplementary timestamp that uses micros() (or CPU cycle) for estimating µs of the second in progress.
To test my approach I made observations on packets of which I know and control the frequency of emission. There's a lot to consider, but overall, the measurements taken seem consistent. However from what I understand, the callback is not an interruption and can therefore suffer slight delays. I'm also afraid that the interruption generated by the clock will make me lose accuracy (I don't care if I lose a few packets).
Which brings me to my questions:
1) What delays can I reasonably expect between packet reception and callback call (in µs, ms)?
2) Can I assume that this delay is fairly steady? I compare time differences, so a stable delay would have little impact on my measurements.
3) I saw that wifi_promiscuous_pkt_type_t contains a timestamp field that I assume is assigned by the wifi driver. The precision is in µs and according to the comment, the timestamp is supposed to be accurate if you disable wifi energy saving. This seems to me to be a better choice to estimate the microseconds of the second in progress. At least that's what I thought because looking at the value of this packet I realize that the same value appears several times over a relatively long time range (500µs or 1ms). In practice the method described above is way more precise and this timestamp is completely useless in my case. I am puzzled because it is really counter-intuitive.
4) Are there buffers to disable at reception that could speed up the delivery of packages (dynamic_rx_buf_num or static_rx_buf_num) ?
5) For the moment I haven't tried to use the 32k signal of my clock with esp (pin 32 and 33 on esp-wroom32), because I didn't exactly understand if it would significantly impact this timestamp. Are there any references on that? I guess if I use interrupts for the clock I might disrupt the callback call.
For the moment I use Arduino-esp (I guess it's not necessarily the best choice?). In the callback I decode and keep the useful information in two lists that to manage the concurrency (10/15µs of treatment). On the second core, I use a task which dump the information (about 80 bytes a packet) on the serial port at a frequency of 1228800 baud every second. The frequency of the CPU is configured to be 240000000L.
Here is a small excerpt of the code :
Thank you for taking the time to read. Any feedback will be greatly appreciated.
Have a nice day,
Yoann
I have some technical questions about how esp32 puts timestamps to receiving packets, RTC accuracy and wifi in general.
I need to estimate packet reception times for an experiment and I use esp_wifi_set_promiscuous_rx_cb for this. I would like to be as accurate as possible or at least be able to assess inaccuracy. I don't have any unrealistic expectations either and I don't expect a gigantic accuracy. It would already be beautiful if I could reach an accuracy of about 20ppm.
I started using the micro() method at the beginning of my callback but I'm afraid that different elements will disturb the accuracy of my measurement (especially buffers if they exist). I couldn't find the accuracy of the esp32 internal clock in ppm. But I imagine it's in the order of 40ppm or more. For this reason, i use a 2ppm RTC and the pps pulse of a GPS to maintain a supplementary timestamp that uses micros() (or CPU cycle) for estimating µs of the second in progress.
To test my approach I made observations on packets of which I know and control the frequency of emission. There's a lot to consider, but overall, the measurements taken seem consistent. However from what I understand, the callback is not an interruption and can therefore suffer slight delays. I'm also afraid that the interruption generated by the clock will make me lose accuracy (I don't care if I lose a few packets).
Which brings me to my questions:
1) What delays can I reasonably expect between packet reception and callback call (in µs, ms)?
2) Can I assume that this delay is fairly steady? I compare time differences, so a stable delay would have little impact on my measurements.
3) I saw that wifi_promiscuous_pkt_type_t contains a timestamp field that I assume is assigned by the wifi driver. The precision is in µs and according to the comment, the timestamp is supposed to be accurate if you disable wifi energy saving. This seems to me to be a better choice to estimate the microseconds of the second in progress. At least that's what I thought because looking at the value of this packet I realize that the same value appears several times over a relatively long time range (500µs or 1ms). In practice the method described above is way more precise and this timestamp is completely useless in my case. I am puzzled because it is really counter-intuitive.
4) Are there buffers to disable at reception that could speed up the delivery of packages (dynamic_rx_buf_num or static_rx_buf_num) ?
5) For the moment I haven't tried to use the 32k signal of my clock with esp (pin 32 and 33 on esp-wroom32), because I didn't exactly understand if it would significantly impact this timestamp. Are there any references on that? I guess if I use interrupts for the clock I might disrupt the callback call.
For the moment I use Arduino-esp (I guess it's not necessarily the best choice?). In the callback I decode and keep the useful information in two lists that to manage the concurrency (10/15µs of treatment). On the second core, I use a task which dump the information (about 80 bytes a packet) on the serial port at a frequency of 1228800 baud every second. The frequency of the CPU is configured to be 240000000L.
Here is a small excerpt of the code :
Code: Select all
void setup(){
Serial.begin(MONITOR_SPEED);
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
esp_wifi_init(&cfg);
esp_wifi_set_storage(WIFI_STORAGE_RAM);
esp_wifi_set_mode(WIFI_MODE_NULL);
esp_wifi_set_ps(WIFI_PS_NONE);
esp_wifi_start();
esp_wifi_set_promiscuous(true);
esp_wifi_set_promiscuous_rx_cb(&sniffer_callback);
esp_wifi_set_channel(FIXED_CHANNEL,WIFI_SECOND_CHAN_NONE);
wifi_promiscuous_filter_t filter;
filter.filter_mask = WIFI_PROMIS_FILTER_MASK_MGMT;
esp_wifi_set_promiscuous_filter(&filter);
xTaskCreatePinnedToCore( genericTask, "genericTask", 10000, NULL, 1,NULL,1);
}
void genericTask( void * parameter ){
while(true){
//print
vTaskDelay(1000);
}
vTaskDelete(NULL);
}
void sniffer_callback(void* buff, wifi_promiscuous_pkt_type_t type){
uint32_t rtcTime = micros();
//decode and store to the list
}
void loop() {
vTaskDelay(1000);
}
Have a nice day,
Yoann