SW: Need to visually differentiate BCF node .bin files on node

[erikwelsh]

Currently, all the BCF bin files have the same LED pattern on the node. To make it easier to understand what bin file is programmed on each node, please change the LED pattern for each bin file.

Given that there are 6 LEDs on a node, you could binary encode which bin file it is using the LEDs. For example:

gateway: 000001
sensortest: 000010
greybus: 000011

or you could do a one-hot pattern or something else. When you have updated the bin files, please document what each LED pattern means.

[jadonk]

I'd like to assign functional meaning to each LED and try to infer the running application from that.

There is a total of 6 LEDs. I believe they are in the order of CHG, 2.4G, 900M, 3V3, LED1 and LED2.

CHG (A)

The mode of this cannot be changed. It is on when an attached battery is being charged.

LED 2.4G (B)

This is the only one available on CC1352. I'd like to use it for things where low-overhead and low-latency matter. I think having it on when some kind of "link" is established and to blink when there is some data transfer. The easiest place I know to hook to is when the TX is active, but I don't want to miss blinking when we have noticed some RX. I may hook in TX initially and RX later. I am not aware of any "link" establishment for IEEE802.15.4 so this will require some research.

900M (C)

Now

I've been using this LED to reflect the UART mux between the MSP430 and CC1352. I might want to add blinking in the case of data transfer. Currently, if gateway is functional, this LED should be on. This doesn't say if gateway is waiting for a connection over USB.

Proposal

I think I'd like to add to the CC1352 something that says it is actively looking for a gateway connection. In the future, this will all be modes rather than different firmware loads. So, if the firmware is not acting as a node and is waiting for a host driver connection to act as a gateway, this LED should toggle slowly based on commands from the CC1352. If the UART mux is flipped to the MSP430, it should turn it on most of the time with short/fast blinks in the case of data transmission either way (not ideal to not have both TX/RX LEDs, but it is what we have. It would not be possible to distinguish between gateway (acting as bcfserial w/o the USB connection) and node operation via this LED.

3V3 (D)

When there is power, this is on. No way to change that.

LED1 (E)

Now

I've been using this for MSP430 debug to indicate an established UART connection (either passthrough or HDLC mode). This would typically be on only when there is a USB connection.

Proposal

Both sensortest and greybus could use this LED. I'll need to think about what they might do with it and how to make up for the loss of debug information for HDLC, but, for now, they can simply turn it on and not have gateway or bcfserial turn it on.

LED2 (F)

Why don't we use this to reflect greybus activity? If blinking slowly, it could mean looking for activity, meaning this is only used in the greybus build. Steady-on could reflect some higher-level activity, such as once a manifest has been fetched. Either after some time-out or if there is some other kind of disconnection event, it could go back to the slowly blinking state. No other firmware load should turn this LED on.

To simplify implementation, the MSP430 should perform the slow-blink operation. Due to the I2C latency, we should likely avoid any quick updates based on individual packets.

Summary

All of this might result in a lot of blinking lights. I think there is a lot of information to consider and dynamic status will help users tell what is going on, given that we have no display for status. Do you think this is overwhelming, or can this be a workable plan?

[jadonk]

Below is what I just proposed, but I'm concerned it doesn't have separate sensor status indication for both sides of the connector.

@Vaishnav98 @erikwelsh - What would you think if I combined Greybus/Sensor into one indicator, but separate for each like:

1/2

1 or 2 on
: Sensor identified and Greybus connection established

1 or 2 off
: No sensor identified and not seeking Greybus connection

1 or 2 fast blink
: Greybus or other sensor traffic for corresponding sensor

1 and 2 fast blink
: Greybus or other sensor traffic for internal sensor

1 and 2 slow blink
: Seeking a Greybus connection

1 or 2 slow blink
: Sensor error on corresponding header

Not too complicated? Give the right information?

--

LED definition

These definitions are proposed with the mindset of giving end-users high-level functional
status indication of the devices and nodes. It seeks to avoid having the status of any
one LED being required to interpret another, which has the undesirable effect of limiting
the amount of information that can be conveyed, but should simplify interpretation.

Single letter abbreviations are provided in case we can put these on a silkscreen on the
side of the case.

Positions

TBD - I need to determine for sure where each LED is on the board and make it clear in this document.

Functions

C (Charging)

On
: Attached battery is being charged

Off
: Charger is not active

L (Link)

On
: IEEE802.15.4 SubGHz connection established (RX occurred recently)

Fast blink
: IEEE802.15.4 SubGHz data TX or RX

Off
: IEEE802.15.4 SubGHz traffic not seen for some timeout period

Slow blink
: IEEE802.15.4 SubGHz connection error detected

H (Gateway/Host)

On
: Device is in gateway mode

Fast blink
: USB UART data traffic over MSP430

Off
: Device is in node mode

Slow blink
: MSP430 is looking for a gateway connection (USB active), but the CC1352 has not set the MSP430 clearly in gateway or node mode

P (Power)

On
: Device is powered

Off
: Device is not powered

S (Sensor)

On
: TBD

Fast blink
: Sensor traffic

Off
: TBD

Slow blink
: Sensor error

G (Greybus)

On
: Greybus connection is active

Fast blink
: Greybus traffic

Off
: Greybus connection is inactive

Slow blink
: Greybus connection being attempted, but not completed

[jadonk]

OK, might be useful to read this history, but I updated my proposal: 49c5539. Please review LEDs.

[jadonk]

Just updated LEDs.md to reflect which LED would get which function.

In the below, note the only LED easy to access from the CC1352 is 2.4G (DIO_18), which I am suggesting should be used as a link indicator.

LED	Signal	Status	Indication
C (Charging)	CHG (no S/W control)	On	Charger active
		Off	Charger not active
L (Link)	2.4G (DIO_18 on CC1352)	On	Radio RX within timeout
		Fast blink	Radio active
		Off	Radio RX inactive (timeout)
		Slow blink	Radio error
U (USB)	900M (P6.1 on MSP430)	On	Device in gateway mode
		Fast blink	USB active
		Off	Device in node mode
		Slow blink	Seeking USB (gateway) connection
P (Power)	PWR (no S/W control)	On	Device powered
		Off	Device not powered
1 (mikroBUS 1)	LED1 (P6.2 on MSP430)	On	Identified and connected
		Fast blink (w/o 2)	Active
		Fast blink (w/ 2)	Internal sensor active
		Off	Inactive
		Slow blink (w/o 2)	Identified, but not connected
		Slow blink (w/ 2)	Seeking Greybus connection
2 (mikroBUS 2)	LED2 (P6.3 on MSP430)	On	Identified and connected
		Fast blink (w/o 1)	Active
		Fast blink (w/ 1)	Internal sensor active
		Off	Inactive
		Slow blink (w/o 1)	Identified, but not connected
		Slow blink (w/ 1)	Seeking Greybus connection

[jadonk]

Greybus node - U off,1/2 slow/fast/on (not off)
Gateway - U slow/fast/on (not off), 1/2 off
Sensortest - U off, 1/2 off