EmCan defines all extended data frames to node address 0 as broadcast frames, and leaves their definition up to the application. All possible opcodes 0-1023 are for application use. The broadcast frames defined by this application are listed in this section. Nodes should ignore broadcast frames with opcodes not listed here. The valid MorBus broadcast opcodes are:
Turn off and power down to the extent possible, but still retain the ability to respond to the ON command. For example, DCC controllers must turn off track power completely. The exact implementation is device-dependent, but it should be assumed that the overall user intent is to "turn off" the entire layout, but that this level of off is reversible with the ON command.
All devices must disable their outputs or go to their most benign state possible. DCC controllers must send a STOP command, preferably several to guarantee at least one is received by all rolling stock. Devices otherwise keep their EmCan state and continue communicating over the MorBus.
This command is generally sent in response to a user panic action. The user may see something that could cause physical damage if operation continues and feels there is no time to stop individual devices. It should be assumed the user intention is to stop everyhing NOW. It is permissible for some re-initialization to be required before normal operation can resume.
Causes a DCC packet to be sent to all DCC outputs. The ADR and DAT bytes will be the packet bytes. The complete packet will contain the preamble, the 0 start bit followed by the ADR byte, a 0 start bit preceeding each DAT byte, another 0 start bit followed by the error detection byte, and then the 1 packet end bit. The error detection byte is automatically generated and not included in the DAT bytes.
Ctrl is a control byte and contains multiple fields. The low 5 bits indicate the maximum number of times the packet should be sent over the DCC bus minus one. For example, a value of 5 will allow the packet to be sent up to 6 times. The minimum wait time of 5 ms between the end of one packet and the beginning of the next to the same address as per the DCC specification must be observed by the DCC controller. If a packet takes 6 ms to send, for example, then it can be repeated no more often than every 11 ms, although it may be sent less often depending on policies of the controller and how many other outstanding packet requests there are. Since the maximum value that can be expressed in the low 5 bits of ctrl is 31, the total number of times to send a packet can be at most 32 as expressed by this field.
The high bit of ctrl specifies that the packet be repeated indefinitely (with appropriate wait between transmissions). This is only allowed for non-zero speed-setting packets. A DCC controller should repeat such a packet indefinitely until another speed-setting packet for that address or a broadcast stop is requested to be sent. A value of 1 requests infinite repeating. In that case, the value in the low 5 bits is irrelevant. A value of 0 indicates that the finite repeat count is specified in the low 5 bits as described above.
It is a violation of this protocol to request infinite repeating of other than a non-stop speed-setting packet. It is up to each DCC controller how to handle such a request, which could include sending the packet a fixed finite number of times or ignoring it altogether. However, in no case may a DCC controller send such a packet more than 32 times.
The remaining bits (ctrl<6:5>) are reserved for future use. They must be sent as 0, and receivers must discard the frame if they are non-zero.
Since CAN messages can contain up to 8 data bytes, this message can specify up to 7 DCC bytes, for a total of 8 bytes in the DCC frame since the error detection byte is automatically added.
Causes a reset sequence to be performed on all DCC busses, which is the same as the initialization sequence performed after powerup, as defined by the NMRA Recommended Practice RP 9.2.4 Section A. This initialization sequence is a minimum of 20 digital decoder reset packets, followed by a minimum of 10 idle packets.
This frame also causes all DCC controllers to delete any pending messages to send.
Each MorBus node that controls a DCC bus must send a DCCINIT node-specific frame after the reset sequence is completed.
Manipulates or reports the state of one turnout. Turnout is the 16 bit unsigned number of the turnout this frame pertains to. The special value of 0 is reserved and not a valid turnout number. Turnouts can therefore be numbered from 1 to 65535. Opc is a opcode indicating what is to be done to or being reported about the turnout. The supported values of opc are:
Indicates the turnout is in the "closed" or "normal" state. Trains can safely pass thru the turnout over the closed route.
Indicates the turnout is in a undetermined state. This is the case, for example, after switching the turnout to a different state but before it is definitely in the new state. Trains should not attempt to pass thru the turnout.
Indicates that a error has been detected in the operation of the turnout. Trains should not attempt to pass thru the turnout.
Indicates the turnout is in the "thrown" or "alternate" state. Trains can safely pass thru the turnout over the thrown route.
Commands the turnout to be switched to the closed state. Whatever device is controlling this turnout must attempt to switch it to the closed state. If the turnout can be reliably determined to already be in the closed position, then nothing needs to be done other than reporting it is in that position. If the turnout is in a different position, then it must first be reported as undetermined, the turnout switched, then reported in the new position. For turnouts where the position is only assumed, not directly measured, it is strongly recommended that a attempt be made to switch it even if it is believed to already be in the desired position.
Commands the turnout to be switched to the thrown state. Whatever device is controlling this turnout must attempt to switch it to the thrown state. If the turnout can be reliably determined to already be in the thrown position, then nothing needs to be done other than reporting it is in that position. If the turnout is in a different position, then it must first be reported as undetermined, the turnout switched, then reported in the new position. For turnouts where the position is only assumed, not directly measured, it is strongly recommended that a attempt be made to switch it even if it is believed to already be in the desired position.
This frame can be sent with just the turnout parameter and ACK REQUESTED. In that case, the node controlling this turnout must respond with a TURNOUT frame indicating the current state of the turnout.