1
\$\begingroup\$

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?

enter image description here

enter image description here

Open SAE J1939

\$\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\$
    – crasic
    Oct 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\$
    – DanM
    Oct 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\$
    – crasic
    Oct 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\$
    – DanM
    Oct 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\$
    – crasic
    Oct 5, 2021 at 16:04

1 Answer 1

1
\$\begingroup\$

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.

Under J1939/11 and J1939/15, the data rate is specified as 250 kbit/s, with J1939/14 specifying 500 kbit/s.

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.

\$\endgroup\$
10
  • \$\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\$
    – jay
    Oct 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\$
    – DanM
    Oct 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\$
    – jay
    Oct 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\$
    – DanM
    Oct 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.