VelBus Protocol in dept

Hi,

I am creating an DLL Velbus interface in C# and I have some question about the protocol.
I made a little word document with all my questions.

The link is
users.telenet.be/vglcw/VelBusProtocol.zip
or
users.telenet.be/vglcw/VelBusProtocol.doc

If there are some problems with this doc, let me now.

Thanks

Sébastien

Please visit the following thread (click here) for more information about the Velbus protocol, and its implementation in .NET.

Hi,

The .net solution explain not really what I was hoping to understand.
I really need to know is these unused bit will be used for a later version of the protocol or if those bit will never be used and are fixed.

  1. priority

If I understand correctly.
In the second byte (byte[1]), the priority byte, there are only 2bits in use.

High = 0xF8 --> in bits: 1111 1000
Low = 0xFB --> in bits: 1111 1011
Bitwise OR --------------
Difference 0000 0011
It’s seems that only those 2 bits are in use.

But then, if I look at your code in PacketParser.cs:line 113
packet.Priority = (m_Buffer[1] == 0xF8 ? PacketPriority.High : PacketPriority.Low);
This means that all packets are priority low exept for 0xF8.

shoutn’t it be:
if (m_Buffer[1] == 0xF8) // if the byte is exactly 0xF8
packet.Priority = PacketPriority.High
else if (m_Buffer[1] == 0xFB) // if the byte is exactly 0xFB
packet.Priority = PacketPriority.Low
else // all the rest
throw new PacketException(); // OR throw new NotSupportedException();

OR maybe even better.

if ((m_Buffer[1] & 0x03) == 0x03) // if the 2 bits are on
packet.Priority = PacketPriority.High
else if ((m_Buffer[1] & 0x03) == 0x00) // if the 2 bit are off
packet.Priority = PacketPriority.Low
else // if only one of the 2 bits is on
throw new PacketException(); // OR throw new NotSupportedException();
In this solution, I don’t even look at the other bits.


  1. Byte[3] Number of Data bytes + RTR bit

something the same as above.

if I look again in the code --> Packet.cs:Line167
the number of databyte (or datasize) can be from 0–>8.
This means 9 possibilities, the first 4 bits(bit[0,1,2,3]) for the number of Data Bytes + the 7th bit(bit[6]) for RTR.
So bit[4,5 and 7] are not in use.


I am really looking in bit lvl to really good understand the protocol.

Greetz

Sébastien

  1. Priority
    There is no bit-level significance, 0xF8 is high priority, and 0xFB is low priority. This is a fixed value field of byte-width.

This means that all packets are priority low exept for 0xF8
The parser already checked the validity of the priority byte in ValidHeaderWaiting(), so it is safe to assume that all bytes != 0xF8 are 0xFB.

  1. Number of data bytes + Rtr
    The maximum packet size is 14 bytes. There are 6 framing bytes, thus the number of data bytes is limited to 8 (14-6).

The rtr flag is set by flagging the most significant bit (0x40). Any other bits have no relevance, and will likely not be used in the future.

I hope this answers your questions :slight_smile:
Have fun programming :slight_smile:

Yes, this answers my question ^^.

and I always have fun programming ^^.

Just one another little question.

Will there be a modules where you can communicate wireless.
Exemple:
A relay with wireless, so I don’t have to connect it to the bus by wire.
or
A wireless module to another wireless module. The 2 modules are connected to a wireless bus.

Greetz

Sébastien

The modules communicate in a different way than you do via the VMB1RS interface. So i don’t think it’s possible to communicate directly to a module.

The only thing you can do is put up a server that’s connected to the velbus network. This server can then accept connections via tcp/ip, which of course can be established via a wireless network.

Maybe R&D will create a wireless alternative for the VMB1RY in the future… but it’s not all that easy. I can image they’ll need some kind of dhcp or whatever networking mojo to get an ip address and what about security, etc.

Yes,

I already thought about using a server with Wifi. But this is too big in price and size.

It’s maybe an idea for the future.

Sébastien

Maybe you could use an old 486? And one of those usb wifi sticks

Vel 448,

with all respect, try to find me a 486 that supports usb and the .NET framework (for your library) :wink:
However, since I’m interested myself in developing a 17" touchscreen application in .NET controlling the VelBus, I am interested too in some dedicated PC solution. This should be one supporting .NET, not consume too much and prefereably keep running when the power drops (ups-like). The cheapest solution seems to be an old laptop?
Another option would have been a PDA, since the VelBus framework is very easily ported to the Compact Framework, provided that the PDA has either USB host capability or a RS232 connection. However this option is set aside since this cannot be used with a large touchscreen.