[mudder]

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!

 

[mudder]

Mario, if you can make this a drop-in or send-off modification, you've laid the groundwork for a G1 revolution. I'm thinking customers send in their gauge clusters for modification, and then they simply plug them back in and maybe have a USB port they can use to program what the gauge cluster displays.

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').

Good luck and please make this a reality!

 

[mudder]

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:

 

[mudder]

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

Thanks for that future support, Mario! Talk about awesome!

Features I'm planning on having, so far:
- 4-way tact button (like in OBDIIC&C) for configuring various features

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.

- Replace the static "150" in the instantaneous MPG area with instantaneous MPG

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.

 

[mudder]

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.

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.

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

 

[mudder]

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.

 

[mudder]

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.

 

[mudder]

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.

 

[mudder]

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 .

 

[mudder]

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.

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 .

 

[mudder]

Looking good, Chris!

 

[mudder]

Any thoughts on pricing yet?

 

[mudder]

I'll early adopt that. Send me your paypal and I'll make a 100% deposit, knowing that the price might increase. Having an early unit will help me suss out Linsight+Pegasus.

 

[mudder]

The problem with gallons/mile is that it's a very small number - 50mpg is 0.02gpm. The digits above the bar graph can only show certain whole numbers. What would make more sense is g/100m, in which 50mpg would be 2g/100m.

Why not do liters/100 km? It's an internationally accepted fuel standard and already part of the OEM UI. Show mpg on the bar graph and L/100 km on the BCD. Force us to metricize .

 

[mudder]

Looks like you and I are at about the same juncture in our respective design processes . Congrats on the successful bringup. Yes, I love having a pick and place machine... I built the first Linsight PCB in less than an hour, and the second one in less than 15 minutes. 450+ components!

 

[mudder]

I'm thinking of making a lean burn indicator on the dash.

As others have mentioned, why not use the "auto-stop" LED to indicate lean burn status? We don't need the OEM flashing behavior to tell us when the engine is off (0rpm and dead quite are redundant indicators).

 

[mudder]

Hey Mario, I assume you posted this schematic for review, so here are my thoughts:
-J2: SMD USB connector. If your design tolerates it, I recommend a through hole connector for improved mechanical rigidity. Of course, if you have no other through hole parts, SMD will work.

-R11/R12: Is 22 Ohms correct series termination for your part? I typically see values in 3x Ohm range (e.g. 39 Ohms)
-C13/C14: Are these required by your uC? Creates a 1 GHz LPF, so shouldn't be a problem, but also isn't really filtering anything either, as most noise is below 1 GHz. D3's parasitic capacitance is likely greater than C13/C14.

U2: 100 mA F1 and 100 mOhm R1 yields 10 mV maximum voltage across U2. With 100 V/V gain in CS30CL, you're only using 1 V of the ADC range at F1's maximum nominal rating. If you've properly rated the fuse to less than half its rated current, then you're only looking at 500 mV max. Thus, I suggest increasing sense resistor R1 value to achieve better measurements, or increase fuse size if you expect to pull more than 50 mA. I worry that since you're exposing 5VU to connectors, the 100 mA fuse will blow out prematurely.

D4: Can you explain what you're using the 3V3 Zener for? I assume you're trying to prevent opamp U10's positive 5V, but am worried D4 might not sufficiently protect the line, if your microcontroller can't tolerate voltages much larger than 3V3.

R9: 510 Ohms is much higher than before, right? I'm thinking the Linear driver (used in both OEM and Linsight) can drive more current. Last we spoke of this, I thought we decided to use OEM values.

R18 & R23 (and related): Looks like you're dividing 5 V signal down to 3.3 V. However, the values for R18 & R23 seem backwards. As found, you're creating a 1.3 V high signal instead of the desired 3.6 V (if resistors are swapped). There are other swapped resistors, too. (I've made several assumptions on what you're trying to do).

...

Hope all is going well.
Let me know when you want to swap projects . Linsight is dragging on and on and on.

 

[mudder]

+1 to the idea of measuring actual fuel flow into a graduated volume. Based on the data I've seen in this thread, I recommend a 20% duty cycle at 30 Hz. That'll let you determine the true mechanical area under the curve (i.e. the volume of fuel released in a given time).

 

[mudder]

Definitely, as long as they are parameters that Linsight will have available to read over the H-Line (pretty sure it will have those).

Yes, those parameters will be supported.

 

[mudder]

But rest assured it's not dead, and Pegasus will be completed at some point in the not-horribly-distant future.

I'm excited to get my hands on one.