Thanks for that! I’ll give it a go.
Nice to see a quick reset fixes it quickly.
I tested your reset code on the Boron & Xenons and after resetting the Boron all Xenons will no longer respond to Borons messages. So I called the reset function on the Boron to reset the Mesh network on the Xenons but it does not cause the Xenons to come back online.
I can see the Xenons reconnect to the Mesh network after running the reset function so it is working but it’s not getting the Xenons to respond to the Borons request. I’ll have to try some other network reset functions to see which is effective.
Calling System.reset(); to reset all Xenons does cause them all to instantly reconnect so at least we know that does work and that the MESH network stays up which allows us to call this function via a Mesh Publish event.
That's right. What is the Boron's request that the Xenons don't respond to?
It’s this:
Mesh.publish(“Marco”, msg);
I’m running the Marco Polo Mesh test code.
It’s weird because the Mesh is avaliable and working when the Xenons do not respond.
I tried disconnecting the Particle cloud and reconnecting but that did not help them start responding like the System.reset() does.
Ok, it looks like the Mesh.publish is getting through. I don’t have time to go through that code but it looks like a GPIO pulled high changes what the code does with sleep modes, replies etc? May be worth looking into.
I’m using the version without sleep modes.
I’m not sure what causes the issue and why a reset fixes it but there is something going on. More testing needed.
So, here I am, back in the “big smoke”. Only about 4km from the nearest Telstra tower.
Ran setup on the “virgin” borons - flashed the “switch to Telstra on external SIM” code - then flashed (via USB) “blink” and then OTA my Trigger code. All good.
On the other borons I ran setup again - then flashed the “switch to Telstra on external SIM” code - then flashed my Trigger code OTA.
One of the borons would not flash OTA - I had to go to DFU and flash via USB - but all good - I have all my borons on external SIMs via Telstra.
…now all I have to do is finish soldering-up all the featherwing triplers, and install. Then I cna start looking at installing the xenons in the feeders and get the real magic happening.
Very excited.
I think the most important issues to be aware of here (in my situation at least) is that the setup process (and “my bad” for not picking up on the Vodaphone in Australia issue) is that the set-up process seems very sensitive to a) high-latency links (eg. satellite); and b) it seems very hard to switch carriers and/or internal/external SIMs if you can’t talk to both carriers reliably during the process.
But that’s OK - it’s new (and exciting) kit and I’m having a ball with it!
I’ll try and post a more complete article on what I’m trying to do once I can get the triggers I’ve got installed out in the field - because “trip wires” just aren’t a reliable method of catching pigs…
Clearly:
Yup, she’s just crawled under he trip wire and is enjoying a tasty snack!.
4 Likes
Make sure you put the code below on the Borons and Xenons so you will be able to reset the Xenons out in the field should they stop responding to Borons request. It’s helping bring Xenons back online after a reset or firmware flash of the Boron during my testing.
I put this on the Boron
int handleReset(String command) {
Mesh.publish("reset", "ok");
return 1;
}
void setup() {
Particle.function("reset", handleReset);
}
and this on the Xenons
void handleNeedReset(const char *event, const char *data) {
System.reset();
}
void setup() {
Mesh.subscribe("reset", handleNeedReset);
}
7 Likes
Will do, thanks. 
I found my 8 Xenons not responding to the Mesh publish request the Boron has been sending out and the Xenons had been responding to over the last 2 days.
I called the system reset function on the Boron which triggered the System Reset on the Xenons successfuly and then the Xenons successfuly started responded to the Boron again without needing to touch any of the devices.
2 Likes
That’s a useful work around. I think I’ll add that to my code.
1 Like
See if you can think up a way to automatically call the reset function when the Boron stops getting responses from the MESH nodes.
My 2 cents. I have an Electron and Boron sitting withing a foot of each other, both running particle sim’s. The Electron, rarely if ever drops the cellular-in fact I cant remember the last time it did. The Boron drops more frequently and when it does, IF it connects again, it takes forever. That’s what brought me here, searching for why the cellular radio in the Boron seems to work so poorly-as I watch it blinking green for the last 20 minutes while the electron breathes cyan happily. They are running different versions of the same firmware, specifically for the respective device.
1 Like
i think a good bit of it is where you are in relation to a cell tower that has adequate Cat M1 coverage. just a hunch. for instance on the east side of the city i live in there is no luck in a 2G electron connecting at all. never tried the boron. yet in the central downtown area the 2G electron has a darn good connection 95% of the time and the boron always connects within 15 secs and has never disconnected except when power has been disconnected. go figure. others have posted bad luck at their primary location, get in the car/truck with the boron and it finds a tower and connects.
1 Like
Is your Electron an LTE model, or 3G (or maybe even 2G)? If your Electron and Boron are on different networks, then you can’t assume that the cellular radio is the problem.
The issue here was the carrier here in Australia for the Electron’s was Telstra - the Borons are trying to use Vodaphone (as noted above). I only get sporadic coverage from Vodaphone - so I switched to external (Telstra) SIMs from M2MOne. All good.
I will note however that the Borons are still more prone to disconnect and take notably longer to reconnect compared to the Electrons I have in the same locations. Pressing the reset button or calling System.reset() makes them reconnect immediately. Given the “time critical” nature of my application I’ve elected to call System.reset() after 60 seconds of disconnected state (while trying to force Particle.connect()).
(The pigs eventually eat their fill you see - so I need to be able to trigger the trap without delay 
)
And just because I’m paranoid I’ve added a scheduled restart every 4 hours and an application watchdog.
Seems to have fixed my problem.
4 Likes
Same here, and both are 3G with great coverage. I am now running Boron standalone without Mesh for comparison.
Hey Ryan,
is this being tracked somewhere as a bug or something? I wanted to know if Particle engineers had the chance to look at it and what was their say.
Thanks!
Yes, I let @BDub know about this a month or so ago and he understood what was going on.
I’m not sure if this has been fixed yet or not with the newer firmware releases.
1 Like
Hi Brett @BDub ,
is this being tracked somewhere as a bug or something? I wanted to know if you guys had the chance to look at it and what was your thinking about it (and potentially when a fix could be released).
Thanks!