esp32 wrover devkit c - clock accuracy problems

[lafar6502]

Hi, im trying to do some semi-accurate time measurements, using esp_timer_get_time function.
According to documentation esp_timer_get_time function returns time in microseconds. But when i'm doing some calculations (to be precise, counting AC mains pulses, or zero crossings of the AC sine wave), i get astonishing results. The frequency calculated can be 80 Hz, or 90Hz, depending on the CPU clock frequency setting in the menuconfig. The zero-crossing detection circuit is rather accurate, i tested it some time ago on arduino and got exact 100Hz [50Hz x 2], but now i feel like I'm going crazy. Dont have an oscilloscope or another ultimate way of checking the signal timing so it's mostly guessing.
So my questions:
- is there a good way to verify clock functions accuracy in ESP32, especially esp_timer_get_time
- what configuration options affect the frequencies / timing calculations done by esp time functions? Is it always pre-set correctly or are there timing differences between boards, different bus clock settings that you can get wrong? ARM-based boards have tons of clocks options and its a whole science to get this right, but esp32- i dont know.

[ESP_Sprite]

What code do you use to detect these zero crossings?

[lafar6502]

just attached an interrupt to gpio line that signals the zero crossing and i'm counting how many times the isr gets called / versus the time elapsed in esp_timer_get_time.

something like

Code: Select all

int counter = 0;
void isr() {
counter++;
}

void main() {
var tstart = esp_timer_get_time()

while (true) {
    delay(1s);
    var tDelta = esp_timer_get_time() - tstart;
    var frequency = (counter / tDelta) * 1000000; 
    printf('frequency is %f\n', frequency); //here i get 
}
}

i dont have the actual code here (different office/computer) but it's more or less the logic. And the frequency should be 100Hz because zero cross happens twice per AC cycle - i'm getting 160 or 180 instead, depending on how i set the cpu clock in menuconfig.
btw interrupt is triggered by pos edge (rising edge)

Question #2: does the gpio interrupt need to be acknowledged / reset somehow in the isr? the example from esp-idf doesnt do any ack but just making sure.

[lafar6502]

and i will do some time measurements with a stopwatch in the evening or tomorrow.

[lafar6502]

for now it appears that this is hardware problem but not in esp32 - the zero detection board has some noise problems and inserts random spikes every few cycles. And of course the maker of this device is absolutely convinced that the world is broken but not his part. - dosent seem to respect word of anyone who doesnt have a PHD in electronics and half-million$ oscilloscope..

[lafar6502]

... but its a nice exercise in debugging signals without proper hardware. Found the problem - the zero detection circuit introduces some chaos at the detected pulses: there's some bouncing back and forth at the start and end of zero detection pulse. And ESP32 picks this up as multiple interrupts in quick succession. So some simple debouncing was needed - if we get an interrupt we ignore all other interrupts for 2 ms. Its short enough not to miss next AC cycle, but long enough to clean up all false signals.

[ESP_Sprite]

Good to hear you solved it, and thanks for posting what the issue was.