Page 004 Testing the CANUSB4 with JMRI. - johnmholmes/Arduino-CBUS--Introduction-Series GitHub Wiki

Last updated 5/10/24

First simple sketch

• The sketch sends two short event on to the can bus. I show these messages being received into JMRI.
• Please note I am not using Duncan Greenwoods libraries for these simple test. These libraries are written to be used in a totally different way from what I am trying to do at this early stage. They are based on following the MERG way of doing things, which means you mimic the previous kit way of using SLIM and FLIM and require 2 extra LEDs and a push button.
• This can be found in the test sketches folder in the repository.

The Can frame message

Here you can see the output from within JMRI CBUS console window.

• Here you can see, I have highlighted the actual can frame message received. In the brackets you see 382, this comes from the can 11 bit header, I will explain this in more details later.
• The next two digit's, represent the c bus op code, and in this case 99 equals, as of, which is a short event off, and in the second message you see we have 98, which is equal to, as on, which is a short event on.
• The next 4 digits, which are all zero, these get used in c bus to represent the node numbers, which can be used to help you identify which module is sending the events. In short messages we tend to just use event numbers to control things.
• The final 4 digits, represent the event number in the message. so in this case, it is event 2 on the can bus. We can have a total of 65535 events by using just 4 different bits. this would look like FF FF instead of 00 02. which is shown in the hex format.

The CBUS message window

Here you can see the c bus message window, and it is showing the it is a message from c bus to JMRI.

• Next you will see a time stamp for the message, and also that it is equal to, an off, and its E N or event number of 2

• The next part you see is just a better description which can be turned on or of using the tick box at the bottom of the window.

• You then see in the brackets minus 2, or plus 2, depending on the op code , this is used by JMRI, more details will be shown in a later video.

• We then see we have a can id of 2, being used. This may seem strange, as the 11 bit can header showed it's as 382. This is because, in the CBUS protocol, the first 4 prominent bits are used for the can arbitration. and the remaining 7 bits, are used to give you a choice of can id. The reason behind this, is that you can only really expect to have 110 modules, working on a bus. The 7 available bits allow for you have can id from 0 to 127.

Short message Opcode

• This here, is an extract of the c bus developer guide, I will add a link to it in the video description. I have highlighted the first 4 bits of the can header here, so we have a major priority and the minor priority bits, These normally get set by the developer of the modules but in most cases they are set as zero,1 , and one, one, If you look through the developers guide you can see there are 255 possible opcodes available. But for my case I will be sticking with 2 opcodes.

• I have highlighted here, that in short events, the last 4 digits, get called device numbers, but in long events they are called event numbers, JMRI seems to call them events numbers in the example I showed.

Sketch Used.

Here is the sketch, I have written to test the CANUSB4, connected to JMRI. I have kept the sketch as simple as possible at this point. I am using the mcp_can library as seen in earlier can bus videos rather than the CBUS libraries.

Here you can see, the make up of the can frame, and the data part of the message. If you have any questions please feel free to leave a comment, or send an email to myself via the channel email address. In the next video I will look at a consumer node to act on the events received. Thank you for watching.