For some time I am creating a CAN/Serial/Network protocol for equipment we are designing. After searching around to get some inspiration I found UAVCAN. The way UAVCAN is using the CAN transport is surprisingly similar to what I specified until now.
Therefore UAVCAN might be option for us to use in our products and contribute to the project. However there are a few things which holds us back.
These are:
Having always a byte of overhead in the CAN payload. In CAN world this is a lot! Having, apart from the already high overhead of a CAN message, 50% overhead on the data part when sending 1 byte is huge. Therefore I would propose having a multi/single message bit in the CAN ID.
Another ‘missing’ feature is to have a publish request. One could use a service request for it but this creates overhead in my opinion.
Combining these 2 points I made an example CAN ID field
Furthermore it gives us a bit for single frame or multiple frame message. Single frame messages have 8 data bytes available. Multiple frame messages are similar as already described in your specification.
Are you willing to consider such changes?
By the way, I am very happy reading you switched using COBS for the UAVCAN/serial escaping. This is a big plus.
All happy CAN protocols are alike. I think this is to be expected considering that the solution space is small.
Allow me to retort:
50% is nothing! If the payload is zero, the overhead is 100% (relative overhead is quite a useless metric unless you are comparing different technologies)
Classic CAN is going away, especially in the fields that are not as encumbered by legacy as automotive or industrial fieldbuses. Many of the new UAVCAN/CAN applications will be leveraging CAN FD from day one, so that should be the primary optimization target. This is not to say that the Classic CAN is irrelevant, but it is to say that its performance is not the most critical factor to consider.
The CAN ID should be a function of the Session Specifier to ensure its consistent and simple behavior at runtime. More on this either in the Specification or in Alternative transport protocols in UAVCAN. Using it to communicate auxiliary states of the transport layer means that the CAN ID will be changing depending on some highly volatile trifling details of the current configuration, which is undesirable.
The extra byte is needed regardless of the above to support deduplication (which happens in CAN due to the ACK loss edge case briefly mentioned in the Spec), redundant transports, transfer loss monitoring, and some fringe features described in the Spec at length. You can remove it but it will be costly to the protocol.
The publish request does not fit into the data model that the protocol is based upon. We value statelessness and service-orientation, pub-sub is the main mode of interaction; you will find a detailed discussion in The UAVCAN Guide. Here it is also explained why node-ID should not be relied on in high-level application interfaces.
No. UAVCAN/CAN is stable and it is not going to be changing for a long time unless the change is wire-compatible with existing deployments out there and is strongly motivated.
I think we are on a completely different level. On a few points you are missing the way CAN (or other media’s) and event driven applications are working. Stateless is my middle name Reading your reaction I think UAVCAN is not the way to go for us.
I wish you a lot of wisdom in getting UAVCAN to v1.0 with a lot of users.
(relative overhead is quite a useless metric unless you are comparing different technologies)
Reading your reaction I think UAVCAN is not the way to go for us.