Like it or not, a whole new wave of Hardware Startups is coming our way. Crowd Funding campaigns are making it possible for everyone with an idea to “test the waters”, tech-savvy Angel investors are eager to help successful ones cross over, and Venture Capitalists are sitting on the other side, always on the lookout for potential additions to their “hardware portfolio”. It’s these billion-dollar acquisitions that made everyone jump on the bandwagon, and there’s no going back. At least for now.
That’s all great, and we want to believe that good things will come out of this whole frenzy. But instead of staying on the sidelines, we thought Hackady should get involved and start asking some hard questions. After all, these guys didn’t think they’d be able to get away with some nicely produced videos and a couple of high-res photos, right?
For our first issue, we picked a relatively innocent target – Spark, the team behind the Spark Core development board. By embracing Open Source and Open Hardware as the core part of their strategy, Spark has so far been a positive example in the sea of otherwise dull (and potentially creepy) IoT “platforms”. So we thought we should give [Zach Supalla], CEO of Spark a call.
What sparked Spark
“The feedback that we had received from the market was that our product was not good enough”
After iterating on product ideas and joining the HAXLR8R incubator program in Shenzhen (a program we first looked at a few years ago), they eventually came up with an idea for the Spark Core and ran another Kickstarter, this time with an astounding response which produced $567,968 with a goal of only $10k. They have been shipping boards since the end of last year; most of us have already had a chance to play with one or at least wish we did.
Hardware Choices
We were curious about the choice of CC3000 as a WiFi module and [Zach] came back with a reason:
“This might still be true, but at the time of our launch, this was the only affordable WiFi module that you can purchase in low quantities extremely easily. For instance, there are other companies that make affordable WiFi modules, when you get to scale – Broadcom and Qualcomm are two of note. One of the challenges with them is that it’s difficult to gain access to these chips in low quantities. And to be meaningfully Open Source, that was important for us”.
In terms of what other modules were taken into consideration, he said that “The main ones that we were evaluating at the time were RN-171, the GainSpan solution and the CC3000. And the main part of it was being affordable. There are some features that CC3000 doesn’t have that others did but, when it comes to providing something that’s cost-effective solutions, it’s a trade-off you inevitably must make. CC3000 doesn’t add up to 802.11n, it doesn’t do SoftAP setup, although they have their own thing: SmartConfig, which is pretty slick, but has its quirks also”.
On the communication side, Spark is using a slightly modified version of CoAP. “What we didn’t like about MQTT is two things: one, we wanted it to do request-response model and MQTT is pub-sub and second, it didn’t define the payload which felt to us like it’s not solving enough of the problem. CoAP had much more of that defined and it felt like a more complete solution”.
Open Development Process
Spark’s approach to solving problems seems to be pretty open and hacker-friendly. Instead of trying to specify and define standards for everything in advance, they adopt a “learning” approach. “When we’re not sure about an answer for something, let’s just leave it open and see what people do, and see if the community starts to fall into a pattern, and then let’s just adopt that pattern”.
A good example of this was the case of device-to-device communication using Spark. While device-to-cloud communication seems to be fairly well specified (after all, that is the main use-case), the device-to-device communications was left fairly open. In figuring out ways to address this, the community seems to have converged into a particular pattern over time. Instead of doing this type of communication through the cloud (which, might introduce latency unacceptable for real-time applications), devices use the “cloud” only for authenticating socket open requests. After this, all communication is done locally. The Spark team is now promoting this as an “official” design patterns for device-to-device communication and will probably end up building protocol-level support for it.
The Cloud
An aspect of Spark that we particularly appreciate is that, at least so far, their “cloud” infrastructure is only focused on one truly valuable use case – scalable messaging between devices. Usually this part is where there’s much handwaving and magic involved, but in their case it seems pretty straightforward. And that’s a good thing. They will also be open sourcing the Spark Cloud in the next couple of months, so we’ll be able to judge internals at that point too.
Even more important is their attitude towards the question of who owns the data that gets pushed into the cloud. “You have IoT ‘platforms’ that have the perspective that they really own the data and you as a manufacturers of the product are ‘renting’ the data. I think our perspective is much more of – you made the product – it’s your data. And we’re here to help facilitate you having access to that. So we’re putting in place products that feed your data back to you. But it’s not data that we own”.
So far everything that the Spark team say checks out. They’re doing all the right things, they have a healthy attitude towards privacy and data ownership, they’re embracing Open Hardware/Open Software, and they actively involve community in the process. But as they keep moving forward, they will face a lot more pressure to monetize. And with that some of these values may be challenged.
We’ll just have to keep an eye on them…
Listen to the full interview below, or read the transcript at The Hardware Startup Review.
I love my sparkcores, one the best things I have bought so far!!!
I’ve got two Spark Cores from the KS campaign, and they’ve become my prototyping platform of choice (in what limited electronics “play time” I have). Being able to reflash my project from across the room, and without worrying about accidentally disconnecting something to attach a USB connection, is great.
The community is active, and there are several people who are quick to port existing Arduino libraries to support new sensors almost as quick as people can request them. There are a few people who have expressed concerns about everything having to go through the Spark cloud service. But when they release (soon) the cloud platform source and people are able to self-host, that should alleviate things in that department.
You can layer req-resp on pub-sub, its trivial – the benefits of pub-sub are huge in an IoT type environment. It’s not easy but it can certainly be done…
Here is a link to the CC3000 WiFi SmartConfig fiasco, I am sure reading it will make your day:
http://e2e.ti.com/support/wireless_connectivity/f/851/t/253463.aspx
Alright, the reply by Tomer most of the way down the first page (hey TI… absolute links to individual comments. *we* have them and our commenting system sucks) seems to be a legit explanation for this.
That being said, an ‘ask hackaday’ post on trying to crack the smartconfig process might be in order. Even if it can’t be done, it would be good to verify that.
Go to page 2 and read the post by George Hawkins on Aug 4. He simply looked at the Java implementation of SmartConfig. It appears there is a momentary insecurity unless each CC3000 device is shipped with a unique key that also has to be entered into the configuration application.
Ask Hackaday post it is.
Yup, agree, though in fairness at least TI was forthcoming (after being pressed) with the fact that sans AES, you are totally exposed. (‘wait, don’t those contradict one another’ :). A big issue to deal with in any push-button config is that at some stage, you have a necessary and deliberate (hopefully managed- ) vulnerability. TI suggests that you solve this by issuing a unique AES key with each device. That’s a major bummer as it has impact on the sorts of devices, production and logistics, and all of the internal & external security around that process. Yet still it doesn’t protect you 100%. An unfortunate, but true consequence of push-button Wifi.
It makes the idea of critical or semi-critical systems dependent on this sort of authentication scary (nevermind the front door, what about your stove? the iron?).
With a device registered in the cloud and a second step authentication process via a cloud back end (i.e. if the system adds that device by GUID or such, linked to a user / event, fixed time window, etc) you get a decent second layer of security that is pretty tight…Not perfect but certainly more robust than the OTS implementation TI is proposing.
A weak point in the Spark offering is they don’t have that back end infrastructure (i.e. cloud services) to support these sorts of things. Spark is only using the cloud for message routing, and as such, there’s no device model in the cloud that’s linked to the products you might buy (unless of course you build it yourself). So there is a hole in there the developer is left to fill and then of course, the likelihood that will be compatible across companies, across products, etc. is pretty low.
It’s one of the really hard problems of doing IoT *right* that needs to get solved if people are going to adopt it beyond simple control of things within earshot.
IoT is in most cases bollocks as there is no need that your iron is connected to the Internet, it is enough when it is connected to your home network and is well behind the firewall.
Except of course Cloud companies want to make masses believe that for some reason it is in their benefit when the iron is connected to their server to upload your ironing times and to create massive potential security issue.
SparkCore is a great IoT device/platform!
I helped porting NuttX RTOS to this device, then instead of using original firmware I’m using NuttX. Then I have a “Linux-like” system running on this small board! It is much more powerful.
If you don’t have this device, please consider getting it!
Open source is not what comes to mind when I think of my CC3000. It’s firmware is closed source. The hardware block diagram is a single rectangle. And what’s inside has got bugs[1] which would have been fixed last year if TI had an open source product. But the big name IoT companies are replaying what happened in the late 1970s when some of the home computer makers thought they would make the hardware and write all the software themselves. For example Atari’s home computers didn’t become popular until the hackers published the Undocumented manual gleaned from reverse engineering machine code.
[1] It seems that if the client connect to the CC3000 closes a TCP connection with RST rather than FIN the CC3000 goes into a loop. In other words if the customer access a CC3000 based web site and presses the stop button or moves on the CC3000 needs to be rebooted before another connection can be made. And this is far from the only bug. My device can’t handle a continuous loop of wget’s either, even if FIN is used.
Thank you Hackaday for providing some insight into Spark and their product!