Stepper motors are a great solution for accurate motion control. You’ll see them on many 3D printer designs since they can precisely move each axis. Steppers find uses in many robotics projects since they provide high torque at low speeds.
Since steppers are used commonly used for multi-axis control systems, it’s nice to be able to wire multiple motors back to a single controller. We’ve seen a few stepper control modules in the past that take care of the control details and accept commands over SPI, I2C, and UART. The AnanasStepper 2.0 is a new stepper controller that uses CAN bus for communication, and an entry into the 2017 Hackaday Prize.
A CAN bus has some benefits in this application. Multiple motors can be connected to one controller via a single bus. At low bit rates, it can work on kilometer long busses. The wiring is simple and cheap: two wires twisted together with no shielding requirements. It’s also designed to be reliable in high noise environments such as cars and trucks.
The project aims to implement an API that will allow control from many types of controllers including Arduino, Linux CNC, several 3D printer controllers, and desktop operating systems. With a few AnanasSteppers one of these controllers, you’d be all set up for moving things on multiple axes.
Prolific hacker [kodera2t] is working on his own “ESP32 monster board” dev board for the still-newish ESP32 WiFi module. His board has everything: Ethernet, OLED, LiPo, and even CAN-bus. But all that peripheral connectivity is worth nothing if you can’t program the microcontroller to use it.
The Arduino environment for the ESP32 is coming along quite nicely, but it’s not yet fully featured enough to run all of [kodera2t]’s hardware. To take advantage of all that, he needs to use Espressif’s SDK — called the “IoT Development Framework” or IDF for short. In his latest project log, [kodera2t] goes through everything necessary to get the IDF up and compiling on OSX. (It’s strangely similar to the Linux procedure.) Read through the official instructions here, if you want more, but we think [kodera2t] hits all the high points.
While most of us will never set foot in a fighter jet, some of us can still try to get as close as possible. One of the most eye-catching features of a fighter jet (at least from the pilot’s point-of-view) is the heads-up display, so that’s exactly what [Frank] decided to build into his car to give it that touch of fighter jet style.
Heads-up displays use the small reflectivity of a transparent surface to work. In this case, [Frank] uses an LED strip placed on the dashboard to shine up into the windshield. A small amount of light is reflected back to the driver which is able to communicate vehicle statues without obscuring view of the road. [Frank]’s system is able to display information reported over the CAN bus, including voltage, engine RPM, and speed.
This display seems to account for all the issues we could think up. It automatically cycles through modes depending on driving style (revving the engine at a stoplight switches it to engine RPM mode, for example), the LEDs automatically dim at night to avoid blinding the driver, and it interfaces with the CAN bus which means the ability to display any other information in the future should be relatively straightforward. [Frank] does note some rough edges, though, namely with the power supply and the fact that there’s a large amount of data on the CAN bus that the Teensy microcontroller has a hard time sorting out.
That being said, the build is well polished and definitely adds a fighter jet quality to the car. And if [Frank] ever wants even more aviation cred for his ground transportation, he should be able to make use of a 747 controller for something on the dashboard, too.
The CAN bus has become a staple of automotive engineering since it was introduced in the late ’80s, but in parallel with the spread of electronic devices almost every single piece of equipment inside a car has been put on the CAN bus. While there are opinions on whether or not this is a good thing, the reality is that enough data is gathered on this bus to turn an unmodified modern car into a video game controller with just a little bit of code.
The core of [Scott]’s project is a laptop and a Python program that scrapes information about the car from the car’s CAN bus, including positions of the pedals and the steering wheel. This information can be accessed by plugging an adapter into the OBD-II port (a standard for all cars made after 1995). From there, the laptop parses the CAN data into keyboard and mouse commands for your video game of choice.
This is an interesting investigation into the nitty-gritty of the CAN bus, but also a less dangerous demonstration of all of the data available from the car than some other cases we’ve seen. At least [Scott]’s Mazda (presumably) lacks any wireless attack vectors!
The CAN bus is a rich vein to mine for a hacker: allowing the electronic elements of most current vehicles to be re-purposed and controlled with ease. [MikrocontrollerProjekte] has reverse engineered a CAN bus media and navigation controller and connected it to an STM32F746G-Discovery board. The STM32 is in turn connected to an Android phone, and allows the media controller to trigger a large number of functions on the phone, including music playback, maps, and general Android navigation.
When reverse engineering the controller, [MikrocontrollerProjekte] employed a variety of approaches. A small amount of information was found online, some fuzzing was done with random CAN bus IDs and messages, as well as some data logging with the device inside the car to identify message data to the relevant IDs on the bus.
The STM32F746G-Discovery board acts as a Human Interface Device (HID), emulating a mouse and keyboard connected to the Android phone via USB OTG. The LCD screen shows the output of the keystrokes and touchpad area. We’re not sure how useful the mouse-emulation would be, given that the phone has a touchscreen, but the media functions work really well, and would also make a really snazzy music controller for a PC.
Part of the fun of watching action movies is imagining yourself as the main character, always going on exciting adventures and, of course, being accompanied by the perfect soundtrack to score the excitement and drama of your life. While having an orchestra follow you around might not always be practical, [P1kachu] at least figured out how to get some musical orchestration to sync up with how he drives his car, Fast-and-Furious style.
The idea is pretty straightforward: when [P1kachu] drives his car calmly and slowly, the music that the infotainment system plays is cool and reserved. But when he drops the hammer, the music changes to something more aggressive and in line with the new driving style. While first iterations of his project used the CAN bus, he moved to Japan and bought an old Subaru that doesn’t have CAN. The new project works on something similar called Subaru Select Monitor v1 (SSM1), but still gets the job done pretty well.
The hardware uses an Asus Tinkerboard and a Raspberry Pi with the 7″ screen, and a shield that can interface with CAN (and later with SSM1). The new music is selected by sensing pedal position, allowing him to more easily trigger the aggressive mode that his previous iterations did. Those were done using vehicle speed as a trigger, which proved to be ineffective at producing the desired results. Of course, there are many other things that you can do with CAN bus besides switching up the music in your car.
Video games, while entertaining to be sure, are a great way to experience things that could not easily be recreated in real life. Shooting aliens on a giant ring in space is an obvious example, but there are some more realistic examples that video games make much more accessible, such as driving a race car. You can make that experience as realistic as you want, too, and can even go as far as using a real car as your controller.
All modern cars use a communication system to allow their various modules to talk to one another. Fuel injection, throttle position, pedal positions, steering wheel angle, and climate control systems can all communicate on the CAN bus, and by tapping into that information the car can be used as a controller for a video game. Once you plug in to the OBD-II port on a car, you’ll need a piece of software to decode all of that information. [Andrew] uses uinput, a tool that allows Linux machines to take any input signal and map it in any way that can be programmed.
The build also includes the use of an integrated pico projector, allowing the car to be parked and turned into a simulator at any time. It’s similar to another project which used a Mazda instead of a Chevrolet Volt, but it just goes to show how straightforward it can be to take information from the CAN bus of a modern car.
In the old days, a physical button or switch on the dashboard of your car would have been wired to whatever device it was controlling. There was potentially a relay in the mix, but still, it wasn’t too hard to follow wires through the harness and figure out where they were going. But today, that concept is increasingly becoming a quaint memory.
Assuming your modern car even has physical buttons, pushing one of them likely sends a message over the CAN bus that the recipient device will (hopefully) respond to. Knowing how intimidating this can be to work with, [TJ Bruno] has been working on some software that promises to make working with CAN bus user interfaces faster and easier. Ultimately, he hopes that his tool will allow users to rapidly integrate custom hardware into their vehicle without having to drill a hole in the dashboard for a physical control.
But if you’re the kind of person who doesn’t like to have things done for them (a safe bet, since you’re reading Hackaday), don’t worry. [TJ] starts off his write-up with an overview of how you can read and parse CAN messages on the Arduino with the MCP2515 chip. He breaks his sample Sketch down line by line explaining how it all works so that even if you’ve never touched an Arduino before, you should be able to get the gist of what’s going on.
As it turns out, reading messages on the CAN bus and acting on them is fairly straightforward. The tricky part is figuring out what you’re looking for. That’s where the code [TJ] is working on comes in. Rather than having to manually examine all the messages passing through the network and trying to ascertain what they correspond to, his program listens while the user repeatedly presses the button they want to identify. With enough samples, the code can home in on the proper CAN ID automatically.
This has been an interesting week. First off, security researchers at Armis discovered a set of serious vulnerabilities in the vxWorks Real Time Operating System (RTOS). Released under a name that sounds like the title of a western or caper movie, Urgent/11. Not familiar with vxWorks? It’s a toss-up as to whether vxWorks or Linux is more popular for embedded devices. Several printer brands, Arris modems, Sonicwall firewalls, and a whole host of other industrial and medical devices run the vxWorks RTOS.
Several of these vulnerabilities are in the network stack, rather than in applications. The worst offender is CVE-2019-12256, a vulnerability in error handling. An ICMP error response is generated from an incoming packet, and assumptions are made about that incoming packet. When data is copied from that packet into the ICMP error, the length is not first checked, allowing unconfined memory write. If this sounds familiar, it should. We covered a similar vulnerability in Apple’s XNU kernel not long ago.
This particular vulnerability can compromise a vxWorks machine even without an opened port. The saving grace of that vulnerability applies here: a maliciously crafted packet is necessarily malformed, and won’t navigate public routing. In other words, it’s LAN only, and can’t be sent over the internet.
They come in through the firewall.
A second class of vulnerability, where the name comes from, is related to the TCP urgent pointer. This rarely used TCP feature was intended to allow more up-to-date information to supersede data still being processed. Not only has TCP urgent not been widely used, the specifications were not written particularly well, with the various RFC documents describing conflicting implementations. It’s surprising that vxWorks supports it at all, but isn’t particularly surprising that their implementation is flawed. Manipulation of the data stream can cause a length integer to underflow. The nature of binary arithmetic means that underflowing an unsigned integer causes it to wrap around to maximum value, which can lead to writing packet data in the buffer in unexpected memory locations. These vulnerabilities require an established TCP connection, but the researchers describe several scenarios where that could be accomplished by an attacker.
The last RCE vulnerability they describe is in the DHCP client, ipdhcpc. This is a very simple vulnerability. One section of code allocates a buffer for DHCP options, but allocates 24 bytes fewer than the maximum size. An attacker could use this 24 byte overflow to manipulate the data structure and potentially jump execution into manipulated memory.
Update (2019-08-02 09:15 UTC-7): Hackaday received a statement from SonicWall that they made a patch for this vulnerability back on July 19th:
Ensuring the security of our customers is a responsibility we take seriously at SonicWall and we work vigilantly to always keep our customers secure. SonicWall physical firewall appliances running certain versions of SonicOS contain vulnerabilities in code utilized for remote management. At this time, there is no indication that the discovered vulnerabilities are being exploited in the wild. The patches are available now and we strongly advised our partners and end users July 19 th to apply the SonicOS patch immediately.
Capital One made use of Amazon AWS for storing customer data. This isn’t surprising, many companies have turned to Amazon’s seemingly inexhaustible cloud computing platform for storing large data sets. It seems, however, that Capital One failed to configure the security properly on that bucket. (As many other companies have done.) Information was leaked for over an estimated 100 million customers. A former Amazon employee has been arrested, and seems to have posted at least a portion of that data in a Github gist.
Reading between the lines, it seems that this was a very simple mistake. Perhaps credentials were leaked, or the S3 bucket was publicly available. That particular detail has not been released. There is something to be said for Capital One’s response to the incident. They were anonymously informed of the existence of the gist on July 17, using their responsible disclosure process. By the 29th, they had fixed the misconfiguration, coordinated with law enforcement, and publicly announced the breach. A twelve day turn-around is an impressive response, particularly when so many companies have tried to hide or ignore similar breaches.
Cabarrus County, NC
It seemed simple enough. The general contractor for the county’s new school building needed to update bank account information. The appropriate forms were signed and filed, and the information was updated. Nothing seemed amiss unto two months later, when the contractor notified the county that they had missed a scheduled payment of 2.5 million dollars. But the transaction went through, and the money was transferred to the account on file.
Yes, the transfer went through, but the the county had been hit with a social engineering scam. The report refers to it as an Email Account Compromise (EAC) scam, which seems to indicate that the scammer first gained access to a legitimate email account of the contractor in question. Alternatively, an attacker could simply spoof the sender’s email address, and set a different reply-to field. Unless a user was particularly watching for such a scheme, it would be easy to overlook the discrepancy. In any case, even after recovering some of the transferred money, the county seems to be out about $1.7 million. These scams are becoming more and more popular, so remember, don’t believe anything you read in an email.
The Weird and Wacky
And to round out this week’s news, yet another [Satoshi Nakamoto] candidate has been found: Linus Torvalds. While it appears to be a serious suggestion, I’ll just note that the author doesn’t have his name attached to this article. He does make one interesting observation — git is the killer blockchain app. You see, I tend to compare blockchain to the laser. Both were very clever inventions, but didn’t have any immediate uses. They were solutions in search of a problem. This article points out that core concepts of blockchain are present in git, which seems to be an accurate and clever observation. So what is blockchain good for? Git!
When [Nishanth]’s Subaru BRZ came to a sudden halt, he was saddened by the wait to get a new engine installed. Fortunately, he was able to cheer himself up by hacking it into a car simulator in the mean time. This would have the added benefit of not being limited to just driving on the Road Atlanta where the unfortunate mishap occurred, but any course available on Forza and similar racing games.
On paper it seemed fairly straight-forward: simply tap into the car’s CAN bus for the steering, throttle, braking and further signals, convert it into something a game console or PC can work with and you’re off to the races. Here the PC setup is definitely the cheapest and easiest, with a single part required: a Macchina M2 Under the Dash kit ($97.50). The XBox required over $200 worth of parts, including the aforementioned Macchina part, an XBox Adaptive Controller and a few other bits and pieces. And a car, naturally.
The Macchina M2 is the part that listens to the CAN traffic via the OBD2 port, converting it into something that resembles a USB HID gamepad. So that’s all a matter of plug’n’play, right? Not so fast. Every car uses their own CAN-based system, with different peripherals and addresses for them. This means that with the Macchina M2 acquired, [Nishanth]’s first task was to reverse-engineer the CAN signals for the car’s controls.
At this point the story is pretty much finished for the PC side of things, but the XBox One console is engineered to only accept official peripherals. The one loop-hole here is the Adaptive Controller, designed for people with disabilities, which allows the use of alternative inputs. This also enables using a car as an XBox One controller, which is an interesting side-effect.
One final gotcha with the XBox version was that the Adaptive Controller doesn’t allow one to control the triggers from its USB port, so they had to use the 3.5 mm (analog) inputs on the controller via an additional circuit to add this functionality. With that out of the way, they were ready to try out some games.
For home use IoT systems, getting sensor data from tons of physical locations centralized to a single Raspberry Pi can be a difficult job, especially when considering the power consumption that’s necessary for doing it all over WiFi. When you’re using an ESP8266, for instance, swapping out batteries and accounting for connectivity issues can be a major hassle for a long-term solution. The NoCAN platform, created by [Alain Pannetrat], solves this problem using a wired approach that improves the use of the CAN bus.
Since SPI and I2C only work for short distances, approaches like RS-485 and CAN bus are a better bet for this type of setup. For systems with one centralized point, RS-485 works best – thus, the CAN bus is the better approach when you’re considering using multiple masters in a single environment.
CAN devices typically need a static address, so messaging involves sending data to the known address of the destination device. With NoCAN, a dynamic address assignment scheme allows nodes to request an address from a node manager on boot-up (similar to DHCP). A command line application also allows users to send and receive message from nodes using a pub/sub implementation – a device sends messages to a channel, and every device subscribed to the channel receives the message.
The hardware for the NoCAN platform consists of a Raspberry Pi with a “PiMaster” HAT and an Arduino-compatible CANZERO board. The PiMaster HAT uses an STM32F042 ARM Cortex M0 MCU, acting as an interface between the Pi and the CAN bus as well as preventing over-current events with a software-controlled smart switch. The CANZERO is based on the the SAMD21G18 ARM Cortex M0+ running at 48MHz, similar to the Arduino MKR Zero, with CAN bus networking using the STM32F042 ARM Cortex M0. The double MCU design allows the secondary MCU to reset the primary if it gets stuck due to a programming error, with the messages sent over the CAN bus.
To join the network together, a four-wire cable daisy-chains the nodes in the bus network, providing connectivity for up to 1000 feet. Either 12V or 24V DC power runs through the network, stepping down to 5V or 3.3V at each node. The approach is similar to PoE (power over Ethernet), although it is slower and lower in cost. Overall, it seems like a good solution for environments where wireless connectivity simply doesn’t cut it.
Progress and the proliferation of computers in automotive applications have almost made the shade tree mechanic a relic of the past. Few people brave the engine compartment of any car made after 1999 or so, and fewer still dive into the space behind the dashboard. More’s the pity, because someone may be trying to turn back the odometer with one of these nefarious controller area network (CAN bus) dongles.
Sold through the usual outlets and marketed as “CAN bus filters,” [Big Clive] got a hold of one removed from a 2015 Mercedes E-Class sedan, where a mechanic had found it installed between the instrument cluster and the OEM wiring harness. When the dongle was removed, the odometer instantly added 40,000 kilometers to its total, betraying someone’s dishonesty.
[Big Clive]’s subsequent teardown of the unit showed that remarkably little is needed to spoof a CAN bus odometer. The board has little more than an STM32F microcontroller, a pair of CAN bus transceiver chips, and some support circuitry like voltage regulators. Attached to a wiring harness that passes through most of the lines from the instrument cluster unmolested while picking off the CAN bus lines, the device can trick the dashboard display into showing whatever number it wants. The really interesting bit would be the code, into which [Clive] does not delve. That’s a pity, but as he points out, it’s likely the designers set the lock bit on the microcontroller to cover their tracks. There’s no honor among thieves.
We found this plunge into the dark recesses of the automotive world fascinating, and [Big Clive]’s tutelage top-notch as always. If you need to get up to speed on CAN bus basics, check out [Eric Evenchick]’s series on automotive network hacking.
In the days of carburetors and leaf spring suspensions, odometer fraud was pretty simple to do just by disconnecting the cable or even winding the odometer backwards. With the OBD standard and the prevalence of electronics in cars, promises were made by marketing teams that this risk had all but been eliminated. In reality, however, the manipulation of CAN bus makes odometer fraud just as easy, and [Andras] is here to show us exactly how easy with a teardown of a few cheap CAN bus adapters.
We featured another project that was a hardware teardown of one of these devices, but [Andras] takes this a step further by probing into the code running on the microcontroller. One would imagine that basic measures would have been taken by the attackers to obscure code or at least disable debugging modes, but on this one no such effort was made. [Andras] was able to dump the firmware from both of his test devices and start analyzing them.
Analyzing the codes showed identical firmware running on both devices, which made his job half as hard. It looked like the code was executing a type of man-in-the-middle attack on the CAN bus which allowed it to insert the bogus mileage reading. There’s a lot of interesting information in [Andras]’s writeup though, so if you’re interested in CAN bus or attacks like this, it’s definitely worth a read.
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]!
The Nissan Leaf is the best-selling electric car of all time so far, thanks largely to it being one of the first mass produced all-electric EVs. While getting into the market early was great for Nissan, they haven’t made a lot of upgrades that other EV manufacturers have made and are starting to lose customers as a result. One of those upgrades is charge limiting, which allows different charging rates to be set from within the car. With some CAN bus tinkering, though, this feature can be added to the Leaf.
Limiting the charging rate is useful when charging at unfamiliar or old power outlets which might not handle the default charge rate. In Europe, which has a 240V electrical distribution system, Leafs will draw around 3 kW from a wall outlet which is quite a bit of power. If the outlet looks like it won’t support that much power flow, it’s handy (and more safe) to be able to reduce that charge rate even if it might take longer to fully charge the vehicle. [Daniel]’s modification requires the user to set the charge rate by manipulating the climate control, since the Leaf doesn’t have a comprehensive user interface.
The core of this project is performed over the CAN bus, which is a common communications scheme that is often used in vehicles and is well-documented and easy to take advantage of. Luckily, [Daniel] has made the code available on his GitHub page, so if you’re thinking about trading in a Leaf for something else because of its lack of features it may be time to reconsider.
Analog gauges gave way to all manner of fancy electroluminescent and LED gauges in the ’80s, but the trend didn’t last long. It’s only in the last decade or so that LCD digital gauges have really started to take off in premium cars. [Josh] is putting a modern engine and drivetrain into his classic Triumph GT6, and realised that he’d have to scrap the classic mechanical gauge setup. After not falling in love with anything off the shelf, he decided to whip up his own solution from scratch.
The heart of the build is a Raspberry Pi 4, which interfaces with the car’s modern aftermarket ECU via CANBUS thanks to the PiCAN3 add-on board. Analog sensors, such as those for oil pressure and coolant temperature, are interfaced with a Teensy 4.0 microcontroller which has the analog to digital converters necessary to do the job. Display is via a 12.3″ super-wide LCD sourced off Aliexpress, with the graphics generated by custom PixiJS code running in Chromium under X.
The result is comparable with digital displays in many other modern automobiles, speaking to [Josh]’s abilities not just as a programmer but a graphic designer, too. As a bonus, if he gets sick of the design, it’s trivial to change the graphics without having to dig into the car’s actual hardware.
[Florian] and his engineering team at Munich-based bmc::labs has developed a clever set of prototyping boards for vehicle hacking and rapid product development, collectively called the bmc::board or bmc::mini. These stackable development boards were initially designed for in-house use. The team took a general purpose approach to the design so the boards could be used across a wide range of projects, and they should be useful to anyone in the field. [Florian] decided to release the boards to the community as open-source and certified by OSHWA (Open Source Hardware Association).
There are four boards currently defined, with several more in the works:
mini::base — Main microcontroller board, STM32F103-based
mini::out — I/O board with CAN bus, JTAG, etc.
mini:: grid — RF board providing GPS and GSM capability
mini::pit — local wireless connectivity, WiFi and Bluetooth, and 2nd CAN bus
At 54 x 42.5 mm, these boards are pretty small; a form-factor they describe as “exactly half a credit card”. We like the Wurth WR-MM family of stacking connectors they are using, and the symmetrical pinout means you can rotate the cards as needed. But at first glance, these thru-hole connectors seem to limit the stack to just two boards, although maybe they plan move to an SMT flavor of the connector in future designs permitting taller stacks.
If you’re into vehicle electronics and/or vehicle hacking, definitely take a look at these. You can check out [Florian]’s bmc::board Hackaday.io project page and the team’s GitHub repository for more details. Here’s another project by team member [Sebastian] using one of the future bmc::bike modules to eavesdrop on ECU communications, where he sensibly advises the reader “First, pull over and get off the bike. Never hack a two-wheeled vehicle while riding it!”.
No discussion of vehicle CAN bus tools should omit the work of Craig Smith, who literally wrote the book on hacking your car, and whose talk along with Hackaday’s own Eric Evenchick of CANtact fame we covered back in 2016. [Florian] has started a CrowdSupply campaign where you can see some more details of this project and a short promotional video.
As cars have become more sophisticated electronically, understanding the CAN bus that forms the backbone of automotive digital systems has become more and more important for hacking cars. Inexpensive microcontroller CAN interfaces have made obtaining the raw CAN bus traffic trivial, but interpreting that traffic can be pretty challenging. In order to more easily visualize CAN traffic, [TJ Bruno] has developed CanoPy, a Python tool for visualizing CAN messages in real time.
A basic PC CAN interface simply dumps the bus’s message traffic into the terminal, while more sophisticated tools organize messages by the address of their intended recipients. Both of these approaches digitally lift the hood and let you examine what your car is thinking, but the wall-of-numbers approach makes finding the patterns that hold the keys to reverse engineering difficult. Automatically plotting the data with CanoPy makes finding correlations much easier, after which the text-based tools can be used to focus in on a few specific addresses.
CanoPy being used to identify the speedometer’s CAN activity.
[Voltlog] has been hacking away at the CAN bus console of his VW Golf for quite some time now. Presumably, for his projects, the available CAN bus interface boards are lacking in some ways, either technically and/or price. So [Voltlog] designed his own wireless CAN bus hacking and development module called the ESP32 CanLite (see the video below the break). The board was tailored to meet the needs of his project and he claims it is not a universal tool. Nevertheless we think many folks will find the features he selected for this module will be a good fit for their projects as well.
In his introduction of the design, he walks through the various design decisions he faced. As the project name suggests, he’s using the ESP32 as the main controller due to it’s wireless radios and built-in CAN controller. The board is powered from the car’s +12V power, so it uses a wide input range ( 4 to 40 V ) switching regulator. One feature he added was the ability to switch automotive accessories using the ST VN750PC, a nifty high-side driver in an SO-8 package with integrated safety provisions.
The project is published as open source and the files can be pulled from his GitHub repository. We noticed the debug connector labeled VOLTLINK on the schematic, and found his description of this custom interface interesting. Basically, he was not satisfied with the quality and performance of the various USB-to-serial adapters on the market and decided to make his own. Could this be a common theme among [Voltlog]’s projects?
A word of warning if you want to build the ESP32 CanLite yourself. While [Voltlog] had intentionally selected parts that were common and easy to purchase when the project began, several key chips have since become nearly impossible to obtain these days due to the global parts shortage issue (it’s even out of stock on his Tindie page).
If you want to dig deeper into CAN bus hacking, check out this talk that we wrote about back in 2016. Do you have any favorite CAN bus development boards and/or tools? Let us know in the comments below.
All of the technological improvements to vehicles over the past few decades have led to cars and trucks that would seem borderline magical to anyone driving something like a Ford Pinto in the 1970s. Not only are cars much safer due to things like crumple zones, anti-lock brakes, air bags, and compulsory seat belt use, but there’s a wide array of sensors, user interfaces, and computers that also improve the driving experience. At least, until it starts wearing out. The electronic technology in our modern cars can be tricky to replace, but [Aravind] at least was able to replace part of the instrument cluster on his aging (yet still modern) Skoda and improve upon it in the process.
These cars have a recurring problem with the central part of the cluster that includes an LCD display. If replacement parts can even be found, they tend to cost a significant fraction of the value of the car, making them uneconomical for most. [Aravind] found that a 3.5″ color LCD that was already available fit perfectly in the space once the old screen was removed, so from there the next steps were to interface it to the car. These have a CAN bus separated from the main control CAN bus, and the port was easily accessible, so an Arduino with a RTC was obtained to handle the heavy lifting of interfacing with it.
Now, [Aravind] has a new LCD screen in the console that’s fully programmable and potentially longer-lasting than the factory LCD was. There’s also full documentation of the process on the project page as well, for anyone else with a Volkswagen-adjacent car from this era. Either way, it’s a much more economical approach to replacing the module than shelling out the enormous cost of OEM replacement parts. Of course, CAN bus hacks like these are often gateway projects to doing more involved CAN bus projects like turning an entire vehicle into a video game controller.
