This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR1642: The delay time after arbitration on MCAN of AWR1642

Guru 16800 points
Part Number: AWR1642

Hello,

Could you tell me the delay time after arbitration on MCAN of AWR1642?
If several devices are connected on CAN bus and a collision occurs, the arbitration is executed and the device having lower ID continues sending the frame.
Therefore, the device having upper ID must try to send the frame again, I think.
I want to know the time between the first frame and the second (re-sent) frame.

Best Regards,
Nomo

  • Hello Nomo,

    This time could depend on the message length and the also on priority of the message and also on the load on the bus due to other nodes on the bus.

    It would part of your system design to keep this timing optimal .

    Thanks,
    -Raghu
  • Hello Raghu-san,

    Thank you for your reply.
    However, in my customer's case, although the node's priority is the highest and the bus load doesn't seem heavy, the message from the node is delayed.
    My customers want to optimize the delay time and can we adjust the time manually?
    Or is the time calculated by the CAN standard?

    Best Regards,
    Nomo
  • Hello Nomo-san,
    Do you have the trace log of the received CAN message to know the delay ?

    -Raghu
  • Hello Raghu-san,

    I attached the log of the CAN bus monitor software.
    This delay can be seen in the case two AWR1642 modules are connected to the CAN bus.
    In case one AWR1642 module and other mmwave module are connected, the delay doesn't appear.
    So, in case the collision happened, because the timing of the resend is same, is there possibility to occur collisions periodically?
    Is the delay time after the collision decided randomly?

    The following is the log.
    Each line is series of a sequence number, a time stamp in ms, DT, an ID, Rx and data length.
    The ID around 03xx and 05xx are the frame from the module of AWR1642 and others are the module of not AWR1642.
    The ID around 03xx should be appeared 50ms.
    Although the first 0304 is at 5384.332 and the second one should be around at 5434, the second one is at 5458.626, so delay is about 25ms.

    7846 5384.332 DT 0304 Rx 8
    7847 5384.580 DT 0301 Rx 8
    7848 5384.828 DT 0302 Rx 8
    7849 5385.074 DT 0303 Rx 8
    7850 5385.320 DT 0305 Rx 8
    7851 5385.568 DT 0306 Rx 8
    7852 5385.815 DT 0307 Rx 8
    7853 5386.061 DT 0308 Rx 8
    7854 5386.307 DT 0309 Rx 8
    7855 5386.553 DT 030A Rx 8
    7856 5386.799 DT 030B Rx 8
    7857 5387.045 DT 030C Rx 8
    7858 5387.291 DT 030D Rx 8
    7859 5387.535 DT 030E Rx 8
    7860 5387.779 DT 030F Rx 8
    7861 5388.027 DT 0310 Rx 8
    7862 5388.272 DT 0311 Rx 8
    7863 5388.520 DT 0312 Rx 8
    7864 5389.732 DT 0502 Rx 8
    7865 5389.970 DT 0501 Rx 8
    7866 5390.220 DT 0503 Rx 8
    7867 5390.468 DT 0504 Rx 8
    7868 5390.716 DT 0505 Rx 8
    7869 5390.964 DT 0506 Rx 8
    7870 5391.210 DT 0507 Rx 8
    7871 5391.460 DT 0508 Rx 8
    7872 5391.707 DT 0509 Rx 8
    7873 5391.953 DT 050A Rx 8
    7874 5392.199 DT 050B Rx 8
    7875 5392.445 DT 050C Rx 8
    7876 5392.691 DT 050D Rx 8
    7877 5392.935 DT 050E Rx 8
    7878 5393.179 DT 050F Rx 8
    7879 5393.427 DT 0510 Rx 8
    7880 5393.673 DT 0420 Rx 8
    7881 5393.916 DT 0511 Rx 8
    7882 5394.164 DT 0620 Rx 8
    7883 5394.406 DT 0512 Rx 8
    7884 5394.658 DT 0520 Rx 8
    7885 5403.532 DT 0420 Rx 8
    7886 5403.816 DT 0620 Rx 8
    7887 5404.097 DT 0520 Rx 8
    7888 5413.547 DT 0420 Rx 8
    7889 5413.831 DT 0620 Rx 8
    7890 5414.111 DT 0520 Rx 8
    7891 5423.530 DT 0420 Rx 8
    7892 5423.818 DT 0620 Rx 8
    7893 5424.094 DT 0520 Rx 8
    7894 5427.050 DT 0400 Rx 8
    7895 5427.295 DT 0401 Rx 8
    7896 5427.533 DT 0402 Rx 8
    7897 5427.777 DT 0403 Rx 8
    7898 5428.022 DT 0404 Rx 8
    7899 5428.264 DT 0405 Rx 8
    7900 5428.506 DT 0406 Rx 8
    7901 5428.749 DT 0407 Rx 8
    7902 5428.997 DT 0408 Rx 8
    7903 5429.241 DT 0409 Rx 8
    7904 5429.486 DT 040A Rx 8
    7905 5429.734 DT 040B Rx 8
    7906 5429.984 DT 040C Rx 8
    7907 5430.230 DT 040D Rx 8
    7908 5430.477 DT 040E Rx 8
    7909 5430.725 DT 040F Rx 8
    7910 5430.973 DT 0410 Rx 8
    7911 5431.220 DT 0411 Rx 8
    7912 5431.468 DT 0412 Rx 8
    7913 5431.714 DT 0413 Rx 8
    7914 5431.969 DT 0414 Rx 8
    7915 5432.213 DT 0415 Rx 8
    7916 5433.521 DT 0420 Rx 8
    7917 5433.809 DT 0620 Rx 8
    7918 5434.085 DT 0520 Rx 8
    7919 5435.826 DT 0502 Rx 8
    7920 5436.076 DT 0501 Rx 8
    7921 5436.324 DT 0503 Rx 8
    7922 5436.574 DT 0504 Rx 8
    7923 5436.822 DT 0505 Rx 8
    7924 5437.068 DT 0506 Rx 8
    7925 5437.314 DT 0507 Rx 8
    7926 5437.560 DT 0508 Rx 8
    7927 5437.804 DT 0509 Rx 8
    7928 5438.051 DT 050A Rx 8
    7929 5438.295 DT 050B Rx 8
    7930 5438.543 DT 050C Rx 8
    7931 5438.787 DT 050D Rx 8
    7932 5439.031 DT 050E Rx 8
    7933 5439.277 DT 050F Rx 8
    7934 5439.525 DT 0510 Rx 8
    7935 5439.769 DT 0511 Rx 8
    7936 5440.013 DT 0512 Rx 8
    7937 5443.537 DT 0420 Rx 8
    7938 5443.822 DT 0620 Rx 8
    7939 5444.102 DT 0520 Rx 8
    7940 5453.549 DT 0420 Rx 8
    7941 5453.833 DT 0620 Rx 8
    7942 5454.114 DT 0520 Rx 8
    7943 5458.626 DT 0304 Rx 8
    7944 5458.876 DT 0301 Rx 8
    7945 5459.124 DT 0302 Rx 8
    7946 5459.372 DT 0303 Rx 8
    7947 5459.618 DT 0305 Rx 8
    7948 5459.864 DT 0306 Rx 8
    7949 5460.110 DT 0307 Rx 8
    7950 5460.359 DT 0308 Rx 8
    7951 5460.605 DT 0309 Rx 8
    7952 5460.849 DT 030A Rx 8
    7953 5461.093 DT 030B Rx 8
    7954 5461.339 DT 030C Rx 8
    7955 5461.583 DT 030D Rx 8
    7956 5461.827 DT 030E Rx 8
    7957 5462.071 DT 030F Rx 8
    7958 5462.317 DT 0310 Rx 8
    7959 5462.563 DT 0311 Rx 8
    7960 5462.810 DT 0312 Rx 8


    Best Regards,
    Nomo
  • Hello Raghu-san,

    Do you have any update on my thread?

    Best Regards,
    Nomo
  • Hello Nomo-san,

    For the theoretical calculation of the time taken for fixed  number of bytes on a CAN network you can refer to link .

    You can consider a actual throughput to be about 90% of theoretical value due to various latencies in the system.

    Hope this is helpful.

    -Raghu

  • Hello Raghu-san,

    Thank you for your reply.
    I check the link you attached. (Baud Rate: 500kbps, Shortest Message: 8 bytes, Longest Message: 8byte)
    From the site, in case the ID is 11-bit, the best-case data bandwidth is 288.29kbps (actual will be 288.29 x 0.9 = 259.46kbps).

    Although the calculated bandwidth from the above log is 94.35kbps which is much lower than the expected bandwidth, the delay of packet is about 25ms (It's so large).

    Could you tell me the probable cause to be made this big delay?

    Best Regards,
    Nomo
  • Hello Nomo-san,

    When a message loses an arbitration, it can re-try(participate again in the arbitration) once the current message(which has won the arbitration) on the bus is completely transmitted, given that auto-retransmission is enabled.

    In your case, you are using 500Kbps as bit-rate and payload is 8 bytes.
    Time for 1 message on the bus(108 bits for 11 bit ID) = 216 us.

    This is the re-try time for the message to participate in the arbitration again.
    This will increase if any other high priority messages than current message are pending for transmission.
    This depends on the system design and directly depends on the number of high priority messages pending.

    Hope this helps the understanding.

    -Raghu
  • Hello Raghu-san,

    Thank you for your reply.
    My customers have tried to raise the data rate (from 500kbps to 1Mbps) and reduce the number of transmitted messages; however, the result isn't improved.
    Although I think the messages should be re-tried after the bus is free, the delay time is large (more than 20ms).
    Also, they've checked the priority of the frames and the frames which should be re-tried have higher priority than any other frames.
    Could you tell me the advice to improve this problem?

    Best Regards,
    Nomo
  • Hello Nomo-san,

    Can you post the code?
    I think the delays you mentioned seem to be the software latencies and not related to CAN IP or CAN protocol.

    -Raghu
  • Hello Namo-san,

    Hope above information helped. I am closing this thread. Please start a new thread if you have more questions.

    Regards,
    Kaushal
  • Hello Kaushal-san,

    Thank you for your reply.
    When I have more questions, I'll create a new thread.

    Best Regards,
    Nomo