SI namespace design

[pavel.kirienko]

@pavel.kirienko

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…

32-bit values with 56-bit timestamps don’t work well with CAN 2.0. They don’t work well at all. Because we don’t fit into one CAN 2.0 frame, we’d have to spill over into another frame, adding two more bytes for CRC. So the overhead would be: 7 bytes timestamp, 2 tail bytes, 4 CRC bytes; the total overhead amounts to 13 bytes for just a single 4-byte float. Uh oh.

I realize that we aren’t supposed to care about efficiency but I’m not sure we’re supposed to not care to such a wild extent.

Kjetil has pointed this out at the today’s call and so we ended up adding SynchronizedAmbiguousTimestamp, 24 bits wide, with an overflow interval of 16 seconds. Which is bad, because overflowing timestamps are dangerous, especially those that overflow every 16 seconds.

So, let’s consider for a second dropping the resolution of ambiguous timestamps down to, say, 10 microseconds. This is bad because of this:

@pavel.kirienko

I would like to avoid talking about representations that offer a reduced resolution (lower than one microsecond) for reasons of consistency and avoiding introduction of new restrictions on application design (a message that relies on a compact timestamp may also require full microsecond resolution).

But 16-second overflow period is also bad, so we have to decide which is worse. Given these new developments, I am inclined to accept timestamps with 10 us per LSB.