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.
@lami Ideally I would like to stay within the same development environment, hence the SparkLE if done right would be perfect 
1 Like
The plan for the standalone product is a bit dependent on the availability of the nrf51822 with 32KB RAM. We are working with our module suppliers to find out when we can start getting production volumes. Once we do, we will put together a schedule and work with our manufacturers to find out dates, then we would launch a Kickstarter campaign for it.
Yes, we want the SparkLE development to be as close to the Core/Photon as possible. We will continue to work with the Spark team to try and integrate completely with all development tools so it is seamless to switch between the two.
Thanks again for everyone’s support and comments, we are going to be very busy over the next few months getting things up and running, but I will post progress here on SparkLE as we go.
1 Like
This might be an interessting case for the “product creator” category. That is, if you’re willing to document the process you’re currently going through(?)
Wouldn’t it be possible to switch to the arm processor used by the photon? Form what i understand, it is much easier to integrate encryption with it and it es overall faster.
@alterschw3de
Yes, that is certainly possible. However, I think one of the benefits of BLE is to make the device as small and cheap as possible. Therefore, there is no need for a second MCU when the nrf51822 can do everything needed.
With a 32KB version of the nrf51, the user would have more RAM than the original Core, by quite a bit. The clock speed would be slower, but the power requirements would be greatly reduced compared to a Core.
I think making SparkLE different is better, rather than trying to make a BLE powered device with the same specs as Core/Photon. If you want a lot of things with low power requirements that don’t do a lot of heavy lifting, something like SparkLE could be a good fit. If you need higher data rates or heavy lifting processing, then Core/Photon could be better. I see them working together and complementing eachother on the processing/power/cost/mobility spectrum by filling in different areas of the graph.
Sounds reasonable. I just mentioned it because it seems you have to invest a lot of time in the whole encryption stuff and the photon MCU should cover it easily.
From my point of view, the faster SparkLE becomes reality the better 
1 Like
@alterschw3de
Yes, you are right that the encryption part was a pretty big stumbling block. However, it will all be resolved with more RAM on the new nrf51, so it will just take a bit of time at this point.
I hope to get SparkLE done as fast as possible as well! Thanks again for feedback and suggestions, I know people are anxious to get their hands on this new HW, so I will keep the communications lines open
1 Like
I was starting exactly down this road. Anything I can do to help?
Do you see the new BT42 IPSP of any help here? I think this would eliminate the need for the phone and allow you to use essentially any super-dumb BT/Wifi gateway but still have direct address-ability.
1 Like
@Stickboy Good timing! I was just about to post an update on this. Here goes, this is pretty long since it’s been a while…
The 32K version of the nrf51 is going into production this quarter. I now have samples of it, along with samples of certified modules from two manufacturers. I had to update to the newest Nordic SDK when I got them, which led to a fun bag of problems, but I have them (pretty much) all resolved at this point and got the firmware up and running again. So now everything runs directly on the nrf51, no more handshake MCU!
I put together schematics and laid out a simple board. I ordered them and got them this week, assembled and tested and everything seems to be working great so far. Here is a picture of the board next to a Core:
These boards are just preliminary, and I am still missing the RGB LED which is on order, but they will work well for me to test and finish off the firmware. I am working on the bootloader right now, so hopefully that will be done soon.
We are placing an order for the 32K modules for GoGlove now so we can get the first ones that roll out of the factory, sometime in March. I hope by that point to have the firmware working pretty solid and then I can start building out more than a handful of these. I was thinking of sending some out to interested people in the community as sort of a Beta run. Then, hopefully, I can start taking pre-orders, either through something like Kickstarter or just on the website.
I am envisioning five parts to this. One is the DK itself, the BLE board running the Spark powered firmware. The second is a USB programmer. The nrf51 doesn’t natively support USB, so if I were to add it to the board it would require another MCU, which I am averse to. So it will be in the spirit of RFDuino or RedBearLab where there is a separate USB board for local programming. This will keep the cost down of each DK. The third piece is just a simple battery shield to power this off a CR2032.
The fourth and fifth parts are the gateways themselves. One is just an app for Android or iOS. This is how I am using it now, with an Android app. The other will be a shield that takes a Spark Core/Photon and has a nrf51 that acts as a Central device. This will be a full gateway in itself. I am still investigating this last part, I have concerns about co-located radios and what that means for performance and regulations.
The official name of this project has changed too, I am now calling it the Bluz DK. I have set up a simple landing page just to have something out there, you can check it out here: http://bluz.io/ (warning: i just linked the domain name, so it may take a few hours for this link to work for everyone).
So, that is the status. Once I get the DK to a good point, I will work on the USB board. Then I will work on the gateway shield. The apps are already well on their way and the battery shield will be very simple.
There are some open questions that I was hoping people can give feedback on, mainly:
- Would you want a USB mini port on the board itself simply for power? It would not work as a real USB port, it would just supply 5v so you can power it without separate shields/supplies.
- How addicted are people to the RGB LED? I love it on the Core, but on this DK, I worry that it will just take too much power. I am trying to make this as low powered as humanly possible so it can last forever on coin cells. A pulsing/flashing RGB LED is not exactly low powered.
And yes, I am pretty excited about the BLE updates that support IPv6. You are right that it will allow simpler and more universal gateways. That is definitely something I am looking in to.
3 Likes
As an edge device I would not care about a USB mini port (coin cell!). As you put it, I am ‘adverse’ to using smartphone/tablet as a gateway so for me the 6LoWPAN would be an essential feature with a headless gateway. I think that topology is essential to keeping it low cost which is needed if, you know, want to sensorify bunches of things. Else it gets into the realm of “Do I really want to pay X$ just to monitor that?” The less of that influence the more connected things we will see.
I am actually not familiar with Spark (yet) but I think a led would be useful (but not constantly blinking). It can always be disabled in programming. It’s the $19 Proton that really “sparked” my interest.
I will be starting to look into that Nordic IoT SDK as well for the gateway.
2 Likes
Completely agree on the gateway. The shield I envision for this, if it works well, will provide a low-cost solution for connecting lots of these little guys. I think of it just like your home Wifi router, but for BLE. Cheap, always on, and ready to connect many of these to the internet.
Another option is mesh. I have been talking to the Nordic guys, and while BLE doesn’t inherently support it, people are creating mesh networks with BLE. So certainly something else to consider for the roadmap that this hardware could support.
I do kind of agree on the USB port as well. I really wanted to put a coin cell battery directly onto the board, but it won’t fit if I keep it the same footprint of the Core//Photon. I am hoping to make a really simple/cheap coin cell battery shield to make up for that.
2 Likes
I would say don’t sacrifice the design just to provide power options. That’s the easiest thing for the end user to resolve the way they want. You never know what Rev 2 will allow you to do or what some inventive user will come up with.
I would say losing the RGB light is a good idea in two parts, the first being power savings, the second being the BOM should be reduced (albit slightly)
One of the downsides of the LightBlue Bean is the price tag, the Photon hits the mark so perfectly on the $20 with its feature set
If you can keep the Bluz at a low cost that would be awesome, and if using a standard serial port to program the board would again save costs as almost everyone has one of these
With the battery you could do is simply place the require points to solder on a CR2032 battery holder? Thus anyone trying to do a project that wants it small, the ability is already there, and those who want other battery options can just elect not to solder it on
2 Likes