SparkLE - A Bluetooth LE powered Spark Core clone

Social Project Share
1

I very recently picked up the two Core’s I got from my Kickstarter backing and have been spending a lot of time tinkering in the last 48 hours. These things really are great and I am glad to see how well everything works.

I have a general issue, though, with Wifi in embedded applications, mainly:

  • Too power hungry
  • Overkill (do you really need high data rates?)
  • Large footprint
  • Expensive

I really like Bluetooth LE, I am working on a few embedded projects with the spectacular Nordic nrf51822 chipset. It solves a lot of the above issues, but of course is Bluetooth so no TCP/IP stack.

I have been thinking about how I would make a BLE Core, so no Wifi on board. My requirements would basically be that the BLE device shows up in the cloud exactly the same as a Core. You could control it from the Tinker app, call it from the REST API, and program it from the Web IDE, just like any other Core. So it would have the benefits of BLE, but the flexibility of Core.

To make this work, you would need a BLE<->TCP/IP gateway, this could be either an app on a phone/PC, or a cored linked with a BLE device (or a lot of other things). You would then need to port some of the Spark FW functionality to the BLE device, and some would reside in the gateway, which would handle the conversion from REST to GATT. Not quite sure yet what that split would be. Also, of course, the BLE device would need to be connected to the gateway for it to be accessed via REST, otherwise it is offline.

The gateway being flexible would allow you to have a dedicated one (a Core gateway always on) or you could only connect/disconnect when the phone is in range, it would be flexible for both. This way, you could have many inexpensive, low power BLE devices per one gateway.

Has anyone tried anything like this? Or completed it? Or is Spark developing something like this? I saw the “New Hardware” notice in the letter from the CEO, has it been announced what that may be? I would absolutely love to undertake a project like this, but don’t want to reinvent the wheel or work on it for months and then have Spark release the same thing.

Any thoughts? Anything I am missing?

4 Likes
2

@eely22, like Zack the CEO said, why limit the Spark to wifi! I suspect you will see Sparks with BLE, GSM and who knows what else in the future. When? That I don’t know. :stuck_out_tongue:

3 Likes
3

Yeah, that is kind of what I figured.

Since I just finally got the time to take a look at all of this, I don’t know how secretive these guys are about their future plans. Anyone have more insight on when and what is next? Probably not, but figured I would just ask!

4

I have some of these on order. Just about what you want. They have BLE modules and a BLE router to connect the devices to TCP/IP

5

We’re not too secretive, we just tend not to announce things before we’ve figured out what it is we’re doing :slight_smile: We are definitely looking at BLE, and the structure you described (hook to the cloud either through a phone as gateway or a Spark Core Wi-Fi as gateway) is definitely something we’ve discussed. What do you think? Worth doing?

4 Likes
6

@MagicTech
Thanks, that is about the type of HW setup I was thinking, but their system looks pretty closed off. They will be open source, but the programming of the BLE boards is done through their rules engine. Also, it looks like you have to use their gateway, I was thinking that any phone could be a gateway.

I think the real power of Spark is their cloud offering. The Spark Core is just the first gateway to that, so it would be great to see this type of hardware working in the Cloud with all the benefits that it brings.

At this point, I think maybe I will just try this and see if I can get something basic working. I will post progress, if I can make any :slight_smile:

7

@Zach, I think it would be great to have a BLE option or easy integration for Spark Core. I have spent several hours researching TI’s SensorTag and have just ordered their developer kit.
http://processors.wiki.ti.com/index.php/Bluetooth_SensorTag

TI seems to be deploying significant resources behind BLE. As @eely22 mentioned in the opening of this thread, it does offer many attractive features for the types of Home Automation projects myself and many others are working on. I for one think easy integration of Spark and BLE would be a killer app, and great strategic addition to the Spark Core portfolio.

2 Likes
8

My current project is actually exactly what Zach describes. I have a few BLE devices that all report to a Spark which will hopefully be the link to the web. So far so good. I will have to get someone involved at the web level though.

9

@zach
That is the best time to announce things, get feedback before you build!

Yes, I definitely think this is worth doing. The more types of hardware connected to the Spark Cloud, the better it becomes.

Sounds like you guys haven’t actually started work on an idea like this yet, so I’d like to give it a shot. I am still looking at this from the 10,000 feet level, so I may be missing something, but are there any hidden issues I am not seeing that would block me from doing this?

10

I think your architecture is spot on!

11

Just thought I would provide an update on this, as I am working on it.

I took the Core FW and kept the core-communication-lib project, but then heavily changed the spark_utilities.cpp library to utilize BLE GATT instead of the TCP socket. So the handshake code and encryption are all happening on the nrf51822, but then it just sends the byte array up instead of going to the socket.

For the gateway, I am currently using an Android app that I wrote to connect to the BLE device and then open the connection to the Spark Cloud. It is just a dummy pass-through, it sends data between GATT<->Cloud.

I think the split makes sense, this keeps almost all the logic on the MCU, and the gateway is very simple. One issue right now, I am running out of RAM on the nrf51822. It only comes with 16K, but the BLE stack takes up 8K of that, so I only have 8K to work with. With all the Spark libraries on there (especially the tropicssl stuff) and the BLE libraries, I am about hitting the ceiling. Ultimately, I think a solution would have to use something more like the STM32 and the nrf8001.

As of now, it is doing something, but not quite working yet. I see the 40 bytes handed down from the Cloud when I connect, which then gets passed to the nrf51822. But then things get a little screwy and the requisite messages aren’t going back up, I see various packets of 18 and 50 bytes. I think the device ID isn’t getting handled right, so I am still debugging. I have also hardcoded some things along the way to make it easier.

I am hoping to get this handshake issue figured out and see if I can get commands from the cloud down to the BLE device. I will post any updates.

Thought of a name for the project too: Spark Low Energy, which equals SparkLE, or Sparkle

3 Likes
12

Ok, I tracked down my problem at least. The encryption step in the handshake is failing, it is returning TROPICSSL_ERR_RSA_PUBLIC_FAILED. Once that fails, the handshake fails. But then the SparkLE still tries to send time requests, which is where the 18 and 50 byte messages come from.

So the transport from BLE->Spark Cloud is working, just the encryption is failing on the nrf51822. Trying to deep dive into the TropicSSL library to find out why…

UPDATE: I figured out the issue, and it is what I was fearing. The TropicSSL library uses malloc when you encrypt data. Apparently, it calls it a lot. I have been ripping things out of the code to make my heap as large as possible, every time I increase it I can see I get a little farther in the encryption. However, I have it up to 1288 bytes and still no luck.

Anyone have any idea how much RAM the TropicSSL library will take? How high do I need to get this?

2 Likes
13

I would buy BLE Spark. However I think Wifi+Bluetooth on the same device would be awesome… Sometimes you power BLE, sometimes WiFi…

If I wanted pure BLE, there are tons of other arm/arduino compatible BLE devices out there that are very cool. However the WiFi integration seems very amazing! I would buy some!

14

Since TI has some new chips (wifi/micro controller embedded), there’s probably some room left for some neat extras. I’m sure Spark is already thinking about some awesome future devices. Looking forward to what that may bring :wink:

15

That'd be a great question for @mohit or @satishgn :slight_smile:

16

@Dave
Thanks. I put a breakpoint on the malloc call, I saw it allocate 2076 bytes before I simply ran out of room and NULL started coming back. Since I am only working with 8K RAM, I just don’t have the room on this MCU apparently.

In the short term I am going to use a second ARM Cortex-M0 to handle the encryption. So I will hand over the data through UART, the second MCU will have the keys stored and will encrypt/decrypt, and then hand that back to the spark protocol library. It will certainly be slower, but it should work for now.

This actually has a few benefits, it frees up (apparently a lot of) RAM on the main MCU for the FW or user sketches. Since all it does is encrypt/decrypt, it could just be turned off when not in use. Would have to look into it, but this may also be cheaper and smaller than an STM32 and an nrf8001. In the short term it will work, possibly an option for the long-term hardware (if it ever gets there).

4 Likes
17

SparkLE is actually working (sort of)!

I managed to get to the point of seeing a glimmering little light of success today in the form of the LED in the Spark IDE. I finally appear to be able to finish the handshake protocol when going directly BLE<->Spark Cloud with an Android app as the gateway between. So I finally have the BLE hardware talking to the Spark Cloud, all running natively on an nrf51822!

Well, almost natively. The nrf51822 still does not have enough RAM to do the RSA encrypt/decrypt, so I am passing off the data through UART and then doing that on my mac. The data then goes back to the MCU and it handles everything else, so the only part not directly done on the Nordic chip is the rsa_pkcs1_encrypt/rsa_pkcs1_decrypt calls.

I am getting a beefier ARM Cortex M0 tomorrow, my plan is to move the FW onto that and then use the nrf51822 as just the radio, so hook the two up with UART and pass the data from Nordic to the bigger MCU, which will do all the Sparky stuff.

I am getting errors now when trying to call event_loop, so I need to start digging deeper. There are definitely still a lot of problems, and a lot I need to figure out. Still, I finally feel like I can pull my head out from the handshake protocol and start looking around a little bit, figure out how all this ticks, and start porting it over to make an actual Spark LE.

4 Likes
18

Wow this is kinda exciting! Will be happy to play around with this in future :slight_smile:

1 Like
19

Ok, I got the event_loop working now as well, so it looks like everything is working! I can have the device show up as online in the CLI, I can even send it new FW to flash from the IDE (which of course is just getting thrown away for now). So all the messaging, protocols, and everything else is working. I must admit, I got pretty excited the first time it actually handled all the messages and showed up like a real core, good thing no one can see my victory dance in my basement!

To show the current status, I made a quick video:

Next steps are to use the bigger ARM MCU so I can keep everything contained on one board. Not quite sure how I want to do this yet, if I will have one big MCU do everything and the nrf51822 just gets the data? Or if it makes sense to keep a lot on the nrf51822 and just offload the encryption? Clearly the nrf51822 is just not adequate, but I really want to keep the encryption on the board (not in the gateway, or you have to make sure all the keys are correct on all the gateways you want to use, which is highly undesirable).

Since I am using BLE, battery life seems like the top priority, so I am skewing decisions towards that. Anyway, once I get this figured out, I can put together a prototype board and hopefully continue porting the code and hook in all the descriptors, and then everything else.

The fun continues!

3 Likes
20

How much do we care about and/or trust security on the BLE last RF hop ?

If the there is a consensus that “not very much” is an answer to that, then we could handle all the spark cloud handshake/crypto/auth in the gateway (could be a phone, could be a custom device.) Freeing the BLE dongle to be as cheap, low power and lightweight as possible.

Discuss.

Extra points for thinking about namespace issues so a BLE dongle could migrate between gateways (obviosuly that it was pre-configured to talk to, not promiscuously.)