Bluetooth Time Service

Hi @Gordon. I saw your new GPS Time Server app. What's your usecase for that?

I was thinking about doing something the other way around: EspruinoHub implements the Time Service, and BangleJS has an app or boot code that receives the current time, if the time hasn't been set. But, like you said, the documentation is too difficult, so I gave up.

Do you think that's a good idea? It would save me from having to go outside to get the current time from GPS (not that the battery ever runs out since 2v07).

Hi,

I didn't have anything specific in mind, other than that it was handy to be able to use the GPS to broadcast up to date time to other places.

But yes, if you're interested in adding a time service to EspruinoHub it'd be really neat (I guess it may not be able to coexist with the HTTP proxy though).

It's a real shame it doesn't seem to be part of the spec for it to be in an advertising packet. I wonder whether in this case it might be worth ignoring the spec and doing it anyway - it'd be so much better to just advertise it, and then any device could pick the info up without a connection

Thanks. I'll let you know if/when I start looking at this. I expect I'll need a bit of help.

I suppose this would work in a similar way to the HTTP Proxy. You could enable one or the other, but not both.
Would advertising affect any of the other functionality? Is it still able to scan for advertised data from other devices while it is advertising it's own?

You could enable one or the other, but not both.

I think that's likely, although it may well be possible to have both enabled.

Especially if you're just going to broadcast the time over advertising (not a service) I think it's pretty easy to have both - you can just change the advertising packets a few times a second.

Would advertising affect any of the other functionality?

I don't think so, no. At least it hasn't for the HTTP Proxy so far

Was looking into synchronizing time and found this topic.

Is this about CTS - Current Time Service or something else?
service guid 00001805-0000-1000-8000-00805f9b34fb
+2 characterictics
2A2B - Current Time
10 bytes
2A0F - Local Time Information
2 byte
as mentioned here?
https://github.com/RideBeeline/android-bluetooth-current-time-service/blob/master/currenttimeservice/src/main/java/co/beeline/android/bluetooth/currenttimeservice/CurrentTimeService.java#L32

Implementation is in 2 methods here https://github.com/RideBeeline/android-bluetooth-current-time-service/blob/master/currenttimeservice/src/main/java/co/beeline/android/bluetooth/currenttimeservice/TimeData.java#L44 and here
https://github.com/RideBeeline/android-bluetooth-current-time-service/blob/master/currenttimeservice/src/main/java/co/beeline/android/bluetooth/currenttimeservice/TimeData.java#L67

This looks easy to implement in Espruino so device/smartwatch can be used as source of time for other devices around - will try it.

As for putting it into advertisement/scan response what about using same format - like including manufacturer data in format
2A2B + 10 bytes + 2A0f + 2 bytes - that's 18 bytes total.
The advertisement packet could just advertise CTS service GUID 1805 as a marker to look for this data and the 18byte data could be in scan response (if it fits). Or could be splitted - the 2byte one in advertisement (timezone, shorter but less interesting) and the 10 byte one (time) in scan reply.

Main idea is to prefix data with 16bit characteristics id so it could be detected inside manufacturer data. Or is there better way to put it there somehow directly (out of manufacturer data)?

EDIT: it is more complex, found also some cypress definition of the service and there is one more characteristics Reference Time Information

The CTS specs are listed here https://www.bluetooth.com/specifications/gatt/ linking to CTS PDF here so just those three characteristics are there and only the first one is mandatory. And Nordic client implementation https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/ble/ble_services/ble_cts_c/ble_cts_c.c is reading just the 10 byte 'current time' one.

Main idea is to prefix data with 16bit characteristics id so it could be detected inside manufacturer data. Or is there better way to put it there somehow directly (out of manufacturer data)?

Answering myself, there is a way, there is 0x16 Advertising Data Type named "Service Data" and it is precisely for this idea https://devzone.nordicsemi.com/f/nordic-q-a/4048/what-service-data-can-be-added-to-the-advertising-package

EDIT: or not exactly for this idea since is is service ID not characteristics ID but these IDs are in same 16-bit UUID Numbers Document and are unique with each other so including current time simply as 0x2A2B: [ 10 byte array ] in NRF.setAdvertising would make sense?

I'm not sure if you'd spotted this, but 0x2A2B is already implemented for Espruino in the GPS time server app this thread was about: https://github.com/espruino/BangleApps/blob/24c84f9ba6a42d0d5aeda4743243d80f3fd7cb48/apps/gpstimeserver/widget.js#L22

That's interesting about using 16 bit UUIDs in advertising - I guess we're fine to do it then.

Oh, thanks, didn't notice the implementation in GPS server, that's great so I can start with that. Was trying to implement time syncing for raspberry pi - it does not have RTC so it syncs time from network at boot time, was thinking about syncing from smartwatch with this service if network is not available. So thanks to the gps server the server side is easy, querying it in startup script on the Pi (via bluetoothctl,hcitool or gatttool or something) will be harder - not sure if scan response is easier to get via bluetoothctl then actually doing connection and reading the characteristics via gatttool (that will work for sure but could be slower).

As for advertising those characteristics 16bit uuid data - it is not standard and typical CTS client won't search for it but I guess it won't break anything and could be there for those clients searching for it.

BTW having the 10 byte current time in scan response could be better as both for more space there and also for freshness of the time value, in theory the time could be filled when scan response is requested. Could I hook some js or native code into generating scan response? I guess it is set statically now and would be quite tricky to add this? The response array could be still statically prepared but just passing the byte array to some optional (native) callback method to update the array on the fly could work - similar to how setWatch can call native code with irq:true flag.

Could I hook some js or native code into generating scan response? I guess it is set statically now and would be quite tricky to add this?

There's nothing in there for that at the moment, so yes, you'd have to build it in. Definitely possible though.