[*sean*]

Extending the display

@Mario, I saw this for the first time and read the whole thing. You have raised the bar on Insight projects.

This is something other Insight electronics builders will want to get data from, send data to display, and control. Any chance of a high speed interface to the board for this purpose? Do you plan to provide an API we can talk to, or release the source, or leave it standalone?

<edit>just noticed on the screenshot above, a UART on GPIO3. will I2C be brought out perhaps?</edit>

 

[*sean*]

There will be an I2C expansion port, and I'm planning on selling "expansion boards" for those that want more GPIO and communications capabilities with Pegasus, for other devices or DIY projects or whatever you want.

Awesome!

https://www.amazon.com/XCSOURCE-Receiver-Controller-Development-TE534/dp/B01IV3ZSKO

(Maybe being a bit premature, and this CAN bus module appears to be a 5V board.)

 

[*sean*]

Here's a vote for a CAN interface. I want it so that I can:

- Activate any buttons you can press on the cluster itself. Allows reset of trip odometer to be controlled by another processor (for example, one that is GPS aware and resets it at the same point every day early in a commute).

- Receive data from the cluster (as opposed to the ECU K-Line, which permits only one device to talk to an ECU). For example, I want to receive engine temperature info and RPM info. My stick shift is a joystick with stick-shaking motors (from an X-box controller) and I want to shake the stick if I should downshift, if the engine temp is too high, etc, if an engine light comes on, etc. I want to receive vehicle speed and MPG information to display in a HUD (like a Navdy).

- Send custom data to the cluster for display where I specify. For example, I want to show my current gear in the speedometer segments.

This actually could open the door to a whole bunch of add-ons connected via a simple four-wire connection.

 

[*sean*]

... there's some cool stuff you could do if you're willing to solder to a few test pads on the stock instrument cluster PCB. I want to add an optional extra "solder harness" that will have 4-8 connections or so, that you solder down to the cluster PCB ...
These would be signals like the fuel level sense, vehicle speed sensor, engine RPM, injector on-time, and the METSCI line. Some of these signals are available through the OBDII bus, but not to a high precision or speed. ...
Hope my ramblings aren't too boring!

Not at all... Extremely useful!

Is this interface and data documented in another thread? I've been looking for a way to obtain this other than OBDII.

 

[*sean*]

Awesome. Thanks!

 

[*sean*]

@Mario

I bought an instrument cluster from a wrecked 2006 yesterday for my experiments. There are some differences between it and the cluster you have.

Of note is that the 5V regulator is a different type and does not have the large attached heat sink. Instead it is using the PCB as the heat sink.

 

[*sean*]

<edited after some thought>

 

[*sean*]

The board holder is very nicely done. What are you using to model it?

 

[*sean*]

Thanks you! I use Solidworks. Pricey, but very good modeling software.

I am using OpenSCAD and I guess after looking at the price of Solidworks, I'll keep using OpenSCAD!

I have information that I want to display from a central computer, and I am wondering if you have an API that will let me command the display to show this.

 

[*sean*]

Will it be possible to poll Pegasus for all the data that the instrument cluster is displaying, and receive it in real time (that is, within 1/10 of a second of it being displayed on the instrument cluster?) Everything, from current speed to IMA info to idiot lights?

Or instead of polling, receive a stream of updates of whatever changes on the instrument cluster (including user input on the buttons?)

In other words, I'm interested in the Pegasus as providing an API to get whatever is displayed on the instrument cluster in real time (rather, real time minus + serial transmission delay).

 

[*sean*]

Idiot lights aren't controlled by Pegasus by default... you could rewire them to Pegasus' GPIO pins

Thanks, that might be a great option, actually.

 

[*sean*]

Seems like a lot of effort though, what are you trying to do?

I'm considering ripping out the display part of the instrument cluster completely and replacing it with a 12.3" automotive 1920x720 display driven by a Raspberry Pi. (Project #9283798 in a long list...) Honestly, your mocked-up display renders a while back are the inspiration...

 

[*sean*]

Thank you for posting the schematic. I've been thinking about alternate instrument cluster displays, and this breakout of the signals saves a lot of work.

 

[*sean*]

You should run separate control lines to RS485 RE~ and DE. I don't remember the reason why off the top of my head

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)

 

[*sean*]

I don't think a running car would ever be below 12V anyway.

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.

 

[*sean*]

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.

 

[*sean*]

Those buttons are totally awesome. I love the design.

I am working on a single DIN HDMI touchscreen to fit in the radio slot. This would make an awesome set of knobs and buttons for them. Display fake buttons, and spin the real ones. These would be PERFECT FOR THAT.

 

[*sean*]

Hi @Mario,

I am considering a number of use cases for Pegasus. I have several new sensors planned (coolant tank level, EGR noise detector) and mods (car operation without ICE) that would benefit from access to the LCD via commands from, say, a serial port (or, in some cases, USB, if Pegasus has a USB programming interface). I am wondering if firmware source will be available, or even just a basic .h file identifying what is connected to what port?

If so, where does Pegasus stand with extra usable ports, serial and/or SPI/I2C interfaces? I'm toying around with installing a small SPI LCD panel where the up/down shift lights are for indicators like lean burn status and other things. Also toying with the idea of repurposing the unused idiot lights replacing with a multicolor or addressable RGB LEDs for things like a lean burn indication, overspeed indicator, "message waiting" from one of my other sensors, etc.

Second, my plan to install a full HDMI panel in place of the stock LCD panel is on indefinite hold as it requires extensive interfacing; I intend to keep the cluster electronics online if only to maintain the existing odometer functionality. Here too, Pegasus could eliminate a lot of work, if connected to the MCU (Pi, likely) driving the display. Is there a show stopper that would prevent Pegasus from being employed to provide a data stream of parameters to a Pi that's driving an HDMI panel installed where the LCD panel is now? (I recognize there is still a tremendous amount of software that I would have to write both in Pegasus and the Pi to do this, and destructive physical mods to the cluster case and the inside of the dash to get the target panel to fit.)

 

[*sean*]

That's awesome. Thanks for the detailed info.

 

[*sean*]

@Mario I like your 3D-printed pogo-pin clamp.

Did I ask you what app you are using for this when you posted about the buttons you made? I happen to like OpenSCAD; not sure what today's cheap (free? open source?) 3D printing model creator software is.