More Accurate Timestamps about barnowl-hci

[jeffyactive]

Hi @trademark18,

You are correct that the barnowl packages, and the raddec objects they use to represent RADio DECodings, measure time to the millisecond using UNIX epoch timestamps.

Answers:

1. For the Raspberry Pi, we've never explicitly tested the accuracy of the timestamp of receipt of a Bluetooth packet, but would expect it to be on the order of the temporal accuracy of the OS.
2. Yes, sub-millisecond timing will almost certainly require dedicated hardware with clock synchronisation.
3. Wouldn't recommend using the Pi's on-board Bluetooth radio for accurate timing, even if coupled with a precise clock.

If you're looking to do time of arrival (TOA) or time difference of arrival (TDOA) calculations for real-time location, note that this can be quite a challenging endeavour (especially with Bluetooth Low Energy). Myself and the team at reelyActive have experience with this, so don't hesitate to reach out via any of our channels: https://www.reelyactive.com/contact/

As a more general note, we could add support for nanosecond-precision timestamps to raddec in future if there's interest to use barnowl for timing-based real-time location. Expectation at this stage is that precision location systems will use their own proprietary software and the open source barnowl & Pareto Anywhere stack might serve in parallel for complementary use cases.

Hope that provides insight and glad to hear that the barnowl packages have been useful to you!

[trademark18]

Thanks for the thorough answer (as usual!). We both know the sometimes-frustrating nature of RSSI when it comes to its uses for location reckoning, so I was wondering if accuracy could be augmented using TDOA techniques. Currently we do location reckoning based solely on the relative difference in RSSI (plus several mathematical and geographic filters). Accuracy is sufficient for our use cases, but I was just curious if we could leverage the TDOA to boost accuracy by some worthwhile percentage.

Sounds like if I (or the reader) want to pursue this further it will involve researching high-resolution (dedicated hardware) clocks, some way to synchronize them across devices, and finally a modification to the raddec package to support fetching and recording the timestamp from the dedicated clock.

Unfortunately I don't have time at present to all that research, but thanks for satisfying my curiosity and helping me understand what's involved.