openinverter forum

At some point during my planned EV conversion I'm going to need to replace my car's gauge cluster. Half of the reason is that it's a particularly rare car and the cluster used a lot of high tech which has failed. Getting it even working is going to involve some specialist work.

The other part of the reason to change is to add info that makes more sense as an EV. Like charging status, regen, battery temperature etc.

The plan is to emulate the style and graphics of the original car's gauge cluster as if it was a real EV from early 1990s, but also have a modern layout option which could have moving graphics, integrated Google maps, reversing camera etc.

I have found plenty of Raspberry Pi diy projects on the web but the boot sequence has to be much faster, < 2 seconds. If you've seen raspberry pi boot up you'll know what an alarming mess it makes of the screen and how long it takes.

The only way I can think of avoiding this is to have it constantly powered and in "sleep" mode when the car is off?

I've found this "bar" LCD which is the right dimensions and aspect to fit in my gauge cluster housing (with some destructive alterations!) https://www.aliexpress.com/item/4000515 ... ttachment]

What do y'all think?

sfk wrote: ↑Sat Mar 21, 2020 8:59 pm What do y'all think?

It might be worth chatting to Zero EV in the UK. They have developed a range of instrument displays that are truly stunning.

Couldn't find anything on their website. Is this prototype stuff?

It is included in their tesla motor kit (but probably sell them seperatly as well). They even have round displays which fit nicely in an old instrument cluster.

sfk wrote: ↑Sun Mar 22, 2020 6:01 am Couldn't find anything on their website.

Some video of both display types on their twitter feed;

https://twitter.com/zeroevuk/status/112 ... 87425?s=20

Also (out of date) user guide on their website;

https://zero-ev.co.uk/userguide/

Love the retro look of their "VW/Fiat" display on that short video thanks Kevin!

PacEmaker wrote: ↑Sun Mar 22, 2020 9:19 am Love the retro look of their "VW/Fiat" display on that short video thanks Kevin!

Yeah, it's a thing of beauty... I'm installing an early prototype in my bus

sfk wrote: ↑Sun Mar 22, 2020 6:01 am Is this prototype stuff?

No, has been used with their Tesla kits for a couple of years. I had a chat with Zero EV today and can confirm that they will sell the displays as a stand alone item once they finish the development of the latest boards (the new version fits the controller board on the back of the display board).

Sounds cool. How do you program it for customisation? And is it near instant-on?

sfk wrote: ↑Sun Mar 22, 2020 9:37 am Sounds cool. How do you program it for customisation?

I don't know what development environment they will support for end users... you'll need to ask them.

sfk wrote: ↑Sun Mar 22, 2020 9:37 am And is it near instant-on?

Yes

Car SOS episode featuring a guy in Wales making custom LCD gauge clusters for classic cars. Anyone able to speculate on the hardware on the bench running the display or the graphics development environment software in use??

sfk wrote: ↑Fri Apr 03, 2020 5:54 pm or the graphics development environment software in use??

Looks like Qt;

https://www.qt.io/ui-design-tools

Thank you. I'll investigate

looks impressive

The modern dynamically generated full-motion video type of displays require some pretty hefty hardware and software to function. This is beyond my ability at this stage so I am working out a solution using Arduino and Nextion displays.

I am recreating the original gauges in the car I am converting but obviously some of the original features are no longer relevant. I don't need a "fuel level" indicator obviously, but I do need battery state of charge.

Because I'm not actually in the midst of the conversion process yet, I'm having trouble guessing the sort of info you need when driving an EV.

Below is a list of the things on the original gauge which I can change if I want as it's all graphics based now, but I want to make it Period Correct. As in, what would Mazda have put on the dashboard of an EV if they made one in the early 90's? Around this time digital dashboards were all the rage with Japanese, European and American cars.

Speedo gauge - backlit display with an illuminated analogue needle
Tachometer - backlit display with an illuminated analogue needle
Left Vacuum Fluorescent Display -
- Telephone (no service)
- Air con temperature
- AC auto, full
- Rear defog
- Fresh or recirculating air
- Trip A / Trip B counter
- Odometer
Right VFD -
- Cruise control active
- Fuel level
- Coolant temperature
Turn signals
Warning light strip -
- ABS
- Alternator fault / low charge
- parking brake
- catalytic converter overheat
- low oil
- High beams active
- auto transmission HOLD
- auto transmission POWER
- seatbelt
- door ajar
- rear fog light
- low wiper washer fluid
- radiator (low level or high temp, not sure)

So I'm thinking the Speedo will be the same, though with Cruise control set point indicator.
The tacho doesn't really make any sense so will be changing that to show power consumption/regen level
The fuel gauge will be the same but graphics changed to electrical rather than petrol.
Is the temp gauge useful anymore? Is the EV motor temp something to keep an eye on?
The car phone stuff won't be functional anymore.
My car wasn't fitted with ABS so that light isn't needed but if I monitored individual wheel speed I could implement launch control...
Alternator fail isn't relevant.
I'll keep the parking brake.
Cat temp and engine oil not needed.
High beams on needed.
HOLD and POWER could be repurposed for EV power driving modes?
Seatbelt, door open, fog light and washer fluid will be kept.
Radiator probably not important, but EV's do have a liquid coolant system.

I guess there would be some sort or "WARNING: charger connected" type light.
Key security functions and lights?
So what else would a EV driver in the 1990's need to know?

I don't remember what car it was that you were using (Eunos Cosmo, I think?), but for my FD RX7 build, I replaced each of the gauges with a regular small TFT that fits in the circular openings. They all communicate over SPI from a Teensy 3.2, so I do have bandwidth limitations, which can be worked around.

The result is 7 TFT panels in the original cluster, it works quite well, but due to the different size openings, many different products were utilised, each with different controllers, which makes for quite the programming exercise!

I've attached a photo during some of the early assembly, it's progressed quite a bit since then.

Total cost was around £80, including Teensy, displays, PCB fabrication and components. I was able to sell the original tachometer unit from the original cluster for more than that!

I have opto-isolated inputs from all the old car signals (from the old dash warning lights, etc), and CAN for communication with my BMS, PCM, and other controllers. It also gives me the ability to add features the car originally didn't have, such as door ajar warnings, immobiliser integration, etc. Most of the relevant buttons and controls from the original car feed into this.

If you design something similar, I suggest doing the same. Being able to bring car controls into CAN is generally quite useful, and the instrument cluster unit is a good place to do this, as it's well situated and already receives many of these signals in that location.

Even though this cluster isn't finished yet, I'm already looking into a newer version using circular panels. This version with the smaller rectangular panels is just go get the project going. Unfortunately, due to the shape of the cluster (it is concave), a single panel is not an option. Most circular panels only offer a MIPI-DSI interface, so that's a new thing for me to look into!



Edit: To answer one of your questions from before, the software he is using is Qt Creator. Hardware unknown.

One thing you will struggle with hardware wise is getting the "instant on" using controllers such as the Raspberry Pi. You'd need to have it powered up at all times and have a "sleep mode".

Tesla use nVIDIA Tegra boards for their instrument cluster and "main screen" (I forget it's name), but details on these nVIDIA products are restricted.

For a project like yours, I'd look at something like the STM32F7, and use its DSI output to drive your TFT via HDMI. See here:



This may be of use: https://resources.qt.io/videos/qtdesign ... al-partone

xp677 wrote: ↑Tue Apr 28, 2020 9:59 pm I don't remember what car it was that you were using (Eunos Cosmo, I think?), but for my FD RX7 build, I replaced each of the gauges with a regular small TFT that fits in the circular openings. They all communicate over SPI from a Teensy 3.2, so I do have bandwidth limitations, which can be worked around.

The result is 7 TFT panels in the original cluster, it works quite well, but due to the different size openings, many different products were utilised, each with different controllers, which makes for quite the programming exercise!

I've attached a photo during some of the early assembly, it's progressed quite a bit since then.

Total cost was around £80, including Teensy, displays, PCB fabrication and components. I was able to sell the original tachometer unit from the original cluster for more than that!

I have opto-isolated inputs from all the old car signals (from the old dash warning lights, etc), and CAN for communication with my BMS, PCM, and other controllers. It also gives me the ability to add features the car originally didn't have, such as door ajar warnings, immobiliser integration, etc. Most of the relevant buttons and controls from the original car feed into this.

Even though this cluster isn't finished yet, I'm already looking into a newer version using circular panels. This version with the smaller rectangular panels is just go get the project going. Unfortunately, due to the shape of the cluster (it is concave), a single panel is not an option. Most circular panels only offer a MIPI-DSI interface, so that's a new thing for me to look into!

If you design something similar, I suggest doing the same. Being able to bring car controls into CAN is generally quite useful, and the instrument cluster unit is a good place to do this, as it's well situated and already receives many of these signals in that location.

Super cool man! I have a Eunos Cosmo EV project but have an FD RX7 also. I looked at the instrument cluster in the FD and looks like a total ball ache with the shapes and weird placement of things. You're right that you couldn't just replace with 1 screen.

I can't believe you managed to get 7 TFT screens running off one MCU. The bandwidth limit would restrict the total resolution, colour depth and refresh rate pretty hard I expect.

I am very interested in your setup for capturing vehicle data directly from the loom to translate into CANbus. This is going to be required for me also. Could you share more info?

The Nextion displays are stand-alone processors. I'm not sure if you looked at them or not. You pre-program them with the graphical elements, page layout and even their own logic routines, then you trigger events with your MCU via serial and receive touchscreen and other processed data back via serial also. This means you can get pretty high resolution gfx as well as process logic and touchscreen interaction on multiple screens with only serial data overhead on your MCU.

There are a few downsides though -
- all your gfx elements and logic has to be preloaded, you can't generate new content on the fly like video or google maps navigation etc.
- data can be loaded through the serial connection but at 9600 baud it is very slow.
- the alternative is via SD memory card but you have to have physical access to the back of the display which would mean taking the gauges out each time you want to upgrade something
- Nextion don't have any round displays so square peg, round hole... Fortunately I need a couple of 7" displays side by side to replicate my dash.

Original looks like this - - and I am replicating the style

I've learned a lot about these displays messing around with one on my desk over the last few weeks. I can tell you more about them if interested. I got a nice speedo gauge with automatic dimming and indicator working It involves a lot of Adobe Illustrator, Photoshop, After Effects to generate the image resources. The Nextion can draw primitives such as circles, rectangles etc but they look totally shit with no anti-aliasing so not really worth considering.

They have 3 versions of screen, Basic, Enhanced and Intelligent. Key differences are clock speed, memory, EEPROM, real time clock, GPIOs, resistive or capacity touchscreen, alpha transparency, media playback, drag-able elements.

sfk wrote: ↑Tue Apr 28, 2020 10:44 pm I can't believe you managed to get 7 TFT screens running off one MCU. The bandwidth limit would restrict the total resolution, colour depth and refresh rate pretty hard I expect.

The bandwidth is limited by the SPI bus, yes. I update all of the screens once per second (except the centre screen which I do at 10Hz), but only update values which have changed, and only draw values which have changed, so for example, if my speed changes from 31 to 32kph, I only write the 2. I also instantly update relevant screens if inputs change (warning lights, etc), again only updating the areas of the screen which changes.

For general driving, for the most part, the screens will barely update at all. Temperatures, battery voltage and level, etc, will only change every so often.

I can get approx 30fps from refreshing one small screen constantly, so you can imagine my limitation here!

sfk wrote: ↑Tue Apr 28, 2020 10:44 pm I am very interested in your setup for capturing vehicle data directly from the loom to translate into CANbus. This is going to be required for me also. Could you share more info?

I have an array of optoisolators, outputting to a MCP23017. Some of these were configured for low side switching, some for high side, I made an educated guess of how many I need of each. This gives me 16 inputs, which was enough. I have I2C broken out on a header to allow an expansion board if needed (I won't).

I just check every input periodically, and write the MCP's pin states to relevant variables. These are used by the program (mostly to draw warning icons), and I can also write them to a CAN frame if I need to (I do this with things such as the parking brake, heater controls, etc).

I also read in 12V battery voltage and interior light brightness directly to the Teensy with an analog input. Yes the display brightness automatically scales with the dash dimmer switch, and I can override this if I choose


Temperatures, battery voltages, speeds, gear selection, etc come in via CAN from other modules, and again I often just decode and display them. I have the ability to set low/high limits for warnings, etc, and I have a piezo buzzer mounted to the board for warning sounds.

I have a graph on the right screen which is a rolling display of previous Wh/km or whatever I choose. It's meant to mimic the ones that Tesla uses. It's all hand-written, and doesn't look all that fancy. Having the graph "scroll" as new data comes in, while keeping bandwidth low, was an interesting challenge.


The board also has an RTC with backup battery (as you know, the FD doesn't have a clock!), and space to add a bluetooth module.

I found that the SAM3X8E chip shares the serial buffer for its UARTs, this means sending diagnostic info over serial can interrupt communication with the GS450h inverter, so instead I send it to the instrument panel over CAN and then spit it out via Bluetooth as a raw data stream. I wrote a windows application to translate this into usable diagnostic info, which mimics Toyotas Techstream software .


I looked at Nextion displays, but generally I avoid commercial products, in favour of expanding my own knowledge by doing it myself as much as possible.

The Cosmo factory cluster is gorgeous. I own a Soarer and have a similar kind of display. Very nice. And it also looks easy to replicate, with a slim TFT like you mentioned.

xp677 wrote: ↑Tue Apr 28, 2020 9:59 pm Edit: To answer one of your questions from before, the software he is using is Qt Creator. Hardware unknown.

Yeah I was going to ask if you recognised the hardware

It is QT and I downloaded and messed around with it a bit. The 1 useful thing I need is the Adobe Photoshop Bridge plugin. It allows you to take your graphic design elements into the QT Creator environment as layered and pre arranged QML files. Unfortunately this plugin is only available to registered users. Registration is about $700 month. Pretty disappointing because the QT stuff looks really powerful and they want people to use it freely. I don't get it.

xp677 wrote: ↑Tue Apr 28, 2020 9:59 pm One thing you will struggle with hardware wise is getting the "instant on" using controllers such as the Raspberry Pi. You'd need to have it powered up at all times and have a "sleep mode".

I have heard this is the only real solution. Have your dash sleeping. Or look for a door open signal and boot up with the screen off and hopefully be ready by the time the key is presented...
I know you can get optimizations from "bare metal" programming and hardcore kernel optimization but that's all Greek to me!

xp677 wrote: ↑Tue Apr 28, 2020 9:59 pm For a project like yours, I'd look at something like the STM32F7, and use its DSI output to drive your TFT via HDMI. See here:

This may be of use: https://resources.qt.io/videos/qtdesign ... al-partone

Yeah, I got all excited when I looked at QT and STM32 controllers driving TFT displays. Super slick. But that Photoshop bridge plugin thing is a big hurdle. And I still don't fully understand how you get your QT stuff onto the board you have chosen. It's like everyone assumes you just know already?

I'm having a really great time with the Nextion and Arduino gear so far. Lots of fun. Makes sense. It's easy and cheap and will be perfect for my modest ambitions. Though I would like to progress into more sophisticated displays at some point.

I contacted a guy who is making and selling gauge replacements using Arduino and Nextion hardware. Primarily for older non OBD2 carbureted classic cars. His setup adds a OBD2 port (for broadcasting data for bluetooth dashboard displays like Torque), as well as optionally gauges that can be linked to relays to switch on spotlights etc.
https://www.theonegauge.com/
There are limitations. He basically runs a parallel set of sensors for engine temp, oil pressure, GPS for speedo and various other things.

I was interested in his setup, but since I'm doing an EV conversion, I have no need for oil temp, fuel pressure etc. I need something fully customisable from the sensor side to the gauge design. He wasn't willing to provide source code (that's his IP and competitive advantage obviously) but that would make it very painful to develop going back and forth between him and me for any change. It would make more sense to do something myself.

xp677 wrote: ↑Tue Apr 28, 2020 11:13 pm I have an array of optoisolators, outputting to a MCP23017. Some of these were configured for low side switching, some for high side, I made an educated guess of how many I need of each. This gives me 16 inputs, which was enough. I have I2C broken out on a header to allow an expansion board if needed (I won't).

Optoisolators are used to handle potentially damaging voltages safely?

xp677 wrote: ↑Tue Apr 28, 2020 11:13 pm I just check every input periodically, and write the MCP's pin states to relevant variables. These are used by the program (mostly to draw warning icons), and I can also write them to a CAN frame if I need to (I do this with things such as the parking brake, heater controls, etc).

Are you using bitmaps at all or are you simply drawing primitives or using ASCII fonts?

xp677 wrote: ↑Tue Apr 28, 2020 11:13 pm I found that the SAM3X8E chip shares the serial buffer for its UARTs, this means sending diagnostic info over serial can interrupt communication with the GS450h inverter, so instead I send it to the instrument panel over CAN and then spit it out via Bluetooth as a raw data stream. I wrote a windows application to translate this into usable diagnostic info, which mimics Toyotas Techstream software .

This is Arduino Due processor? Or does Teensy use same? Bluetooth diags would be super useful.

xp677 wrote: ↑Tue Apr 28, 2020 11:13 pm I looked at Nextion displays, but generally I avoid commercial products, in favour of expanding my own knowledge by doing it myself as much as possible.

I understand but I need more of a headstart

xp677 wrote: ↑Tue Apr 28, 2020 11:13 pm The Cosmo factory cluster is gorgeous. I own a Soarer and have a similar kind of display. Very nice. And it also looks easy to replicate, with a slim TFT like you mentioned.

I searched a long time to find a TFT screen of suitable aspect and dimensions but developing the hardware to drive it is running before I can walk.

sfk wrote: ↑Wed Apr 29, 2020 4:20 am Optoisolators are used to handle potentially damaging voltages safely?

The optoisolator is to accept any 12v signal from the car. The advantage to the optoisolator is that to whatever is producing the signal, the opto appears as an LED. No need to mess around with potential dividers and worry about current sourcing by the microcontroller.

For signals which switch to ground (door open, etc), some of these still have 12v pullups (eg the door open button is connected to 12v through the interior lamp!) So I still use optoisolators for these. Google "arduino optoisolator 12v" and there will be loads of example circuits. I use the ACPL-247-500E quad optoisolators, because they are cheap and have low current thresholds. I put a 1200 ohm resistor in series for 12V and they work fine. I probably should have used a 1k or slightly smaller resistor.

sfk wrote: ↑Wed Apr 29, 2020 4:20 am Are you using bitmaps at all or are you simply drawing primitives or using ASCII fonts?

I do a combination of all 3. For my icons, I hand draw these in Excel and then use an excel macro to output a binary array. For icons which have symmetry, I only draw one half, and then my icon drawing function can look at the size of the array, and if it's only half an image, it will draw a flipped version next to it, examples are high beam (needs top half only), parking brake warning (needs left half only), and sidelights (needs 1/4 only).

For text, I am currently using the fonts which are built into the LCD controllers. I could define my own ACSII fonts, and probably will, but not yet. I've actually gown quite attached to the huge pixelated 5x7 fonts.

I have an Rx7 and Efini watermark logo, for these I converted some picture I found on Google into monochrome bitmaps, then converted this into an array as above. However, due to limitations in the flash memory on my chosen microcontroller, I had to compress these. Not knowing much about monochrome image compression, I wrote my own compression algorithm which basically counts how many black pixels there are, then how many white, etc. These counts are stored in an array which looks something like {50,102,3020,10,200}, I then just output the number of pixels in each cell, advancing the X position as I go, then flip the colour, then continue. I have the image width set, so I reset my coordinates and Y++ after each line.

sfk wrote: ↑Wed Apr 29, 2020 4:20 am This is Arduino Due processor? Or does Teensy use same? Bluetooth diags would be super useful.

SAM3X8E is the due processor. It's importance to the GS conversions is that is has a USART. Teensy 3.2 doesn't.

Teensy 3.2 uses the NXP MK20DX256VLH7, which I believe is a more powerful unit than the SAM3X8E. I wouldn't recommend iit for use these days, the Teensy 4 is 15x faster, at the same price point and form factor.

You can see a performance comparison here between the Due, T3.2, and T4: https://www.pjrc.com/teensy-4-0/

Unfortunately the T4 doesn't have a USART. So for the Toyota inverter controllers, the SAM3X8E or the ESP32 is a good choice.

The only reason I used Teensy 3.2 is because I have a few of them left over from another project. This project isn't really stressing the 3.2, so it wasn't worth the expense to upgrade.

Bluetooth diags are via a standard HC-05 bluetooth module, connected to one of the UARTs on the Teensy. You could do this with any microcontroller. A better solution might be to use the ESP WiFi module that Johannas and Damien are using on their products (ESP8266 I think?). I stuck with UART over bluetooth as it's more familiar to me.

xp677 wrote: ↑Wed Apr 29, 2020 2:46 pm

sfk wrote: ↑Wed Apr 29, 2020 4:20 am Are you using bitmaps at all or are you simply drawing primitives or using ASCII fonts?

I do a combination of all 3. For my icons, I hand draw these in Excel and then use an excel macro to output a binary array. For icons which have symmetry, I only draw one half, and then my icon drawing function can look at the size of the array, and if it's only half an image, it will draw a flipped version next to it, examples are high beam (needs top half only), parking brake warning (needs left half only), and sidelights (needs 1/4 only).

Excel. Lol. That's hardcore!

xp677 wrote: ↑Wed Apr 29, 2020 2:46 pm For text, I am currently using the fonts which are built into the LCD controllers. I could define my own ACSII fonts, and probably will, but not yet. I've actually gown quite attached to the huge pixelated 5x7 fonts.

Yeah I like those huge block fonts a lot too.

xp677 wrote: ↑Wed Apr 29, 2020 2:46 pm SAM3X8E is the due processor. It's importance to the GS conversions is that is has a USART. Teensy 3.2 doesn't.
Unfortunately the T4 doesn't have a USART. So for the Toyota inverter controllers, the SAM3X8E or the ESP32 is a good choice.

Can a USART be added to a Teensy via a shield or something? Or is this a fundamental chip level thing?

xp677 wrote: ↑Wed Apr 29, 2020 2:46 pm Bluetooth diags are via a standard HC-05 bluetooth module, connected to one of the UARTs on the Teensy.

Do you mean connected to the Arduino? The Teensy doesn't have a USART?

I didn't look into adding it, it's quite timing specific so would be best to find a chip that can do it natively.

UART (universal asynchronous receiver/transmitter) is essentially basic serial. It's what you use for Serial.print functions in Arduino, or for data transfer via a COM port on a PC.

USART adds the ability to synchronise the data to a clock, for increased transfer speeds and reliability: https://www.edn.com/usart-vs-uart-know-the-difference/

The Teensy 3.2 has 3 UARTs. The Due has 1 UART and 4 USARTs. The USARTs can be run as UART for serial communication, or as USARTs for synchronous serial communication. The Teensy cannot communicate over synchronous serial.

It's always good to read the datasheets for the chips which you are planning to use. Obviously, for chips like the SAM3X8E, these are huge documents, but there are often useful snippets. Check out page 6 here: http://ww1.microchip.com/downloads/en/D ... asheet.pdf

The Teensy 3.2 chip datasheet doesn't have a fancy block diagram, but it has a list of functions on page 1: https://www.nxp.com/docs/en/data-sheet/K20P64M72SF1.pdf

The ATMEGA2560 also has 4 USARTs https://ww1.microchip.com/downloads/en/ ... asheet.pdf

Loads of options out there, all depends what you want form your chip. But I digress. The USART chat is probably for another discussion. For your application, you'd be looking for things such as DSI output, CAN controllers, etc.

I didn't spot the difference. Thanks.

Why is a USART critical for the displays? Is it just required for the higher baud rate?

USART isn't critical for the display boards at all. It's critical for the GS450h inverter control.

The UART in my display controller is just for the bluetooth, so I can do diagnostics, etc on my phone or laptop. This is, of course, completely optional, and unrelated to the display itself.

If I was running a nice big TFT like your proposal, I'd have a "diagnostic" screen so I can check out all that info on the screen itself, it would save having to connect a computer!