How to flash Xenon with "SYSTEM_MODE(MANUAL);"

Hardware
1

I have written multiple times about the problems of Xenons reliably re-connecting to a Boron/Argon when the Gateway is reset but have not received any good answers leading me to believe that the initial mesh firmware is buggy. Obviously losing Mesh connectivity and not reconnecting prevents this hardware from becoming a serious platform.

Due to the lack of input, I used SYSTEM_MODE(MANUAL); and a Mesh.Connect statement to establish the initial connection which I am realizing is not a good solution. My challenge is aggravated because I need to test the system outdoors at a remote site an hour away.

How do I update the Xenon firmware in this case? I recall on the Photon, pressing its two buttons then releasing one put it in a mode to receive firmware through the cloud. How would this be done in the case of the Xenon?

Thanks in advance.

2

I hear you that there are issues with xenons connecting successfully to a gateway when a user firmware is OTA-ed to the gateway.

Would like to understand what you plan to test at the remote site and whether there’s another workaround instead whilst waiting for deviceOS improvements.

3

Thank you @kennethlimcp for your prompt response and willingness to help.

My most immediate concern is to flash my Xenon at the site with my new firmware which will give me better debugging.

How long is the delay to place in the loop() section:

if (Mesh.ready()); ?

I want to place this in the loop section in case of mesh disconnection. Currently, I have a relay which cycles power to the system once a day …

4

if (Mesh.ready()); doesn’t really do anything useful.

I’d rather go with something like waitFor(Mesh.ready, 30000)

5

I am doing some testing and it is not a trivial situation that can be resolved using SYSTEM_MODE(MANUAL); cos the issue lies in the gateway.

  1. Are you connecting the Xenon to equipment in the field?
  2. Are you trying to test purely range/connectivity between the position of Gateway and Xenon deployed?

These two will give me clue of what you are really planning to test.

If you are only flashing to xenons and not change to the Gateway, i don't see why you are having concerns about: (not saying the bug is ok to have)

Xenons reliably re-connecting to a Boron/Argon when the Gateway is reset

6

Thank you @ScruffR, will change it but the question is what is the delay to check if Mesh is connected? Of course I can just check every few minutes rather than on each loop iteration.

Also, wouldn’t Mesh.ready require a Mesh.connect()?

7
  1. The Xenon is connected to a sensor with a refresh rate of over 100Hz. After data is accumulated by the Xenon, it is then sent to a Boron which collects (in the future) from 3-6 Xenons.

The Xenon updates its Gateway once every 5 minutes.

  1. The spacing between the Xenon and the Boron is now only a few feet. I am trying to setup a system which is “forgiving” of OTA updates to both Gateway and attached mesh devices. I am however “almost” happy with the Boron firmware.

==============================================

Do you recommend I avoid SYSTEM_MODE(MANUAL) in my case?

8

The spacing between the Xenon and the Boron is now only a few feet. I am trying to setup a system which is “forgiving” of OTA updates to both Gateway and attached mesh devices. I am however “almost” happy with the Boron firmware.

If this is your primary concern, it sounds better to have this flagged up as an issue to be looked into for the firmware team.

I will not be performing OTA updates during the on-site testing (not because it is not reliable now), but instead, ensure that the use case of collecting data and publishing data works reliably.

But, just my opinion based on field testing that I do quite a fair bit.

Based on my testing where i OTA to an Argon every 30 seconds, this code allows a Xenon to connect back reliably, but not 100%. Read, not 100%, maybe 99%

SYSTEM_MODE(AUTOMATIC);

unsigned long cloud_check_time = 0;

void loop()
{
	if (!Particle.connected() && millis() -  cloud_check_time > 5000) {
		Mesh.disconnect();
		delay(1000);
		Mesh.connect();
		delay(1000);
		Particle.connect();

		cloud_check_time = millis();
  	}
}
9

I will take 99% :slight_smile:

OK, I will avoid SYSTEM_MODE(MANUAL) in my case but my question is what is the latency in putting your code in the loop() section? I am looking for incidents lasting about 100 ms.

==============================
But how do I update Xenon firmware if it is no longer connecting to the cloud?

10

Not sure what you mean here. The code above will ensure that the Xenon always try to have :particle: :cloud: connectivity.

I am looking for incidents lasting about 100 ms.

Tough question. I don't even know how fast you can have an empty loop() function running to begin with. You might need to measure this alongside exploring threading.

11

I mean the Xenon at the site is not connected to the cloud (just the mesh with the Gateway) because I do not have Particle.connect in my code. So how can I flash new firmware to it?

Do you also recommend not using?

SYSTEM_THREAD(ENABLED);

cloud_check_time > 5000) {

Sorry, I missed that you are not checking on each loop iteration.

14

Hello @kennethlimcp

You helped me with the code below and it has been very useful:


   if (!Particle.connected() && millis() -  cloud_check_time > 5000) {
    {      
		Mesh.disconnect();
		delay(2000);
		Mesh.connect();
		delay(2000);
		Particle.connect();

		cloud_check_time = millis();
  	}

In my application, I will have multiple Xenons connected to a Boron. I really do not care if the Xenons connect to the cloud (actually to save on data, eventually I do not want them to connect to the cloud).

So, should I change the code in the loop section to:

if ((!Mesh.ready() && millis() -  mesh_check_time > 5000) {
		Mesh.disconnect();
		delay(1000);
		Mesh.connect();
		delay(1000);
		mesh_check_time = millis();
  	}
15

Sounds good

16

Thank you @kennethlimcp

If the gateway Boron loses cloud connection, does that also mean that the mesh disconnects?

17

If you are using purely SYSTEM_MODE(AUTOMATIC) without messing around with Particle/Mesh. (connect/disconnect), there should be no with mesh disconnecting.

1 Like