Announcement

Collapse
No announcement yet.

LCD Monitor Gauge Cluster

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LCD Monitor Gauge Cluster

    Hey folks,

    My 2007 Chevy Cobalt has a fully implemented CarPC with Gigabyte mobo running @ a Pentium E6300(2.33ghz x 2, technically a core2duo by architecture), 2gb RAM, Xonar D1 sound, an array of available media reading capability, full wi-fi and internet from my hd2 running wi-fi router, BoomzBoxHD, Phoenix SOHO card, BU-353 GPS, running CF3.1, Lilliput 629 monitor, Win7 x64 and soon to have the OBD2 scanner ordered.

    I've been in the community for a number of years, but as of 2 years ago I made my dreams come true and started with an old Duron setup, upgraded to my old P4, and now to my current machine.

    My CarPC runs 100% stable. Hybrid sleep functionality works flawless, in fact every operation thus far on my new box which has been running for months operates flawlessly. From standby boot it's under 10 seconds. From hibernate boot it's under 30 seconds, without having done extensive bios/os tweaks.

    My newest project involves installing a non-touch screen or touch screen widescreen, preferably 10inch, over the gauge cluster(very easy, gonna leave stock stuff behind as a just in case) as an overlay. Will look professional when finished. The goal is to have normal cluster functionality on the lcd while including the ability to access any of the media windows, cams, gps, or obd diagnostics directly from the drivers gauge cluster monitor.

    I'm hoping that the community and MP3Car will see the value in this development and help make my next dream a reality.

    Also, Intel is just up the road from me. If they ever wanted demo's or anything I'd be more than willing to give a sweet demo for them.

    Attached are a few of the video's I've captured. In a couple you should be able to view the gauge cluster.

    Newest, CarPC night. Taken off HD2

    CarPC, no sub vs sub, with a lil peel

    Back with the P4 setup

    When I was first doing tests on the CarPC. Duron setup

    And some Q/A that's already occurred in the thread:
    Originally posted by 2k1Toaster View Post
    What are your plans to implement this?
    One thought was to tie into the connections on the actual cluster using a fusion brain. But that's not really a viable option as the stock gauge cluster is actually fed by the CAN bus.

    Another thought that I had, the E37 computer equipped in the car has a very fast refreshing and higher baud obd bus. Because of that, I was thinking the easiest route would be for my friend Steve and I to interface using that, and polling the values through the link. My friend Steve already has a proof of concept that he has shown me, via a console which allows him to send commands of his choosing(so long onboard computer understands the command) thru and receive info from the OBD/CAN.

    If I went the second route, I could probably talk to the guy that tunes my car, an ex-lead dev for Microsoft Windows, and see how he's gone about FULLY interfacing with the E37. I mentioned the idea of putting his custom tuning suite on the carpc, he said if I later had time he would look into it. His suite even allowed for live monitoring while observing the tune.

    So there are a few options available at this point. I'd personally want to go the ecm obd route for ease of use, and then use a fusion brain to determine turn signal actions and reverse gear engagement.

    As for placement, I'd make a nice custom overlay to simply cover the stock gauges(removable so if something happened....). There is a lot of room within the gauge cluster cowl to stick a monitor in and not get massive glare. I was putting my HD2 up in the cluster area, it looked absolutely amazing.

    Originally posted by colin View Post
    HiJack was just talking about this actually. What do you plan on doing about the PC being unstable? Maybe yours is stable right now, but a point I brought up in the other thread is that any "updates" to your system could cripple crucial parts of your car such as the tach. How will you make it so that other people's systems are reliable?
    my carpc doesn't update on its own. if anything, i choose when to update and what to update. that really should be the route anyone takes when updating their carpc....just like IT admins do when choosing which Windows Updates to approve etc.

    if the carpc became so unstable that the functions of the digital speedo/tach failed, it'd be easy to simply remove the custom overlay, thus revealing the still perfectly functional stock gauges.

    i recognize this project is new ground for most, as not many folks have done this. the goal is to keep the, at least the POC app, as non-bloated as possible and providing stable connectivity through an attached OBD/CAN or possibly analog interface.

    Originally posted by colin View Post
    Is this developed specifically for your car then? Do you have plans to adapt to other vehicles and users?
    the better the hardware interface the better, the newer the vehicle the better. I'm sure my bud would take a look at other subset protocol's or other protocols in general so long as there is a proper hardware interface. on an obd bus he's shown me how he can sniff commands and replicate them with response through his own console, thus allowing him to make a customizable array of commands to run.

    the extended potentialities are there

    Originally posted by hans14914 View Post
    Why not use an Innovate LMA-3 and then use LogWorks software to create the digital dash. This would allow you to log the output of most sensors and display in real-time, providing a hardware solution on the interface portion.
    i've taken a look before. while it accomplishes some goals it ignores others.

    my concept route already uses a middle man approach in both getting real-time data to the dash while also providing a plethora of data accessible to other software etc. taking the simplest route possible with the least amount of tangles and allowing for bidirectional communication of the CANbus are two requirements for this. don't forget i was even talking about the idea of tuning solutions....


    Thanks for your time,
    Warren

  • #2
    I really like this, actually I was thinking about incorperating something similar to my design, however I didnt know how to accomplish this. If you ever post how to incorperate your design, I would have no problems showing you how to do mine.

    Comment


    • #3
      updated original post.

      Comment


      • #4
        What are your plans to implement this?
        Fusion Brain Version 6 Released!
        1.9in x 2.9in -- 47mm x 73mm
        30 Digital Outputs -- Directly drive a relay
        15 Analogue Inputs -- Read sensors like temperature, light, distance, acceleration, and more
        Buy now in the MP3Car.com Store

        Comment


        • #5
          HiJack was just talking about this actually. What do you plan on doing about the PC being unstable? Maybe yours is stable right now, but a point I brought up in the other thread is that any "updates" to your system could cripple crucial parts of your car such as the tach. How will you make it so that other people's systems are reliable?
          2001 Mustang Convertible Worklog
          Indigo Custom Frontend (Flash/Delphi)
          Blog

          Qube v1.3 Now Available at the mp3Car Store!!!!!!
          The simplest IO controller you'll ever use!

          Comment


          • #6
            One thought was to tie into the connections on the actual cluster using a fusion brain.

            Another thought that I had, the E37 computer equipped in the car has a very fast refreshing and higher baud obd bus. Because of that, I was thinking the easiest route would be for my friend Steve and I to interface using that, and polling the values through the link. My friend Steve already has a proof of concept that he has shown me, via a console which allows him to send commands of his choosing(so long onboard computer understands the command) thru and receive info from the OBD.

            If I went the second route, I could probably talk to the guy that tunes my car, an ex-lead dev for Microsoft Windows, and see how he's gone about FULLY interfacing with the E37. I mentioned the idea of putting his custom tuning suite on the carpc, he said if I later had time he would look into it. His suite even allowed for live monitoring while observing the tune.

            So there are a few options available at this point. I'd personally want to go the ecm obd route for ease of use, and then use a fusion brain to determine turn signal actions and reverse gear engagement.

            As for placement, I'd make a nice custom overlay to simply cover the stock gauges(removable so if something happened....). There is a lot of room within the gauge cluster cowl to stick a monitor in and not get massive glare. I was putting my HD2 up in the cluster area, it looked absolutely amazing.

            Comment


            • #7
              Originally posted by colin View Post
              HiJack was just talking about this actually. What do you plan on doing about the PC being unstable? Maybe yours is stable right now, but a point I brought up in the other thread is that any "updates" to your system could cripple crucial parts of your car such as the tach. How will you make it so that other people's systems are reliable?
              my carpc doesn't update on its own. if anything, i choose when to update and what to update. that really should be the route anyone takes when updating their carpc....just like IT admins do when choosing which Windows Updates to approve etc.

              if the carpc became so unstable that the functions of the digital speedo/tach failed, it'd be easy to simply remove the custom overlay, thus revealing the still perfectly functional stock gauges.

              i recognize this project is new ground for most, as not many folks have done this. the goal is to keep the, at least the POC app, as non-bloated as possible and providing stable connectivity through an attached OBD/CAN or possibly analog interface.

              Comment


              • #8
                Is this developed specifically for your car then? Do you have plans to adapt to other vehicles and users?
                2001 Mustang Convertible Worklog
                Indigo Custom Frontend (Flash/Delphi)
                Blog

                Qube v1.3 Now Available at the mp3Car Store!!!!!!
                The simplest IO controller you'll ever use!

                Comment


                • #9
                  Originally posted by colin View Post
                  Is this developed specifically for your car then? Do you have plans to adapt to other vehicles and users?
                  the better the hardware interface the better, the newer the vehicle the better. I'm sure my bud would take a look at other subset protocol's or other protocols in general so long as there is a proper hardware interface. on an obd bus he's shown me how he can sniff commands and replicate them with response through his own console, thus allowing him to make a customizable array of commands to run.

                  the extended potentialities are there

                  Comment


                  • #10
                    Why not use an Innovate LMA-3 and then use LogWorks software to create the digital dash. This would allow you to log the output of most sensors and display in real-time, providing a hardware solution on the interface portion.

                    Comment


                    • #11
                      Originally posted by hans14914 View Post
                      Why not use an Innovate LMA-3 and then use LogWorks software to create the digital dash. This would allow you to log the output of most sensors and display in real-time, providing a hardware solution on the interface portion.
                      i've taken a look before. while it accomplishes some goals it ignores others.

                      my concept route already uses a middle man approach in both getting real-time data to the dash while also providing a plethora of data accessible to other software etc. taking the simplest route possible with the least amount of tangles and allowing for bidirectional communication of the CANbus are two requirements for this. don't forget i was even talking about the idea of tuning solutions....

                      Comment


                      • #12
                        After talking with Steve about the goal of my project we've determined that the obd processing unit should be external of the main carpc.

                        I'm now looking into Single Board Computers to handle the OBD processing and feeding of the heads up monitor. I may even eventually convert my whole system into a series of them feeding the main pc unit.

                        single board computing is probably the future of carpc's and we don't even realize it yet.

                        Comment


                        • #13
                          I have a custom 56 f100 here in my shop using 89 ford OBDI , and was wondering what it would take to install a setup like the one mentioned above in the truck.

                          Comment

                          Working...
                          X