On 11/21/15 2:43 AM, Attila Kinali wrote:
On Fri, 20 Nov 2015 15:47:27 -0800 Jim Lux <jim...@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.


_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to