I wonder why the command Commanded Address from SAE J1939-21 protocol, requries a delay between 50-200ms for every multiple package message for the transmitter.
Why? Does the microcontroller unit not have a RX buffer for CAN-bus?
\$\begingroup\$
\$\endgroup\$
5
-
\$\begingroup\$ It may have or it may not, the standard simply specifies a packet rate that each device must support. This may be used to calculate buffer and IRQ servicing requirements of your application. A designer is usually given freedom to implement how they so choose as long as they meet the process data rate requirements. This is because standards define expected performance and not implementation. Why this particular standard chose a 50-200ms message rate, consider when it was designed and that it must support the lowest common denominator of all possible devices. \$\endgroup\$– crasicOct 5, 2021 at 13:34
-
\$\begingroup\$ @crasic So if I have a CAN device that have a RX buffer, I don't need to have the "delay" between messages? Or can it be so that when this SAE J1939-21 standard was written, there was no RX buffer for CAN messages? Sending 8 bytes every 200 ms is a very long time. \$\endgroup\$– DanMOct 5, 2021 at 15:36
-
\$\begingroup\$ Your first figure (Figure 14) indicates this is a requirement, a particular device may accept message faster, but if it does, it will be in an undefined manner, according to the specification, so the resulting system would not be "J1939-21" compliant if you were to develop or produce it, and would fail to function if modifications are done down the road without knowledge of this undefined behavior. Perhaps there are related protocols that could support a definition that you want. I understand this is why there is such a zoo of "CAN" application protocols. \$\endgroup\$– crasicOct 5, 2021 at 15:49
-
\$\begingroup\$ @crasic I have tried that Open SAE J1939 library and it works great with Commanded Address. Super easy and this library does not have a delay between the messages. The hardware I'm used was STM32. \$\endgroup\$– DanMOct 5, 2021 at 15:57
-
\$\begingroup\$ That may well be the case, there are many cases when device capabilities which far exceed the definition of the spec, everyone has the freedom to hack, but formally it may not be compliant, whether that matters to you, only you can say! \$\endgroup\$– crasicOct 5, 2021 at 16:04
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
10
Thanks for bringing it up. I was able to refresh some part of my experiences.
Sending 8 bytes every 200 ms is a very long time
Yes, it would be terrible to have 500kbit/s while delaying 200 ms.
It seems, from the image you posted, that is for a Broadcast packet, which does not use ACK/response. Thus the delay spec gives the design margin to receive-end for processing and timeout. For normal master-slave & peer-peer RTX, it can use timeout, though once ACK-ed, any delay wouldn't be necessary.
Meantime, this discusses packet/frame speed as well, which is much faster than 200 ms per packet.
SAE J1939 Message Frame Frequency
The SAE J1939 message frequency depends on its length (the majority of J1939 message frames contain 8 data bytes) and the busload.
An SAE J1939 message frame time (135 bits with 8 data bytes and average bit stuffing applied) is 0.54 msec @ 250kbps and 0.27 msec @ 500 kbps.
Assuming a busload of 70%, which is generally considered the "real-world" maximum, an SAE J1939 data frame may occur every 0.77 msec @ 250 kbps or 0.39 msec @ 500 kbps.
-
\$\begingroup\$ @PurpleLady , Thanks for the editing, the best so far. I had to implement your edit. You will be able to change/edit mine soon, as your score goes up. English is not my mother-tongue. I will ask you to help me another time.. ;-) \$\endgroup\$– jayOct 5, 2021 at 17:01
-
\$\begingroup\$ "Most of today's CAN Bus controllers can theoretically handle a constant busload of 100%" So that means delay in modern CAN bus devices are unnecessary? \$\endgroup\$– DanMOct 5, 2021 at 17:07
-
\$\begingroup\$ @MrYui Yap, absolutely! I agree with you. I guess, the "standard" wanted to be more inclusive. Soon, we can expect that the delay requirement gets disappear, along with larger packet size, become more efficient. \$\endgroup\$– jayOct 5, 2021 at 17:14
-
\$\begingroup\$ "but it is nevertheless highly recommended to create an appropriately sized buffer in your embedded application." and here they are saying RX buffer or TX buffer? Open SAE J1939 library has a internal RX buffer for T.P D.T messages. If you send 3 messages with T.P D.T, then it will be included in the RX buffer for T.P D.T. \$\endgroup\$– DanMOct 5, 2021 at 17:17
-
1\$\begingroup\$ @Jay, Thanks. I am rather new here. So I guess I should focus more on answers and editing questions where needed. Sure, someone else has to approve it, but I still get points. \$\endgroup\$ Oct 5, 2021 at 18:39