Consider defining an upper command rate limit from interface to device

[bruno-f-cruz]

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

At the level of the interface, it may be useful to have a way to establish an upper limit of messages per second that can be written to the device as to prevent the device from potentially dropping/accumulating commands.

Motivation

The current client interface does not assume an upper bound to the number of messages one can send to a device. We effectively assume this value to be infinite. In the past, the assumption has been violated and resulted in dropped write messages from the client to the host when writing a few (2-3 messages) in quick succession (from the client side effectively synchronously). @filcarv implemented a double buffering strategy that far decreased this failure rate but, as far as I remember did not remove it. We have recently come across something similar in the RP2040 implementation and, once again, raised the need to control the outgoing message bandwidth from the client side.

Detailed Design

We should, first and foremost, add the implementation ID to the yaml file (https://github.com/harp-tech/protocol/blob/main/schema/device.json). This can be used as a hook for downstream behavior (not only this proposal but also #18 may benefit)

These are a list of potential candidates to consider to help with this behavior:

1. Add an operator identical to Sample but turn the temperature of the sequence to cold (essentially buffers and resamples). It would be equivalent to CreateObservable(Do()->Delay)->Concat.
2. Move the protocol to be synchronous and block writes until the device returns the expected write.
3. Low level flow-control hardware solution like using CTS. This would be ideal since the timing is largely given by the hardware and it would guarantee the device is ready to receive another message every single time.

Drawbacks

1- High jitter given the non-RTOS, locks the scheduler, its still "open-loop"
2- Annoying to keep track of. Kills the asynchronous grammar of harp/bonsai
3- Needs some studying to check if it is possible to implement from both the client and the host sides.

Alternatives

Unresolved Questions

Design Meetings