A whole family of BLE devices. The BLEbee, the BLE-Shield v2.0.0 and the early version of the BLE-Duino 32u4

Hello everyone,

this time I have a pile of news for you. Since the development of the BLE-Shield and the initial prototype of the BLEbee, I did some more research and prototyping on three new BLE enabled boards:

  • BLE-Shield v2.0.0 (need another iteration before a private beta test)
  • BLEbee v1.0.0 (almost ready for a private beta test)
  • BLE-Duino 32u4 which is an early prototype with version number 0.6

In the following paragraphs I will share some EagleUp renderings and photos of the real boards with you and talk a little bit about the features and improvements of these boards. I will setup feature request polls for the BLE-Shield v2.0.0 and the BLEbee v1.0.0 as well, as I already did for the BLE-Duino before I wrote about the prototype progress. I will add all three prototypes to the “Bluetooth Hardware Prototypes” section of my blog where you are invited to comment on the boards and post feature requests. But now lets start with the board descriptions:

BLE-Shield v2.0.0

The idea of the additional features for the BLE-Shield were demanded by some power users I’m in contact with. I hope that the board is getting more flexible for developers in v2.0.0

BLE-Shield-Proto

photo 1    photo 2

The main hardware changes of the BLE-Shield are

  • smaller SMD packages for the level shifter, the resistors and capacitors
  • SMD Solder points at the Arduino Shield headers and the BLE112 module
  • The reset button on the Shield is now resetting the Arduino where it is attached to and the Arduino Reset button resets the shield as well
  • The switch S1 to select the RX/TX pins to  use the hardware serial on Pins 0/1 or 2/3 for a SoftwareSerial implementation to a jumper headers making the pin usage more flexible
  • The hardware interrupts of the Arduino are now used as connect/disconnect indicator. Using attachInterrupt() you can now use a method in your sketch to get a notification while the shield is connected or disconnected. The solder jumper is using interrupt 1 on pin 2 for the interrupt. You can cut the solder jumper with a scalpel and solder it to use int1 instead as well.

The changes in the firmware are

  • Firmware is based on Bluegiga’s SDK 1.1.1-b71 now
  • Using watermarks for serial communication
  • The receive buffer is no longer used, so the characteristics to deal with the buffer are removed.
  • Reduced the communication speed from 19200 to 14400 baud in order to reduce the transmission errors from 0.14 to 0.03%

In order to deal with the changed transmission behavior, where the RX characteristic is no longer using a buffer which needs to be filled up, I changed BLExplr v1.1.0 to deal with this read serial data communication.

BLEbee v1.0.0 

The Idea of the BLEbee is to act as an add on module for instance the Arduino FIO. The functionality of the BLEbee is similar to the BLE-Shield, since it supports serial transmission. It is not that configurable as an XBee module, where you can configure pins to act as digital and analog pins, put it supports four digitals out pins as well, which can be used to control the Relaiy Shield provided by Seeedstudio.

Screen Shot 2013-11-12 at 19.10.44 photo

Hardware changes compared to v0.7.1

  • reduced the via size on the PCB
  • using smaller SMD packages for the resistors and capacitors
  • added a reset button

The changes in the firmware are

  • Firmware is based on Bluegiga’s SDK 1.1.1-b71 now
  • Using watermarks for serial communication
  • Not using a buffer as the BLE-Shield v2.0.0 and the communication speed was reduced as well in order to minimize the the error percentage as well.

BLE-Duino 32u4 v0.6

Finally the BLE-Duino is a first prototype where I combined both worlds. The BLE-Shield and an Arduino based on the ATmega32u4. The BLE-Duino is currently based on a 3.3V setup compared to the LilypadUSB using the same boot loader so there is no need to add additional hardware definition files to the Arduino IDE installation.

BLE-Duino photo 3

The hardware is using only SMD parts. Even the typical Arduino headers are SMD. The BLE112 module is directly connected to the RX/TX pins, which are Serial1 on the ATmega 32u4 and the USB Port Serial is available as Serial Hardware port without interfering.

Planned hardware features are:

  • add a Lipo header including a charging circuit
  • a fuel gauge to the Lipo and make the capacity available though a corresponding BLE characteristic. In this case the fuel gauge needs to be connected directly to the I2C pins of the BLE112 which must be implemented in BGScript. I don’t know if it would be better to use the BLE113 module since it supports I2C natively.
  • add a audio transceiver to make the board beep from an Arduino Sketch

From a firmware point of view the BLE-Duino will support the same services as the BLE-Shield v2.0.0 with an additional battery service if I will decide to go with the fuel gauge or not. Another question to solve is if the board should be a 3.3V board, which would make it easier to integrate the BLE112/BLE113 without level shifter, or to make a 5V board?

I hope to get you feedback on the features you would like to see in a BLE-Duino board on the forum available at http://forum.mkroll.mobi or the feature request polls which are already available on my blog page.

Comments on all three boards are welcome!

Thanks for reading,

Michael.

 

 

2 Responses to A whole family of BLE devices. The BLEbee, the BLE-Shield v2.0.0 and the early version of the BLE-Duino 32u4

  1. Peter July 5, 2013 at 14:55 #

    Looks great Michael!

    Lots of great ideas here.

    Peter.

  2. Jim July 31, 2013 at 07:28 #

    Love the BLE Shield 2.0.0!

    Comments in order fo importance:

    1 – Firmware for being a central/master PLEASE PLEASE!

    2 – Can we use I2C to talk to it? SoftwareSerial is less than ideal, even when it is talking to a device with a UART. SPI is nice but it requires a SS pin. I2C is great for this application because its plenty fast enough for BLE. I realize the BLE-112 supports I2C as software but that’s fine.

    3 – If we can’t have I2C can we have SPI with a selectable SS pin?

    4 – It looks like using the jumper block that the TX and RX pins can be mapped to any pins in that top row. Thats really good if true, at least for me, as my boards have many pins used and I usually don’t have the UART available, and many of my IO pins are used.

    5 – Is this the one that has a USB connector for firmware programming?

    6 – If you need to trash UART completely that’s fine, but I realize most would want UART over I2C or SPI.

    Thanks for your great work!

Leave a Reply


*