For better comparison it would be better to depicted the deviation not in absolute values (seconds per time interval) but relative in ppm (parts per million) All in all: A good video👍
Hilarious. The R4 minima actually HAS all the proper pads to place a proper crystal (so you can literally buy, and add it back yourself)... but they decided to penny pinch on that!? It's not placed on the board. If it had a proper crystal, and then the RTC based on the high speed clock, it would use normal chip power, but it should be as accurate as many other RTCs. Of course most MCUs also have their 'XTAL' pins, which allows operating the chip at very low power mode with a specific 32khz external crystal, which is nice if you want battery operation with decent timing. The R4 Wifi, well they decided they needed to sacrifice the crystal-stabilized high speed clock source entirely in order to use those pins for the LED display. Hilariously, the R4 Wifi is effectively two MCUs in one, it has an ESP32-S3 onboard as well. Because that is a chip-on-board module, it comes with its own honest-to-goodness 40Mhz crystal inside the metal can, that Arduino don't believe in. So if you can program it, the ESP32-S3 MCU's timing and RTC abilities are probably streets ahead on average better than what the RA4M1 can do, simply because the latter got gimped of all crystals by the board design. If you give these chips proper crystals on either of their high speed or low speed clock pins, they will have a reasonably accurate timing/RTC just the same as any other. For this reason all the ATMega328 Arduino Unos will be roughly accurate (as you found), operating as they are from a bog standard 16Mhz crystal. But at least they were given a crystal! If you calibrate the older Unos' frequency out (i.e, software correct the initial frequency error of the crystal as it is shipped in the board), they'll probably be just as accurate as any normal quartz watch. 10 years ago, I could forgive a lot of Arduino's design mistakes/decisions. But now, to see they can't even be bothered giving their chips proper crystals for timing? It makes it very hard to want to support them with a more expensive purchase from their shop. If I buy an ESP32 or RP2040 board from China, you know what I know? All those boards will come with a crystal...
I hear you. unfortunately placing the main oscillator does not even help because it cannot be used as clock source for the RTC. www.renesas.com/en/document/mah/renesas-ra4m1-group-users-manual-hardware?r=1054146 and they just left the pins for the sub-clock oscillator unconnected, very hard to solder.
thank you! I have two canon m50 one with the standard lens one with VILTROX EF-EOS M2 Speed Booster + Canon EF 50mm F1.8 STM two Rollei Lights: one Lumen Studio 150 in the front one Candela 120 RGB in the back I also use a very flat camera profile and apply custom LUTs
Would the RTC mismatch account for a timer triggered by holding a button to take longer than intended? For instance, instead of it taking 10 seconds, it takes 10.2 seconds?
without knowing the details, I'm pretty sure that the answer is no. Your timer will most likely run on the HOCO oscillator which has a tolerance of 1.5% (worst case would be 10.15s but very unlikely) I think there is some other code issue that causes this issue in your case.
The millis() drift is interesting. Given that it is interrupt driven, I rather suspect that any sketch which calls Arduino code where interrupts are disabled temporarily, will affect the drift too. It would be interesting to know what code you used to measure millis() on the Arduino in case something there disables the interrupts. Cheers, Norm.
@playduino Aha! While delay() itself doesn't disable interrupts, delay() calls micros() which does. It has to disable them to read the value of timer0_overflow_count which is used to calculate the micros() return value on the fly. Cheers, Norm.
@playduino I wrote a couple of books about the Arduino. You might like Arduino Software Internals which explains all this stuff, in excruciating detail! 😉
Interesting. I wonder if this time variance could be calibrated in a useful way. That may depend upon the device temperature variation. Nice explanation.
I just found this discussion. it should be possible. but as you already mentioned, I suspect temperature changes would still be a problem. forum.arduino.cc/t/how-to-correct-the-uno-r4-rtc-time-difference/1215333/18
I commented (and then tried again) but it got deleted. Probably because I posted a link to schematics. Anyway, what I commented was: I wonder if soldering a 32.768Khz oscillator, which are dirt cheap and common as sand, found in every cheap watch and wallclock, to pin 10 would make it drift less...
you would need to place a crystal between XCIN and XOUT (pin 6 and pin 7 of the chip itself) they are left unconnected on the PCB of both R4 MINIMA and R4 WIFI and have a very fine pitch so it will be hard. but possible indeed.
@@playduino I do have an R4 WiFi kicking around here, plenty crystals and the means _and_ skills to give it a try... I just don't have the same test setup as you... Also: The R4 is stil brand-spanking new (it was gifted to me) and I have an irrational reluctance to 'damage' new stuff... but I also need to know... Edit: Pin 6 goes to a via, goes left and pops up left of pin one on a SMD component. Will look into it a little more later.
the thing is, you will also need some software changes to enable the external crystal. I have no experience with the Renesas chip - but shouldn't be too hard I guess.
No computer should be used for clock reference w/o resorting to a proper clock. I use GPS if possible (1 sec tick interrupt - or faster - such as 25Hz in some applications). Properly setup I can get the interrupt in less than 100 ns (Rasp Pi, not sure for Arduino). (Stand alone RTL, no Linux). Of course with GPS you need access to a sky view. Or, use NTP for sub 10ms accuracy. Or - get a GPS disciplined oscillator - still needs a sky view.
My MacBook's clock gets synced to NTP at least every hour, I believe. Looking at the graph, I would expect to see noticeable jumps if the onboard clock was significantly inaccurate - which I didn't observe. I agree though, using GPS would be the best solution for these kinds of experiments. However Arduino Uno R4's RTC is so poor that you could probably use a McDonald's Happy Meal watch to measure the deviation
@@playduino It depends. When I use a random collection of about 50 ntp sites, the board timer (RaspPi) will drift 10 uSec over a period of about 1 hour, but then jump back (usually closer to realtime, but sometimes away) when the NTP hits. In these tests, Apple, Microsoft and some other "big name" NTP's typically come out with 1 - 3 ms error whereas others spread over about 1 - 10 ms. So your Apple devices benefit from Apple's "aggressively good" NTP service (unless you change the name of the NTP server to something not so good). This is based on very - very accurate - dedicated to task, single purpose code that owns the RaspPi (and of course getting 1PPS ticks from a GPS).
We say "point" not "dot" in english for the decimal point in the context you were using it. Pi is three point one four one five dot dot dot. It is such a minor error, sorry if you don't care. Anyway, it is so disappointing for the R4 to claim to have a RTC which doesn't actually work. At this point I don't know why you wouldn't just use a rpi pico or an esp32 (with an externl RTC module if required).
ShOcK & AWE. I AM OUTRAGED (that I didn't know this). GR8T story. I haven't been this intrigued since I found out my hot sister was adopted. Just saying Commendable reporting. You R 🂡🂱🃁🃑's with us
For better comparison it would be better to depicted the deviation not in absolute values (seconds per time interval) but relative in ppm (parts per million)
All in all: A good video👍
Yeah good idea, thank you :)
Fantastic video! I have no intention of using the RTC on any Arduino, yet I enjoyed the video. Very well presented!
Thank you :)
Hilarious. The R4 minima actually HAS all the proper pads to place a proper crystal (so you can literally buy, and add it back yourself)... but they decided to penny pinch on that!? It's not placed on the board. If it had a proper crystal, and then the RTC based on the high speed clock, it would use normal chip power, but it should be as accurate as many other RTCs. Of course most MCUs also have their 'XTAL' pins, which allows operating the chip at very low power mode with a specific 32khz external crystal, which is nice if you want battery operation with decent timing.
The R4 Wifi, well they decided they needed to sacrifice the crystal-stabilized high speed clock source entirely in order to use those pins for the LED display. Hilariously, the R4 Wifi is effectively two MCUs in one, it has an ESP32-S3 onboard as well. Because that is a chip-on-board module, it comes with its own honest-to-goodness 40Mhz crystal inside the metal can, that Arduino don't believe in. So if you can program it, the ESP32-S3 MCU's timing and RTC abilities are probably streets ahead on average better than what the RA4M1 can do, simply because the latter got gimped of all crystals by the board design. If you give these chips proper crystals on either of their high speed or low speed clock pins, they will have a reasonably accurate timing/RTC just the same as any other. For this reason all the ATMega328 Arduino Unos will be roughly accurate (as you found), operating as they are from a bog standard 16Mhz crystal. But at least they were given a crystal!
If you calibrate the older Unos' frequency out (i.e, software correct the initial frequency error of the crystal as it is shipped in the board), they'll probably be just as accurate as any normal quartz watch.
10 years ago, I could forgive a lot of Arduino's design mistakes/decisions. But now, to see they can't even be bothered giving their chips proper crystals for timing? It makes it very hard to want to support them with a more expensive purchase from their shop. If I buy an ESP32 or RP2040 board from China, you know what I know? All those boards will come with a crystal...
I hear you.
unfortunately placing the main oscillator does not even help because it cannot be used as clock source for the RTC. www.renesas.com/en/document/mah/renesas-ra4m1-group-users-manual-hardware?r=1054146
and they just left the pins for the sub-clock oscillator unconnected, very hard to solder.
Love to image quality & color grading of your vids. May I ask what camera & lighting setup you are using? Thanks!
thank you!
I have two canon m50
one with the standard lens
one with VILTROX EF-EOS M2 Speed Booster + Canon EF 50mm F1.8 STM
two Rollei Lights:
one Lumen Studio 150 in the front
one Candela 120 RGB in the back
I also use a very flat camera profile and apply custom LUTs
Would the RTC mismatch account for a timer triggered by holding a button to take longer than intended? For instance, instead of it taking 10 seconds, it takes 10.2 seconds?
without knowing the details, I'm pretty sure that the answer is no. Your timer will most likely run on the HOCO oscillator which has a tolerance of 1.5% (worst case would be 10.15s but very unlikely) I think there is some other code issue that causes this issue in your case.
how does it compare to a ds13xx RTC module?
DS13xx should win easily
The millis() drift is interesting. Given that it is interrupt driven, I rather suspect that any sketch which calls Arduino code where interrupts are disabled temporarily, will affect the drift too. It would be interesting to know what code you used to measure millis() on the Arduino in case something there disables the interrupts.
Cheers,
Norm.
for millis testing, I just did
loop(){
delay(1000);
Serial.println(millis());
}
@playduino Aha! While delay() itself doesn't disable interrupts, delay() calls micros() which does. It has to disable them to read the value of timer0_overflow_count which is used to calculate the micros() return value on the fly.
Cheers,
Norm.
Oh! Great catch! I need to look into this
@playduino I wrote a couple of books about the Arduino. You might like Arduino Software Internals which explains all this stuff, in excruciating detail! 😉
I will have a look :) thx
Interesting. I wonder if this time variance could be calibrated in a useful way. That may depend upon the device temperature variation. Nice explanation.
I just found this discussion. it should be possible. but as you already mentioned, I suspect temperature changes would still be a problem.
forum.arduino.cc/t/how-to-correct-the-uno-r4-rtc-time-difference/1215333/18
A programmer recently told me that Javascript is a vibes-based language.
Similarly, that LOCO oscillator is a vibes-based timepiece.
:D
Been a while since I saw a pebble watch
Great video!
I commented (and then tried again) but it got deleted. Probably because I posted a link to schematics. Anyway, what I commented was: I wonder if soldering a 32.768Khz oscillator, which are dirt cheap and common as sand, found in every cheap watch and wallclock, to pin 10 would make it drift less...
you would need to place a crystal between XCIN and XOUT (pin 6 and pin 7 of the chip itself) they are left unconnected on the PCB of both R4 MINIMA and R4 WIFI and have a very fine pitch so it will be hard. but possible indeed.
@@playduino I do have an R4 WiFi kicking around here, plenty crystals and the means _and_ skills to give it a try... I just don't have the same test setup as you... Also: The R4 is stil brand-spanking new (it was gifted to me) and I have an irrational reluctance to 'damage' new stuff... but I also need to know...
Edit: Pin 6 goes to a via, goes left and pops up left of pin one on a SMD component. Will look into it a little more later.
the thing is, you will also need some software changes to enable the external crystal. I have no experience with the Renesas chip - but shouldn't be too hard I guess.
@@playduino Yeah, I think I'm not gonna bother. Though this will probably keep itching...
someone already did it :D
radiopench.blog96.fc2.com/blog-entry-1280.html
forum.arduino.cc/t/how-to-correct-the-uno-r4-rtc-time-difference/1215333/18
Esp32 + time API = good clock
as long as there is internet I guess? or if you have a good external oscillator.
No computer should be used for clock reference w/o resorting to a proper clock.
I use GPS if possible (1 sec tick interrupt - or faster - such as 25Hz in some applications). Properly setup I can get the interrupt in less than 100 ns (Rasp Pi, not sure for Arduino). (Stand alone RTL, no Linux).
Of course with GPS you need access to a sky view.
Or, use NTP for sub 10ms accuracy.
Or - get a GPS disciplined oscillator - still needs a sky view.
My MacBook's clock gets synced to NTP at least every hour, I believe. Looking at the graph, I would expect to see noticeable jumps if the onboard clock was significantly inaccurate - which I didn't observe.
I agree though, using GPS would be the best solution for these kinds of experiments.
However Arduino Uno R4's RTC is so poor that you could probably use a McDonald's Happy Meal watch to measure the deviation
@@playduino It depends.
When I use a random collection of about 50 ntp sites, the board timer (RaspPi) will drift 10 uSec over a period of about 1 hour, but then jump back (usually closer to realtime, but sometimes away) when the NTP hits.
In these tests, Apple, Microsoft and some other "big name" NTP's typically come out with 1 - 3 ms error whereas others spread over about 1 - 10 ms.
So your Apple devices benefit from Apple's "aggressively good" NTP service (unless you change the name of the NTP server to something not so good).
This is based on very - very accurate - dedicated to task, single purpose code that owns the RaspPi (and of course getting 1PPS ticks from a GPS).
very interesting topic, thank you for the details!
We say "point" not "dot" in english for the decimal point in the context you were using it. Pi is three point one four one five dot dot dot. It is such a minor error, sorry if you don't care.
Anyway, it is so disappointing for the R4 to claim to have a RTC which doesn't actually work. At this point I don't know why you wouldn't just use a rpi pico or an esp32 (with an externl RTC module if required).
Thank you for pointing this out 😅
Yeah - it’s horrible
ShOcK & AWE. I AM OUTRAGED (that I didn't know this). GR8T story. I haven't been this intrigued since I found out my hot sister was adopted. Just saying Commendable reporting. You R 🂡🂱🃁🃑's with us