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 ?
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 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 live.com) 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.
@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 : hollemans.be/pictures/velbus_compare_2.jpg
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.)
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.
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.
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?)