Arduino - Digital AC control system for '80 911
 

Am on tail end of resurrecting my ‘80’s AC from a Black Death experience. With all other complications being embraced, it seemed an interesting project to develop a digital AC control & graphic interface. Plan is to use an Arduino Uno connected to a Nextion 2.8” display. Credit to "Dr. J" / John for jumping in to attend sketch/programming for this. I’m dealing with hardware & install.

Idea for this arose from an interest to better understand 911 AC temps & pressures. To start with, this was a temporary digital setup designed to collect and monitor a wide scope of data---an AC Frakenstein experiment of sorts. With the effort going into development, it made sense to morf it into a permanent system. The many-sensor-program has now been pared down to the essentials:

A. Ambient temp & humidity
B. Evap's core temp
C. Duct temp – ELIMINATED… a non-essential
D. Cabin temp & humidity

http://forums.pelicanparts.com/uploa...1475695683.jpg


Preserving '80 Porsche aesthetics... sure... part of this challenge. Of course a digital system is immediately out of place in an ’80 911 but… will make bold attempt to integrate this mod so unit “seems an appropriate fit.” My stock ’80 center console has 2 AC control knobs---fan speed and temp switch. Between these 2 knobs is a speaker front-to-rear fade controller. Below these controls is where the new hardware is headed.

http://forums.pelicanparts.com/uploa...1475695882.jpg


Both AC control knobs will be maintained. Fan speed switch will feed power to digital system (with step down from 12v to 5v.) Temp control switch will connect to potentiometer and used to set cabin’s temp (“Set Temp.”) Temp sensor placed at evap's core will control compressor, preventing evap from going below 32.1 dF.

4x20 dot matrix was the original graphic display plan. While this would work, challenge was finding a bezel to trim the install with. There are some bezels… but… none could be considered having a Porsche look & feel IMHO. Even with small, full color graphic displays… bezels are a surprising issue. Only product line I found with a comprehensive array of small screen sizes WITH bezels is 4D. Their 2.8” unit fits horizontally with bezel.

4x20 dot matrix compared to 2.8 LCD (drawn to scale.)

http://forums.pelicanparts.com/uploa...1475695980.jpg


Because John knows Nextion and not 4D product programming, we're going with the Nextion 2.8 with a 4D bezel. (4D and Nextion 2.8” units have matching dimensions. The 3.2 units do not.)

Unfortunately the bezel for the 2.8 unit is not much to speak off. As far as I can tell, it’s a solid piece of clear plastic that’s black-coated to form the bezel. (Not complaining---some bezel is better than no bezel!) Being solid vs a cut out means there’s 2 layers of plastic to see through in this case. Am not sure how well this will work from a visibility perspective. Since 4D seems a sharp company, I’d imagine they’d not be doing a double-lens unless it works.

Another down side with a full face bezel is the Nextion’s touch-screen capability is lost. Some interesting things could be done with touch-screen so… am looking into alternative bezel solutions in order to preserve the touch-screen-ability. One idea is to CNC mill a bezel. Another is to 3-D print it. If anyone has ideas on how to approach a “cut out” bezel… pls post.

Planned layout...

http://forums.pelicanparts.com/uploa...1475696101.jpg


Whether to finish the added face/surface in black plastic or leather remains to be tested. Idea here is to make existing panel and the addition... seamless. There are also questions concerning sinking the bezel and screen area as a “design consideration"---would this be "good" design?... or a waste of time? How to attach the new face panel (at the bottom to the console) without any apparent/external fasteners? ...These and more questions seek answers.

Karl,

I was going through some pics last night and I thought you might find this one interesting for inspiration. This is a pic of the controls used in the Singer.

http://forums.pelicanparts.com/uploa...1475700414.jpg

Glad to see someone working on this. I have had this idea noodling around for a while. Wish I wasn't too busy with work right now -- I would love to work on this. :(

^^^ TY Tim. Interesting consolidation of controls. Clearly a retro look. Out of curiosity am wondering if that is Porsche or aftermarket? Dial temp... that does not seem early model Porsche but I'm not up to speed on all the early control configs.

Careful with LCD, some don't like heat and turn completely black.

Consider using the Arduino Nano, or better yet for compact size use the Arduino Mini.
Application should require less than 20-30 lines of C code.

Well, it's Singer so it's entirely possible (likely) it is their own design. I like the retro look as it's obviously more period correct looking. If I can ever get the time/garage space to start a project car, this was going to be one of my goals -- consolidating all of the climate controls to tidy things up a bit.

The thing is that I really can't think of a reason it cannot be done with off the shelf components. It would take a little research to figure out what rheostat, fan speed knobs, etc you'd need, how to adapt it to the existing system(s) and package the enclosure -- but it seems do-able.

Now if you wanted to make it where you set a desired temp and the system adjusts temp/fan speed automatically, that would take a little more work but still do-able.

Personally, I deleted the center console in my car so I'd like to see something that wouldn't require it fitting in that spot alone. It would have broader application to more models.

TY for note Jonny. I checked op temp params before subscribing to Nextion unit. Seemed OK. Just checked again to make sure. Is from -2 dF to 158 dF. Exactly what that means in real world is surly questionable. On rare occasions I may park in direct sun. More often I intentionally park in shade. Here's direct sun park... dash surface temp.

http://forums.pelicanparts.com/uploa...1475764000.jpg


Good ideas Dave. Uno's already in hand... so will use it. John still has to confirm it being appropriate. (I'm still wondering if everything can be connected to it. That is John's call.)


Agreed... all the stuff necessary is "out there." Just have to find it... and make it fit. Then there's always the leading edge challenge. In this case, and of all things, bezel presents the greatest (hardware) challenge.

Thought about an in-dash plan here. While I'm not a purist, placing a display screen in an '80 dash does not work for me---it's too far out of context even for my preference. Located in the center console... it works for me.

Have you seen the Restomod Air stuff? They have some slick looking controls and even have a spartphone app you can control the system with.

Custom Aftermarket A/C Systems & Pro Touring A/C Parts: Hot Rod...

http://www.restomodair.com/wp-conten...-CONTROL-2.jpg
http://cdn.rodauthority.com/image/20...6_23-22-25.jpg

^^^ Uber techno stuff Will! Thought about this direction but... given my leaving phone behind quite often, is better (in my case) to have AC controlled by onboard system.

ROFL! 25 years a control systems designer, if I had a penny for every time I heard that!!!


Choose your temperature sensor type wisely as this will impact the software effort required. Typically, automotive temperature sensors are resistive devices or thermocouples. Both are non-linear, requiring either a LUT or a polynomial calculation against published constants.

Control of temperature against a setpoint requires either a PID controller implementation or 'fuzzy logic'. Both are difficult to get right. PID especially time consuming to 'tune'.

Many commercial PID temperature controllers have auto tuning capability but can still struggle to tune, resulting in never achieving setpoint or too much compressor cycling. You definitely need to have a manual override btw.

If I were you I'd aim firstly to have a read back only system and play with it manually to see if your brain can be the control. You will start to develop a set of rules in your head as to how to control the temperature. This is basically what 'fuzzy logic' is, a set of rules. Code the rules and see how you get on with the control.

Trust me, if you go down the PID route, you may be in for a long ride.

I work on this stuff daily and it most certainly isn't ’30 lines of C code'.

Not trying to be negative, just realistic. Good luck with the project!

^^^ Jonny... I have 2 sensor types planned. One is a temp only sensor. This unit goes into evap's core.

DS18B20 Waterproof Temperature Sensor

The 1-Wire bus has by definition only a single data line. Each device (master or slave) interfaces to the data line via an open drain or 3-state port. This allows each device to ?release? the data line when the device is not transmitting data so the bus is available for use by another device. The 1-Wire port of the DS18S20 (the DQ pin) is open drain with an internal circuit equivalent to that shown in Figure 9.

The 1-Wire bus requires an external pullup resistor of approximately 5kO; thus, the idle state for the 1-Wire bus is high. If for any reason a transaction needs to be suspended, the bus MUST be left in the idle state if the transaction is to resume. Infinite recovery time can occur between bits so long as the 1-Wire bus is in the inactive (high) state during the recovery period. If the bus is held low for more than 480µs, all components on the bus will be reset.

Specifications/Features

• Unique 1-Wire Interface Requires Only One Port Pin for Communication
• Each Device has a Unique 64-Bit Serial Code Stored in an On-Board ROM
• Multidrop Capability Simplifies Distributed Temperature Sensing Applications
• Requires No External Components
• Can Be Powered from Data Line
• Power Supply Range is 3.0V to 5.5V
• Measures Temperatures from -55°C to +125°C (-67°F to +257°F)
• ±0.5°C Accuracy from -10°C to +85°C
• 9-Bit Thermometer Resolution
• Converts Temperature in 750ms (max)
• User-Definable Nonvolatile (NV) Alarm Settings
• Alarm Search Command Identifies and Addresses Devices Whose Temperature is Outside Programmed Limits (Temperature Alarm Condition)
• Applications Include Thermostatic Controls, Industrial Systems, Consumer Products, Thermometers, or Any Thermally Sensitive System

Use the Arduino oneWire library. htt

http://forums.pelicanparts.com/uploa...1475881257.jpg

DS18B20 Waterproof Temperature Sensor - oddWires


Next sensor is temp & humidity. One unit will go behind bumper for ambient info. Second unit is in cabin, on ceiling just aft of seats.

The DHT22 is a basic, low-cost digital temperature and humidity sensor. It uses a capacitive humidity sensor and a thermistor to measure the surrounding air, and spits out a digital signal on the data pin (no analog input pins needed). Its fairly simple to use, but requires careful timing to grab data. The only real downside of this sensor is you can only get new data from it once every 2 seconds, so when using our library, sensor readings can be up to 2 seconds old.

Simply connect the first pin on the left to 3-5V power, the second pin to your data input pin and the right most pin to ground. Although it uses a single-wire to send data it is not Dallas One Wire compatible! If you want multiple sensors, each one must have its own data pin! We have written an Arduino library with example code

Compared to the DHT11, this sensor is more precise, more accurate and works in a bigger range of temperature/humidity, but its larger and more expensive

Comes with a 4.7K - 10K resistor, which you will want to use as a pullup from the data pin to VCC.

• Low cost
• 3 to 5V power and I/O
• 2.5mA max current use during conversion (while requesting data)
• Good for 0-100% humidity readings with 2-5% accuracy
• Good for -40 to 80°C temperature readings ±0.5°C accuracy
• No more than 0.5 Hz sampling rate (once every 2 seconds)
• Body size 27mm x 59mm x 13.5mm (1.05" x 2.32" x 0.53")
• 4 pins, 0.1" spacing
• Weight (just the DHT22): 2.4g

http://forums.pelicanparts.com/uploa...1475882258.jpg

https://www.adafruit.com/products/385

Am waiting on John to hear if all planned sensors and Nextion display can be connected to the Arduino. I believe a "Dallas" one wire config is needed so each sensor must have a unique & readable ID... Just realized this sensor is not one-wire compatible.

Karlicious, I think that you have gone completely and utterly (or is that "udderly"?!?!) insane due to years of ridiculous humidity exposure, bro! My a/c needs are more simplererer than yours; cold and colder - no fancy, electronic climate monitoring and control needed (could probably just use a toggle switch that I would use to cut power to the compressor whenever I was cold enough or detected evaporator icing - don't really even need a fookin' thermostat)!

Butt despite your ever increasing psychosis, I still luv yew, longtime!!!

Some are less efficient in designing a system for minimum code or lack the ability to conceptualize
a solution before the actual coding begins.

What had been proposed by the OP is NOT an overly complex design effort as has been suggested!

Very true! And worst of all, some never bother to collate the requirements BEFORE designing the software which should also happen BEFORE even writing a single line of code.

Rescued too many spaghetti code projects...

By your '30 lines of code' statement you gave the OP the impression that the software would be easy and thus completed quickly. It won't be easy unless effort is put in up front in the requirements stage whcih takes time.

"How to assemble and fix an AC from the NASA's international space station"

You guys should rename this thread to this^

I've seen your padded cell Rono. Is just a different color than mine. :D

Swamp luvs ya back Bro!

I've been looking at using an Arduino computer to take can bus information from my Megasquirt ECU and displaying it on my console. Have you given consideration to the readability of the display in sunlight?

Obviously more if one decides to do assembly language coding.

100% truff, right thar!

Dave… believe system is conceptualized but am open to more brilliance than I'm capable of---(I'm not a programmer or techno savvy.) There are 3 rule "compartments." The first controls cabin temp. The second has priority over system to prevent evap from freezing. The 3rd is ancillary controls.

1. Cabin Temp Rules:

IF Cabin temp is > Set Temp, THEN compressor = ON

IF Cabin temp =< Set Temp, THEN compressor = OFF

IF compressor = OFF, and Cabin temp => Set Temp + 2 dF (hysteresis tolerance), THEN compressor = ON

2. Preventing Evap Freeze Rules:

IF Cabin temp > Set Temp, and Evap =< 32.1 dF, THEN compressor = OFF. (Evap temp always has priority as to whether compressor is ON or OFF.)

IF compressor = OFF, and Cabin Temp > Set Temp, and Evap => 32.1 dF + 2 dF, (hysteresis) THEN compressor = ON

3. There are some other control rules such as auto-display-OFF and screen contrast yet to sort out.


System Ops:

Power is fed Arduino from Fan speed switch. 12v steps down to 5v. When Fan is turned ON, digital control & display is ON.
Display comes on in status it was when last shut off.
Temps are all and always in dF.
Existing thermo knob controls potentiometer for “Set Temp”. This does away with existing switch and capillary.
To prevent screen display from buring in, display auto-shuts-OFF after 2 minutes of non interrupted display. (Turning it back on has yet to be resolved. Touch screen is the idea but stock bezel for 2.8” display prevents touch screen-ability. Need solution to replace stock bezel... 3-d print? CNC milling? I don't know answer.)

Unknowns:

Not being familiar with Arduino environment, am uncertain as to all planned parts being able to connect to it… even with a Dallas One-Wire protocol established. Basically I do not yet know how many pins the display will take.



Readability in sunlight... excellent/critical point. One I’ve left to the assumption it will work. Bad choice. Obviously if screen cannot be read during daylight... this = HUGE waste of time. Seems only way to determine daylight readability is to get unit... put it in position with something on screen. This is now first priority. Good one DLT! TY! Did consider reflection… will place mirror where screen will be to see what comes of it. It's possible to set mounted angle of display so if necessary… fine tuning angle will be done. Contrast at night has been considered---potentiometer will take care of that---perhaps same control will deal with daylight visibility.

____ __ _

Few words on my insanity and NASA-esque nature of this project...

This is all done for the creative challenge of it---answering questions: Can it be done? If so... how? It's like climbing a fookin mountain... there's no practical sense to doing so... one does it to do it. (Same insanity applies here ;) )

That's great! It's that simple:

1. You have one output controlling the compressor clutch relay thru a logic level FET, e.g. 2N7000.
2. You have four inputs which are continually read in a loop; the temp setting pot.,
the cabin temp, the Evap temp, and if desired the outside temp to provide another
feedback element if the control loop. The Arduino chip (AVR), like the PIC chip, provides
analog to digital inputs if your temp sensors lack that.
3. Good that you have thought of hysteresis which helps reduce the closed-loop possibility
of oscillations.

At this point you need to focus on your sensors to determine what the signals will look like
and what conversions will be necessary. That's the critical area of your design. After that,
you can develop a preliminary flow-chart of your design. Interfacing the controller with the
display is secondary in your design effort, as it is fairly straight-forward. Breadboard the
system and test it without the display function integrated to check the overall concept.

What you have there is the bare bones of a 'fuzzy logic' controller. I'm not trying to make this complicated for you but you will find it is not that simple to achieve satisfactory levels of control with a simplistic algorithm like this unless you take some precautions. The main reason is that the algorithm does not take into account time. What?? Read on...

Real world effects (like entering shade / bright sun or opening the door/window) will cause the cabin temperature sensor to not accurately reflect the 'nominal' temperature in the cabin.

To combat this you will firstly need to apply a suitable software filter to the cabin sensor input over time. A 'moving average' filter will probably be ok. It will act like a damper on the sensor value so the system doesn't react to spikes (like a brief door opening).

Secondly, you should use a 'trend' for the temperature (again, over time), rather than a snapshot. To understand this, imagine the car is hot and the A/C system has been on 'full'. You would hope that the cabin temperature would start to fall on an exponential gradient curve. If you suddenly got a below setpoint reading from the cabin sensor, the chances are it is a freak event (like you cracked the window or waved your hand). By your rules above, the compressor would switch off, which is undesirable. If however, you followed the 'trend' you would know that the input is false.

Now, the other issue is thermal inertia. You actually want to stop the compressor before you reach the setpoint, otherwise you will overshoot it. Worse, when the temperature rises, you will not be able to start the compressor in time because of your hysteresis. In hot weather, the car temperature will rise something like 5 times faster with the A/C off, than it cools with it on so the system is lopsided. You really need the compressor to be switched on well in advance of the cabin sensor going over set point or a massive overshoot will occur. How can this be done? Well, it is done with a PID controller. The PID controller takes into account 'history' and also 'looks ahead'. Yep, it's all about time again.

This is an interesting project and you will have lots of fun but expect the software to take at least 4 times longer than you expect.

Drop me a line if you need some help, I have been doing this stuff a very long time and know most of the pitfalls.

p.s. All modern car cabin temperature sensors are fitted in shade and have a small fan so that a known quantity of air is sampled over time (not that again!).

Hey Karl, speaking of "padded rooms"; I use an electronic controller very similar to what you've described in this thread to control/override the thermostat of a window a/c that I use to super-cool my bedroom for sleeping purposes (I sleep best in temps below 60 degrees F - mid to low 50s are the best for me). It is a self contained unit that measures room temp, has a heater element that attaches to the a/c's evaporator temp probe, and a frost sensor for the evaporator. The only "trouble" for automotive use is that it is 120V (AC) powered (not to mention it is costly).

It is fully adjustable for temperature, frost sensing sensitivity, etc.

This is one of the most pleasing gadgets that I have ever bought for myself - have been using it every night for a little more than two years and works perfectly.

I discovered this little gem when I was doing online searching for instructions on how to build something similar since window a/c units are only capable of temps of about 64 degrees, and simply replacing the thermostat with a toggle switch does not work since the evaporator then freezes up (I tried this, buttofcourse).

https://www.amazon.com/CoolBot-Cooler-Controller-window-conditioner/dp/B003VSLTAI/ref=sr_1_1?ie=UTF8&qid=1476040680&sr=8-1&keywords=koolbot


https://images-na.ssl-images-amazon...._AC_US500_.jpg

^. Yep, that's a PID controller.

Here's your typical far eastern copy 12V PID:

12V DC Dual Display Digital PID F/C Temperature Controller with K Thermocouple | eBay

Let's NOT make it overly complicated initially for the OP! Implement the design, i.e. do some basic
coding that controls the on/off of the compressor. Once that's accomplished, one can add more
sophisticated algorithms as system needs dictate. Adding time delays before changing the state
of compressor is simple to add to the algorithms.

Bottomline: He's NOT designing this controller as a replacement for the early problematic
Porsche Boxer 986 CCU.

I have a very stupid question. When someone like Wong programs his chips, he puts the car on a Dyno and reads various data while the car is running (air flow, etc). But, there is no OBD2 port. How do you connect a computer to read the data in the DME ??

The data the he is reading is being gathered by the dyno's data acquisition system (tailpipe sniffer for air-to-fuel ratios, ignition timing monitoring via plug wire clamp or similar method, horsepower and torque output, knock detection, etc) and changes are made to the fuel and ignition systems in order to accomplish whatever his goals are - there is no plugging into, or reading data within the DME.

Actually, you can remove the DME ECM chip and read the data stored for the fuel and ignition maps
using a Windows app. One can also use a chip emulator and another app to store and run modified
chip maps without having final EPROM chip installed, i.e. changing map values easily with a PC connected while ECM is installed in the vehicle.

^^^

Thanks, I was unaware of that.

Sugarwood,

If you have a need to modify your DME's maps, chat with Sal Carceller, you will find him in he forum under topics of MAF.

Sal helped me with my fuel and ignition maps.

There is no 'data' that changes or is collected and stored in the DME that I'm aware of.

Not changing anything, just upgraded to a Wong chip, and was doing a little background reading for fun. That's cool you can use a chip emulator without writing to an actual chip.

Yup, you can use a Moates Ostrich to get things down pat and leave it attached, or
burning the new maps to a chip reduces connections and loss if the ostrich battery dies.

If you go down the MAF road, Sal is the got to guy.

Make sure you don't have any air leaks before change your chip; warp intake manifold flanges are common
if the engine has been worked on in the past.

Thanks for input Dave. Status = Techno-John and I have been going through hardware compatibility and system chats. All components have been sorted and I literally ordered everything a few moments ago... progress is on the table.

Worth noting is a comment on One-Wire. I thought this was an essential system protocol based on the number of wires from the display and multiple sensors feeding into the Arduino. John says One-Wire is good but not a requirement here. (As a One-Wire humidity sensor could not be found... this is good news for the parts monger.)

When I receive parts, all of it goes to John. He'll breadboard the system outside the car. I'll install after it's proven.


TIME... good point Jonny. Cabin temp sensor should have some hysteresis setting so as not to read to quickly. Exactly what is optimal (in Miami) will be a matter of road tests and sketch/programming adjustments. To start with we'll pick a number and go with it.

TREND... mo interesting. I interpret this as averaging data over a given period. Nice thinking.

THERMAL INERTIA... This is great stuff. You're pushing boundaries of AC control beyond even my insanity! This has the feel of "environmental prediction." I can see shutting the compressor down in advance of Set Temp being achieved based on inertia... but turning it on in advance??!! Impressive thinking. This is something to consider after system is up and running.

Thanks for drop line offer Jonny!



Padded room with snow maker... way to go Rono. You chill for sure. That's interesting gizzmo. Looked into some units like that but they were expensive. Funny that you tried to over-ride system to improve... Fookin u at the helm Bro!

FWIW, I think that is just a 964/993 CCU unit that has been re-clad to look older.

http://ep.yimg.com/ca/I/yhst-3964979...1_24083725.jpg

Very cool project.

^^^ Toast... Nice note on mod. And hats off to Singer for clever move on retro'ing new CCU. This project... not concerned with period appropriateness. Design goal is a high quality, finished look that integrates "nicely" with black '80 interior.

Today---tested for reflection off display (using iPhone as stand-in.) Is non-issue depending on viewing angle and angle that display is mounted at. Is definitely bad news if line of sight (via display) is out through rear window to bright background---display is useless in this case. Bottom line = angles are critical consideration. Setting it correctly avoids having to duck/bob to eliminate any intrusive reflection. It's possible to "sculpt" panel where display will mount so reflection is roof of car---works with black headliner. Other possibility is to mount display so it can rotate to preferred angle. This gets complicated to produce. (Reflection from my point of view is black/optimal... so not sure how much attention I'm going to give this.)

John has Nextion display he's going to test for in-sunlight visibility of displayed images.

While John attends sketching/programing, I'll be working on the mounting plate (that extends down from existing AC control panel) and how to finish it---black leather or black plastic cover? Plan is to fab added panel out of sheet aluminum... 0.032" material.

Karl,

Some displays have a matte finish versus a glossy one for this very reason (daylight reflection). Consider the Teslas have a big display right in the center console. Maybe it's time to find a Tesla dealer and go for a test drive. :D

FrenchToast - excellent picking up on the 964 unit.

^^^ Good point on material reflection characteristics Tim. John has display unit (in hand) that we'll use. I'll ask him.

Largest challenge so far has been a bezel to finish install with. Many of these small display manufacturers make a fine display... but NO bezel. Won't go into why we're using a Nextion 2.8 display with a 4D 2.8 bezel but that's where the display/bezel combo stands at this moment. Unfortunately this 2.8 bezel is full plastic. This means if used, there'll be the bezel plastic layer over the screen layer. Not optimal. Alternative is to make cut out bezel. Will eventually explore how to go about doing so. Suggestions are welcome.

Am going to test sculpting the mounting panel so looking at the display reflects my black headliner. Since cubby's verticals (where added mounting panel goes) are parallel, is simple matter to sculp & adjust panel until tilt of display is correct. Might be possible to preserve a ledge of storage space (in center console cubby) when doing this.

I've gone through the same issue with various LED and OLED displays for engine management, although the later (oled) has higher contrasts; either has pro's and con's. And, any late model vehicle I've owned with an oem "LED" display, such as center dash units for sound-climate-nav, are simply terrible with ambient light.

You could review OLED displays that are curve able (flexible). Or mount your display in a frame you can pivot.

Otherwise use a white on black display (white text on black background) for highest contrast; you might find that contrast scheme blends in better
with the cockpit as opposed to full color, or, use dimmable dedicated digital LEDs.

^^^ CG... Display is full color graphic so background will be jet black. Text will be high contrast. Screen set up is seen earlier in thread.

After considering importance of angle that display is mounted at, have decided it being best to tilt it back a few degrees when mounted (in center console.) This will ensure display's face reflecting black headliner (from driver's perspective.) Rather than make mounting plate from aluminum sheet, am going to sculpt the mounting plate out of something. Not sure what yet. Sculpting means AC controls face plate will---without question---be finished off in a leather covering (to accommodate 3 dimensional curves.) This plan adds a good deal of work. Am thinking "finished product" will be more appealing than taking easy route.

John tested legibility of actual Nextion display in car. Visibility is good.

Karlicious, I expect nothing less of you, Bro - pimp or go home!!! :)