2-Channel CAN-BUS(FD) Shield for Raspberry Pi performance fluctuation

Hi!

I’m using the 2-Chennel CAN BUS on top of a Raspberry Pi 4 and configured following the information from here.

I wanted to do some preliminary benchmarks on a toy example. So I connected the can0 interface to the can1 interface as suggested in the documentation. I’ve written a simple ping/pong program using python-can where I first send a message (plain CAN) on CAN0 and then receive it on CAN1. I measure the time necessary to do the whole send and receive.

bus_send = can.interface.Bus(bustype='socketcan', channel='can0', fd=True)
bus_recv = can.interface.Bus(bustype='socketcan', channel='can1', fd=True)

msg = can.Message(arbitration_id=0x42, data=[0x01, 0x02, 0x03, 0x04])

while True:
    dt = []

    for _ in range(1000):
        t0 = time.time()
        bus_send.send(msg)
        resp = bus_recv.recv()
        t1 = time.time()

        dt.append(t1 - t0)

        if resp.error_state_indicator:
            print(f'Error: {resp}')

    dt = np.array(dt) * 1000
    print(f'M={np.round(dt.mean(), 1)}ms STD={np.round(dt.std(), 1)}')

The results I’ve got are most of the time it’s about 0.4ms but sometimes it gets up to 10ms (averaged on 1000 send/recv). I don’t have any other software running at the same time on the RaspberryPi. It could some times run for minutes at 0.4ms and then jump to 10ms for dozen of seconds to 10ms, then back to 0.4, etc.

Do you know what could explain such huge differences?

This may not be the right way to measure it . You need to test the actual physical signal with the CAN BUS analyzer,

Sure, never claim it was an accurate measure. I’ve ordered an analyser and will use it as well.

Yet, the analyser will not tell me much about the time spent inside the driver right? Which I would guess is where we can explain such long delay (10ms). How do you suggest I scientifically measure that part?

I think there are two ways.

  • to measure the delay of the physical signal;
  • use microcomputer to measure delay at the receiving end.