I have a remote installation with 1 Boron and 2 Xenons. RC25 has been a huge problem (as has been reported).
Today, after driving one hour to reach the site, I found both Xenons flashing blue (presumably in Listening Mode). This should have never happened since both were already part of a network and their associated Gateway was on the cloud.
Anyway, I proceeded to flash new firmware and to my “premature” delight, found out that RC26 is out. While not seamless, I managed to update the firmware on the Boron, and the two Xenons.
After the Xenon’s firmware was updated (confirmed through IDE), the Xenons starting flashing White and Green. I tried to update the firmware again, but now, EVERY time the firmware is about to complete, the Boron starts flashing red. Very disappointing.
The new mesh hardware has a really wonderful architecture which has been scarred by half-backed firmware. As I previously posted, the RC25 worked fine with a Boron and a single Xenon. Once another Xenon is added, the mesh stopped working!
This begs the question of the quality of Particle’s QC (or the lack thereof) as this cannot be blamed on the usual “scalabilty hanger”. I would have thought that the mesh needs to be tested with more than a single node?! Had this been done, this unnecessary waste of time would have been averted.
I hope that Particle proceeds to fix these problems and show some respect for their customers’ time.
Did you bring those devices back with you such that we could help you to debug them?
If not, would you be willing to post the code that you are trying to flash to the devices such that we can attempt to replicate and resolve?
We are highly focused on continuing to improve 3rd Gen hardware stability until it meets and exceeds our 2nd Gen devices. If there is information you can provide to help us resolve the issues you (and possibly others) are experiencing, we'd be appreciate of any data you can provide.
Sure thing – feel free to send me a PM with the source code or open a ticket with http://support.particle.io, where our team can best do multi-touch investigations into device misbehavior.
Any chance the blue flashers experienced a low voltage situation? I ran down the battery a few times on various mesh devices, and 3 of 4 times, they would revert back to flashing blue when the voltage was restored. I was using a photon firmware that would shut itself down before using up the battery, but with no support yet for sleep modes, these just keep on operating until the voltage is too low to support the device.
At least once the firmware was still intact, but the mesh credentials were wiped out.
That is a plausible theory. The nRF52840 can run at really low voltages but the SPI flash cannot. In 0.8.0-rc.26 code was added to reset the device when the voltage is below 2.8V to prevent corrupting the external SPI flash where all of the configuration data is stored.
There is absolutely no way this is a voltage issue. At that time, the Boron which is powered by the same circuit was working fine. And since it draws more current, I doubt this was a voltage issue.
When I arrived at the site (while both Xenons were running RC25), both were flashing blue. I could only fix one of them completely at the site (where it was also upgraded to RC26).
I deleted the seocnd’s Xenon’s mesh then rejoined the same mesh and was upgraded to RC26. But then I could never get it out of flashing blue until I returned to the office.
At the office, again, putting it in safe mode still did not help. After @rickkas7 help on updating the firmware via USB and having that Xenon join another mesh network, I was finally able to revive it.
I am “almost” sure this problem occurred as a result of upgrading the firmware via the Gateway Boron.
@rickkas7 - are there any god methods to prevent the corruption from low voltage without external hardware - before we get the sleep modes?? Idiot proofing, that is!
The nRF52840 should prevent low-voltage corruption. We just didn’t have the right settings in 0.8.0-rc.25 to enable it. They should be correct in rc.26.