Handling flow-control in application


I’m writing my own application to control my Velbus setup from a linux environment (Yes, I know this has been done before, but it’s fun to do it myself), and eventually from a web browser using cool AJAX/websocket tricks. I’ve read and re-read the provided documentation (which, I must add, is really great!), but still have some unsolved issues around flow-control.

The VMB1RS (and probably VMB1USB as well) connects to the Velbus at 16.6kbps and towards the computer at 38.4kbps. Since these speeds don’t match, there is a need for flow control (otherwise, the computer would swamp the VMB1RS module). I was happy to see that there is, indeed, a RxBufferFull message defined, but I haven’t been able to figure out how to use this in an efficient way:

The obvious, but painfully slow way to do this is to send the packets one-by-one; waiting an arbitrary time in between for potential RxBufferFull messages, or polling for them after every packet. As already stated, this is painfully slow, and ruins the entire concept of buffering.
The very optimistic approach would be to send packets until on RxBufferFull is received. This does not work, since by the time you processed the RxBufferFull message, the UART will still be sending out packets (which will be lost in the overflowing VMB1RS’s buffer).

What is the correct way to do this flow-control?

PS: I also considered just throttling the output by just waiting a specific time between packets (without regard to RxBufferFull messages), but decided that this would not work: it assumes the VMB1RS will be able to send messages continuously, which is only the case if there is no other bus activity.

Implement a queue and keep 60 milliseconds between each packet sent

Thanks for the quick answer!


This means reducing the throughput to 16.6 messages/second which gives at most (14B/message) 1.866kbps; an order of magnitude slower than the bus can handle…

But maybe I’m just trying to over-optimize my stuff (as usual); I don’t really see a practical need to burst 100+ messages/second…

The buffer inside the VMB1RS and VMBUSB can only buffer about a dozen packets, so sending packets at full speed will overflow that buffer very quickly.

Keeping a 60ms delay will still allow for some regular traffic on the bus (button presses, status packets, …) while you are sending at “full” speed.

Plus everything you send will invoke a response from one or more modules. So if you are already saturating the bus, they will not find a free slot to answer.

There is really no practical use to send hundreds of messages per second :slight_smile: