Honda Insight Forum banner

Controlling the Instrument Cluster's Display

74946 Views 470 Replies 65 Participants Last post by  Mario

A little project I'm working on. :) (Sorry for the horrid picture!)

Here's the elevator pitch: Directly control the LCD panel with a microcontroller to display custom information on the instrument cluster. The microcontroller will also read the data that would normally be going to the LCD and can choose to display that info or custom info.

Maybe you want to display OBDII parameters where the MPG is. Maybe you want to change the charge, assist, and SOC gauges to accurately reflect amps in/out, real battery SOC, etc.

I've got a few other ideas as well. Once I'm finished with this project I'll open-source everything I've learned and perhaps produce some PCBs to sell. We'll see!

I have work and other projects as well, so it may be slow going at times. But I'll try to give updates fairly regularly.
I don't think this has ever been done before. I hope you guys are excited!
If anybody is or wants to work on something similar, I'll be glad to share what I know; just ask.
See less See more
  • Like
Reactions: 5
61 - 75 of 471 Posts
My how much you've grown, senior Pegasus!
I always love unwrapping a new PCB!
Cool update! Getting the bootloader right is really important. I assume your bootloader has an initial structure that tests for keyON?
if( isKeyOnNow(void) == KEY_IS_ON) { immediatelyExitBootloader(); }
else                               { waitOneSecondForNewFirmware(); }
If not... I recommend doing so, which will allow LiBCM to start displaying immediately when the key is on.


I always love seeing in-house programmers. You'd be amazed how many fortune 500 hardware companies use essentially identical programmers... production bed-of-nail testers are expensive.

So then I guess you have a USB cable attachment somewhere? Pretty soon we're going to have at least three USB cables stashed in some cars (LiBCM, Pegasus, Mudder's Manual IMA).
Sweet, glad you've already figured out your particular bootloader solution.


I have a confession: I've (still) never used a USB-C cable for data transmission... not even once, for anything, ever. I suspect many G1 Insight owners are in the same camp. If my assumption is correct, then I recommend using a USB-A USB-B connector for Pegasus firmware update process.

USB-C is certainly the future standard, but IMO USB-A USB-Bis more appropriate for this application. It's not the end of the world either way; USB-C-to-A adapters cables are cheap and transparent above the PHY layer.


LiBCM will never support METSCI updates... that would be so much work ;). But maybe I'll consider adding BATTSCI updates to LiMCM, so that you only need to connect one USB cable to update the entire IMA system.
  • Like
Reactions: 1
IMO F360 is the best free program out there. AutoDesk keeps removing features from the free version, but it's still incredible. We have several paid seats at work.

However, I personally use AutoDesk Inventor 2017 (the last year they offered a perpetual license). I'll probably still be using 2017 a decade from now.
General comments/questions:
1: Where are your reference designators?
2: What is the purpose for the MS621T lithium battery? realtime clock? Could it be a supercap instead? I see that it's rated up to 85 degC, but if nothing else a supercap doesn't need to be replaced down the road.
3: Your buck SMPS (bottom left corner) is laid out 'long'. Ideally you'd place the input caps much closer to the inductor. In a buck configuration, the input capacitor proximity is much more important (than output capacitors) because the current through the input side is discontinuous, whereas the output current is regulated by the inductor. Here's a better layout (from LiBCM):
Colorfulness Pink Font Magenta Red

(U1 is switcher, top copper fill is Vin, middle is ground, bottom ('+5V') is Vout).

4: Same SMPS: Is the diode to the left of the inductor used for over-voltage, or is this a non-synchronous buck? At 5 volts output, I recommend using a fully synchronous converter, as it will greatly improve efficiency. For a fixed +5V output, my goto is AP63205. Given your inductor size, AP63205 might not source enough current.

5: What is just above the "REV A" silkscreen? Is that a switched open drain?

6: Is the oscillator (to the left of the I2C board connector) stable that far away from the STM32? Maybe it's a low frequency RTC? If it's the system clock, stray capacitance might make it unstable.

7: Those 0.1" headers to the left of the CPU are honkers. If you're looking for a slightly smaller header, I recommend the 2mm C2C Hirose DF11 connector (e.g. DF11-8DS-2C). The terminals are still easy enough to crimp, plus you can purchase pre-crimped leads directly from the manufacturer.


If you do end up getting a pick and place machine, you're going to need machine vision for parts that small. For reference, our Neoden 4 machine can only accurately place parts down to 0402... and that's with machine vision and slow speeds. My personal Neoden 3 - that I use to assemble LiBCM PCBs - doesn't have machine vision, so I end up having to manually reposition parts smaller than 0805.

Given how expensive these machines are, if you're only planning to build Pegasus PCBs, then probably contract manufacturing makes more sense.
See less See more
  • Like
Reactions: 2
Well defended... always good to see data, too. FYI: The spike you're seeing on the triangle waveform (input capacitor) exceeds your scope bandwidth. The ~2 ns ringing is 500 Mhz(min) ABW, which exceeds your ABW by at least 2x (but we can't tell due to Nyquist). If you have access to a higher bandwidth scope with an active head, I imagine you might see quite a bit more switching noise. Does it affect your board? Probably not. Might it be an unintentional radiator? Possibly. I've certainly seen issues with unintended radiators before.

Once I was consulting for a startup you've probably heard of... and this exact issue was killing their USB interface about once per second. Before they hired me to figure out the issue, their workaround was to write their own USB kernel that could re-enumerate the USB interface in just a few ms... so they could get up and running quick, transmit data for about a second (until the aggressor noise killed the bus), and then re-enumerate again. Fortunately that USB was only used internally, and they had ECC so they could tell when the data was bad.

Since you're already revving the PCB, my recommendation is to swap the inductor and that freewheeling diode, so that the inductor is closer to the input capacitors. This will cut your input current loop surface area in half, which will reduce radiated emissions. The current through the freewheeling diode is piecewise continuous (if your load is high enough to stay in continuous conduction mode), whereas the current from the high side FET and input capacitors is discontinuous each time to high side FET turns off.
See less See more
  • Like
Reactions: 1
Ah, yeah, you are right about the scope bandwidth. I don't have a better scope to look with unfortunately.

That USB story is wild, hah. I guess you do what you have to do to get things working. Classic example of using software to fix a hardware problem.

Here's the best layout I could come up with, what do you think?
That layout is absolutely better in every way. Ha, that's so many ground vias.
  • Like
Reactions: 2
I do now. :)

Tektronix DPO7104, 1GHz bandwidth and 20GS/s. Used eBay scopes are awesome, this was about 1/5 the price of an equivalent modern scope. It won't perform as well as a new scope of the same caliber, but it still has excellent specifications and features.
That's a great scope! My daily driver at NI was a 2 GHz ABW Tek DPO. Whenever we needed more bandwidth we'd typically just rent test equipment.

I'm just waiting on some 500MHz passive probes, a 1GHz active probe, and a 30A, 120MHz current probe to arrive. All also secondhand off eBay for 1/4 price or less.
Each active probe I used at NI cost more than the entire scope setup I use now. Honestly the real-world analog performance is almost entirely a function of your input probes.

For Pegasus, I've been slowly performing various tests that will make sure every functional aspect of the board is working properly. Then I will start writing the bootloader, then finally the firmware!
I already have 40-50 various changes I want to make, but nothing too major. So far everything has been working great, for the most part!
Are you using the base firmware you previously wrote for the old hardware?

I also installed the power harness (required) and the signal harness (optional) in my test cluster, of course to test that functionality as well.
IIRC, previously Pegasus was powered from the +12V rail on the OBDII port? Why the change? Does the new power harness require soldering?
Even these second-hand probes can be thousands of dollars! It's crazy. Thankfully the older but still capable models are "only" hundreds of dollars.
And definitely. I mis-typed, It's actually a 1.5GHz active probe, so I know the probe shouldn't be the limiting factor with this scope at least.
I agree you have enough bandwidth for pretty much any non-RF home project. Don't forget that overall system bandwidth is typically square root of sum of squares for each analog part in the chain (i.e. probe + scope).

Naw, new microcontroller, entirely new hardware and pinout, and the HAL library even has different functions. Not to mention my coding skills have increased so much since I wrote the initial firmware, I'd want to rewrite it all anyway. Certainly a few things can be reused, though.
I'm in a similar boat over even just the last 18 months... each time I change older LiBCM code sections, I'm ending up rewriting them.

If I powered Pegasus from the OBDII port, there would be a ground loop. Pegasus is grounded to the cluster PCB, which is grounded to the car. The OBDII port is of course also grounded to the car. If I left off the OBDII ground it would eliminate the ground loop, but K/H line signal integrity and 12V power delivery would probably be quite bad. Leaving the ground loop could cause current to flow through the cluster where it shouldn't, and pick up a lot of noise.

My original plan was to have an isolated DC/DC converter and isolated data inside the OBDII plug. This solution is large, expensive, more difficult to design, not as performant as a non-isolated buck, and has higher quiescent current. I'd also need large protection components to protect from voltage spikes on the raw 12V bus.

If I power Pegasus from the cluster, I don't need nearly as comprehensive input protection since the cluster already has beefy protection. And the Pegasus buck regulator can be small, cheap, and efficient. Now I only need to isolate data within the OBDII plug, which is small and easy. The tradeoff is requiring a single two-wire harness to be soldered in the cluster, to some fairly large and easy solder points. I think it's the right choice.
Sounds like a well thought out change. I've designed quite a few isolated DCDC converters, but in your case I agree it's cleaner to just tap the existing cluster voltage.
The last project I worked on at NI was a four channel scope with 26.5 GHz analog bandwidth (per channel), and a 56 GS/s sample rate (per channel). It generated 224 GB of data per second. It was a beast.

At the time (2013), even the fastest memory available just barely couldn't store data that quickly... so we ended up using QTY64 ECC DDR chips in parallel, but we actually wrote data into the error correction bits (instead of redundant check bits)... which was just barely fast enough to work. This of course required a custom DDR RAM controller, which was accomplished with QTY3 dedicated FPGAs with massive I/O so that we could connect each DDR chip to a dedicated bus on the FPGA. Each FPGA cost more than $5k. I forget how many thousands of pins each FPGA had. It was the most complicated hardware product NI had designed at that time.
  • Like
  • Wow
Reactions: 2
Thinking it'll ship RevB?

What is the grenade-looking thing in the background with a spur on it?
Is your timer open source? I want one!
  • Like
Reactions: 1
I'm curious what all those wires in that harness do. My guess is you're routing several different serial buses back to the MCU on the back of the instrument panel? If that's the case, couldn't you place a small interface MCU on the OBDII dongle, and then just route power and SPI back to the main Pegasus MCU? That would bring wire harness count to maybe five or six wires. It would even allow the OBDII dongle MCU to support DFU mode via its USB port (i.e. OBDII MCU would program Pegasus MCU via SPI).

Having a single SPI bus would make galvanic isolation easy, too.
My question is more curiosity than critique. I suppose I'm just curious why there are QTY18 or so wires going from OBDII PCB to Pegasus PCB?

SPI is probably fine. I doubt there's much noise to worry about up at the dashboard... but yeah, if noise is an issue, then substitute "SPI" with "a single differential serial bus". Note that OEM H & K lines are single ended, so again SPI is probably just fine.
  • Like
Reactions: 1
Quite the rabbit hole.
Which LEDs are you talking about?
Is there a reason they can't just always be less bright?
61 - 75 of 471 Posts