Different baud rate for each channel?

[jschmidt]

Hello! An older computer system we use is set to be upgraded. It has a dual-channel PEAK miniPCIe to CAN adapter built in. Unfortunately the new computer won't have a miniPCIe slot or an available PCI slot, so I'm forced to use the PCAN-USB Pro device instead. This has come with some challenges!

The old miniPCIe card worked flawlessly. Channel 1 is configured for 1Mbit, while channel 2 is configured for 500k. All the connected devices (two devices on channel 1, 12 devices on channel 2) communicate perfectly.

Not so with the USB CAN interface. While channel 1 seems to communicate just fine, channel 2 is seeing no end of errors - lots of missing responses and intermittent data. Am I doing something wrong here? Can the PCAN-USB pro be configured for two different baud rates? Should I try to figure out the clock frequency of the old PCI interface and try to use that on this new USB device? The computer system is running Linux 22.04, so I'm just using the built-in driver.

Thanks in advance for any help!

[jschmidt]

Here's the result of running 'ip -details -statistics link show can1' Notice there are a few differences, the largest being that the USB interface is using an 80MHz clock wthile the PCI is just 8MHz. Will that actually make a difference?

miniPCIe:

can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000

USB:

can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 500000 sample-point 0.875
tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1
pcan_usb_pro_fd: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..1024 brp-inc 1
pcan_usb_pro_fd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..1024 dbrp-inc 1
clock 80000000

[M.Heidemann]

Hello,

Seems rather complicated at first but there is a relatively easy way to make that work:

Make sure the Sample-Point matches.

The easiest way to do is using our Bitrate Calculation Tool:

https://www.peak-system.com/Bit-Rate-Ca ... .html?&L=1

Use "CAN-Bitrate" for anything between 20 - 80 Mhz

You can use "SJA1000" for 8Mhz Bitrates..

Make sure you use the same bitrate-speed and sample point and you can then
go from there:

2025-02-07 07_56_31-Bit Rate Calculation Tool.png (32.16 KiB) Viewed 9955 times

Please try this and let me know, if this fixed the problem!

BR

Marvin

[jschmidt]

Thanks, that did help! I managed to get things working with an 80MHz clock by specifically setting the TQ and other values, with this command:

ip link set can1 type can tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

I will see if the linux driver allows me to switch to SJA1000 mode. I didn't see anything while poking around earlier.

[jschmidt]

Well, I can't find anything. It would seem that our old miniPCIe CAN card is defaulting to SJA1000 on both channels. However I can't figure out how to make the PCAN-USB Pro do the same thing! Clearly it's an option, since it is selectable when I connect it to a windows computer and use the PEAK utility to set the various options.

[jschmidt]

If possible, I do need help with configuring the PCAN-USB Pro FD in SJA1000 mode in Linux, using the built-in driver.

It would appear that our connected devices are fickle and while they sometimes work in regular CAN mode, more often than not something goes wrong during initialization and one or more nodes on the bus fail to connect to the network and then just fail consistently thereafter. SJA1000 seems rock solid.

[M.Heidemann]

Hello,

Please refer to the SocketCAN community regarding this, SJA1000 "mode" is just a different format for the bitrates used (all happens in userspace)

Check the documentation, this exceeds our support-scope.

BR

Marvin

[jschmidt]

Alright, I'll see if I can dig up the info I need there!

Thank you, by the way, for making an excellent product. The fact that this device always enumerates to the same interface names on every boot means that we can use it reliably.