[vsaravind007]

Hello BHPians!

I hope you all are doing well.

Owning an older generation German car is a delightful experience in a lot of ways only a petrol head can understand. However, there is a very dark side of that ownership experience which is pretty much a nightmare - Unavailability of parts most of the times & ridiculous pricing if they're available at the ASC. This is in my opinion why most enthusiastic people change their cars as they age even though they don't want to do it whole heartedly, parts become too hard to obtain even if money isn't a problem, for most people, the time & effort is simply not worth the hassle. Reason why this DIY was attempted is because of such a reason - Super rarity of an instrument cluster LCD & the eye watering cost of replacing it at an ASC. Main reason why this DIY happened is the free time I got due to the COVID19 triple lockdowns here in Kerala.

The Problem
There is a peculiar issue with the first batch of Skoda Laura CBU cars that came to India, not just on Lauras, this is there in other VAG cars of the same time. The LCD MFD in the instrument cluster on the top variant, L&K goes dim on one side as the car ages. The reason for this is simple, the LCD module is actually two physical LCD modules glued together, both halves have independent electrical connectors, if the LCD driver on one side goes bad that side goes totally off or becomes less bright - This is not an issue with the backlight LEDs, LCD module itself is the issue. VAG quickly identified the problem & from next model year onwards, they revised the design & introduced an LCD panel that isn't prone to this issue. The problem started on my car about 1.5yrs back, just before the COVID19 first wave, I was able to procure a used one from a parts car for swapping it out & learnt that its not possible. It has been bugging me ever since, even though I wasn't able to use the car like I used to thanks to COVID19, it was still bugging me every time I sit in the car, could be my OCD, but it was really bothering me every single time! Remember that the the car is about 15yrs old now!





Potential Solutions

There are two mainstream solutions to this issue:

1. Replace the LCD module with a new one - This is the cheapest option if it can be sourced, this type of LCD was in production for only a very short period of time, probability of getting a working used one is very less. Module is available in Aliexpress for around 6k INR, but since we cannot buy from Ali anymore, thats out of the question. Also, thinking about the cost of the unit, its pretty expensive. There is one risk to this approach, if something on the cluster board is broken, replacing the LCD won't fix it, no way to conclude the problem module without swapping out the LCD module as well.
2. Replace the cluster as a whole - This is ASC approach, it is possible to get a new cluster & swap out the old one from ASC, unfortunately its not possible to get an old cluster from a parts car and replace it, unlike other manufacturers, VAG cars have a very complex immobilizer system and cluster is one module having immobilizer information. It is possilble to swap the EEPROM module, but the model numbers must match 1:1, the cluster on my car is not swappable with the model with the updated LCD, connectors are same, but there are a lot of differences, how do i know? I bought a used one from the same year thinking its swappable, on swapping the EEPROM, came to know that its not at all compatible - the car started without issues, but there were a bunch of dancing lights on the dash. I'm not mentioning the cost of replacing this at the ASC, just know that you can buy a used car for the same price

My Solution
I was trying to get a replacement LCD through my FNG, due to COVID19, that went nowhere. During that time, I came across a video by the Humble Mechanic about an aftermarket MFD display called ColorMFA, video here:

https://www.youtube.com/watch?v=gOG9...HumbleMechanic

This gave me the idea to go by the DIY route. The ColorMFA is a cluster upgrade made by a Russian guy, it costs a lot, but it looks cool & very functional. Unfortunately, its not available or compatible with the Laura(Octavia Mk2). There was an unfinished project that I started a while back, an app for my car - The idea of the app was to control the windows, lights and a few other things through a mobile app via bluetooth. That project never got finished due to the sheer amount of time needed to decode the CAN messages. Now due to the COVID19 lockdown, I had plenty of time in hand and decided to tackle this on my own.

Below are the requirements i've set for myself:

1. It must look & feel like the OEM display
2. Must have all the functionalities that I use on the original screen
3. It must not drain the battery if the car isn't driven for some time
4. Must show all the errors/warnings that the OEM screen shows
5. It must not create any catastrophic failures - Power train CAN Bus was't tapped due to this specific reason.
6. Must be easy to go back to stock if i decide to sell the car in future
7. Add some additional features such as battery monitor, boost gauge & a few others

For this to workout, I needed to get the following done:

1. Source an LCD display that can fit inside the cluster & easily drivable through a microcontroller
2. Develop a controller board with CAN Bus interface that can communicate with the car's convenience bus.
3. Decode/reverse engineer the CAN Bus data packets to get all the information I needed
4. Control the powering up/down of LCD and other modules based on car unlock/lock status - This is very important as this could lead to battery drains.

The OEM LCD is slightly smaller in the cluster cavity, which is noticable if you look close enough. I had a 3.5 inch LCD screen which I bought for a different project did fit perfectly, this module can be driven by a parallel interface using a microcontroller. I started out with an STM32 microcontroller, did the CAN Bus implementation on it & all was going well. After a day or two, I killed the module by accidentally supplying 12v - I had no spares for the burnt board & COVID19 lockdowns were in effect. That forced me go with what I had laying around - An Arduino Nano, this is a very restrictive microcontroller but was enough to get the job done. I have quite a few number of these low cost microcontrollers in my parts bin. The LCD I chose initially was really hard to program on, everything had to be doe by hand - If you want to show a text on screen that is right aligned, you've to find the character dimension of the font, multiply that by the number of characters in the text you want to display and subtract it from the width of the screen and use that value as the origin of the text! This was pretty tedious obviously & showing images was super tough, it was really hard to implement the UI on it.

Decided to hold the UI development and started concentrating on the CAN Bus decoding part of the project. This was easier this time as I attempted something similar a while back.

The Laura has 3 independent CAN Buses:

1. Drivetrain CAN Bus - High speed bus that is critical, used by engine, brakes, airbag & power steering. Any errors in this bus will shut down the engine
2. Convenience CAN Bus - Low speed bus, instrument cluster, door electronics, interior functions are driven by this bus
3. Infotainment CAN Bus - Low speed bus, radio, amplifier, steering control etc are driven by this bus

Decided not to mess around with the drivetrain CAN bus, its a critical system & I didn't wanted to mess with the reliability aspect of the car. Convenience bus was the bus of choice. It can be easily accessed from behind the stereo head unit, I tapped the bus at the connector and extended the bus with a long wire routed via the glove box. Used the free software CanHacker along with an Arduino based hardware interface to intercept the CAN messages flying through the bus. Identifying and decoding messages are a really time cosuming job. You've to look at messages that are changing when you do an action and decode what you want based on what you see as change on screen. Below is a screenshot of the CANHacker application sniffing the CAN Bus.



Obviously this was going to take a lot of time, luckily I'm not the first person sniffing around a VAG CAN Bus! I found a Google Sheet where someone has decoded a lot of CAN Messages of a Golf MKV GTI Convenience Bus: https://docs.google.com/spreadsheets...en&hl=en#gid=0. About 60% of CAN Bus messages were the same on both cars(thanks to VW!), some required modifications to how they're interpreted though. Most of my time was spent on decoding the door open/close status. Some didn't work at all, for example the coolant temperature - it never returned the correct value.

By this time, I had a proof of concept running, I was able to get the following details from the CAN Bus:

1. Odo meter reading
2. Door status
3. Seat belt status
4. Outside temperature
5. Parking brake status
6. Windshield washer fluid status
7. Reserve fuel / Low fuel status
8. Oil level low status
9. Coolant level status
10. Battery voltage
11. Engine RPM
12. Vehicle speed
13. Cluster light level knob value - This knob controls the light intensity of buttons, cluster and switches inside the cabin. This is an important feature that I use on long night drives
14. Steering stalk buttons - Up/Down & OK buttons, currently these are being used for page navigation just like the OEM MFD.

I wasn't able to decode the time from CAN Bus data correctly, hence I decided to go with a separate module for time keeping. As an additional feature, I've added a digital compass module to my system which will show a compass on the MFD. I used a TIP122 darlington transistor to control the power to modules - This is important because if the modules are kept ON, they'll drain the battery with a few days, especially the LCD needed to be turned off when the car is not in use. For trip data, I'm using the EEPROM thats part of the RTC module.

By this time, I came to the conclusion that the LCD module that I'm using isn't going to cut it, it was too much work & the results were not that impressive - too much flickering and screen tearing on changing values. I had a Nextion Enhanced HMI module in my parts bin - This was again part of an unfinished project, I bought this module to build an LiFePO4 powerwall for my house, plan was to use the Nextion module as the interface to the powerwall. It never got finished(never actually started to be honest!) because of reasons, but it did help me here! Developing UI on a Nextion HMI is easy, we can use Photoshop or any other drawing tool to create graphics & use Nextion provided controls such as buttons/text to render whatever we want. It also has a scripting language in place that can be used to write logic within pages. The main advantage of Nextion is that, graphics rendering work is offloaded from the microcontroller, it uses a simple serial interface to change values on screen and for changing pages. Nextion has a GUI application that can be used to design pages through drag & drop. Main advantage here is that, it has a built in simulator. You can validate the functionality before burning the code to hardware, pretty neat!

Nextion Editor:


On a high level, this is how the whole system looks like:


The real time clock module & the compass module communicate over I2C bus with the Arduino while the CAN Bus transceiver communicates over SPI bus. Simple Serial communication is used to send data to the LCD module. Below logic flow diagram shows how the power rail & comms is controlled:


Results
Mess of files!


Prototype board:


Please excuse the mess!






Video
In the video, you'll be able to see almost all of the functionalities, including the dimming of LCD backlight. You can also see that the unit turns itself off after about 20 seconds of locking the car.

https://youtu.be/kICtPTi6pFg

Things That Work
Below are the features that work correctly without issues as of now:

1. Odo reading
2. Trip reading - resetting works
3. Battery voltage reading
4. Time
5. Outside temperature
6. Compass / heading
7. Door status - All 6 doors
8. Parking brake warning
9. Seat belt warning
10. Trip data - Time since start, distance since start
11. Vehicle speed
12. RPM vs Speed Graph - This was a tryout, not sure how this will be useful, added for fun!

Pending Items / Issues
As of now, the MFD works fine, however its not without problems. Below are the issues that needs to be sorted:

1. Convert the prototype to an actual PCB - I've already created the PCB design & placed an order with a PCB manufacturer for this. Final PCB with all modules will be 1/4th the size of the current prototype.
2. Some UI elements needs refinement, on the above screenshot the "m" of "am" is clipped, this is because the width of that text box is slightly shorter, there are a few such issues across pages.
3. Currently trip data doesn't show decimal values - This is an issue, original MFD shows decimal values, however mine doesn't! This is because I'm calcuating the trip data by saving the odo reading to memory at the time of reset & taking the difference of current reading and the reading when trip was reset. The odo reading available in the convenience CAN Bus doesn't have decimal values. This is an important feature that needs to be fixed.
4. Settings menu is missing - On the orignal MFD, there is a settings menu for configuring the coming home & leaving home time, units & winter tyres - Need to implement this
5. Implement range/distance to empty, average speed of trip
6. Implement way to reset trip data on the fly
7. Implement bulb blown messages - If there is a blown bulb, the original MFD will show throw an error with details of blown bulb, this data is available in the bus, need to decode & code that in.
8. Implement boost gauge, intake air temp, EGT & coolant temperature - This will need KLine reading, for future as KLine interfacing ICs are experiencing shortage as part of the global auto chip shortage.

I'm currently running the setup along side the original MFD in an attempt to identify & fix any issues, will be fixing the screen inside the cluster shortly, will keep the thread updated.

As for the sources, I'm planning on releasing the Arduino code, schematics & the Nextion HMI file as an open source project via Github, I'm currently in the process of polishing the edges to make it presentable to a wider audience

As always, thanks for reading!

[agambhandari]

Fantastic stuff, maybe a bit impractical at the moment. But this is the kind of things that real techies would do for their cars, whatever time it may take.

Your new display looks far more modern and up to date than even the current crop of Skodas on sale(read: Kushaq,Rapid)

[vsaravind007]

Originally Posted by agambhandari

Fantastic stuff, maybe a bit impractical at the moment. But this is the kind of things that real techies would do for their cars, whatever time it may take.

Your new display looks far more modern and up to date than even the current crop of Skodas on sale(read: Kushaq,Rapid)

Thank you for your kind words agambhandari!

[jothishX]

Excellent project @vsaravind007. Good choice to use the Nextion enhanced. I too have one lying around procured from aliexpress for an abandoned project. Had hell of a time making the ui with a tft lcd and arduino gfx libs on a nano for a custom display on my bike few years ago.

https://youtu.be/yWmx-NhBJT4

Doesn't the nextion have an RTC module embedded? Also what's the can transceiver module that you're using? Guess you would have taken care to extend the usb port of the nano to somewhere below the dash to easily reprogram if needed. Nano is no match in speed for the stm32. But since you have used nextion, the load would be pretty much less than those crappy i2c or spi displays. I would go with the rpi zero w, just for fun and all the extra goodies like BT and wifi. Probably overkill and would complicate the coding. I too am from tvm btw.

[vsaravind007]

Originally Posted by jothishX

Excellent project @vsaravind007.

Had hell of a time making the ui with a tft lcd and arduino gfx libs on a nano for a custom display on my bike few years ago

Thank you jothishX, ArduinoGFX library is too low level to be used in projects with high graphics requirements.

Originally Posted by jothishX

Doesn't the nextion have an RTC module embedded? Also what's the can transceiver module that you're using?

Yes, the Nextion Enhanced module I'm using has a built in RTC, but its way too inaccurate, the drift per year is in minutes rather than in seconds! Also, from a maintenance perspective, I'm planning to keep everything outside of the cluster with only the LCD installed within the cluster, in case the battery fails or needs replacement, I'll have to open the cluster again. One other reason is the EEPROM module that comes with the RTC module, that is needed for trip calculation and a few other settings. Nextion EEPROM isn't reliable, only the display part is good in my experience with them! I'm using a very basic MCP2515 module, I bought about 15 of them some years back when I was working on a home automation project I completed that project, but went with wifi & ESP8266 in the end. These modules were sitting idle ever since!

Originally Posted by jothishX

Guess you would have taken care to extend the usb port of the nano to somewhere below the dash to easily reprogram if needed. Nano is no match in speed for the stm32. But since you have used nextion, the load would be pretty much less than those crappy i2c or spi displays. I would go with the rpi zero w, just for fun and all the extra goodies like BT and wifi. Probably overkill and would complicate the coding. I too am from tvm btw.

Yes, I'm planning to route the USB interface for programming to the glove box, one challenge is the Nextion module, once installed within the cluster, it'll not be easy to program, I'll be brining out the Nextion serial port to the outside as well.

Raspberry PI will be an overkill, also it'll never match the boot up speed of a microcontroller. It can be made to boot up faster if gone via the bare metal route, but too much work i'd say. If we go with a Raspberry Pi with a slimmed down version of linux, it'll still take about 5-7 seconds to boot up. Programming will be very easy on a Raspberry Pi though, we could use Python or QT or some other high level language with graphics support. I've started experimenting with the excellent LVGL library running in a bare minimum linux optimised for boot speed on a Raspberry Pi 3B using a 5" DSI screen, its still slow to boot up though. Plan is to create a display showing all of the that will sit in the middle of the dash similar to a BMW iDrive Good to know that you're also from my place, we could meet someday!

[jithin23]

Wow! The number of Technical DIY's are improving leaps and bounds in the forum these days. Amazing mod job though it's in the beta stage. Keep the mods coming and this will make more VAG group owners add this display.

One noob question? Can this be installed with the current Instrument cluster available on the Polo?

[Naveen_0181]

Great work! as a fellow electronics hobbyist I know this not very easy, this takes a good amount of planning and patience apart from the technical knowledge. Appreciate all your time for documenting it in detail. All the very best and looking forward to see the finished output soon.

[vsaravind007]

Originally Posted by jithin23

Wow! The number of Technical DIY's are improving leaps and bounds in the forum these days. Amazing mod job though it's in the beta stage. Keep the mods coming and this will make more VAG group owners add this display.

One noob question? Can this be installed with the current Instrument cluster available on the Polo?

Thanks jithin23, it is definitely possible to develop something similar for Polo, I might do that in future as a few friends want something similar on their Polos

Originally Posted by Naveen_0181

Great work! as a fellow electronics hobbyist I know this not very easy, this takes a good amount of planning and patience apart from the technical knowledge. Appreciate all your time for documenting it in detail. All the very best and looking forward to see the finished output soon.

Thanks a lot Naveen_0181, these kind of projects will definitely make you learn patience

[jothishX]

Originally Posted by vsaravind007

I'm using a very basic MCP2515 module, I bought about 15 of them some years back when I was working on a home automation project I completed that project, but went with wifi & ESP8266 in the end.

Thanks. Aliepxress was my goto place for hoarding all modules like this. Too bad it is gone. I too got around 10 ESP8266 modules and some 5-6 sonoff esp devices linked my home automation system (homeassistant)

Originally Posted by vsaravind007

Raspberry PI will be an overkill, also it'll never match the boot up speed of a microcontroller.

Plan is to create a display showing all of the that will sit in the middle of the dash similar to a BMW iDrive

Agree, boot speed will be an issue. Having an onboard custom dash will be amazing. Do keep us posted. I'm working on a small custom project to push OBD data from Torque to a data logging system.

[vsaravind007]

Originally Posted by jothishX

I'm working on a small custom project to push OBD data from Torque to a data logging system.

Great! You can write plugins for Torque if I'm not mistaken?

[jothishX]

Yes, we can write plugins for torque but I've not taken that route yet. Trying the inbuilt http logging method now

[canibeanartist]

Hey, this is very interesting and I am looking to implement something very familiar. I plan to use the same display as I already have one on hand as well as a few Arduinos and CAN modules. Have you published the code you used for this to Github or somewhere else?