Pi, EGT, AFR, Boost, Temp - Digital dash build

[SPF40plus]

Hi all,
I'm starting this as a separate thread for my digital dash build for my FTS700 camper. I'll be posting up progress on the build and links to Github for the Python files once complete. Hopefully, it provides a useful starting point if you are interested in doing something similar.

The following is from my build thread, pasted here again to show what will follow.

I'd already bought a raspberry pi to monitor the tanks and solar for the camper, so decided to try building a digital dashboard with it.

My requirements for the dash are that it:

1. is readable day or night
2. is able to show data for at least 4 sensors
3. is powered by the cab electrical circuit
4. turns on when the ignition is switched to Acc or On
5. turns off when the ignition is switched to off without killing it
6. logs all data coming in, and saves to an externally accessible drive
7. be updatable/upgradable
8. be repairable and have reasonable component support/availability
9. not be insanely expensive

In relation to the requirements above:

1. getting a real time graph to display data was randomly difficult to find, examples exist but they are generally developed by individuals for their race cars, and most also use OBDII because that is what people are playing with: result - I've written my own in Python (after relearning Python) and using the Matplotlib and Numpy libraries, which are both open source.
2. I'm not sure yet if I'm going to use a small ultrawide screen that is made specifically for raspberry pi, or something else, but am tentatively looking at a 7.9 inch Waveshare capacitive touchscreen.
3. I need a 24v-5v dc-dc converter to power the Raspi
4. I found a project done by Everlanders on youtube, which you should look at if this is something you are interested in, they have a video on controlling the starting and shutting down the Raspi. I'll be doing something similar using an Optocoupler.
5. there needs to be either a direct connection to the battery, or an inline battery capable of powering the Raspi until it shuts down, otherwise it is likely that simply turning off the Raspi will cause it to fail. There are RAID controller backup batteries for servers, and I'm trying to find one of these to see if I can use that, unfortunately it looks like most operate on 12v, not 24v.
6. I bought an SD reader breakout board and 32Gb SD card for the Raspi to save log data to.
7. I've bought some ADC (analogue to digital controllers) to test, and some EGT amplifiers, as EGT voltage is produced by the elements in the thermocouple when heated, unlike other sensors that commonly act as a variable resistor that operate between 0 and 5v. The voltage from the thermocouple is very small and the magnitude of difference between a temperature of 100 degrees versus 800 degrees is less than 1v (4mV to 34mV). Testing these to destruction/failure is going to be interesting.
8. The components for the Raspi are available in every state and territory, so waiting for a part should not be as bad as for some of the other options. The downside of course, is that if you make it you have to maintain it.
9. So far the costs are looking like AU$450 to AU$650 depending on options. It is worth noting that you can get the people at Onegauge.com to make a custom board, or there are units that can read analogue sensors available from Powertune (Australia) and from Just Race parts (Australia) but the latter is the JRP 14 in 1, and the screen on this is very small (and I'm too old for that). I priced up a full set up with Onegauge and it was in excess of $4k. It was awesome, but for that price, buying a second as a backup makes it really expensive as an option.

As you can see most of the above is not that difficult, but it does take time and you have to be willing to burn some components to test that everything works as expected. I hope that at the end of this I can help you to avoid some of that cost.

The biggest question I had was whether I could build a digital dash that updated in real time, and showed the graphs with useful data. Here is where it is a presently - the dials move around randomly because I have a sensor emulator running that simply generates random numbers.
Daytime Screen:

Night time screen (I know the numbers and dial don't match on this):

You will see on the bottom of the above image that the CPU usage is shown for Python. The original concept that I coded was only capable of 1-2 second intervals (refresh) because it was rendering the whole screen each time. It maxed out the Raspi's processor and crashed at full noise. The program now uses blitting, so the only data being updated on the screen is the needle, and the digital readout, the remainder is set at initial start-up.

If you are wondering why the two different screens, the red readout can be on at full brightness at night and only marginally reduce your night vision, but it is harder to see during the day, especially with sunlight on the screen. The daytime screen uses blue with light grey to give a high contrast image without unnecessary glare (such as from white background). There is an interesting discussion here if you want some more information: https://ux.stackexchange.com/questi...sitivity,produces the highest visual contrast. I tried the black with yellow, but where you have a screen that reflects light from its surroundings, yellow/black seems to be affected more than the blue/grey.

I'll post an update once I get some sensors connected, and some physical buttons and a potentiometer connected to control dash functions and screen brightness respectively.

 

[SPF40plus]

If you haven't played with electronics or software before, then the following information may give some context about what is involved for a digital dash that reads analogue sensor data in a pre-OBD2 vehicle.

What signals do analogue sensors send?
In short: voltage. Most sensors act as a variable resistor (there are many types), and except in very old vehicles they all operate between 0v and 5v (so I've been lead to believe), and the gauge you use to read them responds to the change in voltage. These sensors require a supply voltage and return a variant of the supply voltage to the gauge. There are 2, 3, and 4 wire analogue sensors.

There are a few exceptions to the above, and a thermocouple is one of them. These (at least K-Type thermocouples) produce a small voltage when heated, as noted in the last post, and this needs to be amplified to enable the voltage to be read by a gauge.

How does a computer or development board read analogue signals?
While it is possible for a sensor to be directly attached to the GPIO (General Purpose Input/Output) pins of a development board, this requires a script to read, translate, and record the voltage from a sensor. And there are voltage, current, and other limits when using a direct connection.

This is better done with an ADC (Analogue Digital Converter), which has all the hardware for managing input voltage, current, and other factors, and a chip dedicated to converting the signal, so your main computing platform doesn't have to do that work.
The ADC will deliver digital value, and depending on the chip it may be a single value, multi value, and may have a timestamp as well. For ADCs that support 3 and 4 wire sensors, there will be supply voltage and return voltage in the data.

With a device like the Raspberri Pi, you need to write code to accept the digital data from the ADC, and then do something with it. In the images in the last post, I simply used a random number generator with ceiling and floor values to provide the data to be shown on the gauge. You could also do something like make a real time sine wave or similar.

You can see that the third and fourth gauges have different minimum and maximum values. The interface is now set up so you specify what these are and the number of divisions you want to see, and it automatically daws the gauge based on those settings.

What voltage will the computing unit use 24v, 12v or ?
There are a number of common development boards and the operating voltages are listed below (but what you need to know is that you need to convert your vehicle voltage to whatever they use, because none of them are 12v or 24v:

1. Arduino: 5v, however the Uno claims variable input between 7-12v (you need to read the caveats on this however).
2. Rasberry Pi: 5v input/3.3v operating. The latest Pi is powered through a USB-C plug.

There are many others, but the support is limited, and parts (particularly compatible break-out boards) are harder to get for them.

Why choose one over another?
In round terms the Raspberry Pi is a credit card sized personal computer that runs on a variant of Linux, and the Arduino is a programable circuit board that you can upload scripts to (C/C++ based).

I bought the Raspberry Pi because I wanted to be able to build out capabilities that were not likely supported with devices available for Arduino, and because if there is an issue with the prototype, the Raspberry Pi allows you to edit your code, debug it, and test both hardware and software without any other device. The Arduino requires that you use its IDE (Integrated Development Environment - which is really just a piece of software within which you can write code and debug it) on another computer and then upload it to the board/chip.

For ongoing use, the Raspberry Pi has a potential downside, and that relates to its complexity and number of drivers, and software components that must be updated and maintained over time. Also, if you have multiple scripts running, and don't manage the memory and CPU usage, then the Raspberry Pi is more likely to hang, and require intervention (reboot etc).

To be honest speed is the other factor that you have to consider. If you are using Python to script your solution it is slow when you compare it to C/C++. It is possible to use C/C++ for development for the Raspberry Pi, but if you are reading this, it is unlikely that you have a background in C/C++ development, and it is a big learning curve. I have no qualms in saying that C/C++ would be a better universal language to learn, it is fast, well supported (at production level) and used/supported in all major operating systems. But it is harder to find examples and tutorials if you are just starting out, and it takes a long time to learn to code well with it. Finally, you need to compile your source code (the code you write) into binary/executable form in order to use it. Whereas Python is an interpreted language, which means the source code of a Python program is converted into bytecode that is then executed by the Python virtual machine. In short this means that the Python Interpreter (software) needs to be running on the device, so that your code can be executed.

How can you control the dash?
Do you need to? If you want a device that just turns on and off and shows stuff on a screen, then the Arduino would be fine.

It is not possible to control an Arduino with a simple monitor or touchscreen, as these require the connected computer to use a driver to manage input/output. For controlling an Arduino you need a HMI (Human Machine Interface) which is a screen with its own GPU (Graphics Processing Unit), CPU, memory, storage, and data input/output. Instead of relying on the Arduino to process the graphics elements, it simply receives data from the Arduino and uses its own software and processing capability to interact with the data.

If you want to use a touchscreen (without its own operating system or firmware) to enter values, review data logs, search a dataset or execute processes then the Raspberry Pi is likely a better option. You can use HMIs with a Raspberry Pi but you can also use any HDMI computer monitor or screen. With the Raspberry Pi you can also plug in a keyboard and mouse, or other control device and use it like any other personal computer.

_____

So that's the basic outline. If you have any questions, or have some better information to add, let me know.

 

[SPF40plus]

The parts list for the prototype build is as follows (this does not include all the sensors and ADCs required):

1. Raspberry Pi 4
2. Sense Hat (note large stackable break out boards for Raspberry Pi are called hats)
3. HDMI screen/monitor
4. Widgets:
   1. MCP3008 8 Channel 10 bit ADC chip (Adafruit)
   2. ADS1015 12 bit ADC breakout board (Adafruit)
   3. MCP9600 thermocouple amplifier break out board ADC (Pimroni)
   4. Various potentiometers
   5. Break out garden
   6. Piicodev Raspberry Pi adapter
   7. Piicodev Atmoshperic sensor
   8. Adafruit T-Cobbler (for connecting a bread board to Raspi)
   9. Sparkfun Optocoupler
   10. SD Card reader break out board
   11. SD Card
   12. Breadboards
   13. Various SPI, I2C, jumper wires
   14. Fist full of resistors in all common specs
5. USB-C switch (on/off)

I haven't decided yet whether I build a custom board with all components soldered in or if the cluster of break out boards will be resilient enough for life in a medium rigid truck. Initial inspection of the connections suggests that things will come apart with vibration, so a soldered board is likely necessary. As a result the array of ADCs necessary for all the sensors will have to wait until tests are done.

 

[SPF40plus]

The Raspberry Pi has its own version of Linux (Raspbian), so in order to get anything done you need to get familiar with terminal commands. Google it. Having an understanding of how software installation and updates is essential, everything else is a bonus.

With Python, after installing it (or updating it) with the Linux commands you can install dependencies with a component called pip. The critical thing to understand when setting up is that it is likely that both Python 2.7 and Python 3.9 will be installed on the Raspi, and it is possible to install additional versions to suit your needs.

Python versions <3.10 don't have some of the functionality that I like to use (primarily Case statements) so I have installed 3.10.

The problem with installing the latest version of any software is that any dependencies that other people write will likely take time to update, and there can be breaking changes, so keep that in mind. At the time of writing this the latest version of Python is 3.11.3.

Being able to install various versions of Python is great, it gives you some flexibility, but it also brings complexity. With this in mind Python has a feature called "venv" or virtual environments. This means that you can create a virtual environment based on any of the versions of Python that you have installed, and then use pip to install libraries into that virtual environment, and these will not affect, and will not be available outside of the virtual environment. The catch is that you need to be careful to use pip in the relevant virtual environment, so the updates get installed in the right place. The other thing to be careful with is if you are using the pre-installed IDEs like Thonny or Geany you need to ensure that you are using the correct Python interpreter for your virtual environment, or nothing will work as expected. If you are running Python from the command line then make sure you activate the virtual environment prior to running any commands. It will also be necessary to use the Python version to start the process, in my case "python3.10 -m [insert command]". You can set the default interpreter in the virtual environment, and then you can just run "python -m [insert command]". There are plenty of tutorials that describe all of these.

When working with terminal commands it pays to use short directory and file names, because you have to type them in a lot.

To get things working, I needed to:

1. Install an additional version of Python (3.10.x).
2. Update/upgrade pip.
3. Create a virtual environment (ftsdash).
4. Install some dependency packages (for matplotlib).
5. Install matplotlib (graphing library).

I used matplotlib for the graphing because it does not require any webservices, account registrations, or other things to work (which is important if you are using it without an internet connection). There are other shinier and arguably easier to use graphing libraries available, but all of them have a feature or requirement that is not ideal for the intended purpose.

The matplotlib documentation is reasonably detailed, but it is difficult to get detailed information about features and how to use them. The package is also not consistently implemented, so something that works for one graph type will not necessarily work for another. Please take that as notice of issues to be mindful of, not a criticism of matplotlib - the fact that it is available for no cost, and with the features and documentation that it has is pretty amazing.

 

[SPF40plus]

Time for an update...
After battling with the implementation of matplotlib.backends.backend_tkagg and FigureCanvasTkAgg for about 4 hours, I now have the dash concept working. Still a bit fugly, but on its way.


The charts on the Turbo page are as before and use the Matplotlib library (with the addition of a canvas, which is inserted into the Tkinter window). I have developed a number of web applications and like the concept of separation of concerns (i.e. presentation layer, business logic layer, data access layer, persistence layer, etc). The implementation of Tkinter and the canvas object created in FigureTkAgg is some weird admixture of concerns, and is difficult to separate out into different classes without importing the libraries into each file in the project. It works, but if you are going to pursue something like this, just be aware of it.

The engine page is presently just a set of place holders, with no connection to streaming data yet. But there is already a window after() loop that the update can be completed in.

The after() loop is responsible for the streaming data on the Datastream page, and this is just pulled from the Matplotlib object every second.

The solution is currently multithreaded, and uses approximately 22% of CPU 0, 15% of CPU1 and 13% of CPU2 on the Raspberry Pi. I'd like to reduce this further and will have a look at that as I consolidate the code further.

 

[SPF40plus]

On the weekend, I've made the following changes:

1. attached actual sensors and moved the data acquisition and processing to a separate module that operates in its own thread in the background
2. overcome an annoying Raspberry pi GUI issue when using a touchscreen (when minimising and maximising the screen, the task bar shows a pop-up that never goes away if you are not using a mouse, and obstructs the maximised window)
3. added a fourth tab for some buttons
4. added buttons and callback functions
5. enlarged the tabs for easier touch screen use

I tried to get a video of it working but the screen is so shiny, i can't get a clear image. I'll sort that and post one up shortly.

 

[VanWaLife]

This sounds like a cool project. I use PLX Devices products to monitor AFR, water Temps, etc, but their app for monitoring on the phone barely works, and doesn't support logging.

 

[Fenderfour]

Thanks for sharing. I'll be following this thread. The custom dash solutions are expensive.

I've been playing around with an Arduino implementation. I thought about trying a Raspberry Pi and a screen, but decided to start with a simple LCD readout. I'm new to all of this, and it seems like an easier build. I don't need to fuss with screen control, just sending a signal to an LCD based on collected data. I'm currently planning to add EGT, Tach, Oil Pressure, Oil Temp, and eventually Boost Pressure on two different LCD screens. I think the values will cycle with a push button, with some notifications if values are in an unacceptable range. Since the LCD's will just be stuck to the current dash, i can remove them later, and use the same sensors for a more feature-rich build like yours.

I know thermocouples aren't a linear signal, I'm guessing you are using MatPlotLib to do the A/D mapping?

 

[smokeysevin]

If you want a quicker/simpler but more expensive way to do it. You can pickup a microsquirt ecu, a pi display, pi3+ or newer, a serial hat, and just run tunerstudio for linux.

If you go that route, you can use some of the i/o on the microsquirt to run relays or other functions. That said, you are initially more limited on the specific type and number of sensors vs just running adcs straight to the pi, but I believe the microsquirt can run can i/o exoanders and if not, there are a few pi dash i/o expanders that are now on the market.

Sean

 

[SPF40plus]

Thanks for sharing. I'll be following this thread. The custom dash solutions are expensive.

I've been playing around with an Arduino implementation. I thought about trying a Raspberry Pi and a screen, but decided to start with a simple LCD readout. I'm new to all of this, and it seems like an easier build. I don't need to fuss with screen control, just sending a signal to an LCD based on collected data. I'm currently planning to add EGT, Tach, Oil Pressure, Oil Temp, and eventually Boost Pressure on two different LCD screens. I think the values will cycle with a push button, with some notifications if values are in an unacceptable range. Since the LCD's will just be stuck to the current dash, i can remove them later, and use the same sensors for a more feature-rich build like yours.

I know thermocouples aren't a linear signal, I'm guessing you are using MatPlotLib to do the A/D mapping?

I've got three modules now:

1. The renderer/main program which is just a tkinter window and some functions that call data from the other modules.
2. the Matplotlib figure, which contains a class used to create multiple instances of the gauge class.
3. The data module, which has all of the imports for the ADCs, and the functions that receive the data, create a list or dictionary, and make that available as a property of the module.

Here it is working from cold start, I haven't coded or put the hardware together for the automatic shutdown yet. In the video I have an atmospheric sensor attached, which is mapped to the gauges using four variables: 1. Upper bound (this sets the top value on the relevant gauge); 2. Lower bound (this sets the minimum value on the relevant gauge); 3. List of values; and 4. string representing the units of the gauge (this is what is shown in the label, such as the ^C after "EGT"). I have modified the values from the sensor to suit the upper and lower bounds.

Turn the volume down - my jumper was rubbing on the microphone while recording.
screen

	

MVI_5615 by Simon F, on Flickr

 

[SPF40plus]

If you want a quicker/simpler but more expensive way to do it. You can pickup a microsquirt ecu, a pi display, pi3+ or newer, a serial hat, and just run tunerstudio for linux.

If you go that route, you can use some of the i/o on the microsquirt to run relays or other functions. That said, you are initially more limited on the specific type and number of sensors vs just running adcs straight to the pi, but I believe the microsquirt can run can i/o exoanders and if not, there are a few pi dash i/o expanders that are now on the market.

Sean

I haven't looked at those, I'll check it out - thanks.

 

[Fenderfour]

I've got three modules now:

1. The renderer/main program which is just a tkinter window and some functions that call data from the other modules.
2. the Matplotlib figure, which contains a class used to create multiple instances of the gauge class.
3. The data module, which has all of the imports for the ADCs, and the functions that receive the data, create a list or dictionary, and make that available as a property of the module.

Here it is working from cold start, I haven't coded or put the hardware together for the automatic shutdown yet. In the video I have an atmospheric sensor attached, which is mapped to the gauges using four variables: 1. Upper bound (this sets the top value on the relevant gauge); 2. Lower bound (this sets the minimum value on the relevant gauge); 3. List of values; and 4. string representing the units of the gauge (this is what is shown in the label, such as the ^C after "EGT"). I have modified the values from the sensor to suit the upper and lower bounds.

Turn the volume down - my jumper was rubbing on the microphone while recording.
screen

	

MVI_5615 by Simon F, on Flickr

That's looking great so far.

 

[SPF40plus]

So, I decided to have a look at building the dash with an Arduino and 4dsystems PMI screen too. That way I can compare both and will use the same sensors so I can get a useful comparison.

Is there any performance metric or other comparison that I should do?

What I know so far is that the Pi takes the best part of a minute to start and the Arduino takes less than 4 seconds from power on.

 

[javajoe79]

You might consider using an available digital dash from Holley.

Holley EFI 553-116 Holley EFI 12.3" Standalone Pro Dash

<b>Holley has done it again, a pair of industry-leading digital dashes for the masses</b> Have you always wanted the look of a modern digital dash in your project vehicle but lacked an ECU or fuel injection system that supported one? Holley has you covered with two amazing new standalone dash...

www.holley.com

I use one in my NPR build and it couldn't be more simple. You can read pretty much any sensor, log data, customize the appearance, can bus capable, multiple screens that you can toggle through, it will handle output functions like turning on fans, lights, pumps etc.... Combined with the PDM that I use for power distribution, it's an extremely versatile system with huge potential

 

[SPF40plus]

You might consider using an available digital dash from Holley.

Holley EFI 553-116 Holley EFI 12.3" Standalone Pro Dash

<b>Holley has done it again, a pair of industry-leading digital dashes for the masses</b> Have you always wanted the look of a modern digital dash in your project vehicle but lacked an ECU or fuel injection system that supported one? Holley has you covered with two amazing new standalone dash...

www.holley.com

I use one in my NPR build and it couldn't be more simple. You can read pretty much any sensor, log data, customize the appearance, can bus capable, multiple screens that you can toggle through, it will handle output functions like turning on fans, lights, pumps etc.... Combined with the PDM that I use for power distribution, it's an extremely versatile system with huge potential

Interesting. I tried the link in your sig, but its not working since the server upgrade. Does your NPR use OBD2? Or have you connected your sensors individually to the dash?

The local shop that stocks these, also stocks a similar unit from PowerTune, which is an Australian equivalent device. The Holley unit is worth almost $4k here including delivery from the US. The PowerTune unit is between $1k and $2k depending on options.