About Current Time Service

RE: About Current Time Service

ovrebekk — Fri, 28 Feb 2020 09:05:57 GMT

Hi Marty

The problem with nanosecond accuracy is that you need very fast and accurate clocks, which will impact the cost, complexity and power consumption of your solution, but hopefully you can find something out there.

The ble_app_uart example can be configured in different ways, but at a minimum you should have 20 bytes available in each characteristic, and you can configure the size up to 512 bytes if you want, so there should be plenty of room for a 4 byte timestamp 🙂

Best regards
Torbjørn

RE: About Current Time Service

marty9410 — Thu, 27 Feb 2020 05:48:50 GMT

Thank you for the specific reply, Torbjorn! It's a shame I can't achieve the nanosecond accuracy portion from this device, but I guess I'll have to cope with an alternative solution-

and about one of my questions-

[quote userid="2116" url="~/f/nordic-q-a/58195/about-current-time-service/236577"]Do you mean for the timestamp information, or how many bytes you have available in total?[/quote]

Sorry for the vague question- what I meant was how many bytes I'd have available in total; I need at least 32 bits - which is 4 bytes that is available to me.

But I'm guessing the storage is not a problem in this type of packet;

anyways, Thank you so much for your help

Best,

Marty

RE: About Current Time Service

ovrebekk — Wed, 26 Feb 2020 13:54:57 GMT

[quote user="marty9410"]If I understood your comment properly, I would have more freedom in regards to how I would format the information I'm sending, right?[/quote]

That is correct. You can fill the characteristics with whatever information you like, and also extend the example to use more services if you want. The only critical thing is that you change the UUID of the example to avoid mixing your device up with any other running the Nordic UART service.

[quote user="marty9410"]How many bytes would I be looking at if I used the uart example? [/quote]

Do you mean for the timestamp information, or how many bytes you have available in total?

[quote user="marty9410"]Also, we're trying to send timestamps down to the nano second accuracy- if millisecond accuracy is challenging, does this mean achieving nanosecond accuracy is impossible? Or would there be a method to accomplish this task?[/quote]

Yes, I don't see how you would be able to get accuracy this good. At a minimum you will have uncertainty caused by clock drift between the TX and RX, which means the clocks between them will be in different phase compared to each other. Over time this phase will change and add at least up to 62.5ns of uncertainty between the two.

Secondly the tolerance of the clock source will add uncertainty over time. The external high frequency crystal can have a tolerance of up to 50ppm, which means you could have up to 50us drift every second. This means that the accuracy will deteriorate slowly whenever you let the nRF device keep time without setting it from some external source.

With consumer electronics like this you will definitely not get nanosecond accuracy.

Best regards
Torbjørn

RE: About Current Time Service

marty9410 — Tue, 25 Feb 2020 10:11:55 GMT

Thank you for the response, ovrebekk!

If I understood your comment properly, I would have more freedom in regards to how I would format the information I'm sending, right? How many bytes would I be looking at if I used the uart example?

Also, we're trying to send timestamps down to the nano second accuracy- if millisecond accuracy is challenging, does this mean achieving nanosecond accuracy is impossible? Or would there be a method to accomplish this task?

Thank you in advance.

RE: About Current Time Service

ovrebekk — Tue, 25 Feb 2020 08:57:54 GMT

If you are doing something proprietary, that doesn't have to be compatible with any existing systems out there, then it might be easier just to use the ble_app_uart example as a starting point.
With this example you can send strings of any length between the two devices, or send data of any format, such as a timestamp.

The CTS service is very useful if you want to connect to a phone, and get an accurate timestamp sent from the phone side, but is harder to setup if you just want two Nordic kits to communicate with each other.

The TIMER modules have higher accuracy, that is correct. While an RTC tick is about 30.5us in length, the TIMER can run down to a 62.5ns interval (16MHz base clock).
But it's not only the accuracy that is important, but also the frequency tolerance. The TIMER module runs from the high frequency clock (HFCLK), and to get good tolerance it is necessary to enable the external 32MHz crystal at all times. This will give you a tolerance of 50ppm or better depending on the type of crystal used.

When using the RTC the tolerance is set either by the internal 32.768kHz RC oscillator, which is not very accurate, or the external 32.768 kHz crystal, which can have a tolerance of 20ppm or better. In this case it is also necessary to enable the external crystal explicitly to ensure good frequency tolerance.

A final word of caution is that there is some delay in the Bluetooth link layer that makes it hard to send very accurate timing information.

If you need accuracy on the second level this is probably not an issue, but if you are trying to send millisecond accurate time stamps this can be more challenging.

Best regards
Torbjørn