About Current Time Service

[marty9410]

Hello, I am a newb currently working to be able to send and receive timestamps between two nrf52840 dk's.

I have been successful in creating a space in the advertising packets to place an initialized timer value.

However, I soon realized that this information did not continue to be communicated as the two devices entered

a connected state. I did a bit of research, and got to realize that this is because the two devices start sending

data channel pdus instead of the advertisement packets that I configured.

I am aware that the actual procedure of sending and  receiving data has to happen under the GATT protocol.

It seems as though the closest service available in GATT is the Current Time Service; at least from what I understood

from my researches.

Would Current Time Service be a preferable choice to achieve my intentions? And if possible, I'd like to send such data

not created from RTC1, but from TIMER, which from my understanding is a HFCLK with higher precision. Would it be possible

to come up with such a software?

Thank you.

[ovrebekk]

Hi

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

[marty9410]

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.

[ovrebekk]

Hi 

marty9410 said:

If I understood your comment properly, I would have more freedom in regards to how I would format the information I'm sending, right?

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. 

marty9410 said:

How many bytes would I be looking at if I used the uart example? 

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

marty9410 said:

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?

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

[marty9410]

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-

ovrebekk said:

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

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

[ovrebekk]

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