Well-known event ID for brownout

[balazsracz]

We should allocate a well-known event ID that bus-powered devices can produce that signals that they have experienced a power-supply related incident, such as a brownout.

This can be helpful for end-users in understanding certain types of issues with cabling and in particular with too long cables, too weak power supplies, or instability of power supplies during startup.

[balazsracz]

Based on recent discussions, we should make two event IDs: 1) Power supply voltage dropped near the limit - 01.00.00.00.00.00.FF.F0 This would be produced e.g. on the CAN-bus powered node if the input voltage is below 7.5V (the standard minimum). 2) Power supply voltage dropped below the limit - 01.00.00.00.00.00.FF.F1 This would be produced when the input voltage had a trip below the necessary minimum for correct operation of the node (this generally means the node has suspended operation and the voltage has then recovered).

These are automatically routed event IDs.

I plan to add code to JMRI that listens for these event IDs. When a node has produced it, then JMRI will print in red letters a message like "Not enough power! <LCC/OpenLCB> board 01.02.03.04.05.06 'West Bakersfield Jct' had its power supply voltage drop near/below the limit at 5:50pm."

[balazsracz]

I would propose the following text:

1. "Supply voltage dropped below minimum required by the standard."
2. "Supply voltage dropped below minimum required by node operation."

[kiwi64ajs]

Hi Guys

On 24/02/2019, at 11:55 PM, Balazs Racz notifications@github.com wrote:

I would propose the following text:

"Supply voltage dropped below minimum required by the standard." "Supply voltage dropped below minimum required by node operation.” Hmmm. I’m good with those.

It would be useful to know the actual voltage the node is seeing, but we don’t support any analog value measurement that I’m aware of.

I wonder if this would make sense to add to any of the other reports or maybe come up with a new node runtime information and stats type packet/stream/datagram.

The Clipsal C-Bus Automation System I have in my house shows the voltage each node is seeing on the C-Bus, as that powers some of the devices electronics. So you get a good idea of the voltage drop along the Cat5 cable it uses.

Alex

[balazsracz]

Node manufacturers may add components to their CDI that show operational measurements. In this aspect it is possible to show voltage measurement today. CDI allows referencing a segment that is read-only. The XML would store the description and the read-only segment would be consulted for the values. The existing standard allows this, and in fact I have used it to display a booster's actual current consumption.

This allows human-readable but not standardized (centralized) way to display voltages.

To make it standardized, a lot more effort needs to be put into; a new datagram protocol needs to be proposed and standardized, then added to the PIP, then some UI be implemented that queries all nodes' operating voltage and shows to the user. That's probably a lot more work than the problem is worth.

[atanisoft]

Can we add a third event ID possibly, one for "node restarted from brownout"? Or would this be covered as a normal node startup?

The reason I ask is that on the esp32 it has built in brownout protection and it will reboot the mcu when triggered and there is a flag set on startup that indicates why the mcu restarted (normal startup will have a similar reason as well). My thinking is that maybe it makes sense to advertise that node X crashed due to brownout and is recovering. It may not always be possible to post an event before a crash (it all depends on the hardware/firmware)

[balazsracz]

That's exactly the use case of one of the two events.

-- Sent from my mobile device

[atanisoft]

Sorry I must have missed that point. Thank you for clarifying it.

In the case of the esp32, when it reboots due to brown out, would it send the typical node startup frames (alias, etc) and then produce event 2 (FF.F1) early in operation (ie after apply_config callback)?

[balazsracz]

Sorry I must have missed that point. Thank you for clarifying it.

In the case of the esp32, when it reboots due to brown out, would it send the typical node startup frames (alias, etc) and then produce event 2 (FF.F1) early in operation (ie after apply_config callback)?

yes

[dpharris]

Would this be a good use for a well-known event range, encoding the voltage?

On Sun, Feb 24, 2019, 03:03 Alex Shepherd <notifications@github.com wrote:

Hi Guys

On 24/02/2019, at 11:55 PM, Balazs Racz notifications@github.com wrote:

I would propose the following text:

"Supply voltage dropped below minimum required by the standard." "Supply voltage dropped below minimum required by node operation.” Hmmm. I’m good with those.

It would be useful to know the actual voltage the node is seeing, but we don’t support any analog value measurement that I’m aware of.

I wonder if this would make sense to add to any of the other reports or maybe come up with a new node runtime information and stats type packet/stream/datagram.

The Clipsal C-Bus Automation System I have in my house shows the voltage each node is seeing on the C-Bus, as that powers some of the devices electronics. So you get a good idea of the voltage drop along the Cat5 cable it uses.

Alex

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/5#issuecomment-466763716, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg4ShX8lQDOzWofO2vbUsOqam1dWzzMks5vQnGYgaJpZM4MUumN .

[bakerstu]

Balazs wrote:

1. "Supply voltage dropped below minimum required by the standard."
2. "Supply voltage dropped below minimum required by node operation."

David wrote: Would this be a good use for a well-known event range, encoding the voltage?

Right now, the draft standard calls these two events:

1. "Imprecise brownout detected"
2. "Precise brownout detected (CAN Physical Layer 7.5V)"

The idea being that the "precise" brownout event only applied to CAN, since other physical layers might have different power schemes. Now, I'm wondering if I could propose a different wording:

1. "Imprecise brownout detected"
2. "Precise brownout detected (byte 8 determines the voltage threshold, less than or equal to, in units of 0.25V)

We would reserve a new range of Well-Known event ID's:

01.00.00.00.00.00.FC.00 - Imprecise brownout detected 01.00.00.00.00.00.FC.01 through 01.00.00.00.00.00.FC.FF - Precise brownout detected (<= 0.25V to 63.75V)

We would then remove the CAN specificity from the precise brownout event range. A node would of course not be required to support either of these, but could also support one or both of these. The TN would provide the CAN Physical Layer as an example use of the precise brownout detect starting at 7.5 volts, following the CAN Physical Layer standard. A note would be added that other physical layer standards might use different thresholds for precise brownout detect.

Thoughts?

[balazsracz]

Encoding the voltage seems like an overkill. Event range is also not super helpful because it is unnecessary UI complexity. The node documentation can describe it if a node uses a different "standard" threshold, but this should only be the case when there is no physical standard that applies to it.

So I would prefer not to define in the event identifier what the voltage threshold is. This is why I suggested the new phrasing.

[bakerstu]

Balazs,

I don't particularly like your phrasing. Could we change it to:

1. "Brownout detected below minimum required by standard"
2. "Brownout detected below minimum required by node"

[balazsracz]

How about "Power supply brownout detected [...]". with the same endings.

[bakerstu]

Works for me. I'll make the change.

[bakerstu]

I've updated the S & TN in specs/drafts/ for EventIdentifiersS/TN. Please review.

[pabender]

Balazs,

Sent from my iPad

On Feb 23, 2019, at 11:50 AM, Balazs Racz notifications@github.com wrote:

Based on recent discussions, we should make two event IDs:

Power supply voltage dropped near the limit - 01.00.00.00.00.00.FF.F0 This would be produced e.g. on the CAN-bus powered node if the input voltage is below 7.5V (the standard minimum). Power supply voltage dropped below the limit - 01.00.00.00.00.00.FF.F1 This would be produced when the input voltage had a trip below the necessary minimum for correct operation of the node (this generally means the node has suspended operation and the voltage has then recovered). These are automatically routed event IDs.

I plan to add code to JMRI that listens for these event IDs. When a node has produced it, then JMRI will print in red letters a message like "Not enough power! <LCC/OpenLCB> board 01.02.03.04.05.06 'West Bakersfield Jct' had its power supply voltage drop near/below the limit at 5:50pm."

Let me ask these question....

What is the implication to the network if a node is experiencing a brownout?

Does the node experiencing the brownout have to reset completely or is some state saved during the brownout?

Does the node know how long the brownout lasted?

Does the node have any idea what traffic was missed during the brownout?

I really think the proper reply to a brownout is for the node to reset just like it was powered down or unplugged from the network.

Paul

[dpharris]

Yes, likely it is overkill. We can have both without problems. The Events proposed work fine.

A range would require additional software to allow display of voltage ... can come later if there is a pressing need --- unlikely.

David

On Sun, Feb 24, 2019 at 8:32 AM Balazs Racz notifications@github.com wrote:

Encoding the voltage seems like an overkill. Event range is also not super helpful because it is unnecessary UI complexity. The node documentation can describe it if a node uses a different "standard" threshold, but this should only be the case when there is no physical standard that applies to it.

So I would prefer not to define in the event identifier what the voltage threshold is. This is why I suggested the new phrasing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/5#issuecomment-466792096, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg4SjYNASW9Asv075BkeFfwkIP3Ulzrks5vQr6ygaJpZM4MUumN .

[dpharris]

This will depend on the node ... it can only do what it can do. An unconnected or powered-down node can't follow traffic, period. If it is disabled by the brown-out, ie cannot continue processing messages, it may have outdated info, and it will have to follow the protocols including the InitializationComplete message, announcing Consumer and Producer events interest, and sending the new event if wanted. CAN nodes would have to obtain an alias.

David

On Sun, Feb 24, 2019 at 10:23 AM Paul Bender notifications@github.com wrote:

Balazs,

Sent from my iPad

On Feb 23, 2019, at 11:50 AM, Balazs Racz notifications@github.com wrote:

Based on recent discussions, we should make two event IDs:

Power supply voltage dropped near the limit - 01.00.00.00.00.00.FF.F0 This would be produced e.g. on the CAN-bus powered node if the input voltage is below 7.5V (the standard minimum). Power supply voltage dropped below the limit - 01.00.00.00.00.00.FF.F1 This would be produced when the input voltage had a trip below the necessary minimum for correct operation of the node (this generally means the node has suspended operation and the voltage has then recovered). These are automatically routed event IDs.

I plan to add code to JMRI that listens for these event IDs. When a node has produced it, then JMRI will print in red letters a message like "Not enough power! <LCC/OpenLCB> board 01.02.03.04.05.06 'West Bakersfield Jct' had its power supply voltage drop near/below the limit at 5:50pm."

Let me ask these question....

What is the implication to the network if a node is experiencing a brownout?

Does the node experiencing the brownout have to reset completely or is some state saved during the brownout?

Does the node know how long the brownout lasted?

Does the node have any idea what traffic was missed during the brownout?

I really think the proper reply to a brownout is for the node to reset just like it was powered down or unplugged from the network.

Paul

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/5#issuecomment-466802261, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg4SnISc1sa6Xtmsx3vFDQSyJMSpwnTks5vQti_gaJpZM4MUumN .

[balazsracz]

Paul,

I really think the proper reply to a brownout is for the node to reset just like it was powered down or unplugged from the network.

this is an orthogonal question. Yes the node quite likely needs to reset or reinitialize, and then produce the event. This is all written down in the TN. The goal of the event is not to get out of being standards compliant but to give an indication to the user that they wired up the network in an incorrect way that does not supply enough power.

Balazs

[balazsracz]

Fixed by https://github.com/openlcb/documents/commit/116975244642b8d854a7bd1cdf65b2b49361ec41 (it is in draft, not yet adopted).