What is the purpose of the DBC Feeder's elm2canbridge?

[sophokles73]

As described in the documentation, the elm2canbridge module makes use of several STN2100 specific ST commands and thus does not seem to work with generic ELM327 based dongles.

I was wondering if there are plans to extend support to ELM327 based dongles or if this module is simply here to support the Kuksa.val CANOPi dongle (and whatever chip set it is currently based on)?

[SebastianSchildt]

Originally the code was created for the first version of the KUKSA hardware, that only had an OBD interface based on the STN2120. It allows you to use the STN to listen to a "raw" CAN bus without begin limited to the OBD protocol.
While the current hardware version has native CAN ports, it still has an STN, that could act as "third" CAN interface. Even when not using all CANs, using the OBD port might still be "easier" in some situations, e.g. for Tesla vehicles there are aftermarket cables that make the vehicle CAN (just the raw CAN bus) available as a OBD socket (from mechanic, electric perspective), where you could plug the hardware directly.

The current code is limited to STN variants and does not work "native" ELMs or clones. That could however be changed in code. It even would need to be, as we are currently redesinging KUKSA hardware to not use STN2100 family chips but switching to "generic" ELM. The company doing the STN can not supply them anymore in any meaningful quantitiy and reasonable timeframe, and they do not have any useful kind of sales/support, so keeping them is a bad idea. See also eclipse-kuksa/kuksa-hardware#11

However, meanwhile the Linux CAN ecosystem moved forward, and there seems to be a Linux socketcan driver now for ELM chips: https://github.com/norly/elmcan/tree/master If we/someone could confirm that this works and document it, it would be a good chance to get rid of some code in DBC provider.

[sophokles73]

Thanks for the detailed information 👍

[sophokles73]

So, my understanding is that there would be no immediate benefit if I started to tidy up/improve the existing elm2canbridge, right? We should probably wait until you have settled for the new chip set or am I mistaken?

[SebastianSchildt]

Exactly, no immediate benefit reworking the code. There would be immediate benefit/learning trying the new kernel module, but that requires

• a ELM clone and or a current version of the KUKSA hardware
• A linux supported CAN Adapter (potentially even two, becasue an ELM might not do a "CAN ACK)
• A special "OBD-to-CAN" cable
• Time

Currently I would have all except the latter. But keeping this discussion open, latest when we have new samples of the hardware I would need to check that a bit anyway.

[erikbosch]

We have migrated CAN Provider (dbcfeeder) to a new repo. Long term my intention is to close all dbc/can-related issues in this repository. If we see the issue as still interesting or relevant we could create a new issue in the new repo, possibly referencing the old issue in the repository.

Suggested way forward:

• I will migrate selected issues early 2024
• If this issue has not been migrated but you want it to remain open please comment.
• Remaining issues no one seems to be interested in will be closed around 2024-03-31