ESP32 Forum

We're developing an IoT application around the Wrover module. In this application, the ULP collects sensor data every five minutes while the main processors are in deep sleep. Once every hour, the main processor wakes up, collects the measurement data from the ULP and decides on proper actions.
Because it is crucial for us to like a correct timestamp to each measurement, we added a 32kHz crystal to the hardware, however in the first version of the hardware we didn't get the crystal type right so we're using the internal 150kHz RC oscillator. The selection for crystal or RC oscillator is done in the "make menuconfig" tool, we compile separate firmware for the batch with the wrong crystals.

Unfortunately, we see erratic behavior from the gettimeofday() function that we use in the main program to get the current RTC time. When calling this function successively, the returned values differ up to 100 seconds in both directions while the main program itself only takes about 3 seconds to run. A latter call can return a lesser (older) value.

Successive calls to the gettimeofday() function in successive program runs with a 1 hour deepsleep period in between return values that can be wrong by as much as 6000 seconds, also going in both directions.

The newer hardware which sync RTC time with a 32kHz crystal don't show this erratic behavior at all.
I'm surprised that such a simple, basic function can produce such erratic behavior. I'm also surprised how hard it is to find documentation about the gettimeofday() function. For instance, what is the meaning of the integer value that is returned ?

Has anyone else experienced the same problem ?
Is gettimeofday() the correct function to use to get RTC time ?
Any known cures for this problem ?

additional information:

The ULP wakeup every 5 minutes, which we assume is derived from the same clock source (either 32kHz crystal or 150kHr RC) does happen relatively sharp every 5 minutes. We do see a difference in accuracy between the crystal and the RC oscillator - as to be expected - but not the extreme variations we get from the gettimeofday() function.

Fyi, gettimeofday is a posix function, and from what I know, the newlib implementation we use confirms to that. No idea why it jitters so much for you; are you sure you're reading the seconds field of tv and not accidentally the microseconds field?

i got a similar issue with settimeofday and gettimeofday that has been streamlined in the test here below:

============= an excerpt of my code ===========
time_t t = mktime(&tm);
now.tv_sec = t;
settimeofday(&now,NULL);
if (gettimeofday(&now,NULL) == 0)
printf("gettime success and now = %ld\n", now.tv_sec);
char *myDate = ctime(&now.tv_sec);
ESP_LOGI(TAG, "myDate: %s now %ld\n", myDate, now.tv_sec);
===========================================
returns
=============== from MONITOR ===============
now = 1665482054
gettime success and now = 1665480538
I (4641) EVT-HTTP_C: myDate: Tue Oct 11 09:28:58 2022
now 1665480538

===========================================

=======The initial time is acquired from a REST response as follows:
response = Tue Oct 11 09:54:14 2022
==================================================

since the settimeofday and the gettimeofday are adjacent they should return the same value for now.tv_sec
Vice versa they differ by "1516" (every time I run the code I got the same value)

do I make something wrong?
Thank you.

Do you zero-initialize 'now'? If there's garbage in the other fields, that may affect how the functions work.

Hi ESP_Sprite,
thank you for your answer.
Your hint was successful.
I tried the following:
struct timeval timeNow;
timeNow.tv_sec = 0;
but it did not work

At the end I come up to the following:
struct timeval timeNow;
settimeoftheday(&timeNow.tv_sec, NULL);
ESP_LOGI(TAG."myDate: %s and now: %ld\n", ctime(timeNow.tv_sec), timeNow.tv_sec);
which printed myDate: Thu Jan 1 01 00:00:06 1970
and now: 6

After that the "settimeoftheday + gettimeoftheday" is no more erratic.
I guess the dummy cycle above is needed for proper timeNow struct initializing.

Thank you.

sergiomarina wrote: Hi ESP_Sprite,
thank you for your answer.
Your hint was successful.
I tried the following:
struct timeval timeNow;
timeNow.tv_sec = 0;
but it did not work

At the end I come up to the following:
struct timeval timeNow;
settimeoftheday(&timeNow.tv_sec, NULL);
ESP_LOGI(TAG."myDate: %s and now: %ld\n", ctime(timeNow.tv_sec), timeNow.tv_sec);
which printed myDate: Thu Jan 1 01 00:00:06 1970
and now: 6

After that the "settimeoftheday + gettimeoftheday" is no more erratic.
I guess the dummy cycle above is needed for proper timeNow struct initializing.

Thank you.

struct timeval timeNow = {0};

You can't just ignore the structure members you are not interested in.

settimeoftheday(&timeNow.tv_sec, NULL);

This happens to work because tv_sec is the first struct member but don't do this.