Painlessmesh / Time sync time roll

[Gyula Muntyán]

Hi, all!

It is said in the code that Mesh time rolls over every 71 min (that's okay uint32_t max = 4,294,967,295 usec ~ 71 min). 

May I change it's type to uint64_t which is enough big to keep it for... years?

Thank you for your answers

Best regards

Gyula

[Paul Gordon]

Unfortunately not in practical terms. Changing the data type is easy enough but in my limited understanding the value is seeded from (and compared to) the ESP32 micros() function so will never exceed uint32_t. In my use of the code I rely on the unsigned integer rollover logic to handle negative offsets. For me changing to uint64_t would be a breaking change.

Sorry :-(

[Gyula Muntyán]

I understand, thank you for your answer! No problem, I will use integer overflow detection too...

[Eric Marks]

A lot of projects use the PainlessMesh's shared time base to synchronize effects in FastLED.

This is the most common solution:

uint32_t get_millisecond_timer() {
   return mesh.getNodeTime()/1000 ;
}

Fastled has a flag:

#define USE_GET_MILLISECOND_TIMER
Set this flag to use the get_millisecond_timer() function in place of the default millis() function.

Unfortunately, this causes a visual glitch in FastLED effects on rollover (every ~71 minutes).

To work around this, I changed "micros()" to "millis()" on the 41th line of ntp.hpp, and changed #define TIME_SYNC_ACCURACY 5000 (microseconds) to #define TIME_SYNC_ACCURACY 5 (milliseconds).

This changes the shared clock to milliseconds, and effectively pushes the rollover issue out to ~50 days, far beyond the battery life of my project.

So far it seems to work well, I'll reply with updates if I run into issues.