Page 002 Start of a beginners journey - johnmholmes/Arduino-CBUS--Introduction-Series GitHub Wiki

Last updated 5/10/24

My journey into the realm of Arduino, Can bus, and eventually CBUS began during a vacation, away from my layout and hobbies. Fuelled by a desire to keep my mind active and explore new problem solving approaches, I took advantage of having access to a laptop and a pair of Arduino Nano's. Eager to dive into the world of Can bus, I purchased five MCP2515 modules to start my exploration.

Choosing to delve into the Can bus system initially was a deliberate decision. I aimed to establish a foundational understanding of this system before venturing into CBUS, given that CBUS is intricately built around the Can bus system. This sequential approach allowed me to grasp the basics, laying a solid groundwork for my eventual exploration into the more specialized CBUS protocol.

The absence of my usual layout and hobbies provided an ideal opportunity to engage in this educational pursuit, and the journey began with a series focused on understanding and working with the Can bus system.

GitHub Can Bus series.

CBUS was setup to use only 7 bit for the can ID out of the 11 bit header, as this allows for 128 modules on a bus which is more than the 110 recommended. the remain 4 bits are used for setting the priorities when the Can arbitration comes into play. This through me at first, and I am still looking into how they set these first 4 bits via the teaching of events. It seems the opcodes play a big part in this, this will become clearer in the next 2 weeks. 18/12/2023

CBUS guarantees that each frame-header is unique by including a unique-identifier in the header. Each CBUS module that uses CAN is assigned a unique identifier, called its CAN ID (as opposed to its node-number, NN). Each CAN ID is 7-bits, while a (standard) CAN header is 11-bits long, so CBUS uses the remaining 4 -bits as a message priority field. Since each module has a different CAN ID, and any one module can only send one frame, this guarantees each frame-header is unique.

[<MjPri><MinPri><ID>] <Opcode><Dat0> ..<DatN>

• The first two bits are know as the major priority bits, this has 3 possible values,

  • 00 = Emergency priority 0.
  • 01 = High priority 1.
  • 10 = Normal priority 2.

• The 3rd & 4th bits are know as the minor priority bits, This has 4 possible values,

  • 00 = High access 0.
  • 01 = Above Normal access 1.
  • 10 = Normal access 2.
  • 11 = Low access 3.

• The 5 to 11 are used for the Can ID in CBUS

0000xxxxxxx would be the highest priority message then it would depend on the can ID the sending unit used.

This example is a screen grab from JMRI. As this has been assigned a can ID of 120 the last 7 bits will be 1111000

• So in the left hand window you will see the message sent was (5f8) followed by the Opcode of 99 which is a short event of ASOF the 4 bits on the right 07 D2 refers to it being an event from 2002. So a unique can id was created which took in the major setting of 2 and the minor setting of 3 which when all 11 bits are added we have 10111111000 = 1528 decimal or hex 5f8

To be able to work with CBUS I needed to understand a few terms that I came across which can be a little bit strange at first. Here is some of the jargon you will hear being bantered around by people who use it.

• SLiM stands for (simple, layout, implementation, model) One of the starting criteria for CBUS was the ability to set up and use the system without any need for a PC or any similar configuration device using the CBUS itself. Configuration was to be entirely manual using switches on the modules. This use of CBUS modules is called SLiM.

• Even though are units conform to the CBUS way of doing things, we do not use any dip switches for teaching the units we work in FLiM mode.

• The FLiM scheme relies on the use of a PC or similar configuration tool for setting up and teaching the modules. It has more comprehensive capabilities than SLiM.

• It can operate in either the Producer / Consumer (long event) mode, the ‘addressed’ or short event mode or any combination of both.

• Although initial configuration requires a PC tool, subsequent operation doesn’t need a PC to be involved. (CBUS has no ‘node manager’ requirement) There is a comprehensive set of OpCodes and

• including the ability to read back all settings to a file for subsequent reinstatement if required.

• As all nodes need to accessed by the configuration tool, both producers and consumers must have node numbers. These are a 16 bit range (1 to 65535) and would normally be allocated by the configuration software. Nodes (modules) can be given names linked to their NNs.

• A Node number of 00 00 is a special case reserved for SLiM consumer nodes and configuration software.

• In CBUS we use node numbers rather than can IDs, certain numbers have been earmarked for certain MERG kit modules, the suggestion is to avoid using anything below 255.

Understanding Long and Short Events in CBUS:

• In CBUS, events are classified as either long or short based on the information they carry.
• Long events include a Node number (NN) and an Event number (EN), along with the operation code (op code).
• Short events only carry the Event number (EN) and the op code.
• The op code determines whether the event is long or short and indicates whether it represents an ON or OFF event.

When a module receives an event, it must determine whether to act upon it:

• For long events, both the Node number (NN) and Event number (EN) are checked.
• For short events, only the Event number (EN) is verified.

By convention, the Node number (NN) in a long event refers to the producer module's node number.

I am slowly finding my way around the various opcodes here are Mnemonic and hex values. more details can be found here.

or directly from cbus train controller.

• ACON long event hex 90
• ACOF long event hex 91
• ASON short event hex 98
• ASOF short event hex 99

See example from JMRI using a turnout table and the CBUS monitor.