Message timing restrictions
Hello,
We are developing an RV-C compliant device, and I have a few questions relative to the requirement specification.
1) What is the minimum gap between messages?
My understanding is that the minimum broadcast message timing is recommended to be 50 mS per 01A-S-10.
If I have a device that broadcasts a series of DC_SOURCE_STATUS messages, does this requirement suggest that the gap between each of these messages be at least 50 mS or 5 mS ?
2) If my device creates multiple instances and/or device types, does this rate apply to message gaps between one instance/device and the other, or just between messages within and instance/type?
3) In most devices messages are typically queued if necessary to manage timing bottle necks. This implies that the messages needed to be transmitted quickly in bursts to recover from these cases. Does this minimum message gap timing apply in such cases?
Thank you for your
Thank you for your clarification. It is as I thought, however I was having a bit of a dispute with a firmware designer about the primary requirement. The message to message timing requirements are a little bit scattered and somewhat difficult to find.
The specification addresses message timing down in section 4.3.1.3 Profile 01A: Level One Compliance, 01A-S-10. Which is a set of testing requirements. And the wording is a little ambiguous because it uses the term "broadcast" which has different meanings in the CAN terminology.
It is mentioned again in Level 2 compliance: 4.5.6 Maintain a gap between messages where the explanation is a bit clearer.
Food for thought: The CAN message timing is a crucial and rather complex issue, and as you know, it affects base design of the message handling (stack) routines. Your explanation that you just provided is much clearer. I realize that the RV-C spec is somewhat solidified, but it would have saved us some time if that explanation were in a more obvious place early in the requirements. When I was doing a text search for information on message timing or search variations, I never found "4.5.6".
The primary purpose of the
The primary purpose of the timing gap is to ensure that receiving devices aren't overwhelmed with incoming messages. Transmitters need to provide gaps in their messages so that receiving devices have enough time to process them before their mailboxes or queues overflow. This is complicated by the fact that other transmitters may be sending messages on a similar schedule, creating "traffic jams" even when each individual product is well-behaved.
Since the purpose is to protect the receivers, the limit must apply to the entire node, not each instance. The default requirement is for a 50ms gap in normal operation, but some devices broadcast more than 20 messages in a second, so we allow the minimum gap to be reduced. But in any case the gap should be as large as possible while still allowing the device to get all its messages transmitted per their normal schedule. Only the most demanding applications should approach the 5ms minimum.
So as you write your transmission routines, you will want to set a timer task or interrupt to service your transmission queue every 50ms (or faster if necessary, but at least 5ms). Your queue will grow each 500ms as the status messages get scheduled, then shrink as the timer fires. In many of my company's more complex products, we stagger the schedules for certain data items so that the data is as "fresh" as possible, but that's probably not an issue for the relatively "slow-moving" DC_SOURCE_STATUS data.