gettimeofday() still useless across a deep sleep

[eyaleb]

This was raised before but I see no change.

I save gettimeofday() befoer a deep sleep (5s in my test) and then subtract it from gettimeofday after the wakeup. The result goes wild very soon, often over 15s and even negative at times.

Does the API provide a time that is monotonic, regular (even if not very accurate) since the last reset?
I understand that the RTC has a timer that keeps running even in deep sleep, how can it be accessed?

TIA

[ESP_igrr]

For the record, this is the earlier topic where this was discussed: https://esp32.com/viewtopic.php?f=13&t=1908

The issue identified in that topic isn't fixed yet, but we'll update the topic once it is.

[eyaleb]

This time I also asked

I understand that the RTC has a timer that keeps running even in deep sleep, how can it be accessed?

Can this be done? Even if this clock is inaccurate.

TIA

[ESP_igrr]

You can access RTC counter using rtc_time_get function declared in "soc/rtc.h".

[eyaleb]

I was looking at it. I am now evaluating it. It has a very tight relationship to temperature. I have a ds18b20 on the board adjacent the module and this is what I see:

esp-32c.jpg (98.76 KiB) Viewed 19106 times

The red line (right scale) is the temperature and the green (left scale) is the ratio of tick count to wall time during the last app cycle (about 6 seconds). The left scale is the deviation of the ratio from a value of 6.0, so a ratio of 6.69 is plotted as 0.69. This line is dampened by a sliding average of 10 readings.

The blue line is the average ratio for the whole run, so a ratio of 6.7 can be used in the absence of temperature reading. The ratio varies slightly from module to module.

Do we have access to the internal temperature sensor? I see the registers are present in components/soc/esp32/include/soc/sens_reg.h but no API is in the doco.

[ESP_igrr]

Very nice graph! 6.7 us / tick seems to be fairly close to the nominal period of RTC_SLOW_CLK (1 / 150kHz).

We don't have an API for temp sensor, however you should be able to read it by accessing registers:
https://github.com/espressif/esp-idf/bl ... st_tsens.c

Making a library/component which would dynamically adjust clock calibration value based on temp sensor readings would be nice. If you end up writing something like this, please consider making a PR on Github

With regards to the other issues you have raised previously, they have been fixed and will be on Github as soon as we fix some broken build infrastructure...

[eyaleb]

Thanks ESP_igrr,

I added the code and it reads a value of 111 (room temp is 18dC). Holding a finger to it takes it to 113 and it quickly returns to 111.

All the doco says about this sensor is that it has a linear temperature response, units not mentioned. I guess I will need to test and see if it has a specific reference value (does it change between modules?).

I will attempt to write a temperature compensation function for the 150KHz clock. So far it seems that the clock has a linear response to temperature, which should make the job easier.

It will take many days to monitor the changes and come up with the necessary data. I have only 3 modules but it is a start.

[later]
My three modules are sitting near each other, all showing a similar temperature (12dC) using a ds18b20. The TSENS reads 97, 108, 113...
This is going to be some fun Here is a first stab, using a linear function based on measurements at 10dC and 25dC.

esp-32c-20170617-2353.jpg (98.38 KiB) Viewed 19060 times

The brown line is the calculated time/ticks ratio. As before, the green is the measured ratio and the red is the ds18s20 temperature.
The plots are dampened (8 point average), the actual data is much more jittery

esp-32c-20170617-2358.jpg (99.71 KiB) Viewed 19060 times

Looks like TSENS has a resolution of 2dC.

[ken2004]

From the graph it looks like like the 2 degree resolution is less than ideal. The offset between the 3 devices is also too big but that is due to the sensor technology. I remember reading the DS18B20 overcomes the same issue by physically calibrating every sensor with laser trimming. This level of offset error is too great for many other potential applications as well.
To quote from the ESP32 Technical Reference Manual V1.8

Also, temperature-versus-voltage characteristics have different offset from chip to chip, due to process variation.
Therefore, the temperature sensor is suitable mainly for applications that detect temperature changes rather than
the absolute value of temperature.

So when

Making a library/component which would dynamically adjust clock calibration value based on temp sensor readings would be nice. If you end up writing something like this, please consider making a PR on Github

it would also need calibration of the temperature sensor offset on each device.

Eyaleb is using the temperature sensor to scale the timer but the opposite is possible too. An accurate timer can calibrate the temperature sensor offset. It only needs to be done once for each esp32 instance and once calibrated the algorithm to scale the inaccurate timer is the same for each esp32 instance. Also the temperature sensor would be then useful for lots of other things as well.

The ideal place to store the calibration offset would be in nvs (2) which is already used for WiFi data and PHY calibration data.

[eyaleb]

I am at the early stages of collecting data. I do not even know how truly linear the relationship is.
This morning I used a hair dryer to keep the esp around 40dC for 10 minutes in order to get a high temp data point. Leaving it outside for the night should take care of the other side

[eyaleb]

The recent commit seems to have fixed the bad gettimeofday(). Thanks.

I now have a question: how does one retrieve the time in us without the excess arithmetic?

ATM I have (in time.c) a simplifies gettimeofday:

Code: Select all

uint64_t IRAM_ATTR gettimeofday_us(void)
{
#if defined( WITH_FRC1 ) || defined( WITH_RTC )
    return get_boot_time() + get_time_since_boot();
#else
    __errno_r(r) = ENOSYS;
    return 0;
#endif // defined( WITH_FRC1 ) || defined( WITH_RTC )
}