Alternative title: your Bluetooth is great, and you should feel great!
Little Bluetooth devices are awesome! What’s not to like about teeny little things with switches and lights, magnetic sensors and motors? And over the years, I’ve learned what makes a device easier or harder to control.
But first, a quick TL/DR about Bluetooth for people who aren’t as familiar. Some devices are like a serial port: you send bytes, and you get bytes, and the device maker has to invent a little protocol for what the bytes mean.
Picture break: some of the Bluetooth devices mentioned
Left to right: MetaWear, SensorTag, BERO robot, TI Lamp kit
Other devices are BLE devices: each device has a set of “services”; each service has a set of “characteristics” with a name and value which can often be read, written, or can send a notification on change. There are a bunch of standard services and characteristics. For example,
service 180f is the battery service; it includes
characteristic 0x2a19, battery level which is a single byte with a value 0 to 100.
Extra-wordy documentation!
I’m looking at
you, otherwise awesome
BBC micro:bit. Here’s a short snippet from one characteristic:
Read Mandatory
Write Excluded
Write Without Response Excluded
Signed Write Excluded
Reliable Write Excluded
Indicate Excluded
Broadcast Excluded
Writeable Auxiliaries Excluded
Extended Properties Excluded
That’s a big table with lots of rows, and it could all have been replaced with a single entry: “Supported operations: Read”.
Sloppy details!
Service 0x180a, device information, includes characteristic 0x2a29, Manufacturer name string. It should be something like a company name, right? Like “Texas Instruments” should be the manufacturer name on their delightful SensorTags. In reality, the most common manufacturer names I see is a blank string, and literally the words, “Manufacturer name”.
Similarly, each characteristic can be named. TI is really good about adding clear names to their device characteristics; you can almost use just the names to guess how to control the device. The micro : bit, less so. I had to update my Network Explorer program to convert the BBC GUIDs into more readable names.
More bluetooth devices
Left to right: BBC micro: bit, DOTTI, Hexiwear, Magic Lamp
Slow commands!
The
Dotti is an 8x8 pixel light where each pixel can be set to any color using a Bluetooth command. Too bad the write is a “write with response” which is extra-slow, so that actually filling up the screen is slow and painful instead of fast. The BBC micro : bit, in contrast, has a single command that can fill its entire 5x5 pixel display in a single faster command.
Make the app do all the math!
The original 2541 SensorTag is a small device with a bunch of sensors – temperature, pressure, and more. TI decided that “raw” access to the data was more important than “simple” access. This is the temperature and pressure code that each app needs to write:
t_a = ((c0 * t_r / Math.Pow(2, 8) + c1 * Math.Pow(2, 6))) / Math.Pow(2, 16);
S = c2 + c3 * t_r / Math.Pow(2, 17) + ((c4 * t_r / Math.Pow(2, 15)) * t_r) / Math.Pow(2, 19);
O = c5 * Math.Pow(2, 14) + c6 * t_r / Math.Pow(2, 3) + ((c7 * t_r / Math.Pow(2, 15)) * t_r) / Math.Pow(2, 4);
p_a = (S * p_r + O) / Math.Pow(2, 14);
p_a = p_a / 100.0;
The newest SensorTag, the 1350, has values that can just be read directly. Except that they are the only 3-byte results I’ve ever seen. Fun fact: there aren’t any helper libraries for reading in 3 byte values.
Ignore the math details!
Looking at you,
Google Eddystone! One of the values that an Eddystone beacon can produce is the temperature of the beacon; it’s documented to be a floating number in “8.8” format.
Specifically, here’s what the Eddystone spec says:
- Beacon temperature is the temperature in degrees Celsius sensed by the beacon and expressed in a signed 8.8 fixed-point notation. If not supported the value should be set to 0x8000, -128 °C.
Now, that actually doesn’t look bad; there’s a (mediocre) example and a link to the exact details. The link, however, goes to the main page for the current Cornell ECE 4760 course in Microcontrollers. It’s not even to a specific lecture. I eventually found
lecture #11 to be useful.
(Weirdly, there’s a python library for the Ruuvi tag that says that the temperature data is in “8.8” format. But they decode it using the RuuviTag way, where the second byte just has a value 0..99, and where the first byte actually isn’t in two’s complement.)
And some more little devices
Left to right: another MetaWear device, NOTTI, the 1350 SensorTag, and the AutoBike with a Bluetooth shifter
Pretend it’s serial!
The
Magic Light BLE is a pretty standard Bluetooth-enabled, color-changing bulb. It’s weirdness: that instead of having a simple characteristic for setting the color (like the TI beLight and pretty much all of the others!), they have a “serial protocol”. There is a single characteristic to write data to, and a single one to read from, and you have to send in a set of bytes using some other protocol that they just made up.
For extra weirdness: they don’t think Bluetooth is reliable, so there’s a bizarre checksum on the command.
This is different from the
puck.js device, where they do the same kind of thing, but it’s OK because the data you send is literally a stream of JavaScript commands (how cool is that?)
I also give a pass to my
Autobike that has a computer-controlled continuously variable transmission with a stream of Bluetooth data. It’s an older device from before all the BLE stuff was more standardized. And I really like the bike.
And a word about my apps…
Some of my apps directly control devices:
BERO Robots,
Quirky Nimbus,
Autobike,
TI SensorTag 2541,
Magic Light,
TI BLE Lamp,
MetaWear. And my do-it-all
Network Inspector gives a more raw approach to investigating Bluetooth devices.
And then there’s the Best Calculator,
IOT edition. It is programmable in
BASIC (!), and the BASIC has a bunch of extensions to make all kinds of IOT and Bluetooth programming easy. It’s got a free trial, and will save you time when you’re automating your life. Give it a try!
