Show HN: Cantools – an extensive set of CAN bus tools (opens in new tab)

If you saw a library for say Image Processing or cattle husbandry for Java/JVM would you insist that the project provide a description of “Java”? I’m going to guess if you’re being honest you’d say no. CAN really is not an obscure thing at all. Also it is ones of those things that if you don’t know what it is, you probably don’t need this. Otherwise the google burden is minimal for the curious.

I think the issue is that HN doesn't allow blurbs on link stories. A section like that doesn't make sense for a project that is targeted at an audience that already knows the basic jargon. OTOH, a HN post will reach a much wider audience and needs a description.

In this case, you could argue that if you don't know what CAN is, this tool is useless to you. Not all technical documents detail this kind of basic information. I routinely see tools for some technology that don't explain what that technology is. Maybe this is a bad idea, but if you don't work with widgets, then you probably don't need wiget-tools. CAN is a really big deal. It needs no more introduction than USB or TCP/IP, though maybe it would be a good idea to describe what those do too. The fact that you've never heard of it, doesn't make it some niche thing. I constantly see stuff I've never heard of on hacker news, that someone in another industry would assume "everybody knows about".

CAN is almost as old as Ethernet. While Ethernet where introduced in the 1980 and standardized in 1983, CAN where introduced in 1986 and standardized in 1992. So its interesting that a "very technical person" does not know established communication systems.

Yes.

It was used as an industrial communications bus to coordinate slave devices from a master controller. Drop-length was a non-issue as the majority of our devices used an in-rail (DIN mounted) interconnect bus. The larger "drops" were often a under 10" and just jumped one DIN rail to the next DIN rail in the cabinet.

This was selected for the following reasons:

1. These devices were installed in HEAVY EM environments (think in close proximity to very large electric motors) and the electrical characteristics

2. The system topology physically supported multi-drop

3. We had a good deal of talent with CAN experience

4. Our device was already supporting a bunch of wired and wireless protocols (rs422, rs485, ethernet, btle, wifi, etc) and tbh CAN support was a gimme on the SOM we used as the device's core, so initially it made it into consideration by chance

Yes. Motion controlling a Mammography device of one of the largest healthcare companies with CANopen in the early 2000s where one of the selling point over Ethernet was that CAN allowed message prioritisation without collisions, so for example the “emergency stop” message would have the highest priority.

Any (reliable) system you use is using CAN: medical devices, elevators, airplanes, robots, drohnes …

Google is using it internally for their servers. Many rack providers have implemented it for server rack monitoring, …

CAN is cheap. You get it in almost every micro-controller. Requires less overhead in micro-controllers than Ethernet. Is much more reliable than Ethernet if you leave controlled room conditions. It is mostly cheaper if you have to factor in all-over costs like cabling, switches, management.

It is everywhere where you don't see it, where you just care that the system needs to work with less management as possible.

A decent number micros support CAN natively without a PHY, (STM32), it works well over short to medium length link, and is just _vastly simpler_ than ethernet in both protocol and backend implementation. Nothing so complicated TCP/IP stack to deal with, programming for it is more akin to using a serial peripheral on your device.

It supports dead simple hard real time bus arbitration of messages for one.

Take a look at UAVCAN[0], it's a protocol for using CAN in other applications.

[0] https://new.uavcan.org/

You can get away with ELM327 based readers (the cheap bluetooth/Wi-Fi OBDII readers you see on Amazon/eBay) if you want fairly standard data like speed, and some manufacturer specific data in the form of PIDs (https://en.wikipedia.org/wiki/OBD-II_PIDs)

If you want more involved data, or to send messages, it's mostly sniffing, doing an action, and seeing what changes.

`can-utils` has a nice UI for this, which lets you filter messages that don't change easily.

(Also, I've actually never seen a `.dbc` file before, but it looks like a map of PIDs, usually you [or the community for your car] have to reverse engineer those with the sniffing method, afaik)

-

The ELM327 can technically stream all the CAN messages on the bus and do that type of sniffing, but it has a very small buffer and gets completely hosed with chatty cars.

I personally use the MCP2515 with a Raspberry PI for more involved car hacking.

https://www.raspberrypi.org/forums/viewtopic.php?t=141052

The electrical modification mentioned is needed for the most common MCP2515 modules because the PI isn't 5v tolerant, but it's an easy enough fix

I have two of them hooked up to a Raspberry PI (one for each of my car's CAN busses, some cars have more), and that with `can-utils` has gotten me pretty far.

The car doesn't define its own interface, so you're stuck using the Internet.

Overall the easiest place to start is a forum for your specific vehicle. You may get lucky with predefined services or someone else having done the reverse engineering for you.

If you don't get lucky, it depends on the manufacturer. In the case of European manufacturers you are best off if you can acquire the ASAM ODX material for your vehicle (sadly there is not an easy "clear market" way to do this - reverse engineering the manufacturer's diagnostic tool is often easiest). This will define in a very complete manner the available services on your vehicle. Some aspects will still be proprietary, usually specified as DLL files referenced in the ODX (for example, the Seed/Key authentication algorithm for flashing VW vehicles). These you will have to find references to on forums or reverse engineer yourself.

I don't think you can pull a DBC file off of a vehicle. I think you have to build the DBC file yourself by reverse engineering everything--you'd monitor the CAN network, and then turn the light on and off, sit in the driver set, etc. The DBC file is the car's secret sauce.

I was thinking the same question. I could only find C++ implementation at https://github.com/ttlappalainen/NMEA2000 which I assume you have found as well.

Different project, but maybe this helps.

https://github.com/canboat/canboat

NMEA2000 is the marine electronics flavored J1939. Everything but the data dictionary is J1939.

You can just switch on the J1939 protocol in WireShark.

I cant tell you how many times I've seen this type of thing done at different companies. Many of those projects died.

The last one was a LIN tool written in python. My coworker wrote it. He wanted to open source it, so I talked our boss, the local IP guy and eventually the legal department. Legal thought I wanted them to write a license. No, that's not useful, I needed to know which of GPL, MIT, BSD the company would approve. They came with some of the misguided concerns companies tend to have. The other question I could not get answered is who in management needed to OK it. Oh and would the copyright belong to the company or the guy who wrote it. None of my questions could seem to find definitive answers. The guy who wrote the tool quit and it became abandon ware inside the company. I had mentioned that nobody stays around forever and the author would have done some maintenance after he's gone. I said this well before he left as an argument in favor of open sourcing it.

Anyway, I hope a lot of people bring this to life so we can all stop reinventing this wheel or paying certain companies to rent theirs.

Related: Busmaster, but its Windows only.

Any chance this unholy mix is open sourced?

Perhaps CANdevStudio would be what you are looking for?

https://github.com/GENIVI/CANdevStudio

I've recently become interested in a can bus sim, actually. If you know of any resources I would appreciate any pointers.

> The industry so far is very closed and rejects concept of interoperability. It's nice that somebody is taking steps in right direction.

Sadly very true. I've worked in the industry, and while there has been a lot of standardization, there's definitely not a lot of interoperability. Car makers and tier 1 suppliers in my experience are very insistent on keeping their knowledge in-house, distrustful of open source tools and extremely unwilling to share any technical information that could lead to greater interoperability.

I'm glad you find it useful.

In industrial automation there are mainly 2 standard protocols, which can obtain easily: DeviceNet and CANopen.

Welp this makes my day-job a touch simpler now. Thank you for the heads up!

Different use cases in my opinion.

As it is described this would more likely meet the use-cases of CANalizer (sniffing, logging, lightweight scripting) but not CANoe (bus simulation, node simulation full on HIL Simulation).

Yeah, using -L you can shell redirect to a workable log file. I've done this a few times. They also build the asc2bin conversion utility to convert any logs to the more common *.bin format.