Two other projects also deserve to be mentioned. The opendbc is attempt to make sense of CAN traffic in different cars, they reverse-engineer messages and provide descriptions to each. It's part of comma.ai open source autonomous driving effort. The other project is CANboat which does similar thing for NMEA2000 protocol used on boats.
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 a very technical person, and I honestly don't think I'd ever heard of it. I spent a decent bit of time looking on the site trying to figure out what it was before resorting to Google.
It's not a huge deal, but seems to me like it would be helpful, and worth the effort.
So no, I'd say it's actually not worth the effort to add an explanation. It may even give real users the wrong idea.
So you've never visited a web site, read a bit about a topic you knew nothing about, and then thought, "Wow, that sounds like something I'd like to get into?"
There are a lot of people out there who are curious about the world around them and enjoy expanding what they know instead of stagnating in a knowledge silo.
You seem to think I was nitpicking the post (unless I'm reading you wrong), and that was not at all my intention.
> CAN is obscure enough that I’d never heard of it.
These types of statements are why I said “insist”.
There is really is almost no way to make statements like these without sounding foolish. You’re asking us to posit some compelling reason that anything you don’t know is “obscure”!
As someone doing quite a bit of technical writing I’m sensitive to this topic because it really is a type of bikeshedding, which is a patently destructive criticism (even if usually unintentional). It might not be bikeshedding if one has some stronger evidence. My evidence is that CAN is in the marketing material for any automotive car scanner from $10 to $10000. It’s literally as ubiquitous as Ethernet in the US and Europe. As someone else mentioned this really doesn’t matter, what matters is if the term is obscure to the intended users/audience.
Tech writing is about economy, and there are thoughtful discussions to be had about what needs to be described, and what is assumed from the audience and providing an ideal user experience. Appeals to ones own experience unless you’re a member of a special audience are usually the worst.
But not what a CAN bus is. There's no harm in making the word blue.
CAN is also used outside of Automotive. Even Google is using it for their servers, or better for the redundant power supplies for their servers. HP is using it in their printers and copy-machines.
The thing is, there is always a technology you don't know. There is your preferred search engine and Wikipedia to help you with that knowledge, these days.
PS: These days almost everybody miss the difference between Ethernet and TCP/IP. While everybody talks about Ethernet most of the time TCP/IP is meant, not Ethernet.
I used it (as well as Cantools) for importing various CAN-specific data formats.
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
Many (all?) CAN standards transmit on redundant copper, in opposing polarities, making it really easy to identify a signal vs noise. https://en.wikipedia.org/wiki/CAN_bus#/media/File:CAN-Bus-fr...
It's like a one-wire serial signal, but redundant.
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.
And real time latency is not "dead simple". A low priority message will always lose out to a higher priority message on CAN. With ethernet a low priority task can flood the bus if the circumstances are right.
Also, which MCUs come with gigabit ethernet?
I answered the Formula 1 MCU's (Motor Control Unit). Maybe the official one from Illmore already (I think), and some of the internal ones used for testing (which I worked with).
The NASA Space Shuttle also had several dSpace controllers on board (RTLinux with special IO drivers) and I guess modern rockets and planes also will switch to Ethernet also. It's 1MHz vs 1GHz. It makes a difference when you can afford a fast CPU, i.e. high speed controller and you don't want to wait for CAN messages coming in every 1000 cycles.
You can just switch on the J1939 protocol in WireShark.
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.
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.
They're just generally slower and usually missing features of the newest ELM327 revisions.
The problem is if you just search for ELM327, most of them will be clones, so I just use the MCP2515 when I need lots of data, and use the ELM327 for basic stuff
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.
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.
I'm not surprised. I once had a conversation with some business lawyers that were specialized on what is easiest described as "IT law"  (mostly intellectual property, licensing, contract law, data privacy) who were working in the field of IT/software. You could talk with them about client-server and p2p systems or even basic encryption and data security, so they definitely knew a bit about technology.
They knew about open source software but I was surprised that they had never heard about source licenses nor about the creative common license. I tried to explain the basics to them but they didn't seem to get the concept of a license that could be reused by more than one licenser and were confused why a license would need a name (like 'MIT license'). In their view, licenses were always individual drafted documents with terms that needed to be negotiated with business partners or were imposed on customers. They didn't believe me that you don't create your own custom license for open source projects and thought that I was talking about copy&pasting bad license templates from the internet. When I told them the basic concept of the GPL they thought I was bullshitting them.
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).