Bangle.js time steadiness

If you change apps, the timer starts again, 1 hour from when you last changed app.

You could just change the timeout in the code to something shorter, or perhaps the easiest thing is to try and do it 'on the hour'. So right now the timeout is 60*60*1000, but you could make it (60-(new Date()).getMinutes())*60*1000

Maybe it would be better to correct the time on the hour (e.g. 00 minutes past), to make sure it happens regardless of the current app load time?

I tested my watch over a period of 24 hours, and it hasnt really shifted by anything noticable, hmm. Perhaps it depends what type of clock we are comparing it to? I just have a standard Radio Controlled Alarm clock.
I could try comparing it to a website with exact time, like this https://time.is/ eg. You could do the same, and we can compare results.
What is the weather/temperature like where you live @Numerist

Temperature moderate. Even if warm weather has been a problem, the script should fix that. My wifi time is the same as time.is.

Shortly after 11:00 (central eastern North America) May 27 I did a new GPS fix and uploaded the custom boot with the new code above in the last line. I checked the watch once an hour at some point between 9 and 35 minutes after each hour, from 11:09 to 23:10. The watch was on Clock A except briefly as noted below.

At 11+ to 18+ : accurate, fairly constant.
At 19+ : ahead by a second or a little more. No clue why.
At 20+ : still ahead by a second or a little more (same as at 19+).
At 21+ : I switched to Clock B. Surprisingly, the time was accurate, as from 11+ to 18+. I switched back to Clock A with no further change. It's unlikely that the sudden change was caused by my switching (see below).
At 22+ : ahead by a little (less than a second).
At 23+ : ahead by a little more (still less than a second in total). I switched to Clock B and back to Clock A again. Unlike at 21+, there was no change.

Of course, I don't know how the GPS timekeeper was doing over those hours. Nonetheless, the results from this one day are puzzling. (I'm not looking for a precision timepiece!)

What if its related to like using the freezer or fridge whilst the watch is on your wrist? Or even oven? Not sure just guessing here.

ahead by a little (less than a second).

That is likely as I'd mentioned before - the clocks don't generally update on the second, but every 1 second after you happen to load them. So the exact time the clock is loaded can vary the time shown by 0-1 second

Over the past 36 hours the watch gained a little over 3 seconds. I don't know what I may be doing wrong, or what else may be wrong. I'm going to try a few more things and report back here.

After about a week of experiments, it seems that something in the code of Dozenal Time is the problem. Despite occasional slight variations (gaining or losing time by small amounts), it seems to cause a gain of about 2 seconds a day despite the custom boot gps fix.

I'll see if I can find someone to look at it and I'll continue to observe the situation.

After 3 weeks, we may have a solution. If so, after a little more testing I'll post a new commit.

Dozenal time is now stable, accurate to within about 1 second. A commit/pull request has been registered.

Overnight, when the watch has no use but of course still runs, sometimes it wakes up to being a bit behind. But soon it fixes itself, via GPS time.

https://github.com/espruino/BangleApps/blob/f1ce196ad1de28f1d07affe81d27ae4d284bd6f7/apps/doztime/app.js#L175

let wait = 4167*(1-(x%1));

Any variable that is % modulo operator with 1 will output 0. So that code is saying, 4167* (1 - 0) ... which is equivalent to 4167 * 1 equivalent to 4167.

let wait = 4167

Am I wrong?

Thanks for pointing that out. There's another statement like that in there, I've noticed. I'll ask one or both coders what the intent was.

The watch code still causes noticeable gains in time, although much more slowly than originally. The whole code is due for revision, which may be undertaken with the version 2 of the watch coming out.

Thought I would add some comments to help understanding the code.
I also added a couple of console.log() calls to print messages to the IDE.
If you connect to the IDE you should be able to see some messages when the code runs
This will tell you if it was able to extract the time from the GPS chip real time clock circuit.

setInterval(function() {

  // this is defines the GPS call back function
  Bangle.on("GPS",function cb(g) {
    Bangle.setGPSPower(0,"time");    // we got a response so turn off GPS power
    Bangle.removeListener("GPS",cb);  // unregister the callback function
    if (!g.time || (g.time.getFullYear()<2000) ||
       (g.time.getFullYear()>2200)) {
      // GPS receiver's time not set
      console.log("GPS real time clock is not set, use GPS info and get a fix");
    } else {
      // We have a GPS time. Set time
     var t = g.time.getTime()/1000;
      setTime(t);
      console.log("time set to " + t);
    }
  });  // this is the end of the GPS callback funtion

  Bangle.setGPSPower(1,"time");   //  power the GPS on, when GPS responds, callback is called
}, 60*60*1000);     //  run this once per hour, 3600 seconds in milli-seconds

But I can see that you added this code to your app ages ago.
Really interesting discussion regarding the accuracy of the RTC chip verses the one in the GPS.

@Numerist - what an interesting clock. Be interesting to see how an analogue version looked.

I tried it on my Bangle 1. I have noticed that the screen sometimes goes black before the LCD times out.

x =864*dt.getHours()+14.4*dt.getMinutes()+0.24*dt.getSeconds()+0.00024*dt.getMilliseconds();

let wait = 4167*(1-(x%1));

This is getting the fractional part of x. So if x is 456.123
The statement becomes.

let wait = 4167*(1 - 0.123);

So its working out a value for the next timer call.

@HughB
Yes, I did see that the clock was picking up the GPS. I still don't know, however, what causes it to gain, slowly but noticeably.

Thanks for the interest, warmly received. As for an analogue version, I produced many some years ago, although not for a watch face. All are contained at https://dozenal.ae-web.ca/, under Clock, Multibase, and Universal. The calendar is there also, in an interactive version. Everything has explanatory text.

Because I'm not a programmer/coder, I hired others to do the work.

I had a look at the web page. Interesting stuff. I played around with it for a bit. Not quite sure why all the links are half page PDF files. Apart from quirkyness I am left wondering what motivated you to get this far with the project - must have been part of something else ?

I still don't know, however, what causes it to gain, slowly but noticeably.

It will be down to the accuracy of the componant chip. It is more than likely that each watch will drift around with varying degrees. Its not something I have ever noticed as I am not bothered about 1 second here or there. The great thing is that the RTC of the GPS is so much more accurate and a small amount of code was able to compensate. Its a great success story for an Open Source Smartwatch.

The text link pdfs are sized to keep them readable, rather than to have, for example, a very wide span of text. Two columns would have been useful also. I'm not sure if that answers your question!

I've been an amateur interested in this number base for several decades. What I've done is to take others' ideas that are mostly theoretical and realize them in ways that I think are useful. The clocks and the calendar were worked out with various collaborators. The dozenal clock (in one or more formats) and calendar are the only ones I use. There's an elaborate new metrology that includes time and is a whole additional story. The dozenal base also has a long history.

There are also solitaire card games, at https://games.dozenal.ca, the most unusual being in the shape of a hexagon.

I'm not sure that the watch hardware itself is the culprit. It may be, but a brief experiment with it suggested that the code has the problem. Because so few people use the watch, I haven't investigated further, partly because it would cost a fair amount to do so, partly because the original coder stopped working on the project.