What does xenon fast flashing green mean?

It seems the discussion from this thread

has continued here.

@peekay123 you may find this interesting.

From the above mentioned discussion, X1 is the only device now running in threaded mode and this has no bearing on the following.

I did some more testing last night with a heartbeat signal originating on X3 endpoint and counted on X1 endpoint, setup is roughly linear as follows. X=Xenon, A=Argon, X1 cannot hear X3 inferred because removing X2, X3 never connects to the mesh, constantly flashing rapid green with intermittent yellow/orange/red. Put X2 back and X3 immedately breaths cyan.

X1-----15ft----A-----20ft-----X2-----15ft-----X3

Heartbeat (X3) is once a second using mesh.publish which includes a count as data and flashing the blue LED. X1 counts the number of received publishes and displays this and the count from the published data on the OLED display.

Started running with all units breathing cyan last night around 9pm. At 5am this morning the display is no longer counting, all units are breathing cyan but X3 is no longer sending publishes but worse than that it is no longer running the application code as the blue led is no longer flashing. Code is Tinker with a 1 second millis() counter to publish and flash the LED. X1 is running the OLED example with the extra counter code, everything else is running Tinker.

This morning the display on X1 was still counting seconds but heartbeat counts had stopped. Seconds counter read 33115, a bit more than 9 hours, Heartbeat count was 25185 and heartbeat data was 25322. The discrepancy shows some hearbeat publishes were missed but the heartbeat data shows X3 stopped sending heartbeats after 7hrs and 2 minutes.

As a second weirdness last night, when I went to OTA flash X3 I kept getting failed to flash from the web IDE. I moved X3 to within a foot or so of the Argon and still nothing after 5 tries, no response from X3. I opened the phone app to try tinker, it said it was on line but no response from trying to use tinker, could not set any pin to read or write. I thought maybe I don’t have the right device. Opened the console and X3 is online, since it’s running the latest firmware I tried running diagnostics which came back success. Then I signaled the device, X3 responded and the console immediately showed device came online, strange since it didn’t go offline and passed diagnostics. Right after this OTA flashing was successful. This behaviour may be related to X3 no longer running the application code this morning but still showing as being online. Just tried now and it is also not responding to tinker. Tried diagnostics and it is passing as well. I’ll have to try the signalling option when I get home tonight so I can observe what is happening and see if that magically makes it start sending heartbeats again. I’ll report the results tonight.

The heartbeat code is as follows, simply added to tinker. I don’t think I’ve done anything to cause it to stop running after 7hrs. only added variables and a few lines to loop()

unsigned long heartbeatTimer = millis();
uint32_t heartbeatCounter = 0;
bool ledState = FALSE;

/* Function prototypes -------------------------------------------------------*/
int tinkerDigitalRead(String pin);
int tinkerDigitalWrite(String command);
int tinkerAnalogRead(String pin);
int tinkerAnalogWrite(String command);

/* This function is called once at start up ----------------------------------*/
void setup()
{
	//Setup the Tinker application here

	//Register all the Tinker functions
	Particle.function("digitalread", tinkerDigitalRead);
	Particle.function("digitalwrite", tinkerDigitalWrite);
	Particle.function("analogread", tinkerAnalogRead);
	Particle.function("analogwrite", tinkerAnalogWrite);
	
	pinMode(D7, OUTPUT);

}

/* This function loops forever --------------------------------------------*/
void loop()
{
    if (millis() - heartbeatTimer >= 1000) {
        ledState = !ledState;
        digitalWrite(D7, ledState);
        heartbeatCounter++;
        Mesh.publish("BunnyHop", String(heartbeatCounter));
        heartbeatTimer = millis();
    }
	//This will run in a loop
}

/*******************************************************************************
 * Function Name  : tinkerDigitalRead
 * Description    : Reads the digital value of a given pin
 * Input          : Pin
 * Output         : None.
 * Return         : Value of the pin (0 or 1) in INT type
                    Returns a negative number on failure
 *******************************************************************************/
int tinkerDigitalRead(String pin)
{
	//convert ascii to integer
	int pinNumber = pin.charAt(1) - '0';
	//Sanity check to see if the pin numbers are within limits
	if (pinNumber< 0 || pinNumber >7) return -1;

	if(pin.startsWith("D"))
	{
		pinMode(pinNumber, INPUT_PULLDOWN);
		return digitalRead(pinNumber);
	}
	else if (pin.startsWith("A"))
	{
		pinMode(pinNumber+10, INPUT_PULLDOWN);
		return digitalRead(pinNumber+10);
	}
	return -2;
}

/*******************************************************************************
 * Function Name  : tinkerDigitalWrite
 * Description    : Sets the specified pin HIGH or LOW
 * Input          : Pin and value
 * Output         : None.
 * Return         : 1 on success and a negative number on failure
 *******************************************************************************/
int tinkerDigitalWrite(String command)
{
	bool value = 0;
	//convert ascii to integer
	int pinNumber = command.charAt(1) - '0';
	//Sanity check to see if the pin numbers are within limits
	if (pinNumber< 0 || pinNumber >7) return -1;

	if(command.substring(3,7) == "HIGH") value = 1;
	else if(command.substring(3,6) == "LOW") value = 0;
	else return -2;

	if(command.startsWith("D"))
	{
		pinMode(pinNumber, OUTPUT);
		digitalWrite(pinNumber, value);
		return 1;
	}
	else if(command.startsWith("A"))
	{
		pinMode(pinNumber+10, OUTPUT);
		digitalWrite(pinNumber+10, value);
		return 1;
	}
	else return -3;
}

/*******************************************************************************
 * Function Name  : tinkerAnalogRead
 * Description    : Reads the analog value of a pin
 * Input          : Pin
 * Output         : None.
 * Return         : Returns the analog value in INT type (0 to 4095)
                    Returns a negative number on failure
 *******************************************************************************/
int tinkerAnalogRead(String pin)
{
	//convert ascii to integer
	int pinNumber = pin.charAt(1) - '0';
	//Sanity check to see if the pin numbers are within limits
	if (pinNumber< 0 || pinNumber >7) return -1;

	if(pin.startsWith("D"))
	{
		return -3;
	}
	else if (pin.startsWith("A"))
	{
		return analogRead(pinNumber+10);
	}
	return -2;
}

/*******************************************************************************
 * Function Name  : tinkerAnalogWrite
 * Description    : Writes an analog value (PWM) to the specified pin
 * Input          : Pin and Value (0 to 255)
 * Output         : None.
 * Return         : 1 on success and a negative number on failure
 *******************************************************************************/
int tinkerAnalogWrite(String command)
{
	//convert ascii to integer
	int pinNumber = command.charAt(1) - '0';
	//Sanity check to see if the pin numbers are within limits
	if (pinNumber< 0 || pinNumber >7) return -1;

	String value = command.substring(3);

	if(command.startsWith("D"))
	{
		pinMode(pinNumber, OUTPUT);
		analogWrite(pinNumber, value.toInt());
		return 1;
	}
	else if(command.startsWith("A"))
	{
		pinMode(pinNumber+10, OUTPUT);
		analogWrite(pinNumber+10, value.toInt());
		return 1;
	}
	else return -2;
}
1 Like

@Jseiler, Argon as a gateway has always given me issues. Your application is really testing two things - mesh and cloud connectivity. Cloud connectivity is setup by the Tinker Particle.function() calls and the fact that you are running defacto SYSTEM_MODE(AUTOMATIC).

One thing you can do is to NOT use String in your Mesh.publish() and instead use a char array string and snprintf():

char pub[50];
...
snprintf(pub, sizeof(pub), "%lu", heartbeatCounter);
Mesh.publish("BunnyHop", pub);

There are several issues with Argon that have been brought to Particle’s attention and they are working on solutions for the next RC release.

1 Like

Thank you @peekay123 for the advice and the example.

I didn’t think the cloud connectivity was an issue as the mesh should continue to work and certainly not stop the application code. Since the device (Xenon) is breathing cyan I’m thinking it’s not blocking the application code by trying to connect to the cloud in non-threaded mode. The blue LED should continue to flash. Do you think something is blocking the application code or it is crashed in some way? Breathing seems to indicate it is running something in an orderly fashion and not totally running amok.

I have to admit, I’ve been playing with particle devices and programming for 3 or four years now and I still haven’t wrapped my head around char arrays and pointers. They seem like simple concepts but somehow I always end up messing them up.

If I may ask, I’ve seen the aversion to strings in many places, is it because it’s code intensive or clock cycle intensive or fraught with other hidden dangers?

I’ll make the changes tonight and see if that makes a difference.

@Jseiler, Arduino Strings use dynamic memory allocation. The memory is allocated from a memory “heap”. As Strings get created and destroyed, they can leave fragments of free memory in the heap. C++ doesn’t “clean-up” these fragments. When memory is allocated, the allocator looks for a contiguous block of heap memory of the size requested. With the heap fragmented into lots of small free pieces, the allocator will eventually fail and the application will most likely fail with it.

2 Likes

@peekay123 thank you for the concise explanation. That makes total sense to me and gives me a reason to apply myself a bit more to learning and applying other methods.

1 Like

I am now having my first experience with a Xenon in fast blinking green. I put a Xenon endpoint one floor down in my office/warehouse. It is sitting in a room below my office which is about a distance of about 25 feet (~8 meters) but going through a 4" concrete floor with steel trusses and a drop ceiling (not to mention all the other stuff sitting around in my office. At first, it took about 30 minutes to connect to the mesh then it started breathing cyan and responding to heartbeats without any intervention… just had to be patient. Randomly, it stopped responding and when I go check on it, it had fast blinking green. I hit reset and it went to breathing cyan fairly quickly and was again responding to heartbeats. Then 15-17 minutes later, it stops responding again and sitting with fast blinking green. While it is responding, it has fairly good latency (<80ms) but fails to report intermittently. It seems that this issue might arise when an endpoint is on the fringe of the mesh network and may be subject to lost packets. I have a few external antennas (3 different models) on order but I won’t be able to test those until next week.

I think I’m going to put some serial debugging statements into my MarcoPolo code for the endpoint and hook it up to a laptop with serial monitor to see what’s going on.

I see the flashing green with the Xenons only being 10 feet apart line of sight with no obstructions or walls in between.

The external antennas will not work until the external antenna function is implemented per @rickkas7 statements a few days ago.

I have 2 extra Argon antennas here if they will work.

It appears patience is key during this debugging process.

I have had the flashing green as well except I didn’t push reset. It takes a few minutes, sometimes 10, 15, 20, or as @ninjatill said, 30 but it eventually, after flashing the intermittent yellow/orange/red, goes back to breathing cyan.

I have not seen breathing green yet, Has anyone else? Is that supposed to be particle.disconnect() with the mesh active?

For what I’m describing, patience isn’t working any more. In the screen cap, I have 2 places (circled in blue) where I reset the endpoint to get it back to breathing cyan. After a few minutes it drops to fast blinking green again. On this latest drop, it has been down for almost 2 hours:

image

I have Xenons freezing up with just a solid blue D7 led illuminated.

This is running your simple node code.

A manual reset will be required to get it going again.

Which indicates an OS lockup or that the loop() isn’t being processed. But the endpoint code is so simple. I don’t see how that’s happening. If anything should be locking up, it’s the gateway… which I though I might have too much processing going on in the subscribe callback function.

Here’s hoping for an RC26 release sooner than later!

1 Like

It appears from the picture that the status LED isn’t be serviced either, no breathing, flashing, nothing. That means the RTOS isn’t running anymore either. haven’t had that happen yet.

Yea, it’s completely frozen. Video showing this below.

2 Likes

I now have xenons breathing cyan indefinitely.
We have a few threads going on this - not sure what to do about that, but…

In another thread it was suggested that my (and other) routers might still be the issue so I found another one and put it in between and it works:

1 Like

That sequence of lights on a photon would lead me to believe there is a keys issue. Alas this is something completely different.

I’m not too concerned at this stage of the game, it is a new baby after all and like with all babies it will get better with age.

2 Likes

I too had the total lockup yesterday but on my argon gateway (running Marco from Marco Polo)

Resetting and it has been running longer since so it isn’t just time that kills it.

1 Like

So last night I was setting up another mesh network with an Argon gateway and a single Xenon endpoint. I completed the setup and left both devices with the default tinker firmware. This new net was sitting right next to an existing Argon on my original mesh network. All was well before I went to bed (all devices breathing cyan). When I awoke this morning, all devices in the house were blinking fast green. Both on the new mesh and the original mesh. I powered down the 2 new devices and brought them to my office for further testing. The original mesh has not yet recovered and is still blinking fast green.

On a brighter note, the mesh at my office was stable all night and is still beating away. The devices are now all on the same floor/level but I’m slowly moving the endpoints to adjacent offices farther and farther away from the gateway (as long as my colleagues provide me a vacant USB port for power.) I think I’ll start another thread for “Mesh Distance/Range Testing.”

Getting home last night my Xenon with the heartbeat was locked up breathing cyan, the heartbeat light was stuck off. I made the changes @peekay123 suggested and reflashed the new code. All was well for about 3 hours when my Argon suddenly started flashing green followed by the 3 Xenons. The flashing green went on for 2 hours until I finally reset the Argon. Interestingly the heartbeat across the mesh continued normally, I guess indicating that cloud connection was gone but the mesh was healthy. Finally reset the Argon and everything was breathing cyan again.

Until this morning, everyone is breathing cyan but the heartbeat is gone. The heartbeat Xenon is breathing cyan but the application has stopped running with the blue LED stuck on. The heartbeat Xenon ran for 11hrs and 38 minutes before locking up. During that time 14889 heartbeats were generated and 40063 made it across the mesh for a loss of 1826 heartbeats. Setup is still the same as before.

I’ll get rid of the tinker portion of the code tonight and just flash the heartbeat code and see how that goes.

@peekay123, if I just want this to be a mesh only test should I set all devices to SYSTEM_MODE(MANUAL) and then manually connect the mesh or is the mesh still automatic I didn’t see anything in the documentation regarding system modes and mesh connectivity.

Also I’m not sure if the “Assisting Device” is only to add Xenons to the mesh or if it’s critical to the mesh itself. By that I mean if I turn off the Argon I used for the “Assisting Device” will the rest of the mesh fall apart? I realize cloud connectivity disappears if the Argon disappears but for my use case at the moment I don’t need cloud except for OTA flashing.

1 Like

From experience not documentation, the “assisting device” is only used for information during setup. If you turn off argon the mesh stays alive.

1 Like

@RWB Did you resolve your fast flashing green? By using a different router? If so, which worked and which didn’t?