Saturday, June 22, 2019

Bitty Data Logger 4.0

Today marks the release of a new version of Bitty Data Logger for Android and iOS. BittyWeb users, don't worry.... the new release will be with you soon.

So what's new in this release and why were these changes made? Let's take a quick walk through:

1. User Code Capture Mode

The concept of 'capture mode' has been introduced. For the accelerometer, magnetometer and temperature data sources, the choices of capture mode are AUTO and USER CODE. For general data (previously known as 'pin data'), the choice is restricted to USER CODE.

AUTO Capture Mode
This represents the way in which data was acquired from the accelerometer, magnetometer or temperature sensor previously. Your remote device (e.g. a micro:bit) must have the Bluetooth accelerometer, magnetometer or temperature services in its code, typically achieved with a single block in MakeCode and.... well, that's it. You don't really need to do anything else since those services will take care of sampling data from the associated sensor and transmitting it to Bitty Data Logger automatically.

AUTO capture mode is the mode to use unless you have a good reason not to.

USER Code Capture Mode

User Code capture mode is available for all data sources

In the new User Code Capture Mode, your code on the remote device is responsible for acquiring data from wherever it might be, calculating it or deriving it in some other way - the choice is entirely yours. Your code must also transmit it over Bluetooth using the UART service, and in the correct format. 

Think of the UART service as allowing you to send and receive messages or byte arrays. It can handle any data, subject to a maximum message length of 20 bytes. A special set of messages have been defined for communication with Bitty Data Logger and you can find details in the new Bitty Software GitHub repository.

Any of the four data types (accelerometer, magnetometer, temperature and 'general data') can be acquired using USER capture mode. General data can only be acquired using USER Code Capture Mode, though.

Motivation and Benefits

So, why was this change made?

USER Code Capture Mode allows you to separate capturing data from transmitting it over Bluetooth. This could mean, for example, that you could write some code for your device which captures data and stores it to a file system as it is being captured. Later, perhaps when a button is pressed or when a Bluetooth connection is established, you'd then read through the stored data and transmit it to Bitty Data Logger. This would be useful in situations where you want to place your device somewhere that it is not practical to have a Bluetooth connection to a smartphone, such as in the great outdoors!

How do you transmit data in user capture mode?
The Bitty Software GitHub repository has lots of code examples. But here's one of them, showing simulated 'general data' being acquired and then transmitted using the UART service.

let connected = 0
bluetooth.onBluetoothConnected(function () {
    connected = 1
    starttime = input.runningTime()
bluetooth.onBluetoothDisconnected(function () {
    connected = 0
let message_type = 0
let timestamp = 0
let starttime = 0
let value1 = 0
let value2 = 0
let value3 = 0
let value4 = 0

let message = pins.createBuffer(11);

function transmitData() {
    timestamp = input.runningTime() - starttime
    message.setNumber(NumberFormat.Int8LE, 0, message_type);
    message.setNumber(NumberFormat.Int32BE, 1, timestamp);
    message.setNumber(NumberFormat.Int16BE, 5, value1);
    message.setNumber(NumberFormat.Int16BE, 7, value2);
    message.setNumber(NumberFormat.Int16BE, 9, value3);
basic.forever(function () {
    if (connected == 1) {
        message_type = 1
        // random numbers used solely for demonstration purposes. Acquire your data here as required.
        value1 = Math.randomRange(0, 1023)
        message_type = 2
        // random numbers used solely for demonstration purposes. Acquire your data here as required.
        value1 = Math.randomRange(0, 1023)
        message_type = 3
        // random numbers used solely for demonstration purposes. Acquire your data here as required.
        value1 = Math.randomRange(0, 1023)
        message_type = 4
        // random numbers used solely for demonstration purposes. Acquire your data here as required.
        value1 = Math.randomRange(0, 1023)

It may also be easier to implement the UART on devices which do not automatically have it, like the BBC micro:bit does, than implementing each of the other services.

Note: The Bluetooth Event Service is no longer used for transmitting general data (previously known as 'analog pin data'). You will need to change existing code to use the UART service instead, as shown above.

2. Pin Data is now called General Data

Previous versions supported Analog Pin Data as a data source. The original idea was that you would connect something like a sensor to one of the 3 analog pins numbered 0, 1 or 2 on the edge connector of a micro:bit and that data would be sent as micro:bit 'events' to Bitty Data Logger. It became apparent that people wanted to capture data from other sources, other pins for example. This was technically possible already but meant you might use pin data #0 as a container for data acquired from pin 9, which worked but was potentially confusing. So the is a simple renaming of the concept. 'General Data' items can come from anywhere you like.

3. Up to 4 x General Data Items are now supported

Previously, a maximum of three pin data items could be captured and supported at the same time. The new release allows you to capture and chart up to four general data items. Ideal for use with products like the Sparkfun Weather:bit, perhaps!

Plotting simulated data transmitted from user code

4. Accelerometer data is now captured in milli g force

Previously this data was captured in units of g.

5. X-axis scaling options

Previously, your chart would fill and rescale automatically as new values were acquired. Now you choose to have the chart scroll without rescaling. Have a play with this feature to see its effect.

That's all, folks!

Saturday, June 8, 2019

Bitty Controller 3.0.0 - micro:bit, Arduino and beyond!

Bitty Controller 3.0.0

The Bitty Controller application was designed for maker projects involving the good old BBC micro:bit. But it's always been possible to use it with boards, micro-controllers and computers other than the micro:bit. And with the new release 3.0.0, using it with non-micro:bit devices just got even easier.

The Dual D-Pad UI


Bitty Controller uses Bluetooth to communicate with remote devices. It sends information about what the user is doing (e.g. the top button in the right hand group was just pressed and then was released) over Bluetooth and in a defined format. The code on the other device has to receive, decode and react to this in whatever way you, the creator of the maker project, want. Maybe you'll want a wheel to start turning or maybe you want to flash an LED. Whatever the response to a user action should be, only you can decide and implement it in your code.

Bluetooth Low Energy (LE), the type of Bluetooth used by the BBC micro:bit and other popular devices like Arduinos and the Raspberry Pi, takes an approach to defining remote interfaces using constructs called Services, Characteristics and Descriptors. The Bitty Software Beginner's Guide to Bluetooth LE describes this quite well, so I won't repeat it here. But the BBC micro:bit has its own set of services (etc), most designed by Martin Woolley (yours truly, in other words!) when he was involved in the micro:bit project a few years ago. A collection of services and the rules for using them is typically known as a Bluetooth 'profile', by the way. The micro:bit Bluetooth profile includes services which Bitty Controller uses for bidirectional communication with a micro:bit.

But what if you want to control a device that uses something other than a micro:bit?

The digital switches UI

Imitating a micro:bit with the micro:bit Bluetooth profile

What's to stop a developer from implementing exactly those micro:bit services on another type of device? And would an application like Bitty Controller be able to tell it was communicating with something which had the same Bluetooth services as a micro:bit but was in fact not a micro:bit?

The answer to the first question is....nothing.

The answer to the second question is.... no. Not if you do it right.

So, your first option for using Bitty Controller with something other than a micro:bit is to implement the required Bluetooth services on your chosen device type.

The analog touchpad controller UI

The Bitty Software GitHub repositories

Bitty Software recently set up some repositories ("repos") on GitHub. Over coming months, we'll publish example code for various types of device, showing how to implement the BBC micro:bit profile on devices which are not micro:bits, so that you can use Bitty Controller and Bitty Data Logger with those devices. See for what we have for Bitty Controller so far.

The enhanced touchpad UI with cells for sensor data and a handy button

Introduction the HM-10 style serial profile

Some maker boards do not have Bluetooth, themselves. So if you want Bluetooth, you have to connect an external Bluetooth module, a system on a chip, which allows your board to use Bluetooth. Usually such modules connect to your board's GPIO pins or similar.

There are numerous external Bluetooth modules available, with various designs. The HM-10 is a particularly simple and affordable one. It connects to GPIO pins and uses serial communication to pass data back and forth with the connected board. It's not easy to programme though, so rather than programme it to give it the Bluetooth services you need, instead it comes preprogrammed with one service, containing two characteristics. You use one characteristic to write data from the remote device to the device the HM-10 is connected to and the other allows the HM-10 connected device to transmit data over Bluetooth to the other device. It's like sending and receiving messages.

You can send and receive any type of data you like. You define what the format is in terms of messages and message layouts and your code has to formulate messages and receive and decode them (and then react to them).

The touchpad UI with up to 12 configurable buttons

Bitty Controller and the HM-10 style serial profile

Release 3.0.0 makes it possible for you to choose whether Bitty Controller should use the micro:bit Bluetooth profile or the HM-10 style serial profile.

New - Profile type selector in the Options screen

And this, of course, means it's possible to use Bitty Controller with all sorts of remote devices!

Take Roger Wagner's Hyperduino, for example. This is a very cool piece of kit. The Hyperduino consists of a clever daughter board which makes some potentially complex connectivity and electronics scenarios a breeze to set up. It works with an Arduino Uno and for Bluetooth, uses a connected HM-10.

Roger Wagner's Hyperduino and a connected HM-10 Bluetooth module

HM-10 and Bitty Controller Messages

Bitty Controller has defined a number of message types so that it can convey user interaction information via the HM-10 and can receive data, such as might have been acquired from sensors, from the board the HM-10 is connected to. All messages start with a single byte opcode, whose value defines the type of message. This is then followed by one or more other bytes, depending on the message type. We've published a template Arduino sketch which should make it easy to use Bitty Controller with Arduino-based maker projects. The README file includes details of the messages and their format. See

Happy Making!

That's it! Watch out for updates to the new GitHub repo and good luck using Bitty Controller with you micro:bit and non-micro:bit maker projects.

Bluetooth communication roles