Hi All,
I’ve been really happy with my spark cores so far. They are doing exactly what I hoped they would do. I’ve also been REALLY impressed with the community here. Until recently, its seemed the the spark products have been the only game in town for this type of functionality. Lately, I’ve noticed some other products for IoT development with cloud services being announced like the Huzzah and Oak.
Can anyone comment as to how those two products compare to the spark core/photon?
thanks!
-Matt
Hey @matt_ri - thanks for the great question. We get a lot of questions about “How’s Spark different from X?” and rather than focusing on Huzzah and Oak specifically, I’ll try to answer broadly about how we’re different from other products out there. It can be challenging to compare our products to all of the alternatives because there are a lot of alternatives and a wide range of pros and cons, but I’ll try to cover that here. Also keep in mind that it’s particularly difficult to compare to products like Oak that aren’t available yet, and even those products that are available we can only comment on based on our minimal interactions with them, content that they’ve made available online, and what we’ve heard from customers. I’d love to invite others to chime in who have more experience with other products on the market.
Let me start with things that I think are truly unique to Spark compared to anything else out there:
Focus. If you’re trying to create a connected device, I think we’ve got the best platform out there because that’s all we do. What that means is that we’ve got a small range of products and a lot of engineering talent focused on making them better, rather than this being just one product in a wider portfolio. Yes we’ve got the Spark Core and the Photon, and now the Electron, but they’re really all variations on the same theme.
Online development and reprogrammability. There are other folks that have web IDEs (mbed and Codebender come to mind), but as far as I’m aware we’re the only ones who have both a web IDE and a downloadable IDE (Spark Dev) that let you reprogram your device wirelessly. With the Photon, we’ve also made huge improvements to this process so that it’s super fast and extremely reliable, and we expect that once the Photon’s shipping there will be little reason for anyone to reprogram over the wire anymore.
Community. We’ve got the strongest and most vibrant community out there when it comes to creating connected devices. There are larger Maker communities out there - Arduino and Raspberry Pi in particular - but no product with a focus on connectivity has a community like ours. That means that when you need help, we’re here for you, as are lots of other folks on these forums.
Fully integrated. Our hardware, our cloud platform, and all of our development tools are fully integrated, which makes it super fast and easy to get started. There are other integrated platforms out there too (Electric Imp comes to mind), but most of the time you’ve got a handful of tools that require some work to hook up. Besides slowing you down, that also typically means that these tools aren’t 100% designed for one another, so you might run into some compatibility issues depending on what you’re using.
Now, to get more specific in comparison to some of the alternatives that are available out there. For the purposes of this comparison, I’m going to focus on the Photon, because it comes with some major improvements over the Spark Core; in many ways the Spark Core does not compare favorably to some of the other hardware that’s out there now, which makes sense since it’s almost two years old now, and in this industry that means it’s ancient.
The Wi-Fi chipset in the Photon is rock solid and widely regarded as one of the best on the market. The Photon relies on a chip called the BCM43362 from Broadcom. Broadcom makes the majority of Wi-Fi chips in the world, so first off they’ve got the strongest expertise and the best router compatibility (because they make the chips in the routers too). This chip is used in the Nest Protect, Amazon Dash, LIFX, Honeywell’s connected thermostats, Electric Imp, and more. It’s the one that all the real products use. There is one other chip that is threatening its throne: Qualcomm’s QCA4002/4004. The ESP8266 that’s gaining a lot of traction on Sparkfun/Adafruit/Hackaday/Oak/others is really interesting because it’s super cheap and has a large community growing around it. However it comes from a relatively unknown company named Espressif; and while I’ve heard that the situation has improved, it’s had a lot of bugs and quirks. Yes, it’s cheap, and if you’re doing simple projects that don’t need to be super stable or reliable, it’s probably more than adequate. However it’s definitely not best-in-class. Wi-Fi’s 802.11 is a complicated spec, and there are a lot of ways to mess it up; if I were designing a product from scratch today I wouldn’t consider anything except for Broadcom and Qualcomm.
Our cloud platform is different than most other platforms out there. Most of the time if you ask for a ‘cloud platform for IoT’, what you’re getting is a data collection and visualization tool (examples include Xively, Etherios, Adafruit’s Adafruit IO, SparkFun’s Phant, and many many more). At the moment, that’s not what we do; instead we provide secure, real-time, two-way messaging and over-the-air firmware updates. As we build our our new dashboard, we’re focusing on the administrative interface for the devices themselves rather than the data they generate. Yes, we are building some data collection tools, but that’s one small part of our offering, and really we see most other cloud platforms as complements to ours rather than competitors. You can use our cloud platform to easily pipe data from your product into Xively or Phant.
Oak is a special case because Erik, the founder, has replicated our API in his product (his docs are really just our docs). I have an email thread open with him, and I will refrain from commenting too much on it because I honestly haven’t decided whether what he’s doing is a good thing or a bad thing.
@matt_ri, because my response is broader than you were perhaps expecting, I’m going to change your title a bit so this is searchable for people who are looking for comparisons of the Spark platform in general. Thanks again for the question!
Z
I don’t remember where I read it, but one of the competing products said that Spark is the IoT industry standard for doing it right. That standard is open and freely available, even to competitors. However, Spark isn’t letting that standard stagnate. While others are trying to implement their own API to the Spark standard, Spark is still continually upgraded. That may mean you have to wait longer to get cool new features on the other platforms.
All biases aside, I think all the alternatives are great. They all fit or create their own niches, Spark included. It also means more competition, which is a huge boon for us consumers. I have an IoT addiction (and I think these forums are the support group), and have a few of the IoT competitors. However, I keep using Spark as the go-to solution for my projects. It’s fast, reliable, and stable. The documentation and support are simply unrivaled.
All that said, I hope people buy all the alternatives and continue to raise the bar on IoT. I can almost guarantee that Spark will continue to lead the field while others try to imitate and catch up. In the end, we all win!
Does the ESP8266 support more than 1 tcp connection ?
The API docs I have suggest that with the AT command set, only a single connection is possible. That would severely limit any product based on it, IMO.
That was an AWESOME answer (and quick and on a weekend). Thanks!
I think it can support more than 1, but don’t have empirical evidence. I have one loaded up with the NodeMCU firmware. I’ll try and remember to test that later tonight.
Ah - I was just talking about the vanilla firmware - perhaps other firmware loads can exploit more.
But I’m dragging Zach’s delightful reply off into the weeds here…
@matt_ri, I was doing some research on NodeMCU and ESP8266. Here is an important nugget:
NodeMcu is single threaded and the esp8266 has a WatchDog timer. Tight loops will trigger the watchdog timer and restart the firmware. If needed we can we use the tmr.wdclr() which resets the watchdog timer, but then other bad things happen due to the single threaded nature of the firmware, like losing wifi connection, timer triggers not activating, and so on.
From the looks of it, you need to use a timer alarm trick to make sure the WiFi background tasks run or risk a processor reset. As one reviewer pointed out:
So we can see that to program the esp8266 in Lua using the NodeMcu firmware we need to change a bit our programming paradigms.
The Core had single thread challenges as well though they are addressed in a different (better) way. With FreeRTOS, the Photon raises the bar completely by adding a real-time, non-blocking environment. IMO, this makes the Photon more reliable and better suited for commercial applications than the competing products. 
oooh, that is a nugget! Nice find.
I’d love to experiment with elua on my spark core. How exactly did you get nodemcu flashed on it?
Did it end up working out or does it still trigger resets?
@creationix, I did not flash NodeMCU on the Core. I was referring to competing products (esp8266) running eLua. The Core uses a different architecture as does the Photon.
Hmm, I had misread wgbartley’s comment.
I’m aware the spark/photon are different than the esp8266. I’ve just been wondering if it was possible to run elua or any scripting language (maybe bitlash) on my spark so I don’t have to wait for the slow flash, reboot, reconnect cycle when developing. I’ve been a scripting language developer for over 20 years and I love the short feedback cycles.
Maybe I’ll just implement the scripting language I’m inventing as a C interpreter and compile it on the spark. It’s powerful enough that won’t be terribly slow I hope.
Thanks @AndyW for mentioning VIPER http://viper.thingsoninternet.biz/ .
We are proud to have VIPER ready to run on all the Spark boards. VIPER is a multi-threaded operating system for MCUs with on top a virtual machine that interprets Python 3 code.
With VIPER it is possible to develop hybrid Python/C scripts merging the power of low level real-time programming with the efficiency and developing time optimization of an high level scripting language like python.
VIPER is currently in private beta and we are planning to release VIPER on Github in June.
Best
Daniele
VIPER team
And few more words about ESP8266 with NodeMCU - lua. It’s a simple and very powerful tool. But… only if you need something really really simple. Then - a 3-4 USD ESP8266 board fits perfectly. But, it has so little RAM, then it’s almost impossible to write a program with more than 100, maybe 150 lines of code. And you have to be very careful with this NodeMCU, it’s an asynchronous language. You don’t really see that it’s singlethreated - most of the commands just start in the background, and you have callbacks to control when they finish. If you don’t, and you try to do something why NodeMCU is busy finishing similar thing in the background - it just reboots. And believe me, it reboots really often…
The good thing is - you can have a webserver running on ESP8266, on top of the WiFi access point and an dhcp server, using about 10 lines of code ! And, you can run a wifi client concurrently. pretty powerful. But only for small projects.
Hey @kefir135, I have faced the same pain on NodeMCU. I think the running out of RAM issue is essentially because of lua porting itself. In this case I agree that ESP8266 has got a greater power thanks to NodeMCU lua, while it brings such side effects.
Now that there comes the esp8266 arduino, it eliminates some RAM issue and is growing.
Therefore my friends and I created a project based on it called Neurite, which can either be a easy bridge or a connected platform.
Now how would the Particle Photon compare to the ESP32? The ESP32 has got WiFi and Bluetooth and has a 240 MHz dual core Tensilica LX6 microcontroller. It also has 520KB of RAM and 16MB of flash which is a lot more than Particle Photon’s 128KB of RAM and 1MB of flash.
Just to clarify, are these 16MB flash actually installed or just an option
As I read the datasheet it has 448 KByte ROM.
But even so it's an interesting device and if it had the Particle cloud behind it would be even more impressive 
@Greg123, the chip looks great but the magic is in the development and support sauce. Particle’s model is maturing rapidly whereas the ESP line, though low priced and ubiquitous, has had its share of development issues. Certainly worth watching!