Just a short post to let everybody know about a new BLE book that’s recently become available, Bluetooth Low Energy: The Developer’s Handbook, by Robin Heydon.  I ordered it months ago when I first heard about it, and it finally arrived a few days ago.  As far as I know, it’s the first (and only) book written on the subject, although please let me know via comments if you know of any other BLE books.

Since it only arrived a few days ago, I haven’t had much of a chance to look through it, but I’ll be sure to write a review after I’ve spent some time reading it.

connectBlue BLE Platform Module cB-OLP425i-16

I recently discovered the OLP425 BLE module from Swedish company connectBlue, based on the CC2540 chip from Texas Instruments.  While there’s a wide variety of BLE modules available today based on the CC2540, such as the BLE112 from Bluegiga, most of them are quite similar – they simply provide a more accessible hardware interface to the CC2540, as well as the necessary radio and telecommunications certifications. Unlike other basic BLE modules, the connectBlue BLE Platform Module OLP425 is available in a configuration with the following additional options:

• Temperature sensor
• Accelerometers
• 2 LEDs
• JST connector
• Battery holder for CR1632

This is a very appealing package, since you can now purchase one of these pre-configured OLP425 modules with many of the basic sensors already attached and ready for development. No longer do you have to worry about designing your own PCB and soldering a tiny 2mm by 2mm Ball Grid Array accelerometer onto it.

If you thought the QFN package of the CC2540 was difficult to solder, it’s nothing compared to the BGA package of the Murata CMA3000D Accelerometer that’s included with the CC2540 Keyfob

The OLP425 can be configured to include a JST connector, which allows you to use a JST 6-poles to IDC 10-poles adapter cable (part number cB-ACC-71) to connect the OLP425 to the TI CC debugger for programming and debugging, as shown in the following image:

cB−OLP425i−26 with cB-ACC-71 adapter cable, connected to TI CC Debugger

The OLP425 comes in 4 different variants, as described in the very informative data sheet:

I ended up purchasing the cB−OLP425i−26 module (Max equipped, internal antenna), from M2M connectivity in Victoria, Australia, for $48, plus $17 for the cB-ACC-71 CC Debugger adapter cable and $20 for shipping.

At $48 for the module, it’s quite a bit more expensive than the $19.19 AUD charged by Glynstore for the BLE112. However, if you’re looking to produce large quantities of these devices, it’s possible to get them custom made with different accessories, thereby reducing the cost.

I should mention at this point that Blueradios has been selling a similar sensor device for quite a while now, named the BR-BUTTON-S2A SensorBug, which includes an accelerometer, water detector, light sensor and temperature sensor.  However, at the current list price of $149 USD, it’s over $100 more expensive than the OLP425.

The physical size of the OLP425 is quite small at only 15×22 mm, however, the battery holder for the CR1632 takes up the majority of the space.  To be honest, I was quite surprised at the large size of the battery holder, since I assumed it would use a low profile metal retention style, like the CC2540 Keyfob uses.  They may have opted for the larger plastic battery holder due to fact that there isn’t much space between the battery and the CC2540 chip, and RF interference may have been an issue.

cB−OLP425i−26 with battery holder for CR1632

Having said that, I’m glad they decided to use a CR1632 instead of CR2032, since it would’ve been even bigger if it used a CR2032, as you can see in the following image:

CR2032 (left) versus CR1632 (right)

Compiling the Demo Software

The OLP425 comes pre-programmed with a demo application based on the Keyfob code from the CC2540 dev kit.  connectBlue provides a great getting started document which explains all the functionality of the demo software, available here.

Unfortunately for myself, I didn’t bother reading the documentation, and I tried flashing the demo application to the OLP425 device, without realising that the module already came programmed with it.  This wouldn’t have been a problem, except for the fact that I encountered numerous errors from IAR when attempting to compile the demo software.

The reason I had difficulty compiling the demo code was because I didn’t read the cB-OLP425 Development Kit Getting started document, or more specifically, the section entitled Installation of cB-OLP425 SDK zip-archive. If I had, I would’ve noticed that you’re supposed to “extract the cB-OLP425 SDK zip-archive into the installation folder for the Texas Instruments CC2540 BLE Software Development Kit”.  Once I did this, all my problems were solved.

So assuming you’ve extracted the OLP425 SDK as described in the getting started document,  you should now be able to open the IAR project file C:\Texas Instruments\BLE-CC254x-1.2.1\Projects\ble\cB-OLP425Demo\CC2540DB\Demo.eww, connect your OLP425 to the CC Debugger using the cB-ACC-71 adapter cable, and hit the “Download and Debug” button to compile the demo code.

A word of Caution: make sure you don’t insert a battery into the OLP425 if it’s hooked up to the CC Debugger.  You can either use a battery, or connect the OLP425 to the CC Debugger – never both at the same time.

Using the demo software

Whereas the CC2540 KeyfobDemo required you to press one of the buttons to enable advertising, the cB-OLP425 demo software is much smarter and uses an accelerometer interrupt generated when the device is moved, to wake up the CC2540 and enter advertising mode.  If you open up the cb_demo.c file in IAR and uncomment the following code on line 666, it’ll cause the green LED on the OLP425 to flash whenever it enters advertising mode, which can be helpful when debugging:

cbLED_flash(cbLED_GREEN, 1, 100, 0);

So now that we’ve flashed the OLP425 with the demo software, it’s time to test it using the Texas Instruments BTool application (C:\Texas Instruments\BLE-CC254x-1.2.1\Projects\BTool\BTool.exe), along with the USB BLE adapter from the CC2540 Mini Dev Kit.

The Getting Started guide provides very good instructions on using BTool to establish a connection with the OLP425 and describes how to use the Characteristic Write operation to modify the state of the LEDs, so I won’t duplicate that information here.  Instead, I’ll briefly describe how to enable the notifications for the Temperature sensor.

Enabling Notifications for the Temperature Service

If we consult the Texas Instruments Bluetooth Low Energy CC2540 Mini Development Kit User’s Guide (swru270b.pdf) under section 4.3.6, Enabling Notifications, we’ll see that it’s possible for a GATT server device to “push” characteristic value data to a client device, without being prompted for a read request.  We can configure the demo software on the OLP425 to push a new temperature value if it detects a change, or accelerometer data if the device is moved.

According to the CC2540 Mini Development Kit User’s Guide, in order to enable the notification for the changes in temperature, we need to first find the handle of the characteristic for the temperature service. If we consult the Temperature Service section of the cB-OLP425 Development Kit Getting started guide, we see that the characteristic UUID is 0xFFE1. We could also have found this value by looking at the C:\Texas Instruments\BLE-CC254x-1.2.1\Projects\ble\Profiles\Temperature\cb_temperature_service.h file, since this is where the Profile for the Temperature service and UUIDs are defined.  Note that this UUID (as well as the UUIDs for the LED Service and Accelerometer Service) do not conform to any specifications in the Bluetooth SIG.

Now that we know the characteristic UUID, we can obtain the handle of the UUID as well the properties of the characteristic.  We do this by using the Discover Characteristic by UUID process outlined in section 4.3.4 of the CC2540 Mini Dev Kit User’s Guide.  In short, we welect the “Read/Write” tab in BTool, then set the “Sub-Procedure” to “Discover Characteristic by UUID” and enter E1:FF for the Characteristic UUID in BTool (note that the Least Significant Byte is entered first, and the Most Significant Byte is entered last), then click the “Read” button.  On my machine, I get the hexadecimal values “12 37 00 E1 FF”, as shown the following image:

Obtaining Characteristic Value declaration

If we consult Section 3.3.1 of the Core v4.0 Specification from the Bluetooth SIG website, we see that the first byte of this value is the Characteristic Properties, and the value 0×12 represents a Read property (0×02) as well as the Notify property (0×10), since 0×02 + 0×10 = 0×12.  The second and third bytes “37 00″ tell us that the handle of the characteristic value is 0×0037.  The fourth and fifth bytes tell the UUID of the characteristic, 0xFFE1.

Going back to the CC2540 Mini Development Kit User’s Guide, we see that we can enable notifications of the Temperature Service by writing a value of 0×0001 to the client characteristic configuration descriptor for the particular characteristic. The handle for the client characteristic configuration descriptor immediately follows the characteristic value’s handle. Therefore, a value of 0×0001 must be written to handle 0×0038 (since this value immediately follows the handle of the characteristic value 0×0037 as found above). Enter “0×0037” into the “Characteristic Value Handle” box in the “Characteristic Write” section, and enter “01:00” in the “Value” section (note that the LSB is entered first, and the MSB is entered last). Click the “Write Value” button. The status box will display “Success”, indicating that the write was successful.

After enabling notifications on the Temperature Service, I then moved the OLP425 module near my desktop halogen lamp and within a second, I received a notification in the BTool log window showing that the temperature had increased from 25° C to 26° C, as shown in the following image:

Receiving Temperature Notifications

We can remove the notification by writing the value “00:00″ to the Characteristic Value handle 0×0038 as in the procedure outlined above.

Conclusions

I’m very impressed with the small size of the cB-OLP425i-26, as well as the ease of programming the unit with the adapter cable, making it much easier to download software to the module without requiring a breakout board.  I also really liked the documentation provided by the cB-OLP425 Development Kit Getting started guide, which was well written and straightforward.  The cB-OLP425 cB-OLS425 cB-OLS426 Electrical Mechanical Data Sheet also provides a wealth of very useful information.  I liked the fact that the code example used an accelerometer driven interrupt to wake up the module and enable advertising, which provides a useful starting point for people wanting to create a BLE device without a button.

The only downside to the OLP425 is the higher cost compared to other basic sensor-free BLE modules, but that’s the price you pay for the convenience of having the sensors, battery retainer and debugging connector provided for you.

In closing, I’m glad to see a new module on the market that provides something different than all the other standard BLE modules, and I’ve already got several projects in mind that the OLP425 will be perfect for.

UPDATE (December 9, 2012)

After writing the above post, it was explained by Kalle in the comments section that connectBlue have an iOS demo application, as well as source code available.  At the time of writing this blog post, this wasn’t very apparent, however, connectBlue have now updated the landing page for the OLP425 to provide a link to the iOS demo application, which can be found here.

If you’d like to obtain the source code, you’ll need to send an email to support@connectblue.com and ask them for it.  They were pretty quick to respond to my request, and I received access to the source code within a few days of sending them an email.

I’ve been playing around with the demo app for the past few days, and it’s pretty slick.  It scans and pairs with the OLP425 much faster than the Texas Instruments demo iPhone application does with the keyfob, and from the screenshots, it looks like it supports connecting to multiple OLP425 devices as well.  Hopefully connectBlue will decide to post the source code for the demo application directly on their website in the future, in order to make it easier to obtain. I’ve got a feeling that they may just end up doing this after they start to receive thousands of requests from anxious developers!

The bare minimum equipment needed is the following:

• CC Debugger ($49 from Texas Instruments)
• Bluegiga BLE112 module ($18 from the semiconductor store)

And that’s it. You’ll have to figure out some way to connect the CC Debugger to the BLE112, or you could buy a breakout board from Jeff Rowberg and connect it to a breadboard.

So what exactly is BGScript and why is it important? BGScript is a freely available proprietary language developed by Bluegiga for use with their BLE112 modules.  It allows us to write programs for the BLE112 without using the very expensive IAR compiler.  This, of course is very appealing, because IAR costs about $4,000 AUD, which is far beyond the typical hobbyist budget.  BGScript is a nice alternative for applications that don’t need the full complexity of a C based program.

To get started, go to the Create Bluegiga Tech Forum Account page and create an account if you haven’t already done so, then go to the support page and login.  Once you’ve logged in, head to the BLE112 section then head to the “Software Releases” section and download the Bluetooth Smart 1.1 (Beta) Software Development Kit software package.  This contains the windows drivers for the BLED112 USB dongle, sample BGScript projects as well as the necessary tools required for compiling the BGScript projects into hex files to be flashed onto the BLE112.

Then, from the “PC Utilities” section, download the Flash Programmer 1.12.1 (Rev. N) which is just the Texas Instruments Smart RF Flash Programmer. If you’ve already got this as part of the CC2540 dev kit, then you don’t need to download it again

Next, download the following documentation:

• Profile Toolkit developer guide
• BGScript developer guide
• Bluetooth Smart – 1.1 Beta API Spec
• BLEGUI User Guide

The Profile Toolkit developer guide provides details regarding the structure of a typical BGScript project, including instructions on how to use the binary utilities from the Bluetooth Smart 1.1 (Beta) Software Development Kit to compile the BGScript into a hex file.  Make sure you read this guide before anything else

The BGScript developer guide contains an explanation of the BGScript syntax as well as useful BGScript examples.  Read this guide after checking out the Profile Toolkit guide.

The Bluetooth Smart – 1.1 Beta API Spec contains the API reference for all the available BGScript and BGLib functions.

The BLEGUI User Guide contains information to use the the BLEGUI tool included with the Bluetooth Smart 1.1 (Beta) Software Development Kit.  This is an extremely useful tool which allows you to attach to the BLED112 USB Dongle and use it to quickly test other BLE112 modules.

So now that we’ve got all the required software and documentation, let’s set up the BLE112 module on a breadboard as described in this post, but instead of connecting the LED to P1.2, we’ll connect it to P0.7 to better illustrate the usage of bitmasks in BGScript.

BLE112 with LED hooked up to P0.7

Next, extract the previously downloaded Bluetooth Smart 1.1 (Beta) Software Development Kit and navigate to the “example” directory.  Pretty much all of these examples are meant to be used with the DKBLE112 Development Kit, which I don’t own, since I didn’t feel like spending $350 for the kit and opted for standalone BLE112 modules instead.  Go ahead and duplicate the “find_me” project and name it “toggle_led” (or alternatively, download the toggle led project that I created).  Now open up the bgdemo.bgs file in your text editor and change the contents to the following:

# This example script will flash an LED connected to P0.7 every second

# Boot event listener
event system_boot(major,minor,patch,build,ll_version,protocol_version,hw)

  #Set timer to generate event every 1s
  call hardware_set_soft_timer(32768, 1, 0)

  # configure P0.7 as output
  call hardware_io_port_config_direction(0, $80)

  # Disable P0.7 pin. Parameters: I/O port to write to 0/1/2,
  #                               bitmask of pins to modify,
  #                               bitmask of pin values to set
  call hardware_io_port_write(0, $80, 0)
end

dim result
dim port
dim data

#Timer event listener
event hardware_soft_timer(handle)
  # read the current state of P0.7
  call hardware_io_port_read(0, $80)(result, port, data)

  if data & $80 then
    # pin was set to high, set it to low to disable LED
    call hardware_io_port_write(0, $80, 0)
  else
    # pin was set to low, set it to high to enable LED
    call hardware_io_port_write(0, $80, $80)
  end if
end

I’ll walk through each of the important parts of the source code in turn.  First we have:

event system_boot(major,minor,patch,build,ll_version,protocol_version,hw)
  ...
end

From the Bluegiga Bluetooth Smart Software V.1.1 (beta) API Documentation file, it tell us “This event is produced when the device boots up and is ready to receive commands”.  So this is the primary entry point where we can configure the BLE module, sort of like a “main” function in C code.

In the next line, we set up a repeating timer, to fire every 1 second:

call hardware_set_soft_timer(32768, 1, 0)

The first parameter defines how often the timer is fired, in units of local crystal frequency. In other words, time = 1/32768 seconds. Since we’re passing 32768, we’ll get a timer period of 1 second.  If we wanted a 2 second period, we’d use 2*32768, or 65536.  The parameter for this time period is a 32 bit unsigned integer, so the largest period we can have for a timer interrupt is (2^32-1)/32768 seconds, or 36.41 hours. If you need a timer interval longer than this, you’ll need to write your own custom handler to take care of it.  The last parameter of the function defines whether this is a one time event or a continuously firing timer.  Since we want this timer to fire continuously, we’ll pass a value of 0. If we wanted a single shot timer, we’d pass a 1 here.

Next, we need to configure the direction of the port that the LED is connected to as an output.  A pin can either be defined as an input, which means we’ll be receiving a signal on it, or an output, for sending a value to an external device. We’ll configure P0.7 as an output since we’ll be setting a high value to turn the LED on, or a low value to turn it off.

# configure P0.7 as output
call hardware_io_port_config_direction(0, $80)

The first parameter for the function is the port number, which is 0 in our case, and the second parameter is the bitmask for the pin number to configure.  Notice that we’re using $80. The dollarsign in front of the parameter denotes that it’s to be treated as a hexadecimal value.  This parameter is a bitmask where the corresponding bit is set to 1 if the pin is configured for output direction, or 0 if the pin is for input (the default).  Since I’m passing $80, this is equivalent to 0b10000000 in binary, which means we’ll be configuring pin 7 to be used as an output.  We could also pass 128 instead of $80 if we wanted to use the decimal representation.  If, for example, we wanted to configure two pins, say pin 7 and pin 4 as outputs, we’d pass $90 which is 0b1001000 in binary.

Now that we’ve configured P0.7 as output, we’ll set it to 0, to turn the LED off:

call hardware_io_port_write(0, $80, 0)

The first parameter is the port number, the second parameter is the bitmask of the pins you want to configure, and the last parameter is the value you want to set the pins to.

Next, we need to set up a callback to handle the firing of the timer that we configured earlier. Before we can define the timer callback, we’ll need to create some variables which we’ll be referencing later on.  These need to be defined outside of the event block:

dim result
dim port
dim data
event hardware_soft_timer(handle)
  ...
end

For this example project, I want to toggle an LED every second.  So in our timer callback event, we’ll need to get the current value of the pin and if it’s high, we set it to low, and vice versa. So the first thing we need is the current state of the pin:

call hardware_io_port_read(0, $80)(result, port, data)

This is where we use the variables that we defined earlier, to store the return values of this function call.  The first parameter of the function is the port number we want to read, either 0,1 or 2, and the second parameter is the bitmask of the pins we want to read. We’re only concerned with pin 7, so we pass $80 as before.  The syntax of this function is C-like, but the return values are a little different.  It looks as if you pass them as additional parameters.  The first return value result is the error code from the call, where 0 represents success.  The second return value port indicates the port that was read, and the last parameter data is the pin state, which is an 8 bit value representing which pins are high and which ones are low.

Now that we’ve gotten the current status of the pin, we can use a simple if/else conditional to toggle it:

if data & $80 then
  # pin was set to high, set it to low to disable LED
  call hardware_io_port_write(0, $80, 0)
else
  # pin was set to low, set it to high to enable LED
  call hardware_io_port_write(0, $80, $80)
end if

The syntax is pretty similar to C, other than the fact that there’s no facility for using an “else if(condition)” statement, nor can you use more than a single else clause.  For more information on the syntax, be sure to consult the BGScript Developer Guide.

So now that we’ve got a simple BGScript, we need to compile it to a hex file and then flash it onto the onboard CC2540 on the BLE112.  Open up a command prompt in Windows and navigate to the project directory, in my case, I stuck it in “C:\Bluetooth Smart 1.1 (Beta) Software Development Kit\example\toggle_led“

Once there, execute the following command:

..\..\bin\bgbuild.exe project.xml

And you should get the following output, provided there were no errors:

BGBuild output

Now, if you open the directory that the project.xml file was in, you’ll notice there’s a file named out.hex. This is our bgscript that’s been compiled into a hex file that we can flash to the BLE112.

The next step is to open up the Texas Instruments SmartRF Flash Programmer, set the flash image path to the out.hex file, then click on “Actions: Erase and Program”, then hit the “Perform Actions” button, and you should see the following output:

Flashing the BLE112 with BGScript using SmartRF Programmer

Once this has been done, you should hopefully see the LED connected to P0.7 on your BLE112 module flashing every second, verifying that our code has been successfully downloaded to the BLE112.

So that’s all there is to it.  I’ve gotta say, I’m quite impressed by the amount of work that the guys at Bluegiga have put into creating BGScript, and all the documentation available.  It was pretty easy to get everything working, and will be a great alternative to using IAR.  My next task is to create a more complicated project with IAR involving external devices with SPI, and then see if I can duplicate the functionality using BGScript.

Despite the terrible soldering job, it actually works!

I’ve heard it mentioned a few times that it’s not possible to program the Bluegiga BLE112 with IAR, but there’s absolutely no reason I can see why this would be the case, considering that it’s just a TI CC2540 with all the necessary components connected to turn it into a module. Since we can program the TI CC2540 on the keyfob using IAR, we should also be able to program the CC2540 on the BLE112 using IAR.

I finally managed to get some free time during the weekend to play around with some Bluegiga BLE112 modules that I’ve had sitting around collecting dust for the past few months, so I thought this would be a good chance to try and program them using IAR.

I purchased them in January 2012 from Glynstore in Australia for $24 AUD/each, but I notice that the price has now been reduced to $19.19 AUD.   If you’re in the states, you can find them even cheaper at $17.45 USD from the Semiconductor Store (unfortunately for those of us in Australia, the $53 shipping fee ends up nullifying any potential savings).  For this price, you get a fully assembled, tested, and FCC/KCC/MIC/CE certified BLE device.  For a hobbyist, this is definitely the way to go, since building your own custom BLE module would cost much more than $20, and you wouldn’t have any certification.  Having said that, I’d still like to try creating my own BLE module, but this is only to satisfy my own curiosity.

When the BLE112 modules arrived, I realised that I’d need some kind of breakout board to allow me to interface them with a breadboard.  This is not strictly necessary, since you can just solder your wires directly to the BLE112 module itself, but a breakout board is a much nicer solution.

For those of you unfamiliar with a “breakout board”, it’s a printed circuit board with a row of header pins for interfacing a small component with a breadboard for prototyping.  These are extremely useful when you’ve got a really tiny component, such as 2mm x 2mm accelerometer which has pins placed 0.5mm from each other, and would be very difficult to solder wires onto.

After a bit of googling, I came across a custom bluetooth low energy breakout board for the BLE112 created by Jeff Rowberg, designer of the very cool key glove wearable input device.  I ended up ordering two breakout boards at $12 USD each and they arrived pretty quickly.  Jeff was also very helpful in letting me know when they had been shipped, so I can definitely recommend his services.

Here’s a picture of the backside of the Bluegiga BLE112 module next to the BLE112 breakout board. The BLE112 module is actually pretty small, so the breakout board makes it much easier to work with.

BLE112 module on left with breakout board on right

Tools for the job

So now that I had the BLE112 and the breakout board, I needed to do a little bit of soldering to attach the two together.  The pin pitch (distance between pins) on the BLE112 is 1.25mm (0.04″), which is small, but I found it reasonably straightforward to solder, and I’m a complete beginner at this, with very little experience soldering.  I used a Hakko FX-888 soldering iron with a T18-D16 Shape 1.6D Chisel Tip, which is available from Oritech or Mektronics Australia for about $8.

Hakko T18-D16 Shape 1.6D Chisel Tip for FX-888

I also used some Multicore 60/40 Tin/Lead 0.46mm 250g Type 362 Flux 5 Core solder, Available from Mektronics for $22.  This made it easier to solder since it’s quite thin at only 0.46mm.

Multicore Solder 60/40 Tin/Lead 0.46mm 250g Type 362 Flux 5 Core

Soldering the BLE112 to the breakout board

I used a Panavise Junior to hold the breakout board and carefully placed the BLE112 on it, after applying some liquid flux to the pins.

Preparing BLE112 for Soldering

The technique I used was to put a blob of solder on the soldering iron tip, then move it over to the pin and leave it for about a second, to give the solder enough time to wick around the pin on the breakout board and make a solid connection to the BLE112.  Since I was carrying solder from the soldering iron to the pad on the board, instead of melting it directly onto the pad, most of the flux in the solder evaporated, so the extra flux I added to the pins helped the solder stick. Since the pads on the breakout board are so big, the solder tends to flow on them pretty easily and stays there as a result of surface tension, so I only encountered one set of pins that were bridged. It was easily fixed by placing the soldering iron tip between the pins to wick up the extra solder.

So after about a half an hour, I’d managed to solder both BLE112 modules onto the breakout boards, so all that was left was to solder a set of header pins onto the breakout boards, like so:

BLE112 on breakout board with header pins

Once the header pins were soldered on, I was able to attach both BLE112 modules to my breadboard, which now makes it very easy to connect wires to them.

BLE112 Soldered and placed on Breadboard

Programming the BLE112

Now it’s time to test them out and make sure my soldering was successful!  In order to program the BLE112 modules, we need to hook them up to the correct pins on the CC Debugger (which you should have if you own the CC2540 Mini Development Kit) .  Thankfully, Jeff Rowberg provided a very helpful diagram on his site describing how to connect the pins.  We need only connect the following 6 pins, labeled in yellow, to enable us to program the BLE112.

BLE112 Breakout board to CC Debugger pin connections

The CC Debugger user’s guide also provides some useful diagrams showing the pin orientation of the debugger device.

So with the help of the above diagrams, I proceeded to connect the BLE112 board to the CC Debugger using 1 pin dual female-female jumper wire that I purchased from seeedstudio.  You can see in the following picture I connected on the top row starting from the left, a red wire to CC9 (3.3V), a white wire to CC7 (RESET), yellow wire to CC3 (DC Debug Clock), black wire to CC1 (GND) and on the second (bottom) row, I connected a green wire to CC4 (DD Debug Data) and a red wire to CC2 (Target Voltage Sense)

CC Debugger Setup

Here’s the CC Debugger connected to one of the BLE112 breakout boards. After I connected them, I pressed the “Reset” button on the CC Debugger, and the LED changed from red to green, which was a good sign, since it means that the CC Debugger senses a device on the other end.

CC Debugger Connected to BLE112

I then hooked up an LED to the BLE112 in order to test and make sure that I was able to flash it with a simple program from IAR.  I hooked up a 470 ohm resistor between P1.2 (port 1, pin 2) on the BLE112 and the anode (positive, long pin) on the LED, and the cathode (negative, short pin) was connected to ground.

The next step was to open up SimpleBLEPeripheral in IAR (C:\Texas Instruments\BLE-CC254x-1.2\Projects\ble\SimpleBLEPeripheral\CC2540DB\SimpleBLEPeripheral.eww) and modify line 388 in simpleBLEPeripheral.c to the following (the line with the little blue flag on it):

Since I connected P1.2 on the BLE112 to the LED, if we set P1 to 0×04 (which is 0b0100 in binary), it should set pin 2 of port 1 to high. After hitting the Download and Debug button in IAR, I got dropped into the debugger on the line that sets P1 = 0. The LED was actually turned on at this point, since I’m guessing that the system is not yet stable, which is why the code needs to reset all pins to their default settings. After stepping over that instruction, the LED was turned off as expected, then I stopped at the line that sets P1 = 0×04.  After stepping over this instruction, the LED turned back on, which means the BLE112 was successfully programmed!

BLE112 running SimpleBLEPeripheral

While this was by no means a rigorous test, it showed that I had correctly soldered the connections necessary to program the BLE112, and it was functioning as expected.

What’s next

Now that I’ve got the BLE112 modules connected to the breadboard, the next step is to try to get BGScript code flashed onto them to see if I can get them to communicate to each other, and to see how easy it is to write BGScript.

Update: make sure to check out the follow up post where I describe how to create a simple program for the BLE112 using BGScript.

So for any questions related to Bluetooth Low Energy development, whether it be software or hardware related, please visit BLEForum.com and post your questions there.

Adam

A few months ago, I discovered that MIT was going to be beta testing a free online version of their undergraduate Circuits and Electronics course, 6002x.  I figured it would be worthwhile to sign up, since I’m a complete beginner when it comes to electronics, and I thought it would be useful to help me better understand circuit diagrams and electronics in general.  So I decided, along with 154,763 other online applicants, to enrol in the course.

While not related to bluetooth low energy in any way, I thought it might be worthwhile to write a little bit about my experiences, given that the purpose of this blog is to help other beginners, not just to Bluetooth Low Energy technology, but to electronics in general.

10 hours per week, are you kidding me?

When I first signed up for the course, the MITx website mentioned that the amount of time I can expect to invest is about 10 hours per week.  I’ve got a day job, so I don’t have a lot of free time, but I figured I could manage to find 10 hours a week to devote to the course. Boy was I wrong.  I quickly discovered within the first week that this number was extremely conservative.  I must’ve spent about 60 hours over the first two weeks watching the online lectures and tutorials, reading the first chapter of the book, re-reading the first chapter of the book, working on the example problems and finally doing the homework.

I thought about dropping out pretty shortly after the first homework assignment, since I wasn’t prepared to invest such a large amount of time.  Also, since the course was free, there didn’t exist the same financial motivation that I’ve experienced with other university courses where the fear of losing the tuition fee keeps you from dropping the course.  I think a lot of other people felt the same way, since only 26,349 people earned at least one point on the first homework assignment, which is only 17% of the people who had initially signed up for the course! I reasoned with myself that after having spent so much time on the first homework assignment, it would’ve been wasted effort if I didn’t continue, so I pushed on.

As the second week of the course started, I realized that I’d have to get into a routine if I wanted to have a chance at completing the course. The biggest change I had to make was to cut out nearly all of my leisure time and any extracurricular activities.  It definitely wasn’t easy, since when you work a full time job, it’s nice to get home from work and be able to switch off and just relax.  Once I started the course, I spent every evening after work, from about 7pm until midnight working away, and on the weekend I’d spend all day on both Saturday and Sunday doing the homework assignment, so easily about 40 hours per week.

I also modified my study habits after the first week.  I  found reading all the assigned sections in the textbook to be too time consuming, so I started relying on the content provided in the lectures and only using the textbook when I was confused about a topic.  I also started taking written notes during the video lectures.  The lecture notes are actually provided as part of the course materials, but I found that writing them out myself helped me retain the information and made it easier to recall when I was working on the homework assignments.

This was my first time taking an online course, and I really appreciated the flexibility of watching pre-recorded video lectures.  Having the ability to speed up, slow down, or replay the lectures at my leisure made it much easier for me to absorb the material.  I can recall many a moment from my time at university where I was furiously scribbling down notes during a lecture, without really digesting what the professor was saying.  With the video lecture format, if I didn’t understand a concept the first time it was presented, I’d just replay the video until it made sense.  Some students have since complained that the professor went into too much detail on some ideas, repeating them 3 or 4 times, but I think I’d rather have the repetition to really drill an idea into your head, and the videos can just be fast forwarded if you already understand the material.

One of the major drawbacks of an online course compared to the traditional university setting is that the physical distance between fellow students and professors makes it really difficult to create a study group or to get extra help. Thankfully, the online discussion area helped make up for this shortcoming.  As the course progressed, the homework assignments became increasingly more difficult, so I started using the online discussion area quite frequently for help.  I was amazed by just how quickly fellow students or staff members would respond to questions on the forum with useful answers.  This really helped me understand some of the more confusing material, which I would’ve been completely lost with, had I not had access to the forums.

I somehow managed to make it through all 7 assignments that lead up to the midterm, albeit with a lot of help from the discussion groups.  I spent an entire weekend writing the midterm, since we had 24 hours in which to complete the exam.  It was extremely satisfying to enter your answers, click on the submit button and see a row of little green checkmarks pop up next to your solutions, it actually felt like I had understood the material!  My experience of university exams in the past consisted of rushing through each question as quickly as possible, then  furiously scribbling down an answer before heading to the next question, many times without fully answering the question because time was so limited.  This exam was quite a different experience.  I felt as though the actual learning experience was better than a typical university course, since for once I was able to invest the time necessary to focus on each question and really understand it before moving on.  However, I should point out that while we were given the exact same test as the students attending MIT in person, they were only given 3 hours in which to write the midterm, which of course makes it much more difficult.  At this point, 9,318 other students managed to pass the midterm, which is 6% of the original number of applicants.

Brace yourself, math is coming

The assignments after the midterm became much more math intensive, as we analyzed circuits with capacitors and inductors using first and second order differential equations, as well as complex numbers.  Initially I was a little worried about the math involved, since these days, calculating the tip on a restaurant bill is about the most difficult computation that I encounter. I did have a pretty good background in math from my Software Engineering undergrad, but I opted out of taking a Differential Equations class since I’d only ever heard horror stories from other students at the mere mention of the class.  As it happens, the differential equations we encounter in 6.002x weren’t very difficult, since they all follow a similar pattern and most can be derived by using simple differentiation.  To make my life easier, I also made heavy use of computational software such as Maxima as well as developed a new appreciation for the fantastic resource that is Wolfram Alpha. Another indispensable resource for relearning years of forgotten math was Khan Academy.

As we progressed further, we learned some very powerful and quick methods for determining the necessary equations by intuition alone, without the need for tedious calculations.  This was a recurring theme in the course, building up your intuition so you could do away with complex mathematical techniques. As it turns out, electronics engineers are just as lazy, if not lazier, than software engineers!

So after 3 months of working 9 to 5, then coming home and studying until at least midnight, I started to feel quite burnt out. I was very glad when the final exam was posted, since it would free me from this self imposed moratorium and allow me to get back to my regular life.  I found the final exam to be much more difficult than the midterm – if I had only 3 hours to complete it like the MIT students, I’m sure I would barely have passed. As it was, I ended up pleased with my results, but I used the full 24 hours allotted, and was extremely relieved once it was all finished. Of the 154,763 initial applicants to the course,  7,157, or 4.6% ended up earning a passing grade for 6.002x.

Conclusions

6002x is a prerequisite for many other classes in the undergraduate Electronics Engineering stream, so it’s meant to provide a foundation with a wide breadth, but not much depth, since future courses are for delving deeper into specific material.  Since it’s meant to be taken as part of a larger curriculum, many of the concepts and ideas may be more academic or theoretical than a hobbyist like myself might find immediately useful.

Occasionally while trudging through differential equations or scribbling through pages of algebraic expressions, I’d forget why I signed up for the course in the first place.  So while I don’t regret taking the course one bit, from a hobbyist perspective, or someone who won’t be pursuing a career in electronics engineering, I probably learned a lot of information that I may never end up using.  However, while I might not end up using differential equations on a daily basis, it’s been good to understand the underlying mathematical principles to better appreciate the intuitive analysis of circuits.

Overall, I found the course to be extremely beneficial for my understanding of electronics.  When I enrolled, I didn’t really know anything about capacitors, inductors or MOSFETs, nor how to read simple circuit schematics.  This course has taught me many of the fundamentals that I was missing, and having an authoritative source explain these concepts has given me a much deeper understanding of the way circuits and components operate than I would ever have learned on my own.

So having completed the course, would I do it again if I knew what was involved?  As much as I’d like to say yes, if I’m going to be honest, the answer would have to be no. The reason isn’t due to the content of the course, but more for the amount of time you need to invest.  If the 10 hour per week estimate was even remotely close to the actual amount of work involved, then I wouldn’t hesitate to sign up.  I should note that as of September 2012, the web page for the 6.002x course has now increased this number to 12, but this is still a far cry from the 40 hours or more that I invested.  Now, I’m not saying that everyone is going to have to spend this amount of time with the course material, but expect to spend a lot more than 12 hours per week, especially if you’re a complete beginner and don’t know the difference between current and voltage.

Exciting news for Android developers who wish to interface with the TI CC2540 Bluetooth Low Energy chip.  Texas Instruments has just released a video demonstrating a Motorola RAZR communicating with a CC2540 in a BLE heartrate monitor.

Unfortunately, unlike the iOS app, which was made by TI in Oslo, the Android app wasn’t made by TI, so they’re not able to make the source code available to the public.

However, they’re working on an Android demo for the upcoming CC2541DK-SENSOR kit which will be released sometime in Q2.  They’ve provided preliminary source code for the Motorola RAZR on their wiki, available here.

You can find documentation for the Bluetooth Low Energy API from the Motorola developer website, here.

CC2540DK-MINI Keyfob

I recently picked up the CC2540DK-MINI, since it was one of the cheapest dev kits at $99 (including FedEx 2-day express shipping to Australia!) and I was really impressed by their recent video displaying the CC2540 keyfob interacting with the iPhone 4S.

The kit comes with a keyfob, USB dongle, CC Debugger, USB cable and an interface cable to attach the CC Debugger to the keyfob or USB dongle.

The keyfob has a VTI CMA3000-D01 accelerometer functioning in SPI mode, two buttons, an LED which flashes both red and green, a buzzer, and a retainer for a CR2032 battery.  The USB dongle contains just a CC2540 chip, and this can be used to act as the master peripheral (similar to the role that a Bluetooth Smart Ready mobile phone such as the iPhone 4S would play).

The complete package provided with the CC2540DK-MINI kit. Clockwise from top left: CR2032 battery, Keyfob, USB Dongle, plastic keyfob case, CC Debugger, 2 different debugger flash cables and a USB to USB mini connector

I found the Mini Dev kit pretty easy to set up, although I initially had some issues with VMWare intercepting the driver for the CC Debugger and not releasing it to the host operating system even when I shut down VMWare.  I ended up uninstalling VMWare and everything worked fine afterwards.

I also had some difficulty with the Keyfob not being detected by the CC Debugger (the light would remain red on the debugger device, even though I had connected the Keyfob and inserted a battery into it).  The issue was caused by corrosion on the negative battery terminal in the CR2032 coin cell retainer, a problem that others have experienced as well.  The solution for me was to use tweezers to clean the surface of the terminal that was oxidized.

Corroded negative battery terminal on the keyfob

Having said that,  I soon discovered that I was going through CR2032 batteries too quickly during debugging.  I followed the instructions described on page 27 section 5.1 figure 38 of the Bluetooth® Low Energy CC2540 Mini Development Kit User’s Guide, and shorted out the pads for resistor R1 which are located immediately next to the debug header on the keyfob.  The keyfob will now operate without a battery, and will instead draw power from the CC Debugger.

Behold my awesome solder work. It ain't pretty, but it works

If you still run into problems with the CC Debugger not recognizing your Keyfob, make sure you have the ribbon cable properly oriented (the red wire must be attached to pin 1 on the Keyfob) and try using a new battery if you have one – some users have reported that the battery included with the Mini Dev kit had no energy when it arrived.

Another gotcha I ran into was the Keyfob not sending accelerometer data when I tried interfacing it with the Texas Instruments iPhone app.  I had mistakenly programmed the keyfob with the cc2540_ble1.1_keyfob_SimpleBLEPeripheral.hex found in the Texas Instruments\BLE-CC2540-1.1a\Accessories\Hex_Files directory, which lacks accelerometer functionality.  If you run into the same issue, make sure you’re using the KeyFobDemo project (C:\Texas Instruments\BLE-CC2540-1.1a\Projects\ble\KeyFob\CC2540DB\KeyFobDemo.eww) which requires you to use IAR to flash it onto the Keyfob.

Once all of that was sorted out, I was able to connect the Keyfob to the CC Debugger, load up the KeyFobDemo project in IAR and run the “Download and Debug” command to flash the Keyfob with the software.  I also signed up to become an Apple iOS developer, which costs $99/year, and this allowed me to install the Texas Instruments iPhone app onto my iPhone 4S.  After running the TI iPhone demo app through Xcode, I pressed the button on the right side of the Keyfob, which toggles advertising on and off, then pressed the “Scan and connect to keyfob” button on the iPhone which established a connection to the Keyfob, and in a matter of seconds, I was receiving live accelerometer data!

I’m now in the process of trying to split my time between learning how to write apps for the iPhone, trying to understand as much as I can about the CC2540 and the TI BLE stack and libraries (HAL, OSAL, etc) and learning about printed circuit board (PCB) design, since I’d like to eventually create my own PCB with a CC2540 and the minimal components necessary to communicate with another BLE peripheral.

Speaking of which, here’s a really interesting post on the TI forums about the minimum bill of materials necessary for designing your own PCB with the CC2540.  This will most certainly be a topic for another blog post when I become more familiar with hardware and using PCB design software such as Eagle.

Also, for those of you developing apps for iOS, I’ve recently discovered the excellent iPad and iPhone Application Development course from Stanford University available for free from iTunes U.  You can find the content for the Fall 2011 course here, and the Stanford University course page is available here: CS 193P iPhone Application Development. There’s also an Advanced iPhone Development course provided by Madison Area Technical College which has some great content as well.

TI BLE CC2540 iOS app

Big news from Texas Instruments, they’ve just released a video demonstrating the keyfob included in the CC2540DK-MINI dev kit communicating with the Iphone 4S using the GATT interface through the new Core Bluetooth API.

This is a particularly big deal because it shows the CC2540 interacting with the iPhone 4S using the stock 2540 mini dev kit without an authentication chip.

Up until this point, if you wanted to get your bluetooth device talking to your iPhone, you had to apply for acceptance into the Made for iOS (MFi) licensing program.  Once accepted, you could then use a special authentication chip with your bluetooth peripheral to interface with the iPhone.  For small developers and hobbyists, this was a major hurdle, since it costs upwards of $20,000 to get your device certified for acceptance into the MFi program.

Unfortunately, if you don’t become MFi certified, you can’t sell your program on the App Store.  The alternative has been to jailbreak your iPhone and use BTStack, A Portable User-Space Bluetooth Stack.  The downside to this approach is that it requires all your users to jailbreak their phones to install your software.

So this demo by Texas Instruments is significant because it shows that we can now develop Bluetooth Smart devices for the iPhone without the use of an authentication chip.

According to this message from Brian Tucker, Senior Software Engineering Manager iOS Bluetooth Technologies Apple and Bluetooth SIG Board of directors member:

Bluetooth Low Energy is not part of our MFi accessory program. A third party application can interact with a BTLE accessory via a new framework found in iOS 5 and OX X 10.7.2, called Core Bluetooth

I believe classic Bluetooth devices will still require an authentication chip and MFi certification though.

This is all very exciting from a developers point of view, since I’m sure a lot of innovative ideas were stifled by the requirement of an authentication chip and MFi certification in the past.  Developing Bluetooth devices and software for the iPhone 4S just became a whole lot more accessible.

Source code for the iOS application is available from the TI wiki.

The software does the following:

• Connects to keyfob
• Shows live accelerometer data
• Shows live battery level data
• Shows live button data
• Can sound buzzer when button is pressed

iPhone 4S Smart Ready

I was one of the few that wasn’t disappointed by the new iPhone 4S being released today.  While it may not be the iPhone 5 that everyone was expecting, there’s some important new technology under the hood, namely Bluetooth v4.0 support.  It seems as though most people were so enraged by the lack of an iPhone 5 announcement, that they disregarded this new addition.  However, the inclusion of Bluetooth v4 support in what’s arguably the world’s most popular smart phone, marks a major milestone for Bluetooth Low Energy adoption.  I’m sure we’ll start to see all sorts of innovative low energy wireless devices become available in the coming months.

Apple have now released documentation for the Core Bluetooth Framework, which “provides access to Bluetooth 4.0 low energy devices”, available from here.  No word yet as to whether you’ll need to be a Made for iPhone (MFi) licensee, and hence use an authentication chip in order to communicate with BLE devices, although I’m guessing you will.

In other news, the new Google Nexus Prime smartphone manufactured by Samsung will make it’s debut on October 11th. It’ll be interesting to see if they include Bluetooth v4 support, or if they use a Near Field Communication chip instead.  Hopefully they’ll include support for both technologies.

Update: (Thursday, October 20, 2011) Samsung has released the Nexus Prime, now called “Samsung Galaxy Nexus“, although unfortunately they haven’t incorporated Bluetooth 4.0 like Apple has with their 4S.