Hi -
I was running some firmware updates on my Edge and GP series… and noticed the bus speed is low (around 56-62bytes/s) … is this to be expected ? or should I check the bus for terminators/damage etc?
the system itself works like a charm obviously 
1 Like
At a bus speed of 16.7 kbps together with the overhead of the CAN packets (header, RTR, check digit etc) plus the fact that only around 4 bytes per packet are transmitted (max 8 data bytes per packet but one is the command, 2 are the address etc), and after each write packet a read packet is returned - then you’ll understand the throughput is going to be low.
Just wait until you get your hands on the new V2.0 kit
In a pure V2.0 system, they’ll be a LOT faster
Interesting.
Is it using CAN FD ? Or has the bus speed been increased ? And how will this impact on total length and topology etc ?
500M seems to be the new max bus cable length.
As for the rest, that’ll be up to the Velbus team to announce
1 Like
The software implementation of CAN in “old” velbus has extra delays to wait for responses and longer delays to detect no-activity on the bus so it runs quite a bit slower than pure 16K6 bps would suggest. Collisions are still recognised but it cannot respond to bus-contention as quickly as a hardware CAN controller does and things like scanning the bus in particular are slow.
Pure hardware turnaround is faster but MDAR did recently suggest that a pure 2.0 setup will choose to run at a higher data rate. That would help a lot also.
Not that I have any chance of ever seeing a pure 2.0 setup unless we move house again (and my wife currently says that will never happen) 
500m is not long enough for my current project (about 1200m) so I hope it is still possible to set a pure 2.0 hardware setup to run at lower bps?
1 Like
I’m guessing that Velbus 2.0 uses CAN FD.
This keeps the arbitration speed the same (for compatibility with other nodes) but speeds up the transmission rate for the data packet, assuming the recipient can handle that speed.
The bigger improvement will be to the size of the data packet, which can now handle up to 64 bytes rather than 8, so things like reading/writing memory and firmware updates should zip along much faster.
As @MDAR said, we’ll need to wait for any official announcements.
1 Like
Just working my way through the module protocol docs and noticed the “new” VMB6PB-20 push button interface has a configuration bit that signals if CAN FD is being used, and as suspected, the memory data block command (0xCC) supports up to 60 bytes when CAN FD is being used.
1 Like
1 Like
Interesting. I had assummed (for no good reason) just higher data rate.
Now you mention it, CAN-FD would seem likely and very useful.
But if they go CAN-FD but keep the 16K6 bit rate for headers then the old Velbus module firmware could be upgraded to be mostly compatible.
This would not be technically feasible for a classic-only hardware CAN controller because that would generate error frames on seeing a CAN-FD frame;
but since the old Velbus hardware has only a software CAN implementation it would be a fairly minor firmware modification to recognise a CAN-FD frame and just skip/ignore it. And easy for new hardware to still use larger packets and/or higher data rate where possible (also, CAN FD does not have to always use higher data rate). And a CAN-FD device can also easily send classic CAN frames.
That could allow old and new hardware to co-exist on the same bus but still use large packets when programming/downloading and also allow longer (old style) cable lengths.
Several simplifications would be possible to allow more inter-operability so that old modules can talk to new ones and vice versa.
I doubt it will happen… (eg. not doing it might keep new firmware a bit simpler. And maybe they just don’t expect to see mixed old+new devices on a bus) but I think it looks possible.
I’m told…
If there is ONE old module, the new modules roll back.
Operationally it’ll not be noticed, but firmware / full writes will be noticeable faster if pure V2.
I’m waiting to see what my test video reveals
Certainly not after all the V1 Stock has gone.
It’ll only be legacy installs that add new kit that will sadly not enjoy the faster speeds
1 Like
I’m trialing some v2.0 nodes. Doing a read/write from Velbuslink I can see around 260-270 bytes/sec, compared to approx 60 for the older stuff.
And that’s on a mixed installation. So my guess is that the bus will run at the legacy speed for the mixed installation but the software is smart enough to do CAN-FD for data transfer. I have not yet observed if that is achieved via a faster speed for the data part of the packet, or just a longer packet (64 bytes allowed in FD).
I’d break out the 'scope if I cared enough. I’m just happy to see the faster installation time as my initial plans show around 80 nodes to commission, so that will be a much quicker job.
2 Likes