DIY Mini-Dash LCD Gauges Update #2 - New Layout & Multiple Screens!
 

Hey everyone!
I just wanted to share some of the progress on the Bluetooth and CAN bus gauges we are woking on...

We have updated the design/layout for a more modern look AND can now use a steering wheel button to change what the LCD display shows!

Now that we press a button on the steering wheel and change what is shown on the display, we can now show items like:

• Engine boost / intake manifold pressure
• All four tire pressures in real time. (many have asked for this!)
• Drive torque split between front and rear axle (G37X only)
• Intake air temperature
• Automatic transmission fluid temperature
• Engine Torque & Horsepower
• Lateral acceleration in g's
• Battery voltage
• and 50+ additional items... we just need to find space for them!!

With the ability to show multiple screens of data, we now need to use a "Real time operating system" (RTOS). This will allow us to multi-task and get the quickest responding gauges possible. Remember, we have data coming in via bluetooth, CAN bus and OBD and we need to crunch numbers, update the display and look for button presses to display the next page.

If all goes as expected, the next update should be VERY good :)

That is hugely exciting!

Can you share more about what kind of RTOS you're going to use and what benefits you're going to get from it?

Sure... Since I am using an ESP32, it comes with its own version of Free RTOS.
The ESP32 has 2 cores. Core 0 will be doing all the Bluetooth work. Core 1 will be managing the CAN bus, OBD requests, display update and general logic.

In the beginning, I was only planning on displaying 4 items, so the structure was designed around that. BUT now that I can change pages, I need to manage the ESP32 cycles more efficiently.

With the RTOS, I will split the tasks on core 1 to run "at the same time" (not really, but any dead time is given to a task that can do something)
The plan for tomorrow is to have the CAN bus data as its own task, the OBD requests as its own task and see how well that works as I add additional data items.

I am no expert on this... but I have a plan and will try it and see what happens :)

PS Thanks for your excitement!
If you are up for it, I love to meet up in the spring and chat more about this AND if I could record your car's CAN bus, that would be VERY helpful :)

RTOS is cool. I've never really done any work with microcontrollers so hadn't encountered it before. Seems like a priority task scheduler is pretty useful for this. Now that you've added the button listener for changing pages. I don't know that you need to assign specific functions to a specific core tho... wouldn't the scheduler balanced tasks on the cores for you? Either way, interested to see the results.


Happy to help with can scanning too!

When dealing with a micro-controller like the ESP32 you need to specify what task is running on which core. It doesn't want to use any resources to figure out "what is best" PLUS with the wireless communications being on core 0, if a task was moved there it may have unintended consequences.

Thanks for the help on getting CAN bus data!
Do you drive the Z in winter?

I don't drive much in winter but I don't store it away.

I was looking here
https://docs.espressif.com/projects/....html#task-api

i guess in your case you have long running tasks that need to lock down a single core anyway. you wouldn't want a task being put onto the wireless core because it would pause execution of the wireless task.
Makes we want to start a can bus project of my own.

What's the dimensions of the unit?

Correct. Core 0 is going to be left alone for Bluetooth.
As of yesterday, Core 1 now has 3 tasks running: Reading CAN bus, updating display and sending OBD requests.

You should start a CAN bus project...I have found it to be very interesting and a lot of fun.

The video shows the current "test mule" and has a 2.2" LCD screen (diagonal measurement)

The hardware is designed to work with 1.5", 2", 2.4", 2.8" and 3.5" LCDs and a few 1" OLED displays for a "slim line" ~1"x 3" version.
The first version will be for the G37, just because that is what I drive and can easily test functionality and fitment.

In the spring, I will be meeting up with a few local 370 folks (Toronto) and see what the options are for gauge placement and start to design the enclosure for the LCDs.

Ok thank, most interested in what the gross (enclosure) size winds up being.

What screen size are you most interested in?

The current version now has 8 pages of data and by the end of today I will have a total of 14 pages of CAN bus, Bluetooth and OBD live data.

I want to make sure the hardware can receive and process all this data AND continue to re-draw the LCD screen of 30 times per second, for smooth gauge animation.

Tomorrow I am meeting up with a G37x owner to test displaying the current AT7 gear (even when in drive) live TPMS pressures, torque converter lockup, AT7 input/output shaft speed and the GT-R like % front axle torque.

Wish me luck!

[QUOTE=MotorvateDIY;4021299]What screen size are you most interested in?

The current version now has 8 pages of data and by the end of today I will have a total of 14 pages of CAN bus, Bluetooth and OBD live data.

I want to make sure the hardware can receive and process all this data AND continue to re-draw the LCD screen of 30 times per second, for smooth gauge animation.

Tomorrow I am meeting up with a G37x owner to test displaying the current AT7 gear (even when in drive) live TPMS pressures, torque converter lockup, AT7 input/output shaft speed and the GT-R like % front axle torque.

Wish me luck![/QUOTE

Large enough so us old guys with bad eye's don't need reading glasses to read the display :tup:

Good luck!

Agreed... I'm not going to make a display my 50+ year old eyes can't read :)

those that have flex fuel / ethanol sensors wired in and read E% with ecutek, can you display % through can bus / OBD?

With the "Bluetooth Sensor Server" any sensor can be displayed on a gauge... temperature or pressure or anything else. It could tap into the E sensor and provide the fuel temp and ethanol % (typical data that is available)

I don't think EcuTek would send the ethanol % on the CAN bus as there is no need.... no other module needs to know the ethanol %.

Questions:
• What ethanol sensor do you have?
• Does the ethanol % show on the app?

I will start to look into this... I think a small ethanol % gauge would be useful.

I believe it is a GM/continental sensor that is hooked up to a Zeitronix ECA-2 the flex fuel sensor wire is wired into PIN 102 from the ECU which normally controls something in the EVAP system but the signal is hijacked and repurposed for the ethanol content reading.

I can display the ethanol % on my phone with the Ecutek connect app connecting my phone to the Ecutek OBD bluetooth, so it is getting the reading from the OBD only I guess it knows to translate the EVAP signal reading as the ethanol %.

It wouldn't be impossible to convert it to or add Bluetooth but I'd prefer to avoid this if possible.


Another question or suggestion, Is it possible to change the "gauge display type" IE just have it display a number instead of also having a "Sweeping" gauge. In order to have it take up less screen space and possibly allow for a few more gauges to be displayed.

For example on my phone I have 12 "gauges" but only 6 of them are sweeping like bank 1 and 2 AFR, avg AFR, target AFR and bank 1 and 2 STFT. Then I have another 6 that are just a digital number for things that do not change rapidly like ethanol %, trans temp, oil temp, coolant temp, bank 1 and 2 LTFT.

Things with frequent rapid changes the sweeping gauge style is nice because it can help view the number easier at a glance like boost or AFR. but other things that you just need to occasionally monitor slowly overtime like oil and trans temps a smaller number without the sweeping gauges is perfectly suitable.

3-4 sweeping style and 3-4 only numerical style would be nice. Can easily fit 2 numerical only in the same space as 1 sweeping style.

in a perfect world id probably have 3 sweeping gauges for, avg AFR, boost, and maybe fuel pressure, and then just a number for oil temp, trans temp, ethanol %.

Excellent suggestions, thank you!

Displaying just a number for slow changing items (like temperature) is no problem.

The current chosen display is fairly small (2") and having 3 sweeping items on the top half would mean they would be quite small and may not be easily readable. A larger display is an option that I will look into.

I will also spend some time designing and testing a combo sweep/number layout.
Thanks again for your input, I appreciate it!!

can you do it with this display? with maybe 12 squares. with either a circle gauge or number, or circle inside number? Or even two rows.

Would be pretty great to be able to create our own gauges out of html/css/js or something if that's possible. Maybe your server could publish a pubsub interface other code could listen to. Then I can write my own gauges for any screen.

https://www.youtube.com/watch?v=mACX...annel=ETAPRIME

Nice video..... but nope :(
The hardware I am using isn't fast enough or have enough memory for an HDMI input... that's where a Raspberry Pi fits... other than the 15-20 second boot up time every time you start the car. To me that is waaaaaaay to long for a dash/gauge to start up.

BUT there are other HMI (human machine interface) type options. In a nutshell, the HMI displays have a dedicated GPU and does all the rendering/heavy lift using very "light weight" commands from a microcontroller. The downside is the additional cost.

Now, this may be an option down the road, but I want to walk before I run.

I am also not sure how will HDMI signals work in the VERY electrically noisy environment of an automobile. From what I have seen, most video in a car is LVDS (low voltage differential signal) or GVI (gigabit video interface)

Anyways, thanks for the suggestion... I will add it to my "to investigate" list :)