Controlling the Instrument Cluster's Display
381 - 400 of 445 Posts
Joined
·
14,300 Posts
Coolant temperature warning is a must IMHO...
The OBDIIC&C does that.. It's saved a few people over the years.
The OBDIIC&C does that.. It's saved a few people over the years.
I forgot about that Bull Dog, thank you.
I also found out that the beeper doesn't go off if you take off your seatbelt while driving! It only does it for a bit when you start the car.
The past week I've been re-familiarizing myself with what I've done on Pegasus so far and thinking about what needs to be done, and how it should be done. Today I finished the schematic sheet that includes all the input buffering for the optional solder harness. This involved tracing all the relevant signals on the cluster, figuring out how they're processed and buffered, and finding the right spots to tap into the signals. Most of them have nice large test points, but a couple connections will be a bit tricky to solder.
Again, this optional harness will read VSS (vehicle speed), TIM (injector on-time), the fuel tank sender, the backlight brightness (to auto-dim the Pegasus controller LEDs), RS-485 for reading/writing METSCI (for future project integration), control the buzzer to add configurable warnings (the controller has a buzzer but it's very small and quiet), and read the MPH/KMH button for configurable actions, since it's such a seldom-used button normally. All useful things, I think!
![]()
I also found out that the beeper doesn't go off if you take off your seatbelt while driving! It only does it for a bit when you start the car.
The past week I've been re-familiarizing myself with what I've done on Pegasus so far and thinking about what needs to be done, and how it should be done. Today I finished the schematic sheet that includes all the input buffering for the optional solder harness. This involved tracing all the relevant signals on the cluster, figuring out how they're processed and buffered, and finding the right spots to tap into the signals. Most of them have nice large test points, but a couple connections will be a bit tricky to solder.
Again, this optional harness will read VSS (vehicle speed), TIM (injector on-time), the fuel tank sender, the backlight brightness (to auto-dim the Pegasus controller LEDs), RS-485 for reading/writing METSCI (for future project integration), control the buzzer to add configurable warnings (the controller has a buzzer but it's very small and quiet), and read the MPH/KMH button for configurable actions, since it's such a seldom-used button normally. All useful things, I think!
Joined
·
4,812 Posts
FYI: The beeper NEVER goes off if you unplug the single wire plugged into the back of the door plunger. That's how I prefer it.
...
Feedback from my quick glance:
You should run separate control lines to RS485 RE~ and DE. I don't remember the reason why off the top of my head, but I do remember I regretted not doing so on the RevA LiBCM PCB.
I'd add a depopulated resistor between RS485 A & B... I know the instrument panel PCB already has one, but if you're planning to solder to those pads, then it would be much easier to just remove the OEM resistor and then already have one populated on your PCB.
What is your ground referenced to? Previously you've mentioned that the next version will have better grounding to prevent ground loops. So are you using GND_ENG or GND_CHASSIS?
Why use logic gates for your inputs? Are they already present in your design? You can get much higher density if you just build the logic yourself (e.g. a single pulldown resistor that drives a single FET gate). Then you don't need bypass capacitance on the logic rails, or the larger logic gates at all. You could probably cut your PCB real estate in half (or more) by using discrete logic, particularly since the digital logic is simply buffering signals. Your BOM would cost for these circuits would also drop considerably.
Probably want a zener on FUEL_SENSE, in case the opamp voltage translation is lost.
I recommend a 100 kOhm resistor between TLV9041SIDBVR pins 4 & 1 (to match the input impedances). Probably not an issue, but it's good design practice.
33 kOhm is a lot of input resistance to FUEL_SENSE. That opamp can drive lower-valued resistors.
Joined
·
2,358 Posts
Is that so when you transmit, your receiver (on the same device) doesn't get a copy of what you're sending?
(though I suppose if you left the receiver enabled you might be able to sense a collision by comparing what you sent to what you received. I don't know if that's a thing - I have not done much with RS-485 where I didn't control both ends or was concerned about this)
True, might as well!
I think it'll be tricky for an end user to desolder a fairly long SMD resistor. It's also glued on since it's on the side of the board that went through wave soldering. I think it won't be too much trouble to leave the existing resistor and solder to it. Alternatively, I could change the RS485 connection points to be at the through-hole cluster connector. Though, it is free to add the footprint, so might as well?
All grounds are referenced to the cluster's signal ground. G401, behind top left of kick panel, according to the cluster wiring diagram. To prevent a ground loop with the OBDII connection, there are digital isolators in the OBDII plug with their own power derived from the OBDII 12V.
They are already present and necessary in the design, but mainly... because I already bought the quantity for 50 boards, with their usage here accounted for. I suppose I could just not use all 9 I had allocated per board, and save them for future runs. You're right that a single transistor design is way smaller and cheaper, honestly I hadn't even thought of it because I was set on using the parts I'd already bought. I think I will make that change, thank you!
The board real estate saving will be nice, but honestly, there is a lot of crap on this board, I doubt the circuitry on this page takes up more than 10% of it.
Oh whoops, good point, I hadn't even realized! Hmm, there is strangely a second fuel-sense circuit on the cluster that scales it to a lower value (about 1.85V max). I might just run the op-amp from 3.3V and read that signal instead. That's still about 2000 ADC counts across the whole fuel sender range, more than enough to scale to 20 bars.
Interesting, I can see why that's sensible, but I've never seen it done in a unity-gain configuration (nor have I ever done it before). Have you seen issues from not doing that in the past?
The 33k on the output was part of a specific resistor divider, but I may not even need it anymore.
Thank you so much for the detailed feedback!
That's how it's currently configured when connected together, only the receiver or transmitter is enabled at once. You are right that having separate control could allow you to detect collisions,
But, if I have the spare pins and board space, might as well add the second line.
Joined
·
4,812 Posts
The opamp inputs are essentially a current mirror, so in general you want to make the input impedance the same on both sides if possible. This can help reduce distortion and reduce non-linear opamp behavior, and in general stabilizes circuits. Input impedance matching is absolutely required in RF-land, and is also necessary when dealing with linear circuits even at lower frequencies. In this case it's overkill for a unity gain amplifier that only needs a few kHz ABW and doesn't really need to be linear, but if you have the space it's not going to hurt anything. Your existing schematic will work, too.
IIRC, I believe the RevA LiBCM issue I had with connecting RE~ & DE was related to power consumption when the car was off. If Pegasus remains powered when the car is off, you'll certainly want separate control lines. Sean is also correct that you have better control for collision detection if you can independently toggle both lines.
Pegasus is always powered, but the RS-485 transceiver, along with almost everything else, is powered through a load switch so it will be powered off when the car is off.
That's an interesting idea. The cluster buttons are all independently read, but Pegasus is only tapping into the MPH/KMH button. All the other buttons already have often-used functionality, but the MPH/KMH button is basically never used. Holding it down will still switch the cluster units, but a short-press does nothing and so Pegasus can use that for a configurable action.
Made the changes! I also realized I could read the car's 12V voltage from the cluster backlight PWM, by tapping into the low side of the bulbs. I was initially taking the 12V reading off the Pegasus power input, since it's soldered to the filtered 12V on the cluster. However, on 2000-2003 clusters, there is a primitive voltage regulator using a BJT and a zener that won't show the true car voltage. 2004-2006 clusters use a different setup with just a TVS to clamp spikes instead, but most cars are the older style of cluster. This solution lets me read the 12V voltage without adding another connector and solder harness.
This won't work with LED bulbs. However, those with LED backlight bulbs could easily solder a 1k, 1/2W or so resistor to their cluster, across the bulbs (I would make instructions how) to fix this.
Reading the 12V voltage will be useful (I think) for compensating fuel gauge readings or injector timings, while removing the need to read it from the (very slow) K/H busses.
I also had to change the buffers I was using because I forgot they don't have schmitt-trigger inputs, and I'm using them in various ways that require that in Pegasus, so it doesn't matter I bought so many of the other ones anyway... anybody want 500 XOR gates?
![]()
This won't work with LED bulbs. However, those with LED backlight bulbs could easily solder a 1k, 1/2W or so resistor to their cluster, across the bulbs (I would make instructions how) to fix this.
Reading the 12V voltage will be useful (I think) for compensating fuel gauge readings or injector timings, while removing the need to read it from the (very slow) K/H busses.
I also had to change the buffers I was using because I forgot they don't have schmitt-trigger inputs, and I'm using them in various ways that require that in Pegasus, so it doesn't matter I bought so many of the other ones anyway... anybody want 500 XOR gates?
Joined
·
4,812 Posts
Are you sure the "12V Read Trigger" comparator output is going to have enough time to stabilize between PWM pulses (so you can read the 12V rail)? Tau on the input is 4.7 ms (47kOhm * 100 nF). In your notes on the right it looks like you've thought this through, but you mention worst case 12V sense time is 1.45 ms, which is obviously less than 4.7 ms. I guess you could use the two most recent 12V_SNS_TRIG interrupts to determine the PWM period, and then use that to properly time the ADC S/H (with a future time event).
The trigger level for the buffer is only 1.4-1.85V, so even worst case (11V car voltage, 1.85V trigger level) it will take only ~865us for the buffer to flip.
Capacitor charge and discharge calculator | MustCalculate
Online calculator for calculating capacitor charge and discharge times
mustcalculate.com
I found out the cluster actually adjusts the backlight PWM based on the 12V voltage! Makes sense, you wouldn't want the brightness changing all the time. The max PWM actually goes all the way to 100% at full brightness and about 11V. I changed the filters so I'll be able to measure down to about 11.5V, I don't think a running car would ever be below 12V anyway.
I finished up another schematic page, relating to the I/O circuitry for the controller and OBDII. Then the user I/O page, and that's pretty much it for the mainboard schematic. Then I can start layout!
The OBDII plug needs a PCB as well, but it's pretty simple.
Things are going well.
I finished up another schematic page, relating to the I/O circuitry for the controller and OBDII. Then the user I/O page, and that's pretty much it for the mainboard schematic. Then I can start layout!
The OBDII plug needs a PCB as well, but it's pretty simple.
Things are going well.
Joined
·
2,358 Posts
I recall seeing it lower than 12V while driving, when I was monitoring the voltage of a lead acid battery near end-of-life and the green wire mod had not been performed. Such a battery will still start the car as long as it can supply enough power to energize the IMA contactors and power the ECMs.
Still, it does imply that the owner may need to replace the battery.
I've been thinking about what capabilities the "user ports" on Pegasus should have, but I don't want to go overboard when most users won't use it anyway. Here's the current plan:
The I2C ports would let a user develop a board with complex behavior and communicate with Pegasus. It could be wireless, GPS, multiplexed I/O, sensors, etc. This is the "high tech catch-all interface".
The CAN port is essentially for the same purposes, just with a different interface. I figured this would be the port people would develop for, it'd be easy to talk to with Arduino or something. You could make query parameters from Pegasus and show them on a separate display, or feed in your own data from external sources to be displayed by Pegasus.
The I/O ports are for reading simple signals or driving basic loads. You could add an extra lamp in an unused space in the cluster and indicate lean burn with it. Or use the downshift arrow lamp for something. You could drive a relay or read a button or a temperature sensor.
I'm mainly wondering if I should add anything to the I/O ports, of if their basic functionality is good enough. Realistically, I'm not sure what else you'd really use them for besides a lamp or a button.
Help me come up with things you'd want to use any of these ports for!
- 2x I2C ports with 5V/GND, and I2C (one on the Pegasus mainboard, and one easily accessible in the controller)
- 1x CAN port with 5V/GND, and CAN FD (accessible at the OBDII plug)
- 2x I/O ports with 12V/GND, a 3.3-12V analog input, and a low-side switch (Pegasus mainboard)
The I2C ports would let a user develop a board with complex behavior and communicate with Pegasus. It could be wireless, GPS, multiplexed I/O, sensors, etc. This is the "high tech catch-all interface".
The CAN port is essentially for the same purposes, just with a different interface. I figured this would be the port people would develop for, it'd be easy to talk to with Arduino or something. You could make query parameters from Pegasus and show them on a separate display, or feed in your own data from external sources to be displayed by Pegasus.
The I/O ports are for reading simple signals or driving basic loads. You could add an extra lamp in an unused space in the cluster and indicate lean burn with it. Or use the downshift arrow lamp for something. You could drive a relay or read a button or a temperature sensor.
I'm mainly wondering if I should add anything to the I/O ports, of if their basic functionality is good enough. Realistically, I'm not sure what else you'd really use them for besides a lamp or a button.
Help me come up with things you'd want to use any of these ports for!
Joined
·
2,358 Posts
You asked about interface ideas. I have been going to Amazon for CAN, RS485 and Bluetooth adapters that are driven by serial. With these, I can run high data rates over a balanced line to a laptop or another device. Perhaps your board can be made to accept a "shield" or "hat" with the data connections and power exposed. One can then build, or breadboard, one of teh Amazon adapters, and if isolation is desired, add one of those tiny isolating DC-DC converters and an ADUM1201 between the main board and the CAN/485 adapter. This could be used as a logging interface where a remote laptop, Pi, or an Android phone is doing the logging.
381 - 400 of 445 Posts
