(Just a random travel log... Hackaday article coming soon)
Image upload test...
Like it or not, a whole new wave of Hardware Startups is coming our way. Crowdfunding 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 we should get involved and start asking some hard questions. After all, these guys didn't think they will be able to get away with just some nicely produced videos and a couple of high-res photos, right?
For our first issue, we picked a relatively innocent target - Spark.io, guys 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...
---------- more ----------
"I had a problem that was very real to me, which was my parents communicating, and I saw a way to solve this problem with connectivity," Zach says explaining the motivation behind their original project called SparkSocket - connected lighting product inspired by helping his father overcome challenges associated with hearing loss. They ran a Kickstarter for this one, but only managed to get halfway to their funding target.
"The feedback that we had received from the market was that our product was not good enough," Zach said.
After iterating on product ideas and joining the HAXLR8R incubator program in Shenzhen, they eventually came up with an idea for the Spark Core and ran a Kickstarter, this time with great success. They have been shipping boards since the end of last year, and most of us probably already had a chance to play with one. We were curious about the choice of CC3000 as a WiFi module.
"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," Zach said.
In terms of what other modules were taken into consideration, he says that "The main ones that we were evaluating at the time were RN171, 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 its 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," Zach says.
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 device-to-device communication using Spark. While device-to-cloud communication seems to be fairly well specified (after all, that is the core use-case), device-to-device aspect was left fairly open. In figuring out ways to address this, community seems to have converged into a particular pattern over time. Instead of doing this type of communication ove Read more »
---------- more ----------
(all stickers posted on poster-designated locations. no vandalism here)