[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.

 

[Mario]

Not sure what the actual character capacity, layout, etc. is for those screens (the MPH and the FCD) - but if your microcontroller is something that could interface with the OBDIIC&C and display those parameters, or maybe some of them, in some way, that'd be a really useful device. I'd actually pay money for it...

There's not a whole lot to work with, admittedly. The MPH gauge has two seven-segment-equivalent displays (though you can do a couple creative things, like that exclamation point), and a single 1 in front of them. The 1 is either all on or all off.

The trip meter area has 9 total seven-segment digits plus a leading 1 on the far left side (for 100.0+ mpg).

I think the instantaneous fuel numbers are actually (almost) all seven-segments too... you might be able to display custom numbers on those tiny digits. I know that the "0" marker is all on or all off, no segment control there - but the others seem to be full seven-segment digits. I'm not entirely sure, I haven't mapped out the whole display yet.

Of course there's also the bar graphs for RPM, temp, gas, assist/regen, and SOC.

The rest of the stuff on the display is just the specialty icons, like "mp/h", "km/h", "trip a", the trip segment arrow, etc.

I think there's a lot of fun things you could do. I'd like to change the assist and regen bars to show absolute amps or watts in/out of the pack, no matter what gear you're in. And SOC would show the real SOC, of course. We could even make the temperature gauge actually useful with a different range or scale (like samwichse said). I've also always wanted the fuel gauge to be linear. A pretty small thing, but it would make me happier.

You could possibly do something creative with the normally-unused portion of the RPM gauge - everything past the redline is never seen in normal driving. You could use those to indicate something if you wanted.

Even silly stuff like swap the MPH and RPM gauges - not sure why you'd want to, but you could in theory! Or make custom startup animations.

I'd imagine any OBDII parameters would go in the MPG seven-segment display area. Unfortunately, you can't do certain letters with seven-segment displays, but we can work around those.

The real question is how you set up what you want. I'll need to add some external controls somewhere.

Omg make the auto stop light work as the lean burn light!

And the temperate gauge show a compressed scale say... 1 bar=2C with 92 in the middle.

I was actually thinking the exact same thing with the auto-stop light!


If anybody else has ideas or feature requests, feel free to throw them out here.

And Balto - could you find a slightly smaller image? It's stretching the page even on my 2560x1600 monitor!

 

[Mario]

Either you've disabled the auto-scale function of vBulletin, or you're using an adblocker that disables the feature.

http://www.insightcentral.net/forums/hard-hat-area/78785-image-resize-test.html

Oh, interesting. The setting was wrong and my adblocker messed up that functionality as well. Thanks!

 

[Mario]

More information required!
Which data lines are hijacked (METSCI,___,___,etc)? Or have you simply hijacked the LCD output control circuitry directly on the instrument gauge?
If this is a feasible "drop-inish" mod, how is unmodified data passed through?
Does CEL come on with hack present?
Very excited about the technical details, even if it's just an understanding of the LCD output circuitry inside the gauge cluster!

Sure!
I have not changed any of the lines going into the cluster. I've hijacked the LCD control lines, like you said. Right now the LCD is completely disconnected from the cluster, I'm just using it as the backlight.

Though I will likely tap a couple of the cluster's input lines for display of certain information, like the fuel sender line.

This could be done as a drop in. No CEL, no warnings, nothing. The cluster doesn't know that anything is different. The microcontroller reads the data coming from the cluster that would normally be sent to the LCD. The microcontroller also drives the LCD's data lines to display what it wants. So it can take the display data it got from the cluster and send it to the LCD, or send its own data.

The caveat to this is that my microcontroller doesn't know anything that isn't being sent from the cluster to the display - So if the cluster is on the "Trip A" screen, my microcontroller can't know that the lifetime mileage is - unless you press the trip button a couple times to switch to that screen! So I'll need to figure out how that user interface is going to work. I've got some ideas, though.

I'll release more information later, but here's the basics of controlling the LCD. The LCD display is soldered to a PCB with three LCD driver chips on it - the NEC PD16430A. There are 14 connections coming out of that board. Here's the pinout:
1 - GND (VSS)
2 - VLCD (5V)
3 - LCDOFF
4 - STB1
5 - STB2
6 - STB3
7 - DATA1
8 - DATA2
9 - DATA3
10 - CLK
11 - BUSY1
12 - BUSY2
13 - BUSY3
14 - VCC (VDD) (5V)

The three chips share one clock line, but they have three separate chip select and data lines. The cluster writes to all three chips at the same time.
You pull the select lines low and send 15 bytes to each chip, then set the select lines high again. There are some configuration bytes you have to set beforehand as well.

Really, it's all in the datasheet for the chip. The annoying part, and the thing I'm doing now, is mapping which segments on the display correspond to which bits, and writing that data down in a sensible format. And then I need to implement that in code, most likely as an enormous lookup table.

 

[Mario]

Mario, if you can make this a drop-in or send-off modification, you've laid the groundwork for a G1 revolution.

Thank you! When I opened up my cluster to replace the trip button, I noticed the LCD controller ICs and that there weren't very many wires between the cluster and LCD. I figured it was a common LCD controller and I'd be able to drive it easily. Turns out you can! I'm amazed nobody's done this before. I hope it'll be useful. I'm pretty sure I can make a device where you open up your cluster, plug the LCD into this board, and plug it in to OBDII and there you go. Should be possible to make it that easy (though if you want to change certain things like the fuel gauge, you'll need to solder a wire or two to the cluster PCB, but I'll try to make that easy).

It's VERY important that your modification prohibits a user from altering the displayed odometer mileage, as that would be a federal crime. I'm not sure how you would do this in hardware without disabling one of the three drivers you've described (the one that drives mileage). Maybe pressing the FCD button temporarily overrides your circuit in hardware (this is an incomplete thought)? I worry that a bad apple would replicate the OEM display, changing only the mileage. Think this out thoroughly, as you could run afoul of EPA law (a.k.a. 'get volkswagened').

Yes, I've thought this as well. I was thinking that if the user pressed the trip button to get to the lifetime mileage screen, then my board would always pass that through, unmodified. Unfortunately, I can't just disable one of the drivers, as they aren't quite sectioned off so nicely (each driver controls a few different parts of the whole screen, not just one section). I could do a hardware override of all the drivers by using buffers and switches if I really wanted to.

However, I think that anything more than a firmware lockout is unnecessary and ineffective, anyway. As long as changing the apparent mileage is not able to be done in the stock device, I'll be fine.
When I release all the information, somebody who's dedicated could just build my board and modify the firmware. Or even make their own board, as the hardware and protocol are pretty simple.

Of course it'll be illegal for them to do so - just like it would be illegal for somebody to roll back their mechanical odometer. But at least I definitely will not be providing the direct means to do it.

Good luck and please make this a reality!

Thanks, and I'll try my best! We'll see how it goes. I'll be updating this thread as interesting things happen.

 

[Mario]

While it is technically possible to replace the stock LCD with a different screen, it would be a much more massive undertaking than what I'm doing. You'd have to push a lot more data with so many more pixels so you need a very fast microcontroller or an FPGA (I don't yet have any experience with FPGAs).

Actually, I suppose you could probably use a Raspberry Pi. Use an HDMI-capable screen, and use Python to make the instrument display. You could have a microcontroller to read the data coming from the cluster and send it to the Raspberry Pi over SPI or something.

I'm not terribly interested, but somebody else is free to give it a go.

 

[Mario]

I've got the display mapped out, which took absolutely forever. This simple demo actually has a lot of time behind it. Did you know there are 326 individually-controllable segments on the instrument cluster display?

Here's my mapping (I'm mostly just posting this right now because it looks impressive):

I'm going to work on writing functions to write letters and numbers to the display and set the bar graphs to whatever you want, and all that good stuff. At some point soon I'll move away from the Arduino I've been using and make a PCB that has a more powerful microcontroller on it. Then I'll work on reading data from the cluster!

 

[Mario]

Thanks, guys!

Very Impressive video.
The Arduino, for the task is it the Mega or the Uno?
Is your programme cooded in C or AVR?

Right now I'm using a Teensy 2.0 because I like them and had a couple lying around. Eventually I will move to an STM32 chip.

It's coded in C; no need for assembly here! The signals aren't very fast, thankfully.

Nice work, can we get excited about no oil light with fas?

Unfortunately not. The oil pressure indicator is a lamp, not part of the LCD. That's controlled by a separate line that goes into the cluster. It's possible to do, but that's not in the scope of this particular project.

 

[Mario]

I have not heard of the STM32 until your post. Than I came across this:

Netduino 3 Open Source Electronic Platform - Netduino | Mouser

The STM32 may be a solution to the legal deadlock over the unreleased Arduino Tres high performance board.

The development IDE for the STM32 where can I find it on the web?

I use CooCox IDE 1.7.5: Free ARM Cortex MCU IDE
They have newer versions, but I don't like them very much.

It's totally free and a pretty good IDE. That version has support for all but STM's newest chips (the STM32F7 line). There are a lot of tutorials on how to set up CooCox for ST's microcontrollers.

It is not as easy as Arduino is, but if you know C pretty well, it's not too difficult. ST provides a lot of libraries that make it easy to set up the system clocks, GPIO, etc.

For this I'm probably going to use the STM32F103, one of their smaller microcontrollers.

 

[Mario]

Nope, those are determined by a diffuse piece of plastic behind the LCD. If you wanted to change the colors, you'd have to replace that plastic (see http://www.insightcentral.net/forum...ument-gauge-colors-dome-light-other-mods.html).

 

[Mario]

I worked on the code more while I waited for some OBDII cables to arrive. I've finished up pretty much all the "drawing" code, so I can easily put a number or text on any part of the cluster. Before I work on the code more, though, I want to prototype a PCB with the final mircocontroller to develop with instead. I'll share that when it's done.

After getting the cables, I've been reverse-engineering the OBDIIC&C (sorry, Peter!) to get all the extended ECU and IMA codes. I bought an OBDII extension cable and tapped into the relevant data lines to watch all the traffic.

OBDII port, male side, looking in end:
  _______________________
8 \   o o o o o o o o   / 1
   \   -------------   /
    \ o o o o o o o o /
16   -----------------    9

1 - 
2 - 
3 - 
4 - 
5 - GND
6 - 
7 - K-Line
8 - 
9 - H-Line
10 - 
11 - 
12 - 
13 - 
14 - CAN-Low
15 - 
16 - 12V

The naming scheme is taken from the Wikipedia page for OBDII: https://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II

The K-Line is where normal and extended (engine-related) OBDII communication takes place. It's asynchronous serial at 10400 bps, 8 bits, 1 stop bit, no parity bit, LSBit first, MSByte first.

The CAN-Low line has IMA-related communications. Asynchronous serial at 9600 bps, 8 bits, 1 stop bit, no parity bit, LSBit first, MSByte first.

The "H-Line" is not actually named on Wikipedia, as it's manufacturer-specific. I called it that because I've seen Peter call it that before (at least, I'm pretty sure that's the line he's referring to). I've yet to see anything happen on this line, but my guess is that it's for CVT stuff. I'll experiment with it later.

The communication for the extended data is different from a regular OBDII request. A normal OBDII packet looks like this:

Sent to car:
 0    1    2    3    4    5
0x68 0x6A 0xF1 0x01 0x05 0xC9

Byte:
0 - Constant
1 - Constant
2 - Request source address (addr of tester) (constant)
3 - Mode (mode 1 is standard info request)
4 - PID (0x05 is engine coolant temp)
5 - Checksum (Add together all bytes in message)

Response from car:
 0    1    2    3    4    5    6
0x48 0x6B 0x10 0x41 0x05 0x64 0x6D

Byte:
0 - Constant
1 - Constant
2 - Response address?
3 - Mode
4 - PID
5 - Returned data (0x64 = 100, 100 - 40 = 60C)
6 - Checksum

The car can return multiple bytes of data instead of just one, as well. Depends on the PID sent.

When you first initialize communications with the car, this is the packet format the car will be expecting. To get extended data, it seems there is an additional initialization sequence that has to be sent. After that, the car expects packets in a different format:

Sent to car:
 0    1    2    3    4    5    6
0x25 0x07 0x72 0x10 0x04 0x02 0x4C

Byte:
0 - Constant (same lower nibble as in response)
1 - Number of bytes in the message (in this case, 7)
2 - Constant
3 - Mode/Address of unit to talk to
4 - PID
5 - Number of data bytes expected (2 in this case)
6 - Checksum (Add all bytes, subtract that from 0xFF, add 1)

Response from car:
 0    1    2    3    4    5    6    7
0x05 0x08 0x72 0x10 0x04 0x32 0x70 0xCB

Byte:
0 - Constant (same lower nibble as in request)
1 - Number of bytes in the message (in this case, 8)
2 - Constant
3 - Mode/Address of unit to talk to
4 - PID
5 - Data (but only sometimes?)
6 - Data (Temp in this case, 112 decimal - 40 = 72C (162F)
7 - Checksum

Still a couple uncertainties in the returned data, but I'm figuring it out. Sometimes it seems like both data bytes are used, sometimes it seems like only one.

The protocol for the CAN-Low line for IMA-related data is very similar, but without a mode byte as there's only one module to talk to.

Sent to car:
 0    1    2    3    4    5
0xE4 0x06 0x02 0x19 0x02 0xF9

Bytes:
0 - Constant (same lower nibble as in response)
1 - Number of bytes in the message (6 in this case)
2 - Constant
3 - PID
4 - Number of data bytes expected (2 in this case)
5 - Checksum (Add all bytes, subtract them from 0xFF, add 1)

Response from car:
 0    1    2    3    4    5
0x04 0x06 0x02 0x8B 0x08 0x61

Byte:
0 - Constant (same lower nibble as in request)
1 - Number of bytes in the message (in this case, 6)
2 - Constant
3 - Data (12V batt voltage in this case, 139 decimal = 13.9V)
4 - Data?
5 - Checksum

Same deal with the second data byte in this one. I'll figure it out, though.

I've gotten about half of all the PIDs that the OBDIIC&C supports and can successfully communicate with and get data from the car. I just used the same Arduino and wrote some code to bit-bang the K-Line:

Also, normally you cannot use two OBDII devices at the same time, but after some investigation, I think it should be possible to make them both work at once by having the OBDIIC&C plug into my device, and my device plug into the car. My device would read requests from the OBDIIC&C and ask for that data from the car to then send to the OBDIIC&C. My device would also be making requests for its own data. This way there's actually only one device polling the car, but both devices can get the data they want. The instrument cluster cannot replace the OBDIIC&C; there just isn't nearly enough real estate to display 8 parameters at once! So I want to make sure I support using both at once.

That's about all I did this weekend! Making lots of good progress.

 

[Mario]

I've been on a trip for the past week and a half, so no updates, but I do have a name for the project... PCB for Enhanced Gauges and Adjusted Scale, User-Selectable. Or PEGASUS, for short. Easiest way to refer to the system would probably be to say "a Pegasus board" or something like that.

I wanted to call it PHOENIX, but I couldn't come up with a good enough acronym for it. Pegasus was my second choice.

Pretty insignificant I realize, but I've been trying to think of a good name for a while now and I'm happy I finally thought of one I like.

 

[Mario]

I was hoping that you could plug Pegasus and the obdc&c AND leave another port open for a BT reader or emissions visits.

I know that I could just unplug Pegasus but it would be ideal to have an open port. I could either move the open port to another place or cut Pegasus into the data lines and leave the stock port available.

I like using the BT obd for some of the graphing functions available through the app.

I just thought that I would suggest this while you were planning so see if it was possible.

Thanks!

I'll only be including one female OBDII port to plug a device into. You can plug in either the OBDIIC&C or a BT reader. I don't think a high enough percentage of people buying this would use two ports, so it doesn't justify the effort to me. Sorry!

I also wouldn't recommend just splicing it into the OBDII lines because there will be conflicts when two devices try to talk at the same time. Then both devices might not work very well or at all.

Sounds cool for EV conversion project. Remap fuel = SOC, BAT = voltage or something (would like to visualize voltage sag if bars are scaled to show e.g. 300-250V), mpg = miles/kWh...

That will be possible! You'll be able to send data to my board and have it display it on the screen, even without using OBDII. I'm including a connector for RS-485 on my board.

 

[Mario]

Hey Mario,
I think your OBDII pinout is incorrect. Specifically, the H-line is pin 6 (G1 Service Manual), which is SAE pin 14. I'll let you verify against my data:
View attachment 41122

Yes, though only in naming, not in function. For some reason I totally didn't think to look for OBD port pinouts on here, so I forgot about the SCS line. In my diagram I call the H-Line "CAN-Low" because that's what it was called on Wikipedia. I now know that to be the H-Line and the one I previously called the H-Line is the SCS line. I knew about the SCS line, I've even used it before, I just totally forgot about it this time, for some reason.

When the project is done I'll release all the (correct) info I have. That post is really outdated by now, I now know some of it to be false.

Very cool! I love the Gen1 dash, and didn't think it could be much improved, but you did it! Sign me up.

Thank you! It's going to be a while before it's finished, but it's coming along.

Recently I've been working on deciding exactly what hardware features there will be on the board, and with that, finishing up the schematic for the PCB. Rev 1 is almost finished, then I have to do the layout, but that shouldn't take too long.

Once I have a real board I can install, I'll work on the coding. It'll take a while to implement the various features I'm hoping for, but I think it'll be worth it.

Features I'm planning on having, so far:
- 4-way tact button (like in OBDIIC&C) for configuring various features
- Two extra trip meters (accessed through the FCD button)
- Remap fuel gauge to be linear, needs some simple soldering to the cluster PCB (optional)
- Remap SOC to show actual SOC
- Make assist/regen show actual amps in/out of battery
- Change scale of temperature gauge to whatever you like
- Replace the static "150" in the instantaneous MPG area with instantaneous MPG
- Show OBDII or IMA parameters in the trip meter area (one at a time), but scroll through as many screens as you like with the 4-way
- Display any parameter or number you like on any area of the display (except MPH area, when speed > 0), and allow scaling to change what is shown. Wanna have TPS where the fuel gauge is, where the bottom is 5% and the top is 90%? Sure! Or you could change the temp gauge to show from 164F to 220F (4 degrees per bar), whatever you like.
- 2x 12V outputs, configurable to turn on under whatever conditions you want. Can drive lamps or relays.
- 3x 5-12V inputs, also accepts analog input 0-5V. Can show the value on screen, have the gauge do things depending on the value, whatever. Use for temp sensors, buttons, etc. I personally am going to hook up the two cruise control buttons on my S2000 wheel so I can scroll through parameters.
- 1x RS-485 port, for future expansions. In particular, I'm including it so it will be possible to talk to mudder's BCM/Li-ion board. Just solder two wires onto two points on the back of the cluster PCB, very easy (cluster will be controllable through this port).

Plus more stuff as I think of it. All these features are subject to change depending on constraints (there is not a ton of space for a PCB inside the cluster, for example, so I already had to compromise on the removable connectors I wanted to use), but at this point I am confident at least all these features will be in the final product.

More news as it comes! I'll show you all the schematic once I finish it.

 

[Mario]

Impressive list of features... Just a couple ideas on the features below:



On remapping SoC, seems like there's at least a couple ways one might do that.
-There's 20 bars so make each bar worth 5%. But most of the time that would leave roughly the lower 4-5 bars and the top 4-5 bars unused.
-Make the 20 bars represent only the useable capacity, pretty much the way it is, just divide that range evenly, so each bar represents the same amount... That'd work in my car, with the 2 different MCMs I've tried, but some people report that their SoC gauge rescales commensurate with what the BCM calculates to be the useable capacity. Not sure about that...

On assist/regen, if possible I think "power" might be better than current... With that there's also probably a couple different ways one might do it. In general, in stock form, max assist and regen are 10kW - so you could divide evenly by the number of bars. On the other hand, it does peak over 10kW sometimes, and non-stock cars can do more... I guess maybe it would be programmable any way?...

That was actually exactly my thinking as well. You can show the full 100% or have it show from 20% to 80%, or whatever you want.

And yes, I'll add an option to show wattage or current, but I agree watts is a better measure. There's only 18 bars on the assist/regen gauges, so if each bar was 0.5kW, you can only show up to 9kW... I suppose you could do 0.6kW/bar to show up to 10.8kW. Or whatever you want, I think I will keep mine on 0.5kW/bar just to make it easy to do the math in my head.

 

[Mario]

Am I the only one who doesn't like these small joysticks? Unfortunately, I don't have a better compact solution, but I always have a hard time getting them to interpret my input correctly.

I agree they are often annoying to use. I could possibly use an analog joystick a la Mike's MIMA system. I was thinking about not including anything and having you use the throttle and brake as input to set up the display. But I quickly realized that would be quite tedious, and besides, you need some way to switch between displays while driving.

This is my favorite feature thus far . Maybe make the '100' show the trailing mpg over the last minute, too? That would be even cooler.

Thanks! I am excited about that feature because I often find myself resetting my segment trip meter just to see my current MPG as a number. This will be very useful.

Unfortunately, the segments in the '100' are not all controllable, only the middle digit is. So you could show 180, 140, 60, 8, etc but nothing more granular than that. In other words, the 1 and last 0 in that 100 can only be 1 and 0 (or off), respectively.

I can include the minute-average MPG as an option for the 150, though!

Why not make it 1 horsepower per bar (746 W). That'll give you 13.4 kW. That's how I plan to display horsepower with my Linsight board (with or without your LCD board). With the Leaf battery installed, I'll show 0.5 kWh per bar... the OEM pack would thus be empty when the gauge is two bars down... that's how much bigger the Leaf pack is versus OEM.

This is also a valid way to show the power being used. I can include all these as options (horsepower, watts, amps).

By the way, have you come up with a name for your modification yet?

Yes! I posted it on the last page. I'm calling it PEGASUS, which stands for PCB for Enhanced Gauges and Adjusted Scale, User-Selectable. Worked hard to come up with that one. You don't have to capitalize all of it, though, just Pegasus is fine with me.

Another feature you might add:
-Trip gauges no longer roll over every 1999 miles... now they'll rollover every 99,999 miles. You just count the number of times a gauge has rolled over since the user last reset... and then store that value in nonvolatile memory so it doesn't get erased when the 12V battery is disconnected.

Good idea! I'll be sure to add that one.

 

[Mario]

Schematic is pretty much finished and I'm starting on the PCB layout! None of the signals are connected to the microcontroller yet because it's easier to place all the components in their general area on the board, then figure out what microcontroller pins would be easiest to route each particular signal to.
There will inevitably be changes and tweaks later as well; this is only the first revision. Once I get the first boards I'm be able to test everything and make sure it all works as intended.

Here's a rough screenshot of the five schematic pages and a photo of the PCB outline (3D printers are super useful):

 

[Mario]

I like 3D printers, too .

Glad your METSCI line is bidirectional, so Linsight and Pegasus can both talk to each other. You should put a 2k resistor between the differential METSCI pair for better noise immunity, directly at the transceiver.. I'll do the same on my end. That'll force current down the diff pair and increase the noise immunity on whichever side is receiving (i.e. furthest from the low impedance driver). I'll also add 200 Ohm series resistors on both lines to prevent short circuits if we both decide to drive simultaneously... The LT1487 is designed to safely overheat and disable if driven into while driving, but I prefer sinking that heat elsewhere.

The instrument cluster already has a 100 ohm resistor across the two lines, so I wasn't planning on adding one. From Honda's design it's clear the cluster was never intended to send data, only receive it. But I think I might be able to make it work.

100 ohms is pretty low - I'd wish it were higher. Unfortunately, I can't expect a user to replace that resistor. It's surface mount, and it could cause some issues with a stock BCM if it were changed. I'm not sure we'll get good transmission with 220 ohm series resistors on the lines. I think you should probably switch to a 100 ohm termination resistor to match the stock setup.

There shouldn't be bus contention anyway because Pegasus will be a slave device - it'll only send anything if you send it something first and are waiting for a response.

Also, what information am I missing on why you're monitoring the current on the 12V and 5V rails? Is this just a safety feature to disable the rail FETs if too much current is pulled? A PTC is cheaper/simpler if you're just trying to prevent short circuit thermal events. I do like that you'll be able to monitor the current .

You are correct - it's to watch for shorts to quickly turn off the power. This is especially important for the 5V rail because it comes directly from the instrument cluster's 5V regulator! Don't want to bog that down or the cluster will shut off.

If you notice I have polyfuses as well... I'm overbuilding it a little for the first prototype. The current-sensing will likely get taken out in a later revision, at least on the 12V rail. It'll have just the PTC. I think I might still keep it on the 5V rail as I want to make sure I protect the cluster.

Mario, I reviewed your schematic and the flux capacitor on page 3 isn't configured properly. You have pin 35 connected to ground, which causes it to go backwards in time. You should have pin 35 connected to VCC, which will cause forward time travel. Honest mistake. A better idea would be to tie pin 35 to an uncommitted static IO on your uC; that'll let the user select which direction they want to travel. Hopefully you have another free pin.

Aw, crap, you're right. Well, I'm running short on GPIO anyway, I think I'll just remove the time travel feature altogether. It's too hard to calculate the MPG, anyway.

 

[Mario]

I didn't know the instrument cluster already had 100 Ohm termination. I agree 100 Ohms is low... the OEM MCM is driving 50 mA into METSCI. Interestingly, the minimum guaranteed driver output current is only 35 mA, so Honda is using the LT1487 above the linear specification.

Also, from the datasheet, loading the LTC1487 to 50 mA drops the differential voltage to just ~1.65 V typically. LTC1487 only requires 200 mV magnitude between A,B for guaranteed signalling. I hesitate to add any more termination resistance because Honda is already driving the LTC1487 out-of-spec. However, leaving my side floating will almost certainly prevent you from reliably communicating with me (I'll 100% be able to communicate with you, as OEM).

I'll add a SPARE parallel termination on my end and remove the series resistors I mentioned previously. Maybe you can talk to me with 2 kOhm termination on my side... we'll see .

Well, it's pretty much the typical application shown in the datasheet, but using 100 ohms instead of 120. The waveform they show is pretty rounded, but it appears to work okay (and with 2000ft of cable, too!).

And while the minimum current-driving capability is 35mA, the max is 250mA, so I think 50mA isn't too bad a gamble.

I agree, let's try 2k on your side and we'll have the stock 100 ohms on my side. Once I get the board and everything I can set up a dummy receiver with 2k termination and look at the waveforms on a scope.

 

[Mario]

Been working on the PCB layout, here's how it looks so far:

All the component locations are pretty much final, though I might still tweak them a little. Just need to finish up the routing now, put all the designators in the right spots, and add some art! Should be done before too long, then I'll order the PCBs.