Would you like to hear a radical brand new idea?
What if we made timestamps mandatory?
SI types are expected to offer a somewhat lower bus utilization efficiency (what an understatement). Suppose we’re carrying a 32-bit float over CAN; on top of that, there are at least 29-bit CAN ID + 8-bit tail byte + some bits of the CAN protocol overhead, which make the payload insignificantly small compared to the overhead, so adding a timestamp won’t affect the bus traffic significantly. Additionally, it is expected that SI types would rarely contain enough useful information by themselves, one would have to rely on message synchronization as discussed above, which is inherently timestamp-based. Further, I just don’t like the idea of having multiple options of the same thing (timestamped or not) when one might be enough.
32-bit values with 56-bit timestamps work well with CAN FD: 32-bit payload + 56-bit timestamp + 8-bit tail byte = 96 bits = 12 bytes, which corresponds exactly to the DLC code 10012. Same is true for 3-element vectors: (56 + 32 * 3 + 8) / 8 = 20 bytes, DLC = 10112, no padding bytes necessary. Although I’m talking about efficiency again here, and we’ve agreed not to do that anymore…
I like the schema proposed by Scott, which upon addition of timestamps would look like:
si/<quantity>/<Scalar|Vector<N>>.X.x.uavcan
uavcan.time.Point timestamp
<type> value
However, having just “Scalar” and “Vector” is clearly not enough, is it? We have to introduce extensions for Euler angles, spherical coordinates (latitude/longitude), higher-precision vectors (e.g. for ECEF coordinates), and time (the order of magnitude of time is not going to change anytime soon, so it makes sense to use fixed point (e.g. nanoseconds) for the sake of (sigh) bus utilization efficiency). How do we handle that?