SparkLE - A Bluetooth LE powered Spark Core clone

Very interested in this project. Hope it will be successful. Cant wait to order

2 Likes

Wanted to post an update/cry for help :wink:

The main issue with using the nrf51822 (as I have already documented) is lack of RAM. There is only 8K, and this just isn’t enough to do RSA encrypt/decrypt on the key sizes Spark Cloud uses with the TropicSSL library. To solve this, there are a few hardware ways I can think of:

  1. Add a second, big MCU that controls the nrf51822 similar to how the STM32 controls the TI CC3000 in Spark Core
  2. Add a second, smaller MCU that only does the RSA encrypt/decrypt (the “handshake MCU”)
  3. Push the RSA encrypt/decrypt to the gateway
  4. Add more SRAM (though the nrf51822 does not natively support this, so it would be extremely difficult)
  5. Any other ideas?

There are various pros and cons to all of these, but if I was forced to choose I would go with number 2 since it has the lowest implications on cost, size and battery life while maintaining simplicity, ease-of-use and security. I still don’t like it though…

So, I broke out my textbooks from college and really tried to dig into the TropicSSL library and see if it is possible to do RSA cryptography with less RAM (spoiler alert: public key cryptography and efficient ways of doing it is not my area of expertise, I have read more about this in the last few days than I have in the past 8 years).

My short answer is, it appears very difficult, but may be possible. There are many papers on how to fit RSA into tiny MCU’s (here and here for example), but I haven’t been able to get much working so far.

I ran some tests on the current FW during the handshake and I see about 5076 bytes of RAM being allocated on the public server key encrypt and up to 6824 bytes on the private key decrypt. That is a lot. So I was trying to find ways to change how the math works so it is optimized for RAM and not speed (not gonna care too much if it takes a few seconds). I think I would have to realistically get this under 2K for it to be feasible in SparkLE, and I know that is asking a lot (and may not be possible).

Anyway, anyone know a library or better way? Any volunteers to help try? :smile: Any savings we could find here would help this project, but would also help Spark Core since it uses the same method. More RAM for everyone!

I am going to back-burner this for a bit and move on with SparkLE with the handshake MCU so I can continue moving it forward. Any solution can just drop in in the future, so if anyone wants to help in pursuing this, let me know.

Alternatively, is there any intention or desire from the Spark team to move to ECC encryption? Again, I am no expert on this, but it seems to be more conducive to resource constrained devices.

1 Like

Having been around this block a few times, the difference between #1 and #2 on your list is basicly your sanity and the ability to actually make something work in an interesting timeline. Adding a '103 as #1 is not really a “big” processor. They are pretty cheap, and can be got in small packages. They code is known to work, you don’t have any bootloader issues etc etc etc.

Most of the hardware that is under consideration for Core-II has on-chip hardware crypto engines, so it is unlikely that the main thrust of the project will adjust to accommodate a different crypto method targeting lightweight hardware.

My recommendation remains to just use a '103 to establish functionality and get it done, then iterate if required/possible/desired.

3 Likes

And regarding your ECC question, that would be great, but when we were designing the communication protocol last year, there were no open source and patent free ECC libraries available. Switching now would be difficult, and as Andy points out is unnecessary given the hardware available now and in the future.

3 Likes

Hey all,

Just wondered if you had seen this, https://www.kickstarter.com/projects/1842650056/sam-the-ultimate-internet-connected-electronics-ki?ref=category

Its a bit like McModule in that it is BLE but they also offer custom hardware (sensors and outputs) and a visual coding platform. I get the impression that this range of products is not aimed at the maker or manufacturer community like spark but it is aimed at anyone. Of course some compromises have to be made.

Looks interesting though.

2 Likes

Wanted to post a quick update. Mainly I am just excited I finally got this working after running into a few stupid user issues, including reversing the ST-Link SWD interface after I read the datasheet backwards, not realizing my BLE breakout board was using the pin numbers of the chip and not the module, and forgetting to turn off HW flow control.

This is the first standalone prototype, with everything needed to run the Spark protocol over BLE on-board. That is an STM32F072 MCU which takes the data from the BLE module and handles the handshake encrypt/decrypt. Everything else is run on the nrf51822 chip, which I am currently using a Laird BL600. Power is running from the AAA battery pack.

Next step is to add the external flash and add a power circuit so I can shut off the STM32 at all times, except when I am doing the actual handshake. Those parts should be straight forward, then it is time to draw up the schematics, lay out some boards, and make some standalone SparkLE’s so I can work on the FW and integrate into my other project.

4 Likes

So, after all the hard work getting SparkLE working with a “handshake MCU”, there has been an interesting development. I found out a few weeks ago (and Nordic Semiconductor just announced this week) that there will be a new version of the nrf51 chipset with 32K RAM. That means no more need for a second MCU on-board!

Ultimately, this is great as the design is a lot simpler, the board will be cheaper, and it is less components to place. I have the new DK from Nordic and am working with my module suppliers on delivery dates, as the new version won’t go to production until Q1 sometime. So, this is a good thing, but just may delay how fast I wanted to produce a board like this.

In the meantime, we will be launching a product on Kickstarter next week that will use SparkLE and the Spark Cloud, so you can check that out if you’re interested: http://goglove.io/

2 Likes

Hey,

I just wanted to express my support for SparkLE. I habe several ideas which require cheap network hardware without lots of bandwidth so SparkLe would be incredibly useful for me! So keep up you’re amazing work!

1 Like

your product is awesome.
is the video on your goglove site what you are using for the kickstarter? i bet the guys at spark can introduce you to their video guy, and you can make it awesome!

1 Like

Thanks. And no worries, we have already shot a much better video and will be uploading it to the site when we launch on Kickstarter. Check back next week when we go live!

I am also working on some projects that are utilising Spark Cores and BLE, therefore, a Spark LE preferably with WiFi would be extremely welcomed. Also, I t would be great if the BLE function calls available be as high level as possible and that it supports both Central and Peripheral mode.

For SparkLE, I am envisioning three parts (at least initially).

  1. The board itself, which just has BLE and acts as a peripheral
  2. An iOS and Android app, which allows the BLE board to talk to the Cloud as the gateway
  3. A BLE shield which plugs into the Core, the BLE works as a central and the entire package works as a gateway

Beyond that, you could of course program any part to do whatever you want as it would all be open source. I plan to expose as many underlying API’s as possible, the biggest problem I have today with BLE development boards is they are too restricted.

Would this cover most of your needs from s high level?

I would not disagree with the idea of exposing more underlying APIs for the sake of flexibility, but I would still like to emphasis the importance of having higher level functionalities for fast development and deployment. I am actually thinking about the role Spark could play being the Central and as a Client…

Just wanted to post the link to the Kickstarter page as we went live tonight with GoGlove.

This product will use the BLE powered Spark hardware, and we would follow it up with the development boards themselves sometime down the road.

2 Likes

I just wanted to extend a big Thank You to the Spark community. We crossed our funding goal this morning on Kickstarter, and we can’t wait to start making GoGlove and the SparkLE hardware that will drive it. We saw a fair amount of people come in that were backers of the Spark campaign, and even some people who work for/with Spark, so we can’t thank the community enough.

We still have 6 days left, so please stop by if you want to back the project. Thanks again!

1 Like

congrats! very excited to see the first SparkLE product

1 Like

@eely22 just read through this thread and if you can get the SparkLE at a low enough price and have a shield to turn the Spark into a router then sign me up!

Ideally it would be nice to choose between a dedicated wired/wireless router and the shield to convert a Spark Core/Photon into the router

Ans update in availability as a standalone product?

If you don’t want to wait, you might check RFduino, which is out already. It has limited pin number compared to Spark though.

http://www.rfduino.com/

@lami Ideally I would like to stay within the same development environment, hence the SparkLE if done right would be perfect :smile:

1 Like