So I just replaced an Arduino Yun with my 2nd Spark Core, and I love it. My first Spark Core project taught me enough to do a quick swap out and it works beautifully.
So of course I’ve decided to complicate things. I would like to sync several devices using a single Core as the “traffic cop/orchestrator” - right now I don’t want to try and issue commands to the 2 separate spark cores and hope they are timed roughly the same, because I expect there will be normal latency and hiccups.
I thought I would use one Spark Core as the gateway to my UI layer, and then have that spark core communicate with several controllers nearby via short range wireless of some sort. At Maker Faire I talked to a guy about Flutter Wireless, and I’ve read about XBee and even older school 433mhz RC car type controllers.
Wondered if anyone has any experience using the core as the hub of a mesh network, where the commands happen locally and the Core just has to connect it all to the internet. What hardware works well with the Core? What’s the best thing for a master controller-many slaves arrangement?
In a project I am working on I will use nRF24L01+ chips. It uses 2.4GHz band, handles addressing, packet ACK and retransmit, while keeping it all simplle. And it is very cheap, you can get a module, complete with pin headers and PCB antenna for about $1 at eBay or Aliexpress.com when buing 10 of them or so. And there are libraries for Spark (and almost anything).
Communication is mostly one-directional, a chip operates as Primary Sender or Receiver, but you can get some data back to sender when using ACK packets with payload and build your magic on that.
I did not start connecting it to the Spark core yet, still working on TCP part of the project. And I will use Spark to receive commands and passing them using TCP, which is opposite direction you want to. As packets are addressed, I am not sure if a broadcast is possible. You can set up a group up to 6 receivers and send packet to all of them, but did not try that yet.
If you had a local router not connected to the Internet then all your cores could communicate without having to interface any extra hardware, using UDP. As problematic as Spark’s “UDP” has been it is usable if you include end-of-packet indicators, and broadcasts work if you use the MANUAL mode ping initialiser workaround.
Very interesting! I had wanted to do some research before diving in, hence this post, but with the price on these things, there’s really no reason not to just jump in and try them out.
I don’t need to do a lot of broadcast, I guess, just one controller to many endpoints, so these should work great. The main thing I was hoping for was to not have to port a library to the Spark (currently trying to do that with some IR parsing stuff, and hate it) so this sounds perfect.
If, @patrickcentral & @lami, the focus is the fun of interfacing hardware then, OK, go for it. But all you need from a TCP and UDP point of view to allow your Cores to talk to one another already exists with the WiFi functionality already built-in to Core - there is no need for extra hardware, other than a router which is not connected to the Internet or anything at all. Ah, I see I have already made that point.
But why bother with the extra expense of a Spark Core over an Arduino? You gain nothing from the extra capabilities of the Core?
Well, Spark will be central point, a gateway, powered from power outlet. Other devices would be just smart remote switches, battery powered. So I need lowest possible power consumption and fast response. I can achieve low power putting Spark to sleep and wake it up using interrupt. But 2s wake up time (WiFi connect, if I am lucky) is too much. nRF24L01 needs 22uA in Standby I mode (oscilators on, radio off) and starts sending packets in 130us. From power off mode (900nA, SPI on, everything else off) it takes 1.5ms to starting broadcasting. Which is still enough to feel response as instant. Pretty amazing I say. You can tell I am in love with these chips
Plans for remotes are custom PCB with ATTINY44, probably. But I am still far away from this part, working on Spark gateway now.
I’ve been thinking about something similar. I would love for there to be a library where devices like perhaps Xbee end-points or custom sensors to be able to publish events or even perhaps expose variables. I realize Xbee-to-internet gateways exist but I would like Spark-powered
For me it’s a mixture of wanting the more expensive and network-based Cores to be doing something more cool, and wanting to use some existing circuits/shield hardware and setups that I have already built (and use the code without porting it.)
If I’m honest with myself a lot of it is not wanting to port code. I can easily throw together something using existing code for an Arduino Uno, and if I can make it obey the Spark Core traffic cop and sync with other similar kits, then I’ve essentially married my old projects to my new ones in a more scaleable way.
Yes, I seen the topic, I was suggesting RFDuino as already available alternative. Thing is, Spark LE isn’t out yet and AFIK nobody knows when it will be. Architecture seems clear though, most likely it will consist of BLE Central shield for Spark Core and Peripheral type SparkLE. I suppose it takes about a year to have product out with decent library.
So, when SparkLE comes out, I will most likely try it. But since I am working on it right now, I will stick with what I know and what is available. And maybe get some HW design experience on the way (read “lots of burned silicon”)
