SparkLE - A Bluetooth LE powered Spark Core clone

Social Project Share
21

@AndyW

There are certainly pros and cons to both. I have been thinking about this a lot, and so I definitely appreciate the discussion points.

The biggest issue I see with storing the keys on the gateway is that is not how the Core does it. If this were to become a product, then keeping the FW in-line with the Core’s would be important. The further they diverge, the harder any merges would be.

The handshake is really the biggest issue I ran in to. I suppose you could move that off the SparkLE and into the gateway, but then the keys would need to be the same on both. So you would have to update the keys on both at the same time, and then they are locked together. Plus, if there was ever a change to the handshake, you would have to merge it with all the gateway code. I imagine a gateway being a smartphone (iOS, Android, or WP8), a Core+BLE Shield, a PC (Windows, Linux, Mac), your car, or anything else that has BLE and an internet connection. So keeping the gateway simple will save a lot of trouble, I think, as there could be many different versions.

I think my ultimate requirement would be to have any particular SparkLE hook to any gateway, without the need for sharing keys. That could also present some security issues though, as people could hijack SparkLE’s if they are in range. So maybe the SparkLE should only work with gateways that you specify, like how the Core works only with specific Wifi routers that you configure. Maybe there could even be a Public option, so that you can connect to any gateway if you want, just like public Wifi routers.

I think the biggest thing I learned, however, is that it is not just the security portions but also the Core FW in general. Some can clearly be cut down, but even with moving the RSA security off, I am still almost out of RAM, there is only 8k. So this chip probably won’t have enough anyway, there would be very little left over for user sketches. I think we need a bigger MCU no matter what.

Anyway, I am rambling at this point, but certainly lots to think about.

1 Like
22

If the current (8KB) CPU is not fit for task without help of some sort, are there better MCU-BLE combos (whether they are integrated or not) that would allow for the entire spark stack to run at the end-point ? Reducing the gateway to a simple pass-thru device, which is, I think, the model you’re leaning towards preferring.

I don’t want to throw the cat among the pigeons too much - but if the 8KB device is really the perfect vehicle for < some list of reasons > then that would force either a different model or one where the 8KB device was reduced to the role of peripheral to another more capable MCU (which collapses back onto the first solution, IMO.)

23

The only other major BLE/MCU combo I know about is the TI CC2540, and that also has 8K RAM I believe. Also, it is an 8051 and not ARM, so that may change some things. I will take a look and see if I can find something else, but I did a lot of searching on this for another project and haven’t seen many others. Anyone else know of something?

Nordic also makes the nrf8001, which is just the BLE radio and stack. However, it is similar in size and cost to the nrf51822, so it seems better to have the nrf51822 which could have some actual work offloaded to it as well.

What I am thinking is an ARM Cortex M0 that does the majority of the work, it would have enough RAM to run the Spark FW with room left over for user sketches. Then the nrf51822 runs the BLE stack, and possibly even handles the encryption if there is enough room. I received an Atmel SAM D20 today, I am planning on using that for the next prototype. It has 16K RAM and can run up to 48MHz (I think there is even a version with 32K RAM). So it should be plenty.

This all definitely requires more investigation and more thought, so feedback is greatly appreciated. I agree small footprint, low power consumption, and low cost are priorities. I would also like to keep the board as standalone as possible, it leaves flexibility later to figure out how the gateway/SparkLE will pair.

24

Why not design around the STM32F103, like the spark core, and treat the nrf51822 just like the core treats the CC3000 ?

Makes sense to use the same platform if possible.

1 Like
25

Good point, and that may well be the best option.

A big concern when choosing the main MCU will be power consumption. I was quickly looking at the datasheets last night, and it seemed the Atmel may be lower. However, I need to go back and look closer.

26

The STM32 family does a respectable job of low power.

27

Absolutely, and there is a reason the Spark team chose it, it is a good MCU.

I am definitely not locked into anything at this point, there are a lot of options. Looking quickly at digikey, the STM32 is more expensive ($3.85 vs $1.94 for the Atmel for 1,000 units). The Atmel can also come in a 32-pin QFP package, which doesn’t appear to be an option on the STM32 (though it may need a larger package, so this could be moot).

Having a second MCU on-board with the nrf51822 means I would like to pick the lowest powered, cheapest and smallest MCU for the FW to run on. You’re absolutely right that having the STM32 could make the FW porting easier, and easier to manage in the long run, so that needs to be weighted as well.

Overall, I am curious as to how much interest there is for this product. I have heard back from a few people in the last few weeks, but would love to know if this is something everyone wants. Is this a good option for some of the projects people are doing? Is this a good companion to the Spark Core?

28

Why don’t you just start with the RFduino? It already has the nrf51822 with a qualified antenna. I am using it for the BLE and connecting to Spark for the Wireless, well as soon as Serial2 is available.

29

Thanks, I appreciate the feedback as I am trying to gauge if this is something people would want.

As for your feedback, I would say that it is sort of like asking “why not just us an arduino with a Wifi shield instead of the Spark Core?”. The hardware can connect and do everything the Spark Core can do, but it is a much more limited solution. The power of the Spark Core is that it hooks to the Spark Cloud.

RFDuino doesn’t work with any cloud. It can’t do OTA FW updates, publish events, listen for events, call functions remotely, etc. without a lot of custom code. Having a SparkLE would be like having an RFDuino that hooks to and fully works with the Spark Cloud. It would do all of those things out of the box.

My real thought for SparkLE was to create a drop-in replacement for the Spark Core, but since it uses BLE, it would consume much less power and work well in situations where battery life is important. Think of a home automation system where you could use a lot of these in places where power outlets aren’t available, and have one gateway in the home to provide internet access. You’re right, you could do all of that with RFDuino’s and Spark Core, but then you would have to write all the custom code for the RFDuino’s and the Core to do it all, just as you could have to write all the custom code for the Arduino+Wifi Shield if you used that.

1 Like
30

I guess i see the real usefulness as a bridge between the BLE devices and WiFi?
So if i had 10 BLE devices around my house, I would need 1 BLE to WiFi bridge device, correct?
Why would every device need both BLE and WiFi capability.
Sorry if I misunderstand.

31

Exactly, SparkLE would not have WiFi and would only have BLE. So you would have one gateway and ten SparkLE’s. Each SparkLE would be much lower powered and (hopefully) cheaper, but have the same capabilities of a Core when it is connected to a gateway.

A gateway could be anything: your phone, a Core+BLE shield, a laptop, a BLE device hooked to an Ethernet device, a BLE device hooked to a GSM network, whatever. It wouldn’t have to have WiFi, just an internet connection.

So SparkLE is like an RFDuino but running the Core FW so it can do all the awesome Spark stuff.

32

Just wanted to give another update. I went back and stripped out everything related to encryption and tried to reduce the RAM footprint as much as possible. With it still working, I am down to about a 4K footprint (assuming the handshake all takes place elsewhere).

So I am starting to think I will use the second MCU for handshake only. This way, I can use a small and cheap MCU that is dedicated for it, and then run user code and Core FW on the nrf51822. This simplifies things a bit, as there won’t need to be two sets of FW the user wants to edit (the user should never have to worry about changing the code on the handshake MCU). My old architecture would have meant that the user could actually want to change both the main MCU and the nrf51822 code, which would have been a little odd. Plus, I can power off the handshake MCU pretty much at all times, saving power. The biggest downside is, RAM will always be limited for user sketches.

Right now, I have Spark.publish working with SparkLE, I can send events through. I also have the descriptors set up and Spark.variable is working, so I can access variables. Next step is to get the functions and subscribe working, then I should have a pretty rounded out set of Spark features to work from.

I have been reading a lot on the forums about battery power with peoples projects. It seems like most people get, at most, a week out of a relatively decent sized battery with a Core. I plan to do some measurements soon, but based on other projects I have done, I expect SparkLE could last weeks or months on small coin cell batteries depending on what you are doing. So my plan is to make this the most low powered, low cost Spark device out there for projects that really need very long battery life.

2 Likes
33

I now have SparkLE supporting the major functionality of a Spark device: publish, subscribe, function and variable are all working. I also went back and structured the FW with the application.cpp file so I can even write code locally like you would on any Arduino or Spark Core (setup() and loop() functions). Here is my little test code (not pretty, but it works!):

There is still lots to do, but at this point I have a fully functioning prototype. I plan to start putting together some basic, and crude, boards so I have a platform to work from that is close to the final hardware (extra flash, handshake MCU, etc. all on one board). That should make finalizing the FW easier as I now have to worry about things like the bootloader and wiring.

However, I am also now starting to run into some serious questions about how this will work with the Spark Cloud. For example, the ID of a core. I assume Spark loads keys onto a Core and saves the ID into the Cloud when it is manufactured. I don’t think I can change or add keys for a Core when the Cloud doesn’t know its ID (I tried through the CLI, it didn’t work). And if the cloud doesn’t know the ID, the handshake fails. For the current prototype, I cheated and hardcoded its ID to one of my other Core’s ID’s, which is clearly not scalable.

So how could I make boards and enter the ID’s of them into the cloud? Can I? Does Spark want me to do this? Or should I be hosting my own cloud? How does Spark want third party HW to plug in?

Same goes for the Web IDE, would that ever be open to new hardware? Or if someone wanted to offer something like this, would they have to build their own Wed IDE and host their own cloud for the hardware?

I am hoping maybe the Spark Team can answer some of these questions and shed some light here, I just don’t know how (or if) they want people to build hardware for their own cloud.

4 Likes
34

Push as much functionality to the gateway as possible, and then throw one of these at the problem.

1 Like
35

Seems like Spark HQ has not picked up the question so let’s ping @zach or @zachary to answer this.

From my understanding, you can simply generate a key and submit to the cloud using the spark-cli

I’m not sure if the core id is filtered or something but the core id should be encrypted as part of the keys (i think :D)

@Dave will be able to shed more light on this and how to get non-spark manufactured devices up and running.

Have fun! I’m enjoying what i read so do keep up the good work. :wink:

36

Hey Guys,

We’ve been chatting with @eely22 a bit over email, and I already pinged the business development team about this thread. :slight_smile: Zachary is also working on clear documentation and workflow for exactly this sort of situation.

Thanks,
David

1 Like
37

Thanks @Dave! Glad to hear this is something Spark wants to support and I look forward to the documentation.

1 Like
38

@Dave Do you have a timeline for when the documentation may be ready? I was hoping to go over it before I spend money putting hardware together, in case there are any conflicts or issues. Thanks

39

Hi @eely22,

It’s being written now, but I think it’s not slated for official release for a few weeks at least, @zachary would have the official answer, but it might be a few days before he can answer.

You can always email hello@spark.io as well, and the business development team can try and answer any concerns you might have that would be blocking you. :slight_smile:

Thanks!
David

40

Thanks @Dave.

My biggest blocking question for now is a technical one. Once I build a board, I need to give it a unique ID. The Core uses the unique ID provide by STMicro on the MCU. I am not using an STMicro MCU. So,

  1. How can I get or generate unique ID’s for each board?
  2. How can I get those ID’s stored in the cloud so I can upload keys for them?

I couldn’t find any CLI commnds to do this, it seems most of them assume the ID already exists in the public cloud. Maybe I just missed them?

Right now, I hardcoded the unique ID of my SparkLE to one of my existing Cores. This isn’t viable once I have more than one SparkLE. Also, not sure what would happen if I turned both on at the same time as they have the same ID. I haven’t tried that yet, but may be interesting!