Building custom velbus devices


If i take a close look at your VMB8PB, i can see that you are using an MCP2551 and a PIC16F627A. (No MCP2515)
Does this mean that you handle all the CAN (Velbus) controlling by software in the PIC ?

Is there some code available to handle this CAN (Velbus) Controlling. (Makes it easier to create your own velbus devices)


Is there anyone who can help me in receiving the velbus data in a pic ?
On this forum I did find that the baudrate for the velbus is 38400. Although I did set this i can’t get meaningfull data in the buffer of my pic.
On the velbus I 've connected an MCP2551 that is also connected on the RX and TX pins of the pic’s USART.
Through the USART I try to receive these packets and store them in a buffer.
If i display the content of this buffer is does not match the original packet (control through velbus link traffic viewer) at all (missing byts, wrong values,…).
Can anyone help me or give me a hint on how to get this done ?


The Velbus baudrate is 16,6 Kbps.
Sorry, we do not supply other information because of copyright reasons.


since velbus uses a form of CANBUS as protocol, I came to the conclusion that using the usart is not an option.
Now I am using PORTB.0 as RX and i use the PORTB.0 interrupt to detect a start of frame.
I do get some data but not the correct. (still have to work the timing).

Does the VELBUS protocol uses bitstuffing ?

Is there anyone else on the forum who could give me a few hints on how to receive the VELBUS messages into a pic16F628A



i’m getting confused here.

Does the VELBUS run on 16K6 or 19K2 ?
Are there start and stopbits for every byte send and is there parity ?


According to: … l_rev1.pdf

the velbus CAN communication runs at 16.6kbit/s.

And according to me, the protocol is described in: … vmb1rs.pdf

page 3 (Velbus protocol)

I would also like to create some custom velbus modules, so I was wondering if you already have something that you would like to share. Maybe I can help…

For the moment, I only have idea’s, nothing working yet, but my intention was to start with the hardware of a VMB8PB and see where I get from there…


After analzing the velbus with a logic analyzer, it does not make sense.
I can’t find any logic connection between the custom packet i do send through velbus software and the data on the bus.

Is bitstuffing implemented ? (would explain some things)
Is the timing respected ?
Velbus = 16k6 => 60.24 µs per bit
Analyzer shows bittiming varies for 58µs to 63µs per bit. ( i sample every 60µs, so errors can occur at the end of the bittrain.)


Perhaps you could post some screenshots of your logic analysis. I don’t have a logic analyser, so… 8)

Regarding the bittiming. It is indeed odd that the timing varies between 58µs and 63µs… Perhaps timing is not that critical in this case (if the bit is sampled in the middle of it’s ‘high’ or ‘low’ state it doesn’t have to be a problem - the average bitrate still is approx. 60µs… When of course the sampling occurs close to the edges, the you could have timing issues). I should check the MCP2551-datasheet for setup- and hold-times…

@VEL456: Perhaps you should add this rule first to the forum rules, before removing pictures! I don’t see any rule stating that it is prohibited to post pictures…

@penske: Maybe you can email (bdewitte at me your screenshots, since Velleman doesn’t like the fact that their “secrets” are being posted… I noticed before that a message, about someone messing with velbus-module-firmware, suddenly “disappeared”…

This is not a problem. The forum does not allow to upload pictures.
Feel free to provide links to pictures on e.g. a free picture base. Make sure they appear as a link, not as a picture, this reads a lot better.

Pictures that are too wide break the forum layout

@VEL417: the picture was not uploaded, it was a link between “img” tags. (which is one of the allowed tags on this forum).
@VEL448: I did not pay attention to the picture width. (1200+ pixels). You could have removed only the picture. ( or removed the img tags so the links was visible.)

Seems like a little bit of Censorship.
I don’t want to build a copy of your devices, i want to make custom sensors that can talk directly to the velbus. (it would cost me more to build a copy than to buy an original if you take the enclosure and print layout costs in count).

A few of the projects are: an integrated zone volume controller, a water temperature sensor, timebased switching without the need of a server,…

@ All the rest:

This is the link to the trace that i took on the physical velbus :
The values underneath every trace is the sent value according the velbus software.
Bitstuffing is used = after every serie of 5 the same bitvalues, a bit is inserted with the opposite value. This bit must be ignored while decoding.
Look at the actual data byte (5th byte) to find the start of the different bytes.
It looks like the first byte and the first 5 bits of the second byte are not present on the physical buswires (compression ??, they always have the same value)
Checksum and stopbyte seem to be wrong (haven’t figured out why yet.)


can your logic analyzer be triggered on the stopbyte witch is always H04. only then you can analyse the data. The data is not always send equal. i think you have to trigger on H’0F’ (start of packet) and stop when you got a H’04’(end of packet).


My logic anayzer only triggers on edges.
Since the idle state of the velbus is high, i trigger on the falling edge.
Start byte = 0F, this means that the packet begins with a falling edge.

I do test this with the send packet option of the velbus software so i am sure there is no other communication on the bus.
I do have a 6 In module on this bus aswell and it shows similar traces on the wire if i trigger an input.
This means that the actual velbus packet is not send as is on the bus.
I think Velleman does some tricks with it before sending it to the transmitter. (and with tricks i don’t mean the bitstuffing)
Can someone of velleman confirm this. (you don’t have to tell what you are doing with it, altough it would be nice if you would.)


The velbus protocol is a software emulation of the Bosh CAN-bus specification

The baudrate is 16k6

1 Like

Thanks, You did put me on the right track.

I was wondering why you didn’t use a pic that has a can controller build in since it is standard CAN that you use on the wire ? (cost ?)


Hi all,

I’ve installed a CANBUS2.0 protocol analyser on top of my logic analyser software (ZEROPLUS) and now the packets captured are displayed as can bus packets. This makes a lot more sens and now i do understand the relation between velbus and CAN. (It’s actualy explained in the module protocol sheets).
I’m still wondering why velleman did choose to develope a software can-controller instead of using a pic with a can controller onboard.
I will try to build my devices with the PIC18F2685 series. I’ll keep you informed on my progress.

Thanks to all for the usefull hints.



Is there a list of all available module types and their hex value? (available in the velbus software)
Is it possible to make your own module types in the velbus software ?

I’m currently using an existing module type (vmb4dc) that has functions similar to the ones i need on my custom device (Multizone Volume control).
It would be nice if i (or someone else) could create custom devices in the software.
Some sort of device lib where you can add custom devices and all their settings.


see topic list with command codes but is not up to date.

hope this will help you.



I’m looking for a way to create custom devices in the software but with some general elements (Pushbuttons, dimmervalues (Volume), contacts (relays)).
How are the official velbus devices defined in the software ? (through a library?, an xml file?)