Velbus and the CANBus standard

[fastbike]

How closely does Velbus follow the CANBus standard (ISO 11898-1) ?

The reason I ask is that I have some legacy control modules that communicate over CANBus and I’m looking at reprogramming them to work on a Velbus network.

The ISO standard shows a Differential Return to Zero bit stuffed physical layer with a the link layer having 4 fields (see below) that differ from the protocol shown at the Velbus github page.

Does this mean I ignore the built in CANBus controller, or is the Velbus 6 Bytes + N sent as a part of the data field using some type of a multi part message ?

Thx

ISO 11898-1 defines the following parts of a CANBus message:

1. the Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The Arbitration Field contains:

• For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames.
• For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit.

2. the Data Field, which contains zero to eight bytes of data.
3. the CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection.
4. an Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message.

[MDAR]

Hi

There are a few people doing their own funky things on top of Velbus.

Have a search of the forum, you’ll find a few.

Like

Canbus 2.0B Crc calculation

Hi I am trying to communicate with the canbus but the calculated CRC does not seem to conform to the Bosch Can 2.0 standard (http://esd.cs.ucr.edu/webres/can20.pdf). Notes: I can read all messages from velbus without problems (ignoring CRC) I can also send messages and receive them in my own hardware modules (using standard CRC) I cannot sent messages to velbus devices (USB interface)! Used components PICHJ128 family (Microchip) with integrated ECAN module + MCP2551 transceiver. Any help …

Arduino with CAN shield to connect with Velbus

Hi, This weekend, I have written a Library for Arduino to communicate with Velbus through a CAN shield. I have posted the library on Arduino’s forum: forum.arduino.cc/index.php?topic=185743.msg1375617#msg1375617 (you must be logged in on the Arduino forum to download the file).

[EvAndy]

Pretty closely to CAN2.0A.
Those four fields are used the same way. Velbus packs it’s ID and priority bits onto the same 11-bit identifier. Smaller 8-bit Velbus address appears shifted but is completely compatible.

You do need to do the proper CAN CRC (hardware controllers will do this for you and you effectively never see the CRC at all). And your DO need to do the ACK when receiving (a hardware controller will do this for you also).

Watch out for bit rate timing… if you are too far off then you may just occasionally drop bits only when you have several successive 1s or 0s which can make it hard to see what is going on.

I have managed to get several CANBUS controllers talking to Velbus fairly easily :-

1. cheap MCP2515 SPI-bus modules
2. ESP32 WROOM, DEVkit4, S2, and S3.
3. STM32 F103 and F072 (the F072 can even do USB device at the same time)
4. A custom pure-software implementation on 8-bit Arduinos. (Not complete but working OK).

The MCP2515 boards with an Arduino are a very easy way to start and get your head around everything. Try starting with listen-only attached to a working velbus test-rig with eg. just a pushbutton and a relay or dimmer.
I had a little bit of trouble with common ESP32 WROOM modules because they only just support the low baud rate but folks on here helped me out. The S2 and S3 versions were fine though.

My software version on Arduino does not passive sync on bit/frame starts when it is not sending or receiving on a busy bus. ie. it starts its bit timing arbitrarily when you TX rather than syncing with whatever arbitration frames are starting at the same time. I think that is just an inevitable software limitation that older Velbus nodes probably have too. It should not matter unless the bus is very busy in which case the only consequence is that a higher priority transmit cannot so easily override a lower priority one starting at the same time. You can still mostly detect busy-collisions and back down though.

As mentioned above, Velbus receivers DO use the ACK field so if your receiver is the only device on the bus and you do not send an ACK the Velbus transmitter will retry some dozens of times. Just watch out for that one if you try to run your receiver in listen-only mode and there are no other receiving devices to send the ACK.

Other than that it’s just a matter of adjusting the bit timing a little since 16K6 is not a standard CAN bit rate. Datasheets for the various controllers will have info on this but they all seem to be pretty similar. Most software libraries use tables for this so you can just add another entry to the table.

There is lots of CAN info on the net but the original Bosch Protocol Standard is a very clear and useful reference and is readily available from NXP(ex Freescale), just google for BCANPSV2.PDF. That doc fairly easy to read side-by-side with a datasheet for your choice of controller.

You can not only transmit and receive Velbus but of course once on the bus it is also very easy to use the connection between your own nodes to send your own custom data that velbus will ignore… so I can use the Velbus cable to send my own data all over my house

What I have NOT tried to do (but user matthijsfh on here has done, with STM32) is to emulate an existing Velbus device. So my attempts are not recognised and programmed by VelbusLink, I just set them up hardcoded in my firmware.

[fastbike]

@MDAR

There are a few people doing their own funky things on top of Velbus.

Thanks for those links. I can now see that Velbus is a higher level protocol sitting on top of the CANbus, in a similar way to how CANopen sits above the Physical/Link layers of the bus.

It is nice to know that the system is open enough that some custom devices can be included. How would they be configured though - is there an API for the Velbus link software, or instructions on how to add custom devices ?

I have previously worked with LonWorks which provided specs on device definition files (*.xif) that contained the details of the device capabilities and binding options. This allowed the configuration software to present the correct options at setup time. See https://www.lonmark.org/wp-content/uploads/2020/02/LmXif4402.pdf

[fastbike]

@EvAndy

Those four fields are used the same way. Velbus packs it’s ID and priority bits onto the same 11-bit identifier. Smaller 8-bit Velbus address appears shifted but is completely compatible.

That’s useful - thanks. From some of the other links I’ve been sent I can see that internally those values are mapped across to the CANbus bit stream that the controller sends to the network.

[MDAR]

@fastbike

It is nice to know that the system is open enough that some custom devices can be included. How would they be configured though - is there an API for the Velbus link software

Hello

No, that’s never going to be possible.

While Velbuslink is fabulous, you can’t add your own modules to it.

But

Because every module transmits updates and status’ to the bus, you only need program your own things to react or send an instruction.

You can’t configure Velbus modules to react to your homebrew kit, because Velbuslink doesn’t know about them.

Unless you do something like adding a virtual module in Velbuslink and configure with that.

I’ve never tried this, but it might work … Maybe

[EvAndy]

You can’t configure Velbus modules to react to your homebrew kit,
because Velbuslink doesn’t know about them.

It is fairly easy to make a homebrew custom module generate or respond to button presses.
So as long as you have a velbus input module (like a VMB8PBU for example) in the system then you can have a custom module generate those same 8 different button presses. So you can sort of still use velbuslink to program things to respond.

I have hundreds of spare (unused) pushbuttons in my system because every lightswitch has an 8-button encoder in it, even if I only use 2 or 4 pushbuttons from it. So I can still use VelbusLink to set things up for the other unused buttons and then have my own hardware also generate those same button presses.

But otherwise yes, unless you try emulate an existing velbus module then you have to just set the inputs and outputs in your firmware… VelbusLink won’t connect them up to things for you.

The commands that the Velbus V1 modules use are all published and decently documented. And VelbusLink has a log window where you can see the commands on the bus. Most real Velbus modules actually generate and respond to quite a lot of commands though (eg. the pushbuttons also respond to LED commands and the dimmers can send them commands to set their LEDs into various states to indicate what is going on). VelbusLink hooks all these things up by telling them about each other. That does not stop you making something that JUST generates pushbutton signals or JUST responds to pushbutton signals. You do not have to do all the other stuff if you only want something simple.

It’s been fun to play with just for learning CAN, but I note that the last time I actually wanted to do something custom on Velbus I ended up just connecting an arduino directly to a spare VMB8PBU so it can generate 8 different button presses and I can still set everything up in VelbusLink.

Unless you do something like adding a virtual module in Velbuslink and configure with that.

Oh! Yes, that seems to work, at least it does for virtual pushbuttons… ie. you add an input device that is not really there and then configure things to respond to that. And they work!
You do get warnings that “There are undetected modules in this project. Have you already scanned?” but otherwise it does seem to work.

[fastbike]

Thanks for the follow up. Out of interest I connected up a CANUSB module and wrote a simple monitor to echo out bus activity.

The module comes with a DLL that provides a few simple functions to manage connections to the bus to read, write and filter packets.

I can see recognizable activity when I run a scan via VelBusLink, and can now see how the mid level packet protocol documented on the Velbus github page is actually mapped at a driver level.

E.g. scanning node 22 shows the following in the Velbus Log

22/04/2024 22:22:49.381 SEND 0F FB 22 40 94 04

this can be decoded as

start flag = 0x0F //always this value
priority = 0xFB //low
address = 0x22 //node id
RTR/Length = 0x40 //remote frame with zero length body
Checksum = 0x94 //verified with tool found linked on this forum
End flag = 0x04 //always this value

Where as the driver CanMsg structure in the driver library shows (all decimal)

id=1604  //binary=0110 0100 0100
timestamp=56652 //ms
flags=64
length=0
data=[]

Decoding the identifier using the 11 bits from the right as this is what is actually transmitted on the wire (bits to the left of this are just software stuffing in this driver) gives us “110 0100 0100”. We then take bit one on the left as the most significant bit, through to bit 11 on the right.
So now we have:

bits 1-2 =b11 // low priority
bits 3-10 = b0010 0010 // 0x22 //which is the node id
bit 11 = b0 // always zero so can ignore

The flags are interesting as this is the RTR flag and decoded to hex we get 0x40 which corresponds to the value shown for a remote i.e request packet.
The driver also stuffs 0x80 in here if extended frames are being used - which are not in this case.

Length is obvious, there is no data payload on the remote frame, so the data array is also empty.

Anyway this is all interesting stuff so I’m keen to see if I can use a mix of Velbus nodes such as relay output, Finder 15.11 dimmers etc where I need to use mains certified products along with some home baked switch nodes that fit the particular style of non European switches already in my home.