Search results for:

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

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.

Pleased to support this next adventure.

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.

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

Does the GPS Recorder 0.21 affect updating, retaining, or using GPS time? (Sorry, novice here.) Will it be incorporated into something else eventually, so that the Recorder app isn't needed?

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.

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.

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!)

It may be. Even after an hour or more, if I change apps, does the code then cease to work?

What may I do to ensure that the resetting of the time continues to work? Or what should I not do?

May code be placed or created that will set the time every hour regardless of changing apps, as long as the watch isn't rebooted?

I appreciate your continued attention to this!

For the first time, something happened to steady the watch some. At some point in the second half of the day, it appears to have reverted to a more correct time. Not my doing; I didn't redo the GPS fix or reupload the script into the custom boot app. I've merely moved back and forth between my clock and the morphing clock.

It would be good to know what's happening, even if that's a difficult question. I'll continue to observe.

The problem may be something I'm not doing, or not doing correctly. Gordon may have a further suggestion.

(Version 2v09, 7247a2c4 here.) In the emulator MYSCRIPT returns 1, so that's okay. I may still be missing something to activate the script on the watch.

(Note to d3nd3-o0: thanks for the suggestion. I started off with no boot code and manual setting. Same problem.)

After a few days' trial, it seems to me that the watch still gains almost 2 seconds a day. Because the new script is in custom boot, perhaps I'm missing a boot action to activate it? All I'm doing after the GPS fix and uploading the custom boot is pressing BTN3. (A more serious reboot seems to replace the time with a default time.) I may be missing something.

Would the script be more likely to work as desired (and not be subject to nullification by a novice) if embedded into the watch's own script?

I'm still observing, to get a better idea of how steady the watch can be with your script installed. Meanwhile, has anyone else mentioned unsteadiness in its timekeeping?

Good, thanks. I will redo the whole process in case I've done something wrong, and continue observations.

Regardless, I presume that once in a while the GPS may need to be re-engaged to set the time — and if I ever want to remove the boot code, that I merely upload a blank custom boot script.

Thanks for the continued help! I'm not completely sure what that does, nor the order in which to do these four things:

load custom boot code with that script
set watch by GPS
press BTN3 to put away GPS
go to clock

Is it necessary to set the watch using a GPS app? Also, how do I make sure the script stays loaded in the watch?

Which GPS app may you be thinking of? One that doesn't have to access a satellite but (on request or automatically) will reset the watch's time.

Might an app be developed to record a reference time setting and pull the Bangle close to that when it drifts by a certain amount? I suppose that's asking a wayward crystal to monitor itself and is impossible, unless there's an external way to keep track of the seconds, such as connecting to wifi or a cellular phone tower. A GPS setting would correct the time but is a battery-intensive and cumbersome corrective.

Suggestions welcomed.

Default battery and Bluetooth are the only installed widgets.
Over the second 24 hours, the watch gained another 2 seconds or so, totalling about 6 seconds ahead of real time after two days. (Both the morphing clock and my Dozenal Time are ahead by the same amount, no surprise there.)
The watch hasn't been behind in several days. Deliberately I'm not removing or reinstalling or changing anything else, to see what happens.

The GPS time-setting app and two alarms are installed but haven't been in use.

Overnight, when the watch was "sleeping," its clock seems to have gained about 2 seconds. Through the day it gained another 2. Sometimes it's behind, sometimes ahead. I haven't determined the conditions under which the changes occur. I'm looking at the morphing clock and comparing it to an electronic clock I know is accurate.

Possible causes? Remedies?

I had the same problem. In order to make my part of apps.json correct, I had to change spacing after colons, despite a variety of spacings in the examples already present. What my mistake was, I don't know. But finally the upload went through.

Any news on this topic? Requiring 1) an Android phone, 2) Gadgetbridge, 3) a weather helper seems rather awkward, and I don't know yet what the limitations are. Nonetheless, I'll try it if it works and is necessary.

Indeed. Here's the way it looks now on the watch itself, with tomorrow's date (complete with unwanted reflection). The date is colour coded for the day of the (6-day) week. Tomorrow is Arantius dies (orange day). Occasionally an extra day is needed; it has its own colour.

I'm using the vector font. How frequently are there revisions of it, if any?