Using a Raspberry Pi 4B, Power Delivery Module, and Touchscreen
For their final college engineering project, three Camosun College engineering students implemented an automotive Human-Machine Interface that can display vehicle information, show back-up cam footage, access AndroidAuto, and send and receive CAN messages, while having control over 12V auxiliary devices. This project was sponsored by the EV manufacturer, Canadian Electric Vehicles.
Converting a car with an old internal combustion engine to an electric vehicle (EV) has never been easy. A inexpensive conversion might be simple, but the hard part is choosing where to compromise. When it comes to having a human-machine interface (HMI) in a conversion, the price tags we saw during product research can be eye-watering. We spent the first couple of weeks of our final semester’s electrical engineering project struggling to get a high-end, automotive HMI to do absolutely anything at all. Our work was then made possible through sponsorship by EV manufacturer, Canadian Electric Vehicles, of Vancouver Island.
PROJECT BACKGROUND
We heard from one of our professors during the summer that Canadian Electric Vehicles (CanEV) was interested in sponsoring one of the project groups in our cohort of electrical engineering technology students. Not wanting to miss out on this golden opportunity, our project team contacted CanEV early, to get a feel for what they might want out of the project and what we could provide for them. After some email correspondence and a couple of visits to their workshop in beautiful Parksville, British Columbia, we were thrilled to get our hands on the pretty potent gear they sent us home with.
We had a Grayhill 3D70 automotive HMI and an Enovation Controls IX3212 Power Delivery Module (PDM) in our possession. CanEV was hoping that we could get the HMI talking to the PDM, whip up a graphical user interface (GUI), and, bam—they’d have a nice looking touchscreen to update the look inside their EV conversions and do away with some of the physical switches and dials on the dashboard, while also substituting fuses and relays with the solid-state switches in the PDM.
Our liaison at CanEV, Sam Monge, wanted our unit to include AndroidAuto, an app provided by Google that allows users to use the core functionality of their phone in a manner safe for a drive. But as we got busy getting the 3D70 up and running, we discovered this was not going to be an option on this particular piece of hardware. Following this rather demoralizing realization, we also learned that streaming audio and GPS navigation wasn’t going to be supported either. At this point, we were simply straying too far from our initial scope, and conveyed the bad news to Sam Monge. After putting our heads together, we decided to pivot to something that could completely deliver on the original list of requirements.
Our revised project goal was to build a low-cost alternative to an automotive HMI (Figure 1), similar to Grayhill’s 3D70 or Murphy’s PowerView 780B, with the most transparent and easy-to-program code possible. The project also still had to interface with the PDM, and at the same time be an infotainment console. We chose the Raspberry Pi 4B as the new computing device for the project, mostly because it is a downright powerful little device. We opted to couple the Pi with a Sunfounder 10.1” touchscreen. This particular unit appealed to us because the driver board took a 12V supply and delivered 5V via USB-C to an attached Raspberry Pi. Another fantastic aspect of this touchscreen was its adjustable stand-off fittings on the rear of the unit, which allowed us to mount the Pi solidly next to the screen’s driver board.
Our HMI runs Google Maps for AndroidAuto within the OpenDash application, by connecting with an Android phone via USB-C.
IMPLEMENTATION
When we first held it in our hands, the Power Delivery Module was alien technology, and the reference manual was like the Necronomicon; but the fog started to clear over time. We soon understood that the PDM would initially be configured with a series of CAN Bus messages. Following configuration, any of the twelve 12V digital outputs (of which any two adjacent channels can be configured into an H-bridge pair) could be commanded either by a signal (high or low) on a designated digital input or by sending an appropriate CAN message. The line diagram of our HMI system connection is shown in Figure 2.
— ADVERTISMENT—
—Advertise Here—
Line diagram of our HMI system’s connection. Red lines are power, and black lines are signals.
A core requirement of our project was an integrated CAN Bus communication device, which was notably absent on the Raspberry Pi 4. In the early stages of the development, we overcame this issue with some incredibly dodgy modifications to an MCP2551/2515, so the SPI logic level was 3.3V, conforming to our Raspberry Pi, but keeping the CAN transceiver at 5V (due to the MCP2551’s narrow operating voltage range). A few hours following this modification, we happened upon a product on RobotShop.ca—WaveShare’s two-channel, optoisolated CAN Hat.
Like other Raspberry Pi hats (or shields, if you’re of the Arduino persuasion) this unit stacks on top of the Raspberry Pi header pins, with this board using SPI with twin chip selects to operate the two independent CAN channels. We felt like this board was a nice touch, it looks sharp, has great functionality, keeps wiring to a bare minimum, and is modestly priced.
CAN BUS
Despite never hearing of it before this project, our deep dive into the world of CAN Bus illustrated to us that it has rightfully earned the number of ISO and SAE standards devoted to it. A CAN Bus is a two-wire bus with each end terminated by 120Ω resistors. The bus carries the CAN message, or frames, which comprise an 11-bit (standard) or 29-bit (extended frame) identifying header, a priority ID (allowing higher priority messages access to the bus over lower priority), a data payload of up to 8 bytes (commonly represented with hexadecimal characters), and assorted networking magic to check for and handle errors.
Implementing our CAN Hat with the Raspberry Pi required setting up each channel as a network device using serial-peripheral Interface. First, we went into the Raspberry Pi configuration menu by entering [(sudo raspi-config)] into the terminal, scrolled down to “Interface Options,” and enabled SPI. With SPI enabled, we used it to communicate with the CAN devices. We did this by editing the boot configuration file[sudo nano /boot/config.txt], adding the following lines of code at the bottom, and rebooting the device.
[dtoverlay=mcp2515-can1, oscillator=16000000, interrupt=25dtoverlay=mcp2515-can0, oscillator=16000000, interrupt=23]
To confirm we had done this successfully, we ran the terminal command [dmesg | grep spi] and received the output given in Figure 3.
Ubuntu terminal output showing a successful SPI connection to the CAN Bus module. The output shows two usable channels on the same device (SPI0.0 and SPI0.1).
With an SPI link established between the CAN controllers and the Raspberry Pi, the next step was to set up the controllers as a network device using the following lines of code in the terminal:
[sudo ip link set can0 up type can bitrate 250000— ADVERTISMENT—
—Advertise Here—
sudo ip link set can1 up type can bitrate 500000]
Note that in this example we have set the can0 device to 250kbps (the specified data rate for SAE J1939/11 and J1939/15) and the can1 device to 500kbps (the specified data rate for SAE J1939/14). Our motivation for these choices was that the PDM adheres to J1939/15, in that it only handles messages with the appropriate 29-bit identifier on a 250kbps bus that we connected to the can0 device. We used the 500kbps data rate for can1 because we had found CAN Bus traffic in our cars at that particular rate, and it was helpful in our troubleshooting.
With the devices’ bitrates set, it was appropriate to set the transmission queue length, and as recommended by the manufacturer, we set both to 65536, and then to run ifconfig in the terminal to confirm the devices were established (Figure 4).
Ubuntu terminal output showing details of the CAN Bus module operating as a network device. The images show zero cumulative network traffic, and a transmission buffer of 65,536 bits, on both channels.
sudo ifconfig can1 txqueuelen 65536]
Having confirmed the establishment of the network devices, to avoid repeating the above steps every time the Pi rebooted, we appended the following code to the network interface configuration file (Listing 1).
Listing 1
Terminal box code for configuring the two independent CAN Bus channels as 250 and 500 kbps, respectively.
[auto can0
iface can0 inet manual
pre-up /sbin/ip link set can0 type can bitrate 250000 triple-sampling on restart-ms 100
up /sbin/ifconfig can0 up txqueuelen 65536
down /sbin/ifconfig can0 down
auto can1
iface can1 inet manual
pre-up /sbin/ip link set can1 type can bitrate 500000 triple-sampling on restart-ms 100
up /sbin/ifconfig can1 up txqueuelen 65536
down /sbin/ifconfig can1 down] With our Pi now able to make use of these CAN Bus network devices, the next step in our troubleshooting was to include some tools to make our lives easier. Can-utils, a collection of commands for working with CAN Bus, is easily installed to the Raspberry Pi by entering [sudo apt-get install can-utils] into the terminal. The following commands are included in this package: candump (shows a rolling list of all can traffic in the terminal), canplayer (for replaying CAN logfiles), cansend (for sending a single frame), cangen (generates random CAN traffic) and cansniffer (sort messages by ID and update as delivered data changes). The functions were useful, since we could send, receive, and sort CAN messages easily. A word of caution, however: cangen is extremely chaotic with its output, so we caution against calling that function if your device is connected to an active CAN Bus inside a vehicle. There’s no telling what messages might inundate your system as a result.
OPENDASH
Given that we had honed in on using the Raspberry Pi, we began to research how we could use it as a platform for AndroidAuto. YouTubers Novaspirit Tech and Everlanders (among others) both have several excellent videos demonstrating the deployment of AndroidAuto on the Raspberry Pi using OpenAuto. OpenAuto is an emulator of head unit software allowing embedded devices that can connect to an Android phone to run AndroidAuto. The Android device handles all the features of AndroidAuto, such as navigation and music streaming. OpenDash is responsible for projecting the image to our head unit screen. We needed an application that operates OpenAuto and a platform for our CAN Bus communications, and we happened upon OpenAuto Pro and OpenDash.
OpenAuto Pro is a paid product, but is an excellent value at about $30 per license. However, it was almost too feature-rich for our project, and because we were budget conscious we opted to work with the open-source OpenDash, knowing that we could always upgrade should the need arise.
OpenDash delivered all the functionality that we were looking for: 1) a vehicle data page showing typical gauges (speedometer and tachometer) that update upon reception of CAN Bus messages with the appropriate OBD-II parameters ID; 2) a page for displaying a connected camera that can be brought to the front with input from a designated GPIO pin (perhaps detecting the level of your reverse light circuit); 3) a page for playing media local to the Raspberry Pi or via a Bluetooth connection to a phone; and 4) a page for AndroidAuto. Beyond its functional prowess, OpenDash also features robust community support for developers and enthusiasts on their GitHub and Slack channels. Anyone seeking troubleshooting support or help building a plug-in is warmly welcomed.
With our choice of software solidified, we forked the OpenDash repository to GitHub [1] and set about creating a custom plug-in to tie in the functionality of our Power Delivery Module. We used Qt Creator to design the GUI and implement the touchscreen buttons, which, when pressed, would send a CAN message to the PDM to command the output corresponding to that button. For instance, a headlight button would send the message 04 7F 00 00 00 00 00 01 with arbitration ID 14EF1E11 to turn channel 1 on (encoded the final “01” byte) at 100% PWM (encoded in the “7F” of byte 2). Note that this ID is specific to PDM and the IX3212 reference manual elaborates on the justification. Pressing it again would send 04 7F 00 00 00 00 00 00 from the same ID, which commands channel 1 off, even when we keep a non-zero PWM value.
POWER DELIVERY MODULE
Before you start taking notes on the content of these messages, just know we didn’t conjure them from the ether. Enovation Controls puts the burden of constructing these configuration and command messages onto a simple desktop GUI application that one can find on the IX3212 product support page [2]. The user can enter PWM values, define if a channel is a high-side switch or part of an H-bridge pair, set current limits and motor or lamp soft-start characteristics all into the PDM Message Generator (Figure 5). It will spit out the exact CAN Bus messages you need to get the output you want.
Screenshots of the Murphy PDM Message Configurator tool. The left side shows Digital Output 1 is configured. The right side shows run-time settings, such as PWM values (all zero) and enabled outputs.
The beauty of the PDM is that one doesn’t necessarily have to command the outputs with CAN messages. Any number of the outputs can be configured to respond to any of the digital inputs. An example of this benefit is if your conversion still has the wiring for the headlight stalks, you could then wire several of the PDM’s digital inputs (for low beams, high beams, and fog lights) into that circuit, and configure the PDM to respond to those respective inputs instead of expecting a CAN Bus command.
Another useful feature of the IX3212 is the routine feedback messages it broadcasts onto the CAN Bus. They relay the status of the inputs and outputs and any output failures, such as an over-current event. Although these messages can take a bit of brainpower to decipher, Enovation Controls does an excellent job of breaking them down in the PDM’s reference manual [3], and the feedback is extremely handy for troubleshooting unexpected behavior without getting your hands dirty.
We now had a comprehensive device on hand that could do all the things we set out to accomplish: display vehicle information, show back-up cam footage, access AndroidAuto, and send and receive CAN messages, while having control over 12V auxiliary devices. This was a definite mood booster. Our liaison, Sam Monge, was also energized by our success, particularly with the Power Delivery Module. With this momentum, we now set our sights on making an eye-catching demonstration installation. Sam had been dreaming of sliding the unit into the dash of his 1985 Nissan 300zx EV conversion project, and was nice enough to completely remove the dash and deliver it to us. Together with Sam, we set about taking measurements and photos for photogrammetry, so that he could wield his 3D design skills to print an enclosure for the HMI and an adapter fitting to fasten the entire unit into the dash in time for us to wow the attendees at our project symposium. At the time of this writing, those fittings are sitting on a printer bed demonstrating the power of additive manufacturing.
— ADVERTISMENT—
—Advertise Here—
CONCLUSION
Our finished product could display standard PID values for vehicle speed, engine RPMs, coolant temperature, and percent motor load, through OpenDash with emulated CAN messages. We were able to command the PDM with SAE J1939 conforming CAN messages with 29-bit identifiers, at the press of a touchscreen button within a plug-in inside the OpenDash application. This drives headlights, hazard and dome lights with single high-side switches, and bi-direction DC motors with H-bridge pairs.
OpenDash natively supports AndroidAuto when connected via USB, and can access local media by phone with Bluetooth. Our team, called DesignToWin, is thrilled with the success of our project and what we learned about project management along the way. Our project demonstration is detailed on our website [4]. As we scheme how we’re going to implement these units in our vehicles, we hope our experience inspires you to give this project a shot! 
REFERENCES
[1] OpenDash Repository forked to GitHub:
https://github.com/walt140/dash[2] IX3212 product support page:
https://support.enovationcontrols.com/hc/en-us/articles/115010766868-Intelligent-Xpansion-IX3212-PDM[3] IX3212 Specification Reference Manual:
https://support.enovationcontrols.com/hc/article_attachments/4408823367827/00-02-0829A_IX3212_PDM_Reference_Manual_20211002.pdf[4] Website detailing the teams’ project demonstration:
https://designtowinproject.wixsite.com/website
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2022 #385 – Get a PDF of the issue
Sponsor this Article
Walter Parsons completed his diploma in Electrical Engineering Technology at Camosun College in the fall of 2021. He is currently working in the Canadian public sector as an Electronics Technician involved in naval repair. His interests include electro-motive power and communications systems.
Tyrell Collins completed his diploma in Electrical Engineering Technology at Camosun College in the fall of 2021. He is currently working in the private sector as an Electronics Technologist involved in radio communications and networking. His interests include 3D design and multimedia production.
Dylan Davis completed his Electrical Engineering Technology diploma at Camosun College in 2021. He is completing a diploma-to-degree bridge program to gain his Bachelor of Electrical Engineering. His interests range from learning new coding languages to repairing recycled power electronics.
