Is it possible to sync Bangle.js 2 time to smartphone time?

That's certainly simpler than cross-compiling my Rust code to Raspberry Pi. (I just got that working and I'm now reading on systemd services to make this a service. I can provide executable for latest Raspberry Pi OS if anyone wants to test this.)

It may be possible to make it much simpler.

The GPS chip already provides the time about 1-2 seconds after switching on (even without fix).

I wrote an app, which turns on GPS every 4 hours, sets the clock if necessary and then turns off the GPS again.

If no time is received within 10 seconds, the GPS is also switched off.

A log file is written to measure the deviations and possibly make adjustments in the rhythm (this must be deleted manually).

Unfortunately I am not that experienced in writing js.
I would be happy if someone could review my PR (https://github.com/espruino/BangleApps/pull/1342).

Does your script work indoors? I've been asking here how to access the GPS, including after an outdoor fix, and whether it continues to work indoors, but no one has answered. Bangle.js 2 is clearly different from Bangle.js 1 in this, but again no one has said how that affects getting an accurate time.

What sort of drift have you noticed so far between the two? Aren't the crystals in the GPS and Bluetooth at the same frequency (32.768 kHz)?

GPS time can be good and precise. But yes, indoor reception can be very poor. Also it is UTC. You need to keep timezone and time savings adjustments somewhere.

With Bangle.js 1 I had the GPS run the clock after setting the GPS outside. It worked. Indoor reception, which is nil, didn't matter. Time zone etc. are no problem: they're in settings.

Again, what's the difference in how GPS time works with Bangle.js 2?

As I understand there is no much difference. GPS should receive a time from a sat and then it can keep it in its RTC. My uderstanding, the main battery is connected to AT6558 backup power supply. When you turn off GPS power AT6558 will keep time in RTC and ephemerides in memory.
But the quartz is external, not in the chip, so if it is not good enough it can drift similar way as a "main" watch quartz. In normal operation GPS always receives time from sats. So RTC is just a backup, when no reception. Because it is not that important, they may put a cheap quartz there.

I've read that there are a few significant differences in the GPS operation. I myself do not know.

Today I did a complete reset and uploaded only one clock (Anton). In 8 hours it gained a little less than 2 seconds. Does anyone else have such an observation? Does your Bangle.js 2 gain throughout the day?

(Then I uploaded my clock. It reset Anton (and set itself) to the correct time.)

Does your script work indoors?

In my apartment and at work it also works indoor.

What sort of drift have you noticed so far between the two?
Approximately every 12 hours the difference increases to 2 seconds.

I reset my GPS chip to factory settings with

$PCAS10,3*1F

and still got a time within a second.
I think as long as there is a satelite in view, it will also find the time.

... In 8 hours it gained a little less than 2 seconds. Does anyone else have such an observation? Does your Bangle.js 2 gain throughout the day?

Yes, my Bangle.js 2 is also gaining several seconds per day (I havn't measured it exactly yet.)

(Then I uploaded my clock. It seemed to reset Anton (and set itself) to the correct time. Weird.)

Every time you connect to https://banglejs.com/apps/ the watch time is set by that website.

@Gordon I noticed https://github.com/espruino/Espruino/issues/2125 last night. Is this related, or am I conflating two completely different things just because they relate to timers?

@myownself they're different - the high res timer is very specifically for sending timed pulses (and software PWM).

The time on Bangle.js comes from the RTC hardware on the chip, which is driven directly from a low speed oscillator. About the only thing that can change the time is if you do a hard reset or run DFU - during that time the RTC won't be running until Espruino boots.

A second or two of drift in smartwatches/PCs/phones is pretty normal I'm afraid - the oscillators are usually rated at around 30 parts per million. Since there are 86400 seconds in a day, 86400 * 30 / 1000000 = 2.5 seconds/day

Usually you don't notice because phones/PCs/etc keep time updated from the internet all the time

Just a quick note on the BLE advertising code above - I didn't spot it at first.

Looks like NRF.setScan(function(d) { is being used. I'd strongly recommend just using NRF.requestDevice as this basically implements the 'stop after 1 packet received' internally, and will behave much better in areas where you'be got loads of BLE devices advertising

It uses filter for serviceData, also maybe with setScan you get the packet with time sooner just when it arrives so that timestamp inside is more fresh? Was thinking to suggest requestDevice at first too but then was thinking setScan with filter may be better.

Also if you get more packets (from one or more devices) then you have more data to adjust the time.

I'm noticing about 5 seconds' advance per day on Bangle.js 2. You helped me to get GPS time into Bangle.js 1 and read often enough. Is the same possible for Bangle.js 2? Any specifics?

Alternatively, is it possible for Bangle.js 2 to access an iPhone's time via a script for the watch?

Or is there some other way to avoid the large gain per day that others have also noticed?

Sorry, I had forgotten that uploading from the computer resets the time.

Let us know how much your watch gains per day.

I just did a 3-hour-test and Bangle.js 2 gained 0.68 seconds in 3 hours, which is about 5.4 seconds per day, so about same what you got.

@fanoush requestDevice works with the exact same filter. It's basically doing exactly what you do with setScan, but inside Espruino - so if anything it should be marginally faster.

so if anything it should be marginally faster.

the total time may be faster but with setScan you get the packet data sooner? As I understand it the requestDevice sets up a callback to collect data, starts it, collects data, stops it and resolve promise and call your code. setScan first calls your code with the data as the packet arrives and then you do the rest. And with setScan you can get more packets in one scan to do some average on the timestamps and stop when you are happy with the result.

Of course it doesn't matter with precision to seconds but @malaire tried to do more

... requestDevice vs setScan ...
Of course it doesn't matter with precision to seconds but @malaire tried to do more

I don't think that matters as there is even worse inaccuracy. I've now realized other 0-20 ms inaccuracy in BLE advertisements I overlooked before: Each advertisement is send on 3 channels with up to 10 ms between, and receiver doesn't know which one they received.

I've been testing to make Bangle.js 2 determine its clock drift and accuracy from advertisements just doesn't seem to be enough to do that (quickly enough).

So next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).

I've been testing to make Bangle.js 2 determine its clock drift and accuracy from advertisements just doesn't seem to be enough to do that (quickly enough).

There is still scan response. I will try the hack with SoftDevice >=6.1 with updating timestamp in scan response static buffer on the fly (there is even BLE_GAP_EVT_SCAN_REQ_REPORT event you get when someone requests scan response, see e.g. this) and see whether it breaks or softdevice will pick up the changes.

next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).

That may be easier and more predictable after all.

Each advertisement is send on 3 channels with up to 10 ms between, and receiver doesn't know which one they received.

theoretically receiver should know which one they received. Because this reception will happen on a particular channel. I am not sure if that low-level info can be available from the device.
Also I read that a BLE device can be configured to advertise on particular channels only. For example, you can advertise on 37 if (second % 3) == 0, on 38 it is 1 and on 39 if it is 2. So it will cover all channels and have no inter-channel delay. I hope. The price is - overall latency of receiving time can be up to 3 sec. But this time will be more precise.

I will try the hack with SoftDevice >=6.1 with updating timestamp in scan response static buffer on the fly

this is promising approach. I think a checksum needs to be sent as well, because there can be a risk of sending partially updated buffer.

BLE device can be configured to advertise on particular channels only

Yes, I read that also, but the Rust library I'm using doesn't seem to support that. (BlueR - official BlueZ library)

Yes, I read that also, but the Rust library I'm using doesn't seem to support that. (BlueR - official BlueZ library

with the HCI way there is 0x0006 LE Set Advertising Parameters Command with Advertising_Channel_Map parameter with 3 bit array for channels 37,38,39

next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).

That may be easier and more predictable after all.

Strangely this seems to be much worse. Connecting to get few bytes can take several seconds and BluetoothRemoteGATTCharacteristic.readValue() part of that takes at least 90 ms but sometimes up to 300 ms - much worse than using advertisements.