Archive for August, 2013
Yea and verily! I've successfully flashed a BLE112 with firmware that makes it behave as an iBeacon that can be used for iOS 7's Bluetooth LE location services.
By using a CC2540 USB Dongle and TI's SmartRF Packet Sniffer application and an iPhone running a sample app provided by Apple on the Development site, I reverse engineered the iBeacon protocol and made a firmware project for a BLE112 using a minimal GATT profile and a BGScript to set the custom advertising data required for a iBeacon.
I guess I'd better design a PCB for a minimal circuit containing a BLE112, a 3 V coin cell and a programming header.
Looking at some of my old schematics, I can see that I haven't been entirely consistent when naming components. Nowhere near consistent, actually.
Sometimes I have used "T" as prefix for transistors and sometimes "Q". And especially IC's that are prefixed either with "U" or "IC" – often I have used both in a single schematic. And also connectors that are named "CON" or "J" or "JP". Sloppy…
Well, no more! This page on Wikipedia has a nice table with designators for various component types (even though it does not comply with with IEEE- or ANSI-whatever standard).
So this is what I will use henceforth:
|D||Diodes – all types including Zener, Schottky and LEDs|
|U||IC's of all kinds. Technically it is used for "Inseparable Assemblies".|
|J||Connectors. The more fixed part of a connector pair (often the part soldered to the PCB).|
|P||Plugs. The less fixed part of a connector pair (i.e. the one on the wire).|
|Q||Transistors – all types including MOSFETs, IGBTs, BJTs etc.|
|Y||Crystals and oscillators|
|X||Transducers/sensors (no, X is not for crystals anymore).|
|JP||Jumpers. Not connectors but only actual jumpers that are linked or unlinked.|
|TP||Test point (pad or pin for measuring)|
|MP||Mechanical parts (standoffs, screws, mounting hardware etc.)|
Apple has announced the introduction of Bluetooth LE-based positioning in their iOS 7 framework. Apps can now get notified when entering a region which basically is defined as being close enough to a BTLE beacon with a specific identifier.
The iOS framework already supports the concept of regions and notifications when entering regions, but until now the system has relied on GPS and WiFi positioning. Which will not be able to provide very accurate positioning data when used indoors.
Bluetooth LE-based positioning, however, will work just fine. And will be able to provide very accurate positioning data. Right down to "you are standing in front of this particular sculpture in the museum" or "you are standing at check-in counter number 18". Nice.
In keeping with the classic Apple way of doing things, Apple has decided not to use the existing Bluetooth Proximity Profile but do things their own way.
Since Apple has not published the specifications for the iBeacon protocol yet, I had to snif the Bluetooth packets from an iBeacon device (using a TI CC2540 USB Dongle and their SmartRF Packet Sniffer – http://processors.wiki.ti.com/index.php/BLE_sniffer_guide).
Apple puts all the required information into the advertising packets in a "Manufacturer Specific Data" field of connectable undirected advertising events.
Apple's iOS 7 pre-release documentation shows what properties are available for iBeacons (but I'm not going to tell you since that information is still under NDA) so they are fairly easy to spot in the advertising data and so it should be easy to copy – and if necessary modify – that data and put it into a BLE112 of my own.
I'll keep you posted as to how it works…