Whilst swapping out the stereo in his car for a more modern Android based solution, [Aaron] noticed that it only utilised a single CAN differential pair to communicate with the car as opposed to a whole bundle of wires employing analogue signalling. This is no surprise, as modern cars invariably use the CAN bus to establish communication between various peripherals and sensors.
In a series of videos, [Aaron] details how he used this opportunity to explore some of the nitty-gritty of CAN communication. In Part 1 he designs a cheap, custom CAN bus sniffer using an Arduino, a MCP2515 CAN controller and a CAN bus driver IC, demonstrating how this relatively simple hardware arrangement could be used along with open source software to decode some real CAN bus traffic. Part 2 of his series revolves around duping his Android stereo into various operational modes by sending the correct CAN packets.
These videos are a great way to learn some of the basic considerations associated with the various abstraction layers typically attributed to CAN. Once you’ve covered these, you can do some pretty interesting stuff, such as these dubious devices pulling a man-in-the-middle attack on your odometer! In the meantime, we would love to see a Part 3 on CAN hardware message filtering and masks [Aaron]!
I can CAN, can U CAN?
B^)
Learning CAN in the automotive context is sort of like learning the Latin alphabet. Every manufacturer has their own language built on top of it. Furthermore there are regional dialects layered on top of that for many distinct vehicle models and car families. FCA vs Ford maybe like Italian vs English – both Latin alphabets. Mustang vs F150 is more like modern Australian slang vs 16th century Shakespearean English.. And most vehicles have a half-dozen isolated CAN busses – all with a different data dictionary.
Then there is Flex CAN, single-wire GM-LAN, and other variations. And CAN is quickly being replaced by MOST (EU) and Ethernet AVB (NA) for higher bandwidth transport needs in the vehicle.
CAN will be around for a long time, whether in cars or elsewhere (it is an industry standard that is widely used) – the electrical robustness and relative simplicity are hard to beat. MOST and Ethernet AVB are mostly targeting multimedia streaming (e.g. camera image, audio, video distribution within the vehicle) but the control connections for things like the engine ECU, dashboard buttons and gauges, etc. are still CAN and going to remain CAN (or some similar protocol).
So what you are saying is…
The bus in our cans will remain CAN for as long as it can.
Can is not a language, CAN is a Network hardware, Bus and a transport protocol. You are not responsible witb your application, to take ensure, that the data who is trasmitted, will receive the partners. CAN is like near every Fieldbus systems a half duplex bus. It works different as tcp/ip or so. The main difference is, that on CAN BUS, all frames are not addresses the receiver directly. Frames will broadcast on the BUS with their sender ID. The receivers uses programmed hardware filters, that could contains the valid sender addresses for the receiver. If the sender id is accepted , the receiver system will dispatch the received frame and do the frame depended processing for the received data. This processing is special in every case for the special use case.
This is an universal bus system for a bunch of different payloads ans data structures, that could transmitted. The receiver decide to get the frame or not just by the filters.
This is not depended on the brand of the controller or car. it’s depend on the use case of the data frames. In conclusion means this, that you maybe can attach a device on the CAN bus and do something , without the requirement to modify the sernders in the car.
As an example – you want to show the current speed of the car. If you know the filter setttings for the frames, you are able to receives that frames in your application too and process the payload data of the speed. Collisions detection and prevention is done by the hardware.
So, it’s not like a different language as more like different data tables and filter setting with differen sizes and payloads.
Actually, just two frames sizes are valid and some further advanced derivates like Pelican 2.0.
I’ve been hunting for info I’ve the last week to do exactly what he is doing with that same radio into the same car for my daughter!
Intermittently the radio stopes the car from going to sleep and drains the battery- I’m off to dissect his video and work and hopefully solve my problem as well …
Some new models of Welding Machines are using CAN bus for internal comunication
It’s funny but it’s true.
Not funny at all. CAN (especially CANOpen) is incredibly common in industrial systems.
I thought the blue pill’s STM32F103 had CAN periferal on chip. I wonder why add external MCP2515 then?
Yes good point. I think the external chip has very good Arduino libraries and support so that helps because configuring CAN using standard ARM libraries is not super easy. Infact, sparkfun used to make a CAN shield for the Arduino with that hardware so I suspect a lot of code already exists.
I added the MCP2515 to make it more versatile.
If someone wants to use an UNO or esp he can do it without problems.
Trying to find logic in people using “arduino” is a wide highway towards madness with few places to turn.
I have been using Teensy 4.0 with two TJA1055 Low speed faut tolerant CAN transcievers to make can gateway and being able to sniff, what is control unit behind sending.
Thanks Aaron! Very helpful videos.
I went thru the same journey when trying to integrate a similar chinese android radio into my older 2010 Chrysler T&C with dual rear video system. Built a CanHacker compatible arduino+mcp2515 sniffer.
You need to know the “canbox” (the dark grey dongle hanging from the dvd unit) is a device that translates the can bus to a serial command set understood by the android dvd’s “mcu” (yes the android system has a mcu that controls the mux and majority of the low level functionality of the dvd system which then talks to android, alot of things are not done in android).
This allows the dvd unit makers to sell the same (almost) dvd unit for many different cars by simply shipping a different “canbox”.
I sniffed the data coming from the oem entertainment system and the car and eventually figured out most of the control packets for the video and other things.
I also sniffed the data from the canbox to the car.
Finally I ended up building a can interceptor/mitm device based on the esp32 (it has 1 built in can bus, making it easier to do mitm at the speeds needed by my car)
This allowed me to change the packets from the canbox to the car and vice versa.
In my case the canbox was sending a packet that would force my entertainment system to turn off, so I modified the packet.
But why stop there?
I used the Bluetooth capability of the esp32 to then make an android app that can configure the esp32 settings of my program to control fade of the vans built in amp (its controlled via can bus), control what video goes to which rear screen, and a few other things the car does – oh and to also read some pid’s the car is sending and present it on the android screen.
A byproduct is also I was able to get the oem dvd player running on my bench and unlocked some features that you normally need a $200 3rd party dongle to do.
Ive been meaning to do a few blog entries on the above but its always so time consuming to make proper articles compared to just writing code and tinkering.
If anyone has any questions or wants some pictures reply/email and I will try and send what I have.
PS I also replaced the (ugly to me) analog clock on the T&C to a digital unit and looks oh so nice.
Hey there Nic, I am interested in the project you are talking about, Could you please email me the contetns you are refering to in your project?
Thanks!
naua@mail.com
Be careful here.
ICANN is something completely different.
UCAN has at least 27 different meanings: https://www.abbreviations.com/UCAN
Fortunately none seem to be related to slavery, or it will be outlawed soon.
Oops, this was meant to be a reply to the first post.
===================
As a more general remark. I find it strange Sigrok / Pulseview is not mentioned here. This FOSS Logic Analyser software can be bundled with EUR7 hardware to sniff CAN and more then 100 other protocols.
I’m getting more and more convinced that most hobbyists do not recognize the power of logic analysers for debugging microcontroller stuff.
It’s sort of “printf( )” on steroids. If you’ve got some unused serial interface on your microcontroller you can easily put out a byte on for example each function entry (sort of like assert) and on entry of ISR routines, to check if they are triggered and if they are triggered in the right time. This way you line up this debug trace with for example what happens on the CAN bus, and you can look back in history what happened in what order.
Sigrok / Pulseview together with a Saleaeae of UsBEE clone should be part of each “arduino” beginners kit.
There is no “intellectual property” conflict, as the CY7C68013A has no flash of it’s own, always has to download firmware from USB, and Sigrok comes with fx3lafw which is completeley rewritten for SDCC.