norly/elmcan

elm327 with wifi interface

Closed this issue · 3 comments

johnathana commented

I am trying to use the can327 module that comes with my distribution's kernel 6.2.8-100.fc36.x86_64. The device is using an open wifi network and you have to connect to 192.168.0.10:35000. It is working fine with regular mobile software were I can read ecu errors and see live data.

After some googling I found the command to forward pty to a tcp connection using socat:
socat -d pty,link=/dev/ttyUSB0,waitslave tcp:192.168.0.10:35000

Then I am following the documentation instructions:

# ldattach --debug  --speed 38400 --eightbits --noparity --onestopbit --iflag -ICRNL,INLCR,-IXOFF        30 /dev/ttyUSB0
ldattach: iflag (set/clear): 64/4352
ldattach: opened /dev/ttyUSB0
ldattach: set to raw 38400 8n1: cflag=0xbf
ldattach: line discipline set to 30

# ip link set can0 down && ip link set can0 type can bitrate 500000 && ip link set can0 up
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 38:00:25:8b:0a:5b brd ff:ff:ff:ff:ff:ff
35: can0: <NOARP,UP,LOWER_UP> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can

# dmesg
[25810.509171] can0: can327 on pts4.
[25851.397760] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

Then I use candump can0 and I don't get anything back.
I could use some help.

norly commented

I am surprised that you are naming the PTY created by socat /dev/ttyUSB0 - such names are reserved for real devices.
Could this lead to a naming clash on your system? Can you please retry with something like the following, where /root/mypty is a path on a regular file system, without mount options such as "nodev" set?

socat -d pty,link=/root/mypty,waitslave tcp:192.168.0.10:35000
ldattach --debug 30 /root/mypty

I have no experience with the WiFi connected OBD adapters, and no experience attaching can327 to virtual PTYs, but if the TCP port is truly just a forwarded raw serial port, then I suppose this should work.

I've left out the serial port configuration options to ldattach, since these are meaningless with a socat generated PTY.

johnathana commented

I made some progress following your instructions. Just for future reference I also used -v -x socat arguments to print the ongoing communication in hex and plaintext:

socat -d -x -v pty,link=/root/canpty,waitslave tcp:192.168.0.10:35000
ldattach --debug 30 /root/canpty
ip link set can0 down && ip link set can0 type can bitrate 500000 && ip link set can0 up

I am attaching the socat log.
I can see the message BUFFER FULL and the same frame repeats all the time using candump can0:

can0  130   [5]  45 F1 FD FF FF
norly commented

Congratulations, it looks like you have got it working! Thank you for showing that it works with WiFi adapters, too :)

As for the message repeating, that looks like some other device is sending the message, but not receiving a CAN acknowledgement. This can happen if the ELM327 is the only CAN interface on the bus, next to your target device. ELM327 before version 1.4b does not support the "AT CSM" command, which means that it does not ACK any frames while in ATMA mode. This is documented in the README and in the ELM327 datasheet, so please refer to them if you wish to know more:

(In the "Versions prior to 1.4b" paragraph)
https://github.com/norly/elmcan#known-limitations-of-the-controller

https://www.elmelectronics.com/products/dsheets/

To fix this, you can either:

a) send a CAN frame, any frame, as long as it doesn't disturb your target device. The ELM327 will then ACK frames it receives for about a second.
b) add another device to your CAN bus that does ACK frames.
c) buy an ELM327 based device with a newer version ELM327.
d) use a different, "real" CAN interface, such as the 8devices one.

The reason you see BUFFER FULL is because the ELM327 is spammed full of the other device repeating its message (because nobody ACKs it), and the ELM327 tries to relay it to you via its UART (which in this case is hidden from your sight, it's the connection between ELM327 and the WiFi chip). The UART operates at a much slower speed than the CAN bus, so the ELM327 cannot send the translated frames as quickly as it receives them, and its UART transmit buffer overflows. This results in the BUFFER FULL message. This is briefly mentioned, albeit somewhat hidden, in the README and in the ELM327 datasheet, which hopefully clarifies things further:

(at the end of the "Communication example" section)
https://github.com/norly/elmcan#communication-example

Thank you for testing this driver in a new configuration, and I wish you good luck and fun with your CAN project :)

  • 🚀1