How accurate the cpu cloc frequency on the various esp8266 modules? Two issues - how accurate are the crystals on the boards, and how is 80 Mhz (or 160 Mhz) derived from the 26 Mhz crystal oscillators? The easiest way that I can see is to divide the 26Mhz by 13 (to reach 2.0 Mhz) and then use a PLL (or moral equivalent) to multiply that frequency by either 40 or 80 to reach 80 or 160 Mhz. I know that this is achievable (Microchip does it with some of their PIC24 and dsPIC33 parts), but I wonder how must jitter there is and how expensive in chip resources (or not). And in any case, 26Mhz seems to me to be an odd choice for a crystal frequency, but maybe they are used in great volume somewhere else.
ESP8266 Module Clock Frequencies
- Thread starter P. Short
- Start date
MartinMueller2003
Supporting Member
I can tell you that the clock on the ESP line of products is HORRIBLE as a real time source. I was seeing errors in excess of 1ms per second. If you really want an accurate clock get an I2C based RTC and keep it in sync with NTP.
So this means that if an ESP-based controller is outputting pixel data by itself without clock tuning (no RTC, no external synchronization) the pixels could be off by 0.6 seconds at the end of a 10 minute sequence (600 seconds * .001)? Probably quite noticeable.
And using multi-cast synchronization packets from a PC would have issues if a cheap AP is used (given the issues mentioned in other threads here) because of the lack of timing precision.
And using multi-cast synchronization packets from a PC would have issues if a cheap AP is used (given the issues mentioned in other threads here) because of the lack of timing precision.
MartinMueller2003
Supporting Member
That is correct and you can see it in the large number of corrections reported in FPP remote mode. As a data point, I have also seen a direct (but not significant) correlation between signal quality and the number of corrections performed. Poor signal performance results in fewer but larger time shifts when a sync packet makes it through.
I'm seeing different results. Using an ESP8266-01S, I don't see any timing errors after 7 hours. The sequence sends a seconds counter to the Arduino IDE serial monitor, and the number of seconds reported by the ESP exactly corresponds with the serial monitor timestamp. This is with a single sample at room temperature (if 64?F is room temperature) at whatever voltage the programming module is putting out. That is in good agreement with reports that I've seen on the internet (less than 1 second of error per day), as well as with the expected crystal tolerance (100 ppm stability tolerance and 50 ppm frequency tolerance seem to be the worst cases).
After 90 hours of run-time the ESP8266-01 has lost 6 seconds, or about 19ppm. Over a 10 minute sequence that amounts to .01 seconds, or 4 pixel updates at 40 fps. That is certainly good enough to ensure that the pixels are in sync with music (assuming they start simultaneously) without clock-rate compensation in each controller. It's likely not good enough for determining when to start playing a sequence, that would need a central controller sending out a multicast packet to all controllers.
This, of course, is in the context of my minimalist controller project.
This, of course, is in the context of my minimalist controller project.