We're starting to work on Bluetooth Low Energy Support in mbed, so this thread is for those interested in helping develop or trialling use of the technology as we start releasing some of our proof-of-concept code and hardware.

Please share any projects you want to work on as an alpha tester, or if you want to help with development and testing!

One of the projects I'm working on has Bluetooth 4.0 as one of it's long term goals, so I'm very interested in official support from mbed. What is the library going to look like? Is it going to be a complete stack, or just link up with something like the BlueRadios nBlue modules?

I think this will enable many applications for IoT. Looking forward to seeing more. Especially a low cost platform with the mbed CMSIS-DAP interface connected to the nRF51822.

Hi, I am Bob and I worked as an intern in ARM this summer with the IoT team working on some Bluetooth Low Energy project. I am interested in providing some test case for mbed's BLE API, I have a LPC1768 and KL25Z but I do not have any Bluetooth Low Energy module. Can you give me some guide so I can start with this? My email is bf1891@bris.ac.uk and I am looking forward to contribute to mbed SDK.

Thanks a lot!

Hi, we are also looking at building a DipCortex with BLE in the same form factor as the WiFi DipCortex, your module selection would be interesting to us.

It would be nice if the module also came pre-approved with FCC/CE/ETSI to reduce costs around creating a product with it.

Carl SolderSplash Labs

Hi,

@Neil, the library is going to provide a high level API to allow simple creation of the BTSmart services and characteristics for a device, and update them etc as appropriate. Here is an example of the sort of thing being worked on:

BLEService        battService ( 0x180F );
BLECharacteristic battLevel   ( 0x2A19, 1, 1, 0x10 | 0x02);

/* Add the battLevel characteristic to our service */
battService.addCharacteristic(battLevel);

/* Add the service to our radio/HW */
radio.addService(battService);

/* Start the radio */
radio.start();

/* Update the value of our characteristic(s) */
uint8_t batt = 72;
radio.updateValue(battService.index, battLevel.index,
	(uint8_t*)&batt, sizeof(batt));

Then under that API we will implement for different radio configurations. For the nRF51822, we're starting with it as a peripheral device with the nRF51822 running a serialised GATT/GAP protocol (based on the Nordic softdevice) to any host mbed-enabled MC via spi. The next step is then making it a native target

@Luke, yes, there will be nRF51822 platforms including CMSIS-DAP.

@Boyu, Yes, you can be part of our alpha testing, thanks!

@Carl, Sounds great - we're evaluating modules that could be used pre-certified, to simplify that case.

Hope that helps!

Simon

Hi,

This all sounds really good - and a reliable low power Bluetooth solution might be just what we need for some short range inter-module communications (primarily for part of our test/acceptance process but possibly later also becoming a product in its own right).

I'll have to check how much more information I can divulge but I'm certainly interested in how the developments are progressing & would be interested in testing & maybe even some development (if I can find a way to make some time available).

Another great advance for the many mbed platforms!

Cheers,

Jez

BLEService        battService ( 0x180F );
BLECharacteristic battLevel   ( 0x2A19, 1, 1, 0x10 | 0x02);

/* Add the battLevel characteristic to our service */
battService.addCharacteristic(battLevel);

/* Add the service to our radio/HW */
radio.addService(battService);

/* Start the radio */
radio.start();

/* Update the value of our characteristic(s) */
uint8_t batt = 72;
radio.updateValue(battService.index, battLevel.index,
	(uint8_t*)&batt, sizeof(batt));

That sounds awesome! The nRF51822 was one of the radios I considered for this project, but I ended up dismissing it since Panasonic's PAN1721 modules came pre-flashed with BlueRadios firmware. Since then, however, unexpected delays have come up and bluetooth is no longer a priority. So needless to say I will be following this with great interest!

EDIT: Just thought of a few more questions. Is the SPI bus used by the radio going to be "owned" by the stack, or can I connect other peripherals to it as well (in this case an OLED display)? Will it be a standard 4-pin SPI connection (MOSI, MISO, SCK, SSEL), or will there be additional pins like DC or an IRQ pin, etc? I'm trying to make room in my design for the eventual radio.

Simon said " The next step is then making it a native target " So , If I understand this well , will we be able to put (small ) mbed projects inside nRF51822 or similar SoC ??? that would be marvelous !!!

Regards, Christos

This is what I took it to mean. The nRF51822 has a Cortex-M0 processor, up to 256KB flash, and 16KB RAM. According to the product page, the S110 stack only requires 80KB of flash. Seeing as how the LPC11U24 only has 32KB of flash, 176KB should be awesome!

Awesome!! I can't wait! A native module would definitely be more desirable than a separate radio/mbed chip

I too am very excited to read about this. We have been doing a lot of Bluetooth Smart work, but mostly with the TI CC254x parts. It works very well, but the IAR license can be expensive. Would much prefer being able to develop with the mbed online compiler.

We do have a Nordic nRF51822 devkit and many mbeds, so if I can do any testing for you with this setup, let me know.

Thanks, Tyler

Simon,

Do you have any kind of project time line for native target?

We are making a healthcare device based on the LPC1768 and this is perfect timing for the development of our next prototype which should include Bluetooth! I will try to get hold of a Nordic devkit and would like to be a part of this if testing is needed

Simon and all the other,

we have already begin with some prototyping with the nRF51822 but we found it extremely complex and bad supported. So I'm so interested if you bring out a platform with an API developed for it. To me, using the BLEstack has been one of the most frustrating activities made in the past times.

So finally we decided to go for the nRF8001 enclosed together with an ARM M4, less efficient in power, size and what so ever, but working fine in not much time.

Dont hesitate to mail me for further discussion about this subject or exchange of knowledge.

Best regards and good luck.

I've developed an Arduino-compatible shield with nRF51822 connected to host via UART. I think UART is a better option than SPI because it uses less pins. Is it too hard to make a universal SPI/UART implementation?

I'm currently working with the nRF51822 to develop several devices, although this is not a priority for our company, so it is more of a 20% time deal. Being able to use the mbed SDK along with the SoftDevice would be a huge speedup for my work. I'd also be interested in testing anything in the interim.

I second this. My current design has the UART pins (including CTS and RTS) broken out for use with a BlueRadios radio, and the SPI pins buried. Hence, UART support would allow me to drop the nRF51822 in later with no modifications.

My name is Ken Andersen. I am an IOS Developer working on Bluetooth LE iBeacon Technology and would be interested in using the mBed platform to program iBeacon transmitter information and as a base unit to tune and adjust the power setting on an beacon network. Most of the iBeacon units I have been working with are based on the TI 254x Chip and Stack

Ken Andersen getkha@me.com

I can't wait to hear more about this Bluetooth LE support as it becomes available.

Hi,

Yes, we are actually using UART as the interface for now, so that is what we'll make available (we may skip SPI and then go straight to developing the native version)

Our basic goal is to get enough working to be useful and usable and some test hardware as soon as possible, then open it up as a private alpha to a small number of people who show interest, have projects (and skill!) as we develop it, then when it is more functional/tested, we'll aim to put it out for public beta.

We're off to work with Nordic next week, so we'll have some of the planned timelines out of the back of that! We've been testing some pre-certified modules and Chris already has one board 90% laid out, so will try and share more end of next week after our trip!!

Thanks for all the support too!

Simon

Perfect! With UART support this should fit nicely into my current design. Just for clarification, are you going to be using CTS and RTS for flow control?

SPI would be nice as the LPC11U24 has 2 SPI channels and only 1 UART, leaving the UART free for debugging or external control would be desirable. Also presumably the 11U24 can achieve lower power consumption vs the 1768 which I would have thought would be the focus of a wireless device.

I agree regarding SPI.

Great! stuff going around!

What's the update on the extent of the API is developed?

nRF51822 has two SPI channels too, but both are SPI masters. I guess it might be awkward to make a peripheral device with master SPI.

I have mbed 1768, and I've made myself nrf51822 demo boards. Maybe I can do some contributes testing.Can you share the alpha code with me? I'm using it to control some PWM signals.

I have worked with the nRF8001 interfacing it with an ATMEL processor and currently designing a board around the nRF51822. If someone can share their hardware design I will be more than happy to create my board and also be an alpha tester.

What is the timeline for the alpha testing to begin?

Neel

If you're interested in following the API development more closely, we've setup a dedicated Team page around Bluetooth Low Energy, which includes a quick setup guide and the latest development release and examples.

There are currently examples to emulate an iBeacon device as well as a basic Battery Level service showing you to create GATT Services and update their content.

Let us know what else you'd like to see, and if you have any specific feedback on the current state of the API!

With Nordic Semi having announced the mbed platform for nrf51822 and the progress that is happening here, I am excited! I am so happy that there is Apache licensed code available for use with this chip which one can share. Was feeling constrained with the SDK license of Nordic Semi.

Right now I see a couple of files in the repository still with Nordic Semi's license. I guess it needs clean up.

From what I understand the plan is to use the SoftDevice stack binary provided by Nordic Semi. Would it not cause a conflict with the license scheme of mbed? It is quite restrictive that only people who buy the nrf51822-mbed gets access to this binary, but not ones who buy a board with this chip from other sources.