Same issue here. Did you ever come up with a solution?
The gen3 firmware is rough on the edges but there’s a lot of improvements done since Spectra!
Hopefully these issues highlighted will be resolved with the newer firmware release.
Well, I found a way I can get them to connect, but I figured I just need to give Particle enough time to really sort it out.
If I can get the endpoints to flash fast green, I can then connect the gateway to Ethernet and they all start working as you would expect.
The gateway has to go thru it’s cloud connection when the endpoint is trying to make its connection for the first time since reset. That may not be exactly what’s happening, but that understanding is enough to get me to fumble thru making the connection.
They do stay connected fairly well now, so that’s a significant improvement.
I’m having a similar issue with my Xenons as well: they’re just blinking green. It seems that if I restart the Argon, the Mesh Network comes back and the Xenons reconnect. Then eventually (within minutes) they lose connection again and go back to blinking green again. All three devices are running firmware version 0.8.0-rc.25 and the Diagnostics section of the Particle Console doesn’t seem to have much in the way of information. All I see are disconnect events for the Xenons.
I’ve gotten a little further here.
My trouble seems to stem from my Arris Modem.
I did some reconfiguring of my network at home, so that I have another router in front of the Arris, I have an Apple Time Capsule that was in bridge mode, and now it’s doing DHCP and NAT.
Once I did that, the Xenons have been connecting well.
For folks who are reporting issues with Xenons disconnecting after you flash user firmware to a gateway (Argon, Boron), thank you.
I managed to replicate the issue and have brought up to the team.
Hope to bring some updates when there’s any.
I received my particle xenon shipment and I am all excited to get it started. the same way I did photon setup the P-series Particle Photon I put it in DFU mode and using ATOM particle-dev-IDE Flash it with the code but not so fast… I use the same instruction to put Xenon in DFU mode and the windows10 does automatically recongize the Xenon in DFU mode just like photon and electron and the
So I run the particle device doctor since I already have particle-cli installed and the device doctor does require Xenon into a standard listening mode NOT DFU mode So I did reset it back listening mode
But without any luck
Yup, that message is a bit misleading.
It’s true that Win10 doesn’t require drivers for the USB serial interface, but for DFU it does.
Hence a new driver setup that delivers the DFU drivers for mesh devices is in the works and undergoing testing.
For the time being you can use zadig to install the DFU drivers (libusbK) for mesh devices.
Definitely having issues with the Xenon to mesh connect via the Argon. Argon connects to wifi perfectly but
the process gets stuck on adding Xenon/connecting to the cloud and just blinks green most of the attempts. Xenon did go to cyan a couple of times and then flashed red and stuck on blinking green again. Had no problems with setting up 2 Xenons to the Boron though.
I’m having this issue too.
I have two argons and 4 xenons. The argons are fine and connected to the cloud but all 4 (2 paired with each argon) of my xenons are flashing green. Occasionally one specific xenon will intermittently flash a red SOS code and then reset and go back to the same thing so I haven’t had enough time to catch the actual code.
They worked at first from a couple of minutes (I used the “signal” button in the Web IDE.
Resetting them and/or the argon hasn’t really helped either.
Same for me.
Having this issue too, but only after flashing new custom application code on the Argon!
With the initial Tinker firmware on the Argon it worked, all my 3 Xenons could connected to cloud. After flashing custom code to the Argon, all Xenons started flashing cyan quickly.
Looks like an endless loop. After reseting one of the Xenons it starts flashing cyan quickly for ~20 sec, the 3 yellow flashes, then loop starts again.
Update: I could resolve the issue by disconnecting all devices and reconnecting them again. Looks like the Argon firmware update and restart left the 3 Xenons somehow in their own isolated network which could not join the Argon any more.
My network topology
I have Argons named Argon_1 and Argon_2.
My Xenons are named Xenon_1a, Xenon 1b, Xenon_2a and Xenon_2b.
Xenon_1a & Xenon_1b are paired to Argon_1 in one mesh network, and Xenon_2a & Xenon_2b are paried with Argon_2 in another mesh network.
So I tried flashing the tinker firmware on both of the Argons. That worked well enough for me to start flashing the tinker firmware to Xenons. Unfortunately as soon as I was done with Xenon_1a & Xenon_1b, Xenon_2a & Xenon_2b starting flashing green. I was able to use the “signal” option on Xenon_1a & Xenon_1b a couple of times until they starting flashing green as well.
I decided to try reconnecting Xenon_1a to the network as it’s been the most problematic of the three (It was the one that would occasionally flash the red LED code I mentioned) I used the buttons to factory reset it and now I’ve been siting at “Your Xenon is joining the mesh network” for at least 10 minutes now.
Over the course of writing this post Xenon_2a & Xenon_2b starting flashing cyan and I still haven’t gotten 1a to connect yet.
Update: I was able to get Xenon_1a & Xenon_1b reconnected and flashed the tinker firmware. Once that was done I began working on reconnecting Xenon_2a & Xenon_2b. While working on that Xenon_1a & Xenon_1b went back to flashing green. Xenon_2a & Xenon_2b were breathing cyan but went back to flashing green as I typed this sentence meaning they stayed connected for barely a minute.
Theiibusbk driver work Thanks to you for the zadig driver info for DFU setting. ScruffR, i notice other people are having problem with setting up a MESH with Xenon and Argon, Pairing Xenon with a phone take a little longer then normal. Pairing / Setup of Xenon So to check for version update I did run a particle serial inspect
and flash it in DFU mode it was a success but no change in the version number. How does one MAP the rc-25.bin to the information you see in particle serial inspect and what might be the purpose of factory location left empty ?
Folks, Xenons’ disconnecting from cloud and then fast flashing green is caused by a current bug whereby ARGON is allergic to your router.
I know this doesn’t seem to make sense.
“Why would the xenon’s have problems when the argon is breathing cyan?”
We don’t know but it is true. Try putting different routers between your existing router and the argon.
Particle is working on it.
I have a netgear R7000 and nothing else in my house has issues and I’m not going to go out and spend money on another router just to make these devices happy when literally nothing else in my house has a problem with them.
This is an issue that needs to be fixed on particles end.
And it will be. Soon. Just don’t ask for a firm date… “soon” is the best anyone will give you.
The most common Argon connection failure issue (which affects the Xenons behind it) is fixed in 0.8.0-rc.26. That should be out in the next day or two.
I’m always puzzled with the mapping of the internal version numbers to the device OS versions.
@rickkas7 usually has a lookup table for that, but I can never remember where
I just know that v324 should be 0.8.0-rc.25 and v325 is rc.26
The second part of your question: There is no purpose in having the factory location empty, but since there currently is no rock-solid version it’s little use to populate it with a known to be buggy version.
Once a stable version is locked down, I’d assume it’ll be placed there.
I know for the Spark Core there is a CLI command to flash a custom firmware image to the factory location.
I can confirm like others on the Forum that it most certainly is an issue with my Xfinity router. As I have a Raspberry Pi 3B+ as an AP to the same router. Setup the Argon to use that and then my Xenon was up and running in seconds after that Funny thing is, most of the time I always use that as an AP in development as it makes it easy to continue working if I move locations with a bunch of Photons but thought in this case I would make it simple and eliminate any possible issues being first gen devices and all. Damned if you do and damn if you don’t. lol.