Well-Known Event to LocoNet Sensor Mapping

[bakerstu]

There is a request to add well-known events for LocoNet sensor mapping. Based on my own review of the LocoNet Personal Addition document, this appears to require a 4096 size event space. It will be good if there is some confirmation that this is correct, and that there are no additional LocoNet well-known event mappings to consider before beginning the document updates.

[balazsracz]

On and Off requires separate events. Could you clarify if the requirements is 4096 bits (8192 events) or 4096 events (2048 bits)?

[balazsracz]

4096 bits / 8192 events for the basic loconet messaging.

[heikens]

LocoNet sensors effectively use 12 bit addresses, so up to 4096 sensors can be configured. This requires 8192 events.

[heikens]

Note that Digitrax makes a distinction between general sensors and turnout sensors. Each sensor type has its own opcode (message identifier) with a 12 bit address space. So, in theory, one could have up to 2048 turnouts, each with 2 position sensors (C/T), and up to 4096 general sensors, e.g. block detectors. This makes a total of 8192 sensors, requiring 16384 events.

In theory. I don't know if JMRI and Digitrax make this distinction. It could well be that both 4K sensor spaces overlap, but I think it is worth noting that the possibility of 8K sensor space exists.

[heikens]

The LCC-LN Gateway currently decodes/encodes 4 LocoNet messages types (excluding Traction Protocol messages):

• 0xB0 OPC_SWitch_REQuest (turnout)
• 0xB1 OPC_SWitch_REPort (turnout feedback)
• 0xB2 OPC_INPut_REPort (general sensor)
• 0xED OPC_IMM_PACKET (signal aspects only)
  • = decodes 3-byte Extended Accessory Decoder Control packet only =
  • NMRA packet reserved for transmitting aspect control to signal decoders
  • Format: {preamble} 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1
  • The most significant bits of the 11-bit address are bits 4-6 of the
  • second data byte. By convention these bits are in ones complement.
  • The least significant bits are bits 1-2 of the second data byte.
  • XXXXX is the aspect for a single head.

It would be great if we could also embed LocoNet signal decoder messages into LCC well-known event space. Doing so makes all entries in the 1024 line table superfluous and also makes the translation from LCC to/from LocoNet more transparent (faster).

[bobjacobsen]

The size of the space reserved for turnouts was set by the DCC space size. There's no corresponding common definition for sensors.

So it make sense to me to define e.g. a 16k sensor (32k eventID) space that vendors can map to exterior technologies (e.g. LocoNet, but also NCE AIUs, C/MRI inputs, etc) as they see fit.

[bakerstu]

• 0xED OPC_IMM_PACKET (signal aspects only)
  • = decodes 3-byte Extended Accessory Decoder Control packet only =
  • NMRA packet reserved for transmitting aspect control to signal decoders
  • Format: {preamble} 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1
  • The most significant bits of the 11-bit address are bits 4-6 of the
  • second data byte. By convention these bits are in ones complement.
  • The least significant bits are bits 1-2 of the second data byte.
  • XXXXX is the aspect for a single head.

@heikens As an FYI... We have updated the Event Identifiers [draft] standard today for the definition of the extended DCC accessory decoder address space in a way that is incompatible with the previous definition. We were unaware that anyone may have implemented this Event ID space, but it seems that you may have. We made an update for two reasons:

1. Harmonization with the latest RCN-213 and NMRA S-9.2.1 draft.
2. Fix the issue that the block of Event IDs was too discontinuous to use the producer/consumer identified "range", as it occupied only ~5% of the Event IDs in the range it spanned.

Reason 2 is an extremely good reason to make this change, and for this reason we intend to move forward after discussion with @bobjacobsen, @balazsracz, and @dpharris. However, we need to draw your attention to this for obvious reasons. You can find the updated definition here: https://github.com/openlcb/documents/blob/a7f4743bd413dd2493ea418d98e12ee392fb1900/drafts/EventIdentifiersS.pdf

[heikens]

Op do 30 mrt. 2023 19:41 schreef Stuart W Baker @.***>:

@heikens https://github.com/heikens As an FYI... We have updated the Event Identifiers [draft] standard today for the definition of the extended DCC accessory decoder address space in a way that is incompatible with the previous definition. We were unaware that anyone may have implemented this Event ID space, but it seems that you may have.

Thanks for the update. The Gateway doesn't implement this extended DCC accessory decoder Event ID space in any way (yet), so I think we're good. It merely decodes/encodes the 0xED LocoNet packets to/from the factory default Event ID space of the Gateway. The Event ID's may be modified by the user in the configuration table (CDI). It is good to know that a well-known event range for extended DCC accessory decoders is being defined. I wasn't aware of that.

[balazsracz]

The current proposal is to assign 2x 4096 long ranges.

• one range for turnout feedback. These would be encoded equivalently to the turnout commands. 2 bits per turnout. (four events)
• one range for sensors. This would be a linear range from 0 to 4095. We recommend for user interfaces to offset this by one (display as 1 to 4096).