This code is designed for at least one Argon and as many Xenons as you want. There is only one piece of code and it compiles on both platforms without any changes. Here is a link:
First, flash the Argon and enable your favorite flavor of serial monitor. The Argon will perform a mesh subscribe to “random_num”. As each Xenon is brought online, it will publish to "random_num/<device name>/X, where X is a random number between 30 and 64. I used random numbers to make it easy for those without any specific sensors.
There is about a second delay between each publish, so it works out the whole system pretty well.
One thing I wasn’t sure about yet (and I need to research), is whether or not to enable threading on either the Argon or Xenons. If anyone has any particular thoughts on that topic I would like to hear them.
One other question on “delay”…will it eventually cause a problem in mesh communications? Is it better to use millis-based delays instead so you can still use Particle.process()?
I've been running 2 mesh networks, one with SYSTEM_THREAD(ENABLED) and the other without. It might not be a fair comparison because the one without is only 1 Argon with 1 Xenon while the one with threading enabled is 5 total nodes (1 Argon with 4 Xenons). The mesh without threading is running very stable with low latency. The mesh with threading has been flaky until RC.26; after the update, the mesh is very stable with about 1 lost response in 10 minutes or so. The missing responses are usually from one particular Xenon which may be experiencing the SOS 7 crashes. So I would say go ahead and run threading. It should help to keep the program flowing especially when there is a cloud or WiFi interruption.
Oh. In my testing, I enabled the threading on both the Argon and Xenons on the 5 node mesh network. If anything, I think you want it on the Argon so it doesn’t miss any inbound messages. On the Xenon, I’m not sure what scenarios would cause threading to become a must. If the Argon loses WiFi, for example, then the Argon would miss messages making threading on the Xenon unnecessary I suppose. If you enable on the Argon, I think it makes sense to also enable on the Xenon.
One thing I saw today in testing (1 Argon, 2 Xenons), when I set the inter-publish delay to 250ms, I started seeing weird issues, particularly when flashing code. I don’t know if such a low delay is fair or wise, but I wanted to put some stress on the Argon.
On the serial monitor, the output on the screen kept up. It showed the Argon receiving the publish from each Xenon. However, the weirdness started when I also tried to then flash one of the Xenon’s. If I tried to flash Xenon1, the flash would fail and I would have to end up resetting the Xenon before it would come back alive. Also, I had to power off the other Xenon before I could successfully flash the first Xenon. This was repeatable between both Xenon’s over a number of test cycles. Once it was running, it seemed stable.
Another thing I observed was an occasional “blink”, where both Xenon’s would flash green and then back to cyan.
I’m mainly just running hearbeat testing every 10 seconds but I am capturing round trip latency of the mesh publishes. When a flash starts to a Xenon (not sure about to the Argon) I can see the round-trip latency spike to 4000ms and more. That would surely cripple a mesh that is already stressed… or prevent a successful flash as you’re seeing.
I don’t want to run around like the proverbial chicken, but if I can’t update code on a meshed network with 2 devices that is going to be a serious problem. It’s just not feasible to have to shutdown all other nodes when attempting a flash. I sure hope things improve as the Particle folks get more experience with “real world” networks and the varied ways people intend to use them.
Wanted to follow-up with this thread to let everyone know that a fix for the SOS-7 issue has been released with v0.8.0-rc.27. The issues was tracked to a problem with the Nordic 802.15.4 driver. Instructions for upgrading are available below. We'd love to know if applying the release fixes the issue SOS-7 issue that you're experiencing.
Note that we have seen some reports of change in behavior for rc.27 when users call the Mesh.subscribe() function within the setup() loop that can result in a separate SOS-10 code which we're currently investigating. If this issue affects you, please note the following workaround.
I can’t make it through the OTA update to get rc27, seems to SOS7 in the middle of the update process as it’s flashing magenta. My argon is currently on rc25. Is there another way I can update the firmware?
Update: I see another post about doing a factory reset and letting the setup process update it. I’ll try that now.
Update 2: That worked, all good now. Happy to have Scruff’s alternative and even happier not to need it
