In car multigauge

What are you developing?
dannyf
Posts: 167
Joined: Wed May 11, 2016 4:29 pm

Re: In car multigauge

Post by dannyf » Mon Nov 13, 2017 11:17 am

Pic of my original Nano driven replacement just prior to install - it's a bit Heath Robinson:
maybe a different approach:

1) each display unit consists of a small mcu driving a display;
2) the display units act as slaves taken data input from a master and visualize it on the display;
3) a master collects take from obd2 and user inputs and sends the data to the display units where the visualization is handled locally.

This approach allows scalability and modulization: the display units should be highly similar to each other, and the communication will be quite simple to handle, potentially via uart or i2c, or whatever suits your environment.

dannyf
Posts: 167
Joined: Wed May 11, 2016 4:29 pm

Re: In car multigauge

Post by dannyf » Tue Nov 14, 2017 9:57 pm

To just expand on my post above, each slave would be identical, with a library of charts or graphs, customizable by the master, to display a value sent by the master.

So the master can simply tell a slave to render a particular graph, with titles, and range, and refresh periodically with a data item to be visualized.

As the slaves are identical, users can customize variables to be displayed on command.

It greatly simplifies programming and production: one piece of master and one piece of slave code running on multiple display units.

User avatar
RogerClark
Posts: 7482
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: In car multigauge

Post by RogerClark » Tue Nov 14, 2017 11:48 pm

Sounds similar to what a new member posted about a distributed alarm system, which uses multiple I2C slaves.

User avatar
BennehBoy
Posts: 423
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Thu Dec 14, 2017 3:52 pm

dannyf wrote:
Tue Nov 14, 2017 9:57 pm
To just expand on my post above, each slave would be identical, with a library of charts or graphs, customizable by the master, to display a value sent by the master.

So the master can simply tell a slave to render a particular graph, with titles, and range, and refresh periodically with a data item to be visualized.

As the slaves are identical, users can customize variables to be displayed on command.

It greatly simplifies programming and production: one piece of master and one piece of slave code running on multiple display units.
I really rather like this idea, parts are cheap enough but I'm probably too lazy to do all the fab and programming :D
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 423
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Thu Dec 14, 2017 3:55 pm

Rx7man wrote:
Sun Nov 12, 2017 8:23 pm
Interesting project.... I have similar goals on my '94 Dodge (Cummins) diesel.. non OBD2 compliant vehicle.

I've come across a number of the same issues you have been having, and because of eternal scope creep (don't we all know about that), I've found some decent solutions to it all...

I too was getting to the point where my rats nest of wiring was starting to cause all sorts of electrical interference, etc, as well as 3.3V/5V compatibility issues, Processor load problems, and so on...

So what I did was make a few small boxes to collect data under the hood.. they all talk over CAN to each other, which eliminates ground problems, etc... Also, I have one box with an Arduino Pro Mini that takes care of all the 5V sensors, no need for resistor bridges. Then I have a blue pill that takes care of all the 3.3V stuff.. 9DOF, BME280, MAX31856's... Inside the cab (a work in progress), another blue pill that has a rotary encoder input (for data selection) and takes care of the display(s), blinky LED's, and so forth. I also have an HE351VE turbo which is a variable vane turbo that is controlled via CAN bus, so as a remnant of previous efforts, it is still controlled by a Mega2560.. That will change in the future.
Another node will be added at some point when I get a different injector pump that will be electrically controlled (PWM signal).
I'm supplying each node with it's own 12V power and CAN signal lines.. so pretty much it's just 4 wires to each one, makes for much neater wiring and no more ground loops... Also, it's a little easier to code for, at least for me.

If you're using a 100PSI generic pressure sensor for a lot of things that don't go over ~65PSI, you don't need to have any resistor bridges... The other option is to go a step up in sensor range.. Just an idea!

Lastly, since I hate loss of precision when I can help it, I do a lot of work in floating point, and to transfer them from one node to another, you use a "union".. it works wonderfully, low overhead, etc.

Code: Select all

union Fourbyte{
   byte b[4];
   float f;
   uint32_t uint32;
   int32_t int32;
}

Fourbyte value1, value2;

void somefunction(){
   value1.f = 1.2345f;
   value2.int32 = -12345;

  for(int i=0; i<4; i++){
   	Serial.println(value1.b[i], HEX); //display the value as it's stored in memory
   }
   
}

Just some of my thoughts and how I got around my problems
I think if I had originally only been looking at this from the perspective of my own vehicle I'd probably have done something similar. As it was I had a ridiculous notion that I might make a couple of bob from selling these to other people and thus tried to pack as much into the smallest package available. Both were fallacious assumptions. :D
-------------------------------------
https://github.com/BennehBoy

Rx7man
Posts: 4
Joined: Sun Nov 12, 2017 3:36 am

Re: In car multigauge

Post by Rx7man » Thu Dec 14, 2017 6:08 pm

hahah, yeah.. I'm doing this for myself.. I don't think I could ever be satisfied with it to put it on market, I'd always be adding just one more feature until I broke it entirely and starting from scratch

Post Reply