In car multigauge

What are you developing?
dannyf
Posts: 231
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: 231
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: 7693
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: 503
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: 503
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

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

Re: In car multigauge

Post by BennehBoy » Sat Jan 13, 2018 2:21 pm

I found some time to start mucking about with this project again, the aim in the main is to pare it back to what is essential for my needs.

I'll be ditching the 9 axis code because the magnetometer is too easily swayed by ferrous objects nearby.

I'll probably also park/hive off the ECU code to a separate project.

Anyhow, I have taken the opportunity to upgrade some of the libraries to newer versions and have corrected the code accordingly.

I then grabbed the latest git snapshot of Roger's core and there are some problems....

1) any i2c inits hang the maple mini - if I remove the i2c code then the code runs.

2) only 4 of my SPI screens now work... I'll need to investigate this one further though. can't reproduce this, must've been a typo somewhere.

The core repo I wrote it all against is from last April.
-------------------------------------
https://github.com/BennehBoy

User avatar
mrburnette
Posts: 2236
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: In car multigauge

Post by mrburnette » Sat Jan 13, 2018 2:50 pm

BennehBoy wrote:
Sat Jan 13, 2018 2:21 pm
<...>
1) any i2c inits hang the maple mini - if I remove the i2c code then the code runs.

2) only 4 of my SPI screens now work... I'll need to investigate this one further though. can't reproduce this, must've been a typo somewhere.

The core repo I wrote it all against is from last April.
https://github.com/rogerclarkmelbourne/ ... e07fb05+35

Use github to find a "before date" and use the right-hand symbol "<>" to cause github to provide a snapshot of that date. Try that ZIP. If it works, take the currentvZIP, expand into a temp directory and run a file compare program to identify what happened.

Good luck. I just keep my own Zip of my PC /hardware directory before I upgrade the core. There were lots of pull requests applied last year - lots!


Ray

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

Re: In car multigauge

Post by BennehBoy » Sat Jan 13, 2018 3:08 pm

Fortunately I kept a copy of the repo that I originally built against, I'm a paranoid sort of soul :D

I've dug out some threads which indicate some Wire changes - I'll do some reading but for now it's not a priority since the device I was using over i2c won't be in the final project.

SDfat seems to have also transformed considerably. Again I kept a copy. This I do want to get working. Looks like the stuff for spi transactions has gone or been transformed somehow.
-------------------------------------
https://github.com/BennehBoy

User avatar
mrburnette
Posts: 2236
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: In car multigauge

Post by mrburnette » Sat Jan 13, 2018 3:44 pm

BennehBoy wrote:
Sat Jan 13, 2018 3:08 pm
Fortunately I kept a copy of the repo that I originally built against, I'm a paranoid sort of soul :D
<...>
Yes. With changes coming in from numerous places, paranoid is a good state of mind. I'm git proficient `nuff but I still prefer ZIP archives on my own Linux server!

... paranoid is also why I take the time to incorporate library files into my sketch folder... libraries are not immune either. As I publish some projects, a single ZIP known to work with a specific version of the ArduinoIDE essentially minimizes my support on hackster.io.

I updated Chromium on my Linux systems a few days ago. Then the next day there was a Chromium update and then the next. If Google cannot get their QA and regression testing correct ... well, what chance do we have with our github sources?

Be wise - backup everything.

Ray

Post Reply