[time-nuts] time sync from cellphone TO microcomputer

Attila Kinali attila at kinali.ch
Sat Nov 21 05:43:31 EST 2015

On Fri, 20 Nov 2015 15:47:27 -0800
Jim Lux <jimlux at earthlink.net> wrote:

> While this is trivial with a GPS receiver, we were thinking about a very 
> minimalist implementation, with a smart phone as the control interface.

So, some electronics with a micro controller that do the actual
modulation/demodulation and a smart phone to control that?
> That brought up another discussion about whether it is possible to get 
> time sync (at a better than 1 second, but potentially at the 
> milliseconds level) across bluetooth or WiFi from a cellphone (Android 
> or iDevice).

All these wireless protocols are relatively low delay. Most of the
handshakes (which cause delay) is done during "connect" (peering or
whatever they call it) and the "master" forces the "slaves" to follow
its clock. Unfortunately, this synchronization is not accessible from
the higher levels. But as I said, the delay is rather low. 

If you want to use a uC as receiving partner, i would go for BT/BTLE
rather then wifi as it's easier to setup. There are wifi modules that
behave kind of the computer modems of old (complete with AT command set)
to connect to an AP and intiate a TCP connection. But if you want to
go for a smartphone, it makes more sense to use BT/BTLE as you can
directly connect the smartphone to the device, without first needing
to find it in the network. BT was originally started as a wirless 9600
serial connection for cell phones and has retained much of that property
in the protocol. You can still use it as such and that works pretty much
with every cell phone today (if it supports BT). BTLE (or BT smart as it is
officially called) is it's modern cousin of sorts. The on-air protocol
has been completely rewriten and as such should count as a different
system, but it retains an API that is very similar to that of BT.

Although the standards are freely available, they are not an easy
read. I used the book "Bluetooth Low Energy: The Developer's Handbook"
by Heydon 2-3 years ago to get the basic understanding.

In terms of modules you can get to day, the cheapest are the
BTLE 4.x modules. Some of them support "regular" BT, but not all.
The usual interface to those is an UART, sometimes SPI.
Get at least a 4.1 module, as they fixed a couple of bugs in the
protocol of version 4.0.

As for delay, that's a bit a more difficult question. BTLE is optimized
for low power use, as such has higher delay than BT. The poll interval
of the slave can be set to anything between 7ms to 4s. There are a few
other parameters that control polling interval, but my memory is hazzy there.

I've never actually measured what delays one can achieve, but given that
we were able to transfere data in small chunks pretty quicky, i guess it
could not be much over 10ms.

A word about compatibility: All Android Phones support BT, but BTLE support
came only around 2012/13. I think it's safe to assume that any Android phone
after 2013 supports BTLE. With Apples iPhones it was the other way round.
They supported BTLE early on (4s in 2011) but didn't support BT until much
later (don't remember exactly, i have something like 2013 in my head).

As a stack on the uC we used bluektichen [1,2] which did a pretty good
job. The author is also very helpfull and easy to talk with. I'm pretty
sure he'd help on non-commercial projects as well. (for commercial
projects, his prices are pretty cheap)

BTW: this information might be important to select the 
right sub-protocol[3]:
So far, the most popular use of BTstack is in peripheral devices that can be connected via SPP (Android 2.0 or higher) and GATT (Android 4.3 or higher, and iOS 5 or higher). If higher data rates are required between a peripheral and iOS device, the iAP1 and iAP2 protocols of the Made for iPhone program can be used instead of GATT. Please contact us directly for information on BTstack and MFi.

MFi means here "Made for iPhone" which is Apples way of extorting money
from device manufacturers. You have to buy an Apple crypto chip for that
and put it in each device. And they wont talk to you unless you buy a
few millions a year. Stay clear of that.


			Attila Kinali

[1] https://github.com/bluekitchen/btstack
[2] http://bluekitchen-gmbh.com/
[3] http://bluekitchen-gmbh.com/btstack/protocols/

Reading can seriously damage your ignorance.
		-- unknown

More information about the time-nuts mailing list