If you are new to Arduino you might not understand what the ‘shields’ are. Basically people with much better electronics knowledge than me have worked out how to hook up various components to arduino board using a standard set of headers. In this case the smart guys at Red Bear Labs have worked out how to wire a Nordic nRF8001 Bluetooth Low Energy IC to an Arduino. Each shield can have other shields stack on top of it. In this demo I am using a Danger shield from Sparkfun to provide 3 sliders to allow us to change the color of our iOS app.

The three shields to be used, the Arduino, the Red Bear Labs Bluetooth LE shield, and the Danger Shield.

The shields stacked together.

We will use these shields will be to use the three sliders on the danger shield to control the iOS app. So you can get an idea of what is going to happening I have produced a short video of the end result.

The main change in this Arduino code is that the analog pins are setup for reading in the setup, and then in the main loop we check the values and if they differ from the stored values by more than 10 we will send that data to the Bluetooth host. I choose a value 10 to ignore tiny changes simply because of electrical interference or temperature changes.

When we send the data we are sending a sequence of 9 bytes, the first byte telling us which value we are about to read, then the value of the slider. Arduino’s have 10bit analog to digital converters, which means the values are between 0 and 1023. We also print these values to the serial output so that it is possible to watch what is happening on the shield while you are running.

On the iOS side of things it is a little more complicated. As the connection is made we need to drill down and find all of the information about device. A Bluetooth LE device is seen by Core Bluetooth is seen as a peripheral, each peripheral has many services and those services have characteristics. It is the characteristics that we are going to read from and write data to. The setup of these peripherals, services and characteristics is handled by the BLE.h library. This is done as a series of calls to the Core Bluetooth delegate.

Once the Bluetooth hardware is ready on our device, we call our startLookingForConnection method. The key call at this stage is the scanForPeripheralsWithServices providing our service ID.

All things going well, this will call our delegate method centralManager: didDiscoverPeripheral: advertisementData: RSSI:. We keep track of the peripheral , set our self as the delegate and then ask the central manager to connect to the peripheral. We are also updating a string property ‘bluetoothStatus’ so we can display a label with details of our status to the user.

The next delegate method we handle is the connect/disconnect of the peripheral. I included a disconnect option so if the Arduino is power cycled the iOS app will reconnect. The main call to a connected peripheral is to make it discover the services available.

The discovery of services and the and subsequent discovery of characteristics are both delegate methods of the CBPeripheral. It is the individual characteristics of a service that we write data to, and read data from. In our case we send a message that we want to receive updates from every characteristic using the call [peripheral setNotifyValue:YES forCharacteristic:characteristic]; With this call we don’t have to poll for changes in our Bluetooth device. Our final check is to find the reset characteristic, which I think is a Red Bear Labs specific characteristic which we call when we are done reading data from the device.

With the device setup we are now ready to receive data from the Bluetooth Shield. We receive delegate callbacks to the peripheral:didUpdateValueForCharacteristic:error: The values from the sliders are at byte ranges 1-2, 4-5 and 7-8. We need to unswap the order of the byte values, something you have to be aware of as the architecture of a Bluetooth LE device might be different from the iOS device. In this case we swap the bytes and return a UInt16 value with the bytes returned to a value that iOS can use. Once the bytes are unwrapped we store them in local variables.

For our user interface I have thrown in some Reactive Cocoa to make it simple to update the user interface when changes occur in our Bluetooth device. The ins and outs of Reactive Cocoa are for another blog post, but it is a perfect match to the asynchronous nature of Bluetooth devices. The label text is hooked up to the bluetoothStatus field that we are updating in our controller, and the background color is derived and updated whenever one of the values from the Bluetooth device is updated. Note that the values from the Arduino analog pins are a 10 bit integer, so they need to be divided by 1024 to get a float value suitable for calculating a color.

While the process is a multiple step one it is quite easy to get the details of your bluetooth device and receive information as it is updated. It is now easy for your iOS app to control the real world, or for a ‘dumb’ device to now connect to an iOS device and display its status.