the time goes forward 5 minutes each week

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.

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

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 https://github.com/espruino/Espruino/commit/7c5de9dc8095e91bb00c5668cbc7b9bd336318d0 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.

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.

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.

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?

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.

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.

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...

@Gordon 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.

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.

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.

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.

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.

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

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.

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

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+.

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.

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

https://github.com/espruino/Espruino/commit/5be8869ae36b7d9fe955e1b1071b9f8a58a038cf

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

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

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.

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

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