Synchronize timestamps between SoC and mobile app

RE: Synchronize timestamps between SoC and mobile app

Einar Thorsrud — Thu, 26 Sep 2019 08:21:54 GMT

A17: Reducing the connection interval would reduce the delay introduced by packet loss, so it could help in that way. I do not see any other benefit. Regarding packet loss it depends. The center may have a harder time scheduling events the more frequent they are, so in that sense, the likelihood of packet loss may be higher. But I do not see any other problems, except for the obvious increase in average power consumption.

RE: Synchronize timestamps between SoC and mobile app

alejandrohc — Wed, 25 Sep 2019 12:22:08 GMT

Hi Einar,

Q17:

Do you think that dynamically reducing the connection interval for the timestamp sync process (to something close to 7ms) would help?
I know that it is now also supported by iOS, but am afraid that it would cause more packets to get lost / not arrive during that smaller time frame.

Other than that, all of my questions have been addressed and I thank you for your helpful advice.

RE: Synchronize timestamps between SoC and mobile app

Einar Thorsrud — Mon, 23 Sep 2019 08:25:45 GMT

Hi,

A11: No. There is no standard way, so there is no way of doing this together with a phone.

A12: It is not possible to pop packets from the Tx queue on the nRF side. Once the packets are queued the will be sent at some point (unless there is a connection supervision timeout).

A13: No updates. It is still not supported by the SoftDevice.

A14: The pseudo-random delay is only used for advertisement packets, not for connection events.

A15(13): It depends on the link configuration (the packets per connection depends on several factors such as packet lengths, event duration, and buffer sizes). You can only control the nRF side, as the BLE stack on the phone is less configurable. So ideally "Yes", and you should remember that even if you test with one phone, a different phone can behave differently.

A16(14): I have not heard about it being an issue with indications, and it seems less likely since the ack has to come the whole way round before a new packet is transmitted. But in any case, this is just a strange behavior we have seen a few times within the phone, and not something that you can observe on the BLE link. It is difficult to predict what may happen on the API between the application and BLE stack on the phone side since that is totally out of our control.

RE: Synchronize timestamps between SoC and mobile app

alejandrohc — Fri, 20 Sep 2019 14:34:49 GMT

Hi Einar, thank you for your responses, they're very informative.

A1: Great to know I'm on the right track.

A3: I see, did not consider that the protocol is retrying the transmission of packages for me.

Q11: Is there any other way of transmitting data without the protocol automatically retransmitting lost packages? This way I could send a series of packages, where the one with the lowest offset wins. Dropped and therefore outdated packages would then not further clutter the queue either (I am thinking of something like UDP vs. TCP in the web).

A4: Yes, it is the exact same firmware on the SoC. Q12: How can one pop packages from the queue? That would help me to cancel the message if it's too late already.

Q13: Do you have any news about the potential way of knowing which characteristic sent out a packet? With that information I could notify the mobile phone if the packet was sent out too late.

A5: Q14: Is that pseudo-random delay exclusive to the advertisement packets or are notifications also susceptible to that due to the transmission window?

A6, A7: Interesting.
A8: Will definitely try to not transmit packets from the SoC to the phone during the timestamp synchronisations. Q13: Should I also make sure no packets are transmitted from the phone to the SoC? That would be harder to do, particularly in iOS since I don't control its services ANCS and CTS for push notifications and time correspondingly.
A9: Some phones changing the order of the notifications sounds critical, will then not assume that the packets are always sent in a specific order. I think this is not an issue for Indication Q14: right?

A10: That's a very interesting post indeed, I've looked at it in detail. In an ideal world, I'd be able to develop a BLE dongle what connects over USB to the mobile device and also runs a Nordic Semi SoC with a custom radio notification protocol... but that's a dream for another time.

RE: Synchronize timestamps between SoC and mobile app

Einar Thorsrud — Tue, 17 Sep 2019 12:13:18 GMT

Hi,

A1: Yes. If sd_ble_gatts_hvx() returns NRF_SUCCESS, the packet has been queued. It will return NRF_ERROR_RESOURCES if the queue is full.

A2: The notifications are transmitted int the order there were transmitted. But if you also send other BLE data, there may be some other packets that were queued before, and if so, these will be transmitted before. This is the most likely explanation for variation within a connection event.

A3: The most probable reason for seeing delays which are multiple of a connection interval is packet loss, which leads to retransmission the next connection event (and so on, until the packet is successfully transferred or there is a supervision timeout). It could also be that if you are transmitting a lot of data and/or the link does not support "enough" packets per connection event, the packet is delayed until the next event in this case as well.

A4: Is this with the exact same firmware on the nRF side? The number of packets you can queue depends on the SoftDevice configuration. If not, then perhaps there is a problem with your test, for instance, that packets are popped from the queue while you are filling it (in the middle of a connection event), and therefore you can fill more? But in another case, you are doing the test outside a connection event? This is just one possible explanation.

A5: I am not in a position to recommend one or the other. However, putting the timestamp in the advertisement packet also has the limitation that there is a time from when you read the timestamp to when you transmit the advertisement. A particularly important point here is that advertisement packets are transmitted with a pseudo-random 0-10 ms delay, which may not be acceptable.

A6: No good/obvious alternatives. Since you are communicating with a phone, you have to use standard BLE, so using, for instance, ESB (which has been recommended to some customers before) is not an option in this case.

A7: Yes. The nRF is capable of handling several roles concurrently, and advertising while maintaining a connection is no problem.

A8: Yes, using notifications in a connection seems sensible, and looks like the best approach in my mind. The accuracy depends on several factors. You will get the best accuracy if you don't transmit other BLE data and you syncronize the clocks regularly. Then you can filter out synchronization packets that have a jump in the time since they are probably bad (a result of packet loss). Inaccuracies due to other packets being queued before is a bit more difficult to predict, but perhaps you could make sure that you never queue other data until after having queued the synchronization notification.

A9: This one is difficult. It can vary from phone to phone and may change over time (with SW updates). So I cannot make any promises on the phone side. We have also seen earlier that some phones may change the order of the notifications. But this is unfortunately out of our control.

A10: Not really. You may find Wireless timer synchronization among nRF5 devices interesting, as it describes the problems you are seeing. But the proposed solution cannot be used between an nRF and a phone since the phones do not support ESB.