the time goes forward 5 minutes each week

[espruino-discuss2]

Posted at 2024-06-21 by uname

I've been meaning to write for a while, I just decided now.

The time on my bangle2 goes forward every week by about 5 minutes.

I currently have version 2v22.42 but even with previous versions I always had the same problem.
(actually the problem appeared from a specific update onwards of the previous major release, unfortunately I didn't pay too much attention to it and didn't mark the version)

I keep BT off and don't use connections with smartphones or pc so my bangle is standalone.

This forces me to connect my smartwatch more often to sync the time.

Is there a solution to this problem?

Thank you.

[espruino-discuss2]

Posted at 2024-06-21 by @gfwilliams

Hi,

actually the problem appeared from a specific update onwards of the previous major release

This is very interesting - if you were able to try installing an early release (even if much earlier) and confirm it doesn't happen with that then that would be a really big help.

The timekeeping should be done by a hardware RTC (real time clock) in the chip based off a low speed oscillator, so the software shouldn't be involved at all. The only time the time might get messed up is if doing a full reset (where the bootloader is displayed) as in that case the RTC gets reset and the Bangle has to reset itself to the last known value (which could be a few seconds out)

But if that happens the time would be going back, not forward.

There is however an app which will apply a correction for you: https://banglejs.com/apps/?id=widadjust&readme

So you could install that, and if it's really 5 minutes a week the PPM is: 5 / (7*24*60) * 1000000 = 496

But that is a lot. The crystals are specced for 20ppm but I've heard of some watches that are 50ppm. 500ppm is 10x that, and it feels like there might be some other cause.

It'd be interesting to see if after a factory reset the watch still behaves the same

---

Posted at 2024-06-21 by @fanoush

someone already has similar issue before, the 32kHz crystal being worse than built-in low speed oscillator so build with this turned off actually improved accuracy for him

actually the problem appeared from a specific update onwards of the previous major release

this is strange because it was turned on 3 years ago in this comit espruino/Espruino@7c5de9d so basically it was always the same almost since the beginning. so maybe this is different issue after all

Anyway if you want to try then just fork Espruino repo on github and edit this single line (comment out 'DEFINES += -DESPR_LSE_ENABLE ' by adding '#') then save/commit and github will make new build for you. It is just few clicks on github web to get this custom build.

---

Posted at 2024-06-21 by @andresdju

I have the exact same issue. My bangle.js 2 accumulates around 40 to 45 seconds per day, so it seems that it would be like 5 minutes per week.

Right now I have stable 2.22. I used to have the watch unconnected for several days and it didn't happen before. Recently I have connected nearly every day, so I don't know which update broke it. My guess is that it happens since some development update during 2.21.x.

---

Posted at 2024-06-21 by user149184

Same for me. I never had such a discrepancy before. It started a few weeks ago. Unfortunately I do not know exactly when or after installing what firmware version. Without syncing for about four days the time goes forward about three minutes.

---

Posted at 2024-06-21 by @gfwilliams

Same for me. I never had such a discrepancy before. It started a few weeks ago.

If it was a few weeks ago, and your firmware was up to date before, maybe you had 2v21?

If so it would be really helpful if you could downgrade and see if it still happens?

---

Posted at 2024-06-21 by tev

I was just going to post about the same issue with my Bangle.js 2. I am seeing a similar discrepancy, gaining over 50s per 24h. I believe I did start seeing this roughly around the time I upgraded to 2v22, so perhaps I will downgrade and see what happens.

---

Posted at 2024-06-21 by user149184

Just downgraded to 2v21. I will let you know if there is any result.

But I would like to inform you about a strange behavior: To be honest I did not checked the time before downgrade. But there is no reason for being totally wrong. But after flashing and restarting the clock showed 10:26 pm - but local time was 8:40 pm. After "set time" via web interface it showed the correct time 8:45 pm.

---

Posted at 2024-06-21 by user113695

Add me to the list: a few weeks ago, after a firmware upgrade my Bangle started to be fast by about 600ppm.
Unfortunately I also didn't pay close attention so I can exactly pinpoint the version this started with. I typically update to cutting edge builds every 3 to 4 weeks or so...

---

Posted at 2024-06-21 by uname

@gfwilliams where i can find a page with all the 2.21.x releases?
maybe we can share the steps, in a few days we figure out what is the version jump that caused problems.

---

Posted at 2024-06-21 by @halemmerich

You can find the firmware builds here: https://github.com/espruino/Espruino/actions. I don't know if there is an easy way to match them to versions, but you can see the git revision in each individual build.

---

Posted at 2024-06-21 by tev

But I would like to inform you about a strange behavior: To be honest I did not checked the time before downgrade. But there is no reason for being totally wrong. But after flashing and restarting the clock showed 10:26 pm - but local time was 8:40 pm. After "set time" via web interface it showed the correct time 8:45 pm.

Yeah, when I downgraded to 2v21 I noticed my clock jumped forward a couple of hours, even though the last GPS fix was a couple of days earlier. Can't say I've seen this happen before when changing firmware versions, but this is also the first time I've gone backward a revision rather than forward.

---

Posted at 2024-06-21 by Numerist

I haven't tried to update firmware in a long time, because I don't think I need to—my js2 is used solely as a dozenal clock—and I'm afraid of the result of updating. I can say that malaire's Adjust Clock widget works well in my case. I'm still determining what my best setting is, although it's likely to be in the 66+ range, for about 5.7+ seconds a day fast, ca. 40 seconds a week.

---

Posted at 2024-06-22 by user140377

Yeah, when I downgraded to 2v21 I noticed my clock jumped forward a couple of hours

I had the time jump by hours wenn updating to 2v22, can't remember the direction.

---

Posted at 2024-06-22 by @fanoush

Yeah, when I downgraded to 2v21 I noticed my clock jumped forward a couple of hours

that could be timezone change (to/from GMT) or some bug related to it - not getting timezone right at some point and making wrong correction

---

Posted at 2024-06-22 by user149184

Of course that could be the case. I don't know. But 1:46 h (08:40 pm / 10:26 pm) does not really look like a time zone effect.

---

Posted at 2024-06-22 by uname

i've downgraded and experienced the same clock jump, not time zone related but not a problem, solved with a first time sync.

---

Posted at 2024-06-22 by tev

Okay, so I went back to 2v21 and waited about a day, and so far the clock drift seems more reasonable now, only about 4 seconds over the last day rather than 50+.

---

Posted at 2024-06-22 by user149184

Same result here. After downgrading to 2v21 I had a more reasonable clock drift of about 6 seconds over 24 hours.

I went back to 2v22 now to see whether the bad result is reproducible. Clock time was 08.50 pm before update and 07:21 pm after flashing.

I will let you know about the result.

---

Posted at 2024-06-22 by d3nd3-o0

I can confirm it my tests:

Testing latest firmware:
   2v22
17:26:55 - synced.

19:48:30
5 seconds drift.
5 seconds over 2 hour 22 mins

===================================
2v21
19:53:50 - synced.

23:24
In sync 0.5 seconds

---

Posted at 2024-06-23 by d3nd3-o0

espruino/Espruino@5be8869

v21.124
This is the culprit, but I have no idea why, it doesn't seem like it should be the culprit.

---

Posted at 2024-06-23 by BartS23

I can confirm that commit 5be8869ae36b7d9fe955e1b1071b9f8a58a0­38cf produces the problem:

let firstFix = true;
let mesureStartTime;
let latestLogTime;

function calcTimeDifference(fix) {
  if (!fix.time) {
    return;
  }

  const currentDateTime = new Date();
  const delta = currentDateTime - fix.time;
  if (firstFix || delta < 0) {
    // Set the time to the first time received, or if the time is behind the GPS time 
    // because we have a forward drift
    console.log(`${fix.time.toISOString()} Start measuring`);

    setTime((new Date() - delta) / 1000);
    firstFix = false;
    mesureStartTime = latestLogTime = new Date();
  } else if (!latestLogTime || (currentDateTime - latestLogTime) > 60000) {
    const measureSeconds = (currentDateTime - mesureStartTime) / 1000;
    console.log(`${currentDateTime.toISOString()} difference ${(delta / 1000).toFixed(3)} second/s within ${measureSeconds.toFixed(3)} second/s`);
    latestLogTime = currentDateTime;
  }
}
console.log(process.env.VERSION);
Bangle.on("GPS", calcTimeDifference);
Bangle.setGPSPower(1);

2v21.123
2024-06-23T18:08:40.000Z Start measuring
2024-06-23T18:09:40.012Z difference 0.013 second/s within 60.009 second/s
2024-06-23T18:10:40.020Z difference 0.020 second/s within 120.016 second/s
2024-06-23T18:11:40.025Z difference 0.025 second/s within 180.022 second/s
2024-06-23T18:12:40.033Z difference 0.034 second/s within 240.030 second/s
2024-06-23T18:13:41.026Z difference 0.026 second/s within 301.023 second/s
2024-06-23T18:14:42.019Z difference 0.019 second/s within 362.016 second/s
2024-06-23T18:15:42.023Z difference 0.024 second/s within 422.020 second/s

2v21.124
2024-06-23T18:49:06.063Z Start measuring
2024-06-23T18:50:06.106Z difference 0.044 second/s within 60.039 second/s
2024-06-23T18:51:06.146Z difference 0.084 second/s within 120.079 second/s
2024-06-23T18:52:06.182Z difference 0.119 second/s within 180.116 second/s
2024-06-23T18:53:06.216Z difference 0.153 second/s within 240.149 second/s
2024-06-23T18:54:06.250Z difference 0.187 second/s within 300.183 second/s
2024-06-23T18:55:06.286Z difference 0.224 second/s within 360.219 second/s
2024-06-23T18:56:06.328Z difference 0.266 second/s within 420.262 second/s

---

Posted at 2024-06-24 by @fanoush

https://github.com/espruino/Espruino/com­mit/5be8869ae36b7d9fe955e1b1071b9f8a58a0­38cf

v21.124
This is the culprit, but I have no idea why, it doesn't seem like it should be the culprit.

Good find. The first change looks harmless if the SYSCLK_FREQ is divisible by 1000 (which it maybe is - 64000000 for nrf52?). but the second is now multiplication by small floating point number with low precision so maybe that may be the cause.

---

Posted at 2024-06-24 by @gfwilliams

Wow, thank you so much for tracking this down - that's perfect!

The first change looks harmless if the SYSCLK_FREQ is divisible by 1000

Actually, SYSCLK_FREQ = 1048576 (it's a bit confusing as it's different to STM32 since it's just the precision used for storing time values)

So it'd be losing 576 out of 1000000 which is almost exactly what I'd worked out above at 496.

I had the time jump by hours

I would have said that was maybe the issue with the RTC being reset and the re-loaded on reboot, but having seen that I guess it's not the case!

I've just pushed a change so if you try a Cutting Edge build now it should be fixed.

Sorry about that! I'll do some tests here and assuming it's fixed I'll push out a 2v23 release

---

Posted at 2024-06-24 by @gfwilliams

Also, thanks for the test code @BartS23!

Thinking about that, I wonder whether something could be added to https://banglejs.com/apps/?id=widadjust to allow it to figure out the drift using GPS.

Even this code:

let lastTime = getTime();
function calcTimeDifference(fix) {
  if (!fix.time) return;
  var t = getTime();
  print(t-lastTime);
  lastTime = t;
}
console.log(process.env.VERSION);
Bangle.on("GPS", calcTimeDifference);
Bangle.setGPSPower(1);
NRF.setConnectionInterval(200); // low BLE speed = less GPS interference

Works surprisingly well - because we know the GPS sends data once a second, we just see how many seconds the Bangle thinks have passed. Obviously it'd be better averaging over more seconds though.

2v22:

1.00073289871
1.00045800209
1.00067186355
1.00073266029
1.00045800209
1.00067186355
1.00073289871
1.00045800209
1.00067162513
1.00076341629
1.00045800209

With the fix:

1.00009155273
1.00009155273
1.00009155273
1.00006103515
1.00006103515
1.00009155273
1.00006103515
1.00009155273
1.00006103515
1.00003051757
1.00009155273

So it's an order of magnitude better

---

Posted at 2024-06-24 by tev

Thinking about that, I wonder whether something could be added to https://banglejs.com/apps/?id=widadjust to allow it to figure out the drift using GPS.

It would be pretty nice if it had some means of measuring its own drift. Years ago I wrote my own clock drift corrector for a HP 50g graphing calculator, though instead of using GPS it was just based on my periodically entering the correct date and time and manually pressing a button right on the second, at which point it would calculate the corresponding drift. Just a couple of iterations of this quickly made it more accurate than a $50 quartz Timex watch. :)

If there was a way for the app to receive an event when connecting to the App Loader and updating the date/time, it could then compare the new value to the current clock along with the last known date/time of adjustment in order to determine the drift itself.

---

Posted at 2024-06-26 by @gfwilliams

If there was a way for the app to receive an event when connecting to the App Loader and updating the date/time, it could then compare the new value to the current clock

That's a neat idea putting it in the App Loader, it'd just require writing a file after we set the time. The only issue is that watch reboots between App Loader runs would knock out the timings, and so if it was automatic it's possible it could end up configuring the PPM difference wrong.

Thinking about how the timekeeping broke in 2v22 made me realise it wouldn't be the end of the world to actually add an optional adjustment inside the Bangle.js firmware (in the jshGetSystemTime function) so I guess that could be an option to make it even more seamless...

---

Posted at 2024-06-26 by tev

That's a neat idea putting it in the App Loader, it'd just require writing a file after we set the time. The only issue is that watch reboots between App Loader runs would knock out the timings, and so if it was automatic it's possible it could end up configuring the PPM difference wrong.

I thought about that. Maybe a sanity check could be performed that makes sure the watch's reported time isn't too far off from actual time, and if it is, the recalculation of the drift could be skipped for that occasion (perhaps with a warning message printed on the console, if desired). Or else have a way to just let the user manually request when the drift should be calculated and the time be adjusted, perhaps.