Clock accuracy Bangle.js 2

I bought a Bangle.js 2 half a year ago. One thing that been bothering me is how inaccurate the clock is, drifting a minute over a week. At first I thought the 32768Hz xtal were saved to use pins for something else, but recently saw it is mounted on a picture. Failed to find a schematic.
Now I am wondering why oscillator is configured to internal RC? I know the softdevice can calibrate it to about 250ppm, good enough for BLE with cost of extra power consumption. But seems strange why xtal not used they usually 20ppm if balanced properly.

Anyone knows reason behind it?

I am wondering why oscillator is configured to internal RC?

I think it is not like that. For bangle 2 32768Hz xtal is used however it is still inaccurate. However when switching to RC (you may try with this line commented out) it becomes much worse so I guess it is what it is. Search this forum, there were some attempts to autoadjust/correct this over time, maybe even some app. It is supposed to be synced periodically when connected to the phone so not the best crystals are used in these smart watches.

There is https://banglejs.com/apps/?id=widadjust

Thank you for response. In mean time I also figured out I were wrong about setting, had some issues get it to build and didn't have overview where build configs were.
It look like softdevice setup for 20ppm tolerance, it should be adjusted to more realistic tolerance else it can give random disconnects on Bluetooth.

As @fanoush says - it's using the oscillator, it's just not that accurate.

I think the vast majority of devices do fall within 20ppm (which'd be 2-3 seconds a day I guess) - that seems a pretty standard tolerance for 32kHz oscillators. Are you sure yours is really off by as much as a minute a week?

I did not measure it precisely, my reply was based on the example in the app linked which based on 5 sec drift in 24 hours which is over 50ppm.
I will try measure it more precisely.
20ppm is 1.7s per day.
I have two Banglejs 2, the first is where I experienced big drift, only had the 2nd for a week and have feeling it more accurate.

For me and my wife "Adjust Clock" solved the issue completely.
Almost no more drift during the whole year. So the offset seems to be pretty fix and not influenced by temperature much (at least on the wrist when outside and within range of room temperatures inside). Before she had 3-4 minutes a month.

OK I did some measurements on my two watches.
First is about 54 PPM.
Second is about 20 PPM.
With the first I experienced many disconnect when connected to my PC to upload new software and such. Especially in beginning. Second watch is much more stable connected. I do believe it would be better to configure softdevice to 50 PPM tolerance on LFCLK.

Very interesting - thanks! I've just pushed an update that lowers expected accuracy to 50ppm when using an external crystal - I'd be really interested to see if that solves your connection problems.

Sorry to hear that Bangle's so far off though - I'm not sure how the crystal used ended up being so out of range.

One option might actually be to not use the xtal on that watch. Then it'll calibrate using the high speed one which might actually end up being more accurate. The difference in power usage is unlikely to be noticeable

Thank you Gordon for building a new version, I only got time to try it yesterday. Updating did not go smooth for some reason first time it fail with an error, so had to update twice before it succeeded. Same happened on both watches.

While updating the phone with 55ppm often disconnected before it scanned for installed apps. After successful installation of 2v21.9 connection were stable and I had it connected for maybe an hour without disconnects. So for me it an success and I believe the cost is marginal regarding power consumption while connected, 20ppm vs 50ppm but user experience is much better if you were unlucky to get one with inaccurate clock.

For your suggestion to not use xtal I believe you are incorrect, the calibration accuracy is more like 250ppm and if I remember correct they changed it in newer softdevice versions so it always use 500ppm. Calibration cost power, it wakes up every 1 second to do the calibration. I have worked with Nordic semiconductors in my work, from nRF51822 to nRF52832. We saved the extra xtal to save cost when we do not have power all the time to have a real time clock.

Great, glad that helped for you! As you say I think on the Bangle the increased power usage is pretty marginal.

Interesting about the calibration, thanks! It's just anecdotal from the other devices I sell like Puck.js that don't have an XTAL, they don't seem to drift off loads over time - I run some in the garden the whole summer and they've never drifted off by enough that I notice anything (so must be less than half an hour).

I've noticed an even larger drift - I'm seeing a few minutes a day currently. I'm going to try solving it with the ios integration option to sync the time but I was expecting drift of seconds a day or much less, is several minutes of drift a day unusual? Thanks!

That is extremely unusual - are you absolutely sure it's that much? And has it always been like that?

If you're hard-rebooting the watch or turning it off a lot then you might expect something as the oscillator stops while rebooting, but that's not something that should normally be done.

That's like 1400ppm when the oscillator should be 20 - and in that case I'd be amazed if Bluetooth worked at all.

If you're sure it's happening I could try and do a custom build for you that didn't use the low speed oscillator - if that works it'd definitely narrow it down and perhaps I could look into finding a way to automatically disable it if it appears to be wrong.

I have switched my daily driver bangle to my second one and had massive problems with the Bluetooth stability to my HRM belt, connection loss about once every 2 minutes. After finding this I set the expected accuracy in the firmware all the way up to 500ppm and it seems much better. Comparable to the older Bangle. Both had the same firmware and exact same software (brought over via backup/import).
Is this possibly this timer accuracy thing? How can I prove this theory, is comparing clock drift between the two Bangles over 24 hours good enough for this?

How can I prove this theory, is comparing clock drift between the two Bangles over 24 hours good enough for this?

Yes, I think that's probably good enough. One thing you can do is if the Bangle isn't sleeping at all, the SYSTICK timer is going to tick up for every CPU cycle (based on the high speed oscillator) while the RTC counts up with the low speed oscillator - so you could compare how much each one increments...

• read RTC and SYSTICK
  
• for (var i=0;i<10000;i++);
  
• read RTC and SYSTICK
  
• compare
  
  

And hopefully that should give you a comparison between the two oscillators.

Over 32h the drift was about 3 seconds, so just on the order of 26 ppm. I do not think that should be problematic in any way since the firmware uses 50ppm by default?
What surprised me was that I seemingly had to change the accuracy in two places to actually make a difference: https://github.com/espruino/Espruino/commit/2c2ba5894a9a1450d20100e8370eb622acd64a4a while your 50ppm commit only changed bluetooth.c.

I will have to try your suggestion comparing RTC and systick.
So systick is expected to go up with 64MHz while RTC goes up at the 32kHz of the external crystal?

setInterval(()=>{
  const systickMax = peek32(0xE000E014);
  const rtcMax = (0xFFFFFF);
  let systickLater,rtcLater;

  let systickNow = peek32(0xE000E018);
  let rtcNow = peek32(0x4000B504);
  for (let i = 0; i < 10000; i++){}
  systickLater = peek32(0xE000E018);
  rtcLater = peek32(0x4000B504);

  let systickDiff = systickLater-systickNow;
  if (systickDiff < 0) systickDiff += systickMax;
  let rtcDiff = rtcLater-rtcNow;
  if (rtcDiff < 0) rtcDiff += rtcMax;

  print("Systicks:", systickDiff );
  print("RTC:", rtcDiff);
  print("Sys/RTC:", systickDiff/rtcDiff);
},1000);

This gives me values from 92-95 for Sys/RTC when the watch is on my arm and 152-156 when it has been stationary for a little while. I would have expected values on the order of 2000, so I do not have an idea how to interpret this. Or 0x4000B504 is the wrong address :-D
I got it from https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Frtc.html.

so just on the order of 26 ppm. I do not think that should be problematic in any way since the firmware uses 50ppm by default?

Exactly, that should be fine.

... but thanks for the hint on the PPM setting - looks like the 20->50 change I made was applying for older SDKs, but would never have had any effect for Bangle.js 2! I've just tweaked that.

Odd about the systick/RTC thing - I wonder whether it's related to the peripheralPollInterval (it goes into low power mode after 1 min of not moving). Not sure why that wouldn't work though

Great, thanks for the fix. The current bleeding edge firmware seems to now work fine with my HRM belt.
When looking at the absolute time calculated with the nominal frequencies there seems to be a factor of 16 between systick and RTC. No idea where that's coming from but I think it is not really relevant as it is now working.

Enabling the iphone time sync option solves the issue but if it reoccurs I'll let you know. I'm happy to compile the build myself if you can tell me which changes I need to make. Thanks!

I'm happy to compile the build myself if you can tell me which changes I need to make.

If you mean turning off the external 32kHz clock then commenting out this line https://github.com/espruino/Espruino/blob/master/boards/BANGLEJS2.py#L48 should do it.

Yes, as @fanoush says... you can fork the repo, comment out that line, and then GitHub Actions should automatically build firmware for you! https://github.com/espruino/Espruino/blob/master/README_Building.md#super-easy-github-method

Thank you, if I get the problem again I will try that. For now I'll stick with companion app time syncing.