[time-nuts] time sync from cellphone TO microcomputer

[Jim Lux]

On 11/21/15 2:43 AM, Attila Kinali wrote:
> 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?

something along those lines.. maybe the phone does the mod/demod (there
are PSK31 apps, for instance)..



>
>> 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.

And one could probably do a round trip measurement once you're connected.


>
> 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.

yes, BT was what we were thinking..




>
> 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.

of course, as I've found, not all phones and iDevices (particularly
older ones, like my old iPad 1) support BTLE


>
> 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.
>

Useful to know..


So, probably reasonable to get 1 second level sync, sub 1 millisecond is
probably not possible, somewhere in between is plausible.

Well, for the things we were talking about that's probably plenty good.