Mesh stability and device brownouts

xenon
Tags: #<Tag:0x00007fe2240a3e40>

#1

I have got a mesh gateway based upon a Xenon in an ethernet featherwing and 5 Xenons battery powered presence detection sensors. I have been running this as a test using 1.4.1-rc.1 to see if the Mesh network now has long term stability to support a deployment in a pilot environment (but not my office). Alas, I am seeing two troubling behaviours and wonder whether anyone else can contribute their experience and/or suggested remedies.

  1. Problem with the gateway is that it will roughly every 24 hours but sometimes more frequently start to flash cyan very fast and will not reconnect to the cloud. The only solution is a manual reset which leads to it instantaneously reconnecting. This is a real showstopper for a pilot. I haven’t yet implemented a watchdog but kind of thought an ethernet connection would mean the device would not fall into such a corner condition.

  2. Problem with the end nodes is that to reduce power usage they are on a cycle of sleeping and waking either by RTC or by interrupt pin from the sensor. The device each hold an identity / asset number in a struct held in RAM. I have noticed that as the battery voltage goes below 3.7V the memory appears to get reset. Holding such data in EEPROM is the obvious solution. Just wondered if there is a clear level with LiPo battery voltage where RAM will not be retained on wake from sleep?


#2

Sorry that I don’t have any great ideas, but I wanted to share my experience with a similar size Mesh.
I’ve been testing a 5 Xenon Mesh with Argon Gateway for about 1.5 months.
Last night (8:00 PM Central 10/10/19) was the only time that my Argon and Mesh lost connection to the Cloud. It lasted for 20 minutes and the Argon finally re-connected and the Mesh healed itself.
I haven’t touched the Argon.

None of my Xenon’s are sleeping, but I’ve let a few of them drop down to 3.38 V during Li-Po Discharge and Solar Recharge trials and haven’t noticed any problems that low.

I’ve got a Xenon that’s due to finish-up a 3 week Li-Po discharge this weekend (5,000 mAH).
I’ll flash it with sleep code and Retained Variable to see how it works ~ 3.40 Volts this weekend.


#3

Thanks - interesting to hear of such long-term stability. I guess the big difference is the sleeping. I assume you are running with SYSTEM_THREAD(ENABLED)? I have been trying to use micro-sleeps literally 1 or 2 seconds between sensor reading cycles but have found that recently with 1.4.1-rc.1 it will not wake and reconnect on the first cycle - rather like the memory has been lost. I am figuring that my devices are actually restarting given the data they start to report, Using retained memory has the same issue as EEPROM - need to differentiate between a restart after flash and a restart.


#4

@armor, I’m noticing the opposite of what you are seeing with Retained Memory.

I’ve added this code (from ScruffR a year ago) to my Xenon’s test code.

const int LED = D7;
retained int x;
void setup() {
    pinMode(LED, OUTPUT);
    digitalWrite(LED, (x == 123));
    x = 123;
}

Xenon is running 1.4.0 with SYSTEM_THREAD(ENABLED)
The Li-Po Voltage is really low at 3.38 V, it just completed a discharge trial.

LED will turn ON after the first Reset.
Neither Sleeping System.sleep( {}, {}, 60); nor OTA Flashing will destroy the retained variable (turn LED off).
The only way to get the LED off is to completely remove all Power, which makes sense.
But I was surprised that OTA Flashing didn’t cause the retained int to be re-initialized.


#5

Thanks for sharing this. The Xenon is restarting, during which in setup() the device asset name [not the device name in Particle cloud terms] is being reset to a default. This is what I am seeing. Why is it resetting is the question - possible there is a memory leakage. I need to keep a track and see if this is the cause.


#6

Which name is that? How is it set? How is it stored?


#7

It is currently stored in a char array, not used retained or EEPROM.
char assetRef[11];

The reset is the real problem to solve!