Reference Hardware Info?

It looks like a lot of (well, some) people are going beyond simply running RealDash on a phone or tablet and building custom hardware as a permanent install in order to replace factory gauges. These systems must all solve the same problems:
-powered by vehicle 12V system
-automatically turn on/off with ignition, both CPU and screen
-start directly in realdash app (not Android home screen for example)
-control screen brightness for day/night viewing
-start up quickly (either fast cold boot or sleep/hibernate)
-reduce/stop power consumption when vehicle is off
-connect to vehicle hardware - GPS, backup camera, audio amplifier etc
-etc etc etc
Is there a “reference” / “recommended” / “simplest” hardware setup to address these issues? I see lots of discussion in the custom hardware forum but nothing organized like “here’s what you need to solve for a permanent install” (the list above) “here’s a reference build that solves those things” (recommended hardware and how to put it together) or "here are several hardware possibilities and pros and cons of each?
Perhaps a section of the website that walks newbies through possible installs?
Perhaps as simple as a forum topic to identify all the common problems that a permanent install must solve (the list above is of course incomplete) and another forum topic for each issue? (“12V power for your build”, “responding to ignition”, “controlling screenbrightness”, “reducing cold boot time”, “hibernating vs cold booting”, etc etc.
I get that you’re one guy and this is probably not your job - I have to say I am super-impressed with what you’ve accomplished! This is just intended as constructive feedback from a new user wanting to build a permanent factory dash replacement and not easily finding info. It appears that a lot of info is there in the forums, just not organized into “how to get started with a custom build - what are the issues and possible solutions”

I just re-read that and it sounds harsher than I intended - sorry about that - not my intent to criticize! Maybe a different tack - any ideas how we all could organize a forum topic or topics into something like “Custom builds 101: what you need to know before building your own integrated dash” or something?

I faced a lot of this myself recently, and honestly I’m still working through some of the issues and hardware currently myself. I will say that much of the issues you are talking about there isn’t any solution that fits all of those problems, and much of it has to be some sort of custom electronics. I’ll give you a bit of a start in where to look for a few things and maybe it will help to some degree.

Screen control&brightness:
This is going to be a bit tricky depending on the screen you use. Many screens have some sort of LED backlight now with a separate controller board for the backlight. For example this is the screen that I’m using. There is a board in the pictures that has a 3 wire connector on one side and 2/2 wire connectors on the other. This is what powers/drives the screen backlight. There are several like it, but essentially these are 12v powered on the red/black wire, and some will have 2 yellow wires and some will only have one. One of the yellow wires is an enable wire, meaning that it turns on the backlight when this wire gets voltage AND the red wire has voltage. This yellow wire can be anything from 3.3v up to 12v to turn the screen on (I will get to why that is important later.). The other yellow wire that many have is a dimmer wire and will lower the backlight based on the voltage it gets. 3.3v will have it brighter than 5v for example. This can also be PWM controlled which will make life easier.

Most of the screens that I’ve seen have run off 12v-20v.

There are plenty of computer options out there, and I’m going to call them as SBCs (single board computers). The SBC you decide to use will be up to you for the most part on what you are comfortable with OS wise. A few that I have tried is a raspberry pi, a kahdas vim3, odroid n2 and a few other small enclosure intel based SBCs. The benefit of the pi, vim3, n2, is that these have GPIO pins that can be used for inputs and outputs for the dash. These also have some other benefits of being able to have canbus attached directly to the GPIOs vs using a USB can device. Now keep in mind, all of these pins cannot run 12v in or out and would need other electronics to drop the input voltage down or drive a relay for an output. The n2 will run off 12v, the pi, vim3 and such you can use a buck converter or some other way to bring the 12v down to the 5v USB voltage to drive it. The pi, vim3, n2 and such can run linux or android for the most part, but what I think I’m going to settle with is this SBC . I’m still working the differences between either running linux or windows as both of them will work. The main reason I’ve had issues with narrowing down a SBC is that the screen I linked to above is the one I’m using, and it has a really weird resolution that it doesn’t report properly, so I’ve been having some issues trying to get an SBC that will drive the correct resolution without issues. I’ve run into several, like the vim3 I couldn’t get it to work at all at the correct resolution, the n2 worked perfectly except that it would blank the screen out sometimes unless I turned off the screen driver and turned it back on, the current computer running windows would occasionally crop the edges off until I ran a utility again to fix it, etc.

Other controls:
Now here’s what I would call the meet and potatoes of the systems of control. I’m using an arduino based controller. The one that I found that has a log of protection built in with things like 12-20v inputs and such is by Products — Rugged CircuitsRugged Industrial Arduino Microcontrollers this solves many of the 12v issues. Now I’m going a bit overboard on my setup on my car as I’m replacing all of the fuses and such with canbus controlled PDM’s to directly control all of the different loads in the car, so ALL of the car inputs are going to be going into this arduino and then it will have logic to control the PDM’s to turn on the different outputs based on what it sees and the programing I give it. But this is also handling the inputs for RealDash and some of the control. For example it is controlling the SBC power, screen power and screen backlight. The rheostat for the dash control is fed into the arduino, and the arduino is controlling the screen brightness. The SBC I have it set to power on as soon as it gets power, and a relay is what is being used to drive that power. The arduino is going to be constantly powered as they usually don’t draw too much power themselves. It will turn the lcd driver on and off based on the logic I program, and will also do the same with the backlight and the brightness of the backlight. Now my ultimate goal is that I don’t want the OS of the computer to be seen, so I will have realdash sending signals to the arduino so that the arduino knows if realdash is running or not, and will control the screen based on that. If realdash isn’t running, and other things like the ignition switch is on, then it will power cycle the SBC, wait till it boots up, and when realdash is running it will turn on the screen. The arduino is also handling the other inputs like turn signals, lights and such, and sending the signal to realdash over canbus so that it can display that input. Now as for bootup speed, power consumption, turning on and off and such. I am kind of combining those into the same functions to a degree. First I want to have it go into hibernate or sleep if I can for faster startup time, but I haven’t worked that out completly yet. However, as for bootup speed/power consumption, I plan on leaving the SBC running if I can’t get it to wakeup from sleep, and for the arduino to monitor the power of the car. If the power of the car drops below a certain voltage, it will shutdown the SBC and kill the power. Bootup speed is still about 20-30 seconds, so the way that I plan to handle that is if the SBC is off, when the door locks are opened, the arduino will start the bootup process of the SBC so it’s booting while I’m walking up to the car, opening the door, getting in, getting the key in, etc… So the perceived bootup time will be lower. I still have some tweaking and working on that to do as everything is on the bench at the moment, but that’s the plan anyway.

That’s kinda the overall nutshell, and I know it seems like a lot, and it’s a daunting task. I’m not really an electronics guy, I’m a sys admin by trade. What I would suggest you do is to write down all of the issues that you see that will need to be tackeled. (screen brightness, sbc control, etc) and then address each one of them one at a time until you know how to make that portion work. For example the screen brightness. Figure out how to get the screen to adjust the brightness, then figure out how to control that brightness with some sort of logic control, if you want that to be the knob on your car or through realdash, or however you want to do it. Once that is created, then move to the next item. Eventually, you will have everything marked off and you will have a system that controls the things you want. If you have any questions I will help point you in the right direction to try and figure it out.

Thanks, that’ll help a lot!

What an interesting read.

I had the same questions/issues when I started my build. I didn’t end up with what I wanted. And I’m a little disappointed that I’ve given up in trying. My build was for a car I built for AutoX and occasional street use. For AutoX I wanted to monitor and record the normal inputs like oil pressure/speed/RPM/etc. But I also wanted other engine controls like wideband, steering input, brake pressure. When on the street I really only cared about my speed. I’ll just say that very little of that happened.
The display I’m using is a VSDisplay 12.6" I’m using a Raspberry PI for the SBC running Linage OS (an Andriod build) and RD. I planned on using a Seeed canbus but couldn’t get that working. And I planned on using the GPIO pins on the PI but couldn’t get those working. So after trying those items I settled on the Bluetooth approach with only the standard inputs.