Adventures with an Arduino

The printing finished up and I'm very happy with the fit into the coin tray.

1595905522477.png


1595905536431.png


I'll have to reprint the outer bezel as there was a small miscalculation on the height of one of the connectors on the back of the Nextion screen. I can't quite completely close things up. Looks like I need to add another 1.5mm worth of material so it'll snap closed nicely.

1595905679730.png


One step closer to being installed in the truck.
 
Well rather than reprinting the portion of the housing I made 1mm short I put together this piece to go in the middle. It also has much better standoffs to hold the Nextion display in place. The two numbs on the outside piece were really just for locating the screen in place. These actually press the circuit board firmly up against the outside of the housing.
1595994170905.png


So freaking cool to design something and then hold it in your hand an hour later.

1595994358011.png


Screen fits snug with just the right amount of room to run the wires.

1595994407831.png


And everything snapped together pretty nicely. Upping the print resolution for the final version should eliminate the stair-stepping and close up the gaps and ridges where the 3 parts snap together. This will work well for testing in the truck though.

1595994488567.png
 
So that whole reinventing the wheel thing...I don't seem to be able to leave well enough alone.

I took my prototype, stuck it in the coin holder after reinstalling said holder in the truck and...I hated it. The angle was off. The dash has a natural curve at the edge of the coin tray and my shroud had a sharp corner that didn't match. Basically it was going to take a lot of fine tuning, adjusting angles, rounding edges, etc. I could throw all these tweaks at the model, wait 4 or 5 hours while it printed and then test it again. I'd probably have to do this 5 or 6 times, and I could probably get it to where I would like it. That's the beauty of 3d printing I suppose. Multiple prototypes, fairly cheaply in a short amount of time. The thing I wouldn't be able to fix is I didn't care for the ergonomics of it. It's a little bit of a reach to get to the screen, nothing horrible, but enough that I didn't care for it. I also happened to have a large cup from McDonalds sitting in the armrest cupholder that impeded my view and access to the touchscreen. So back to the drawing board.

I took the front cover off, taped the screen in place and started holding it all over the truck. The F250 has a natural void, that's flat I might add, on top of the dash just to the left of the cluster. A lot of aftermarket tuning companies use this area to mount their tuners. This seems like a win. I liked the position and it should be easy to stick something up there. Out of direct line of sight so it's not a hindrance while driving. Let's see what I can do with this.

Here's a picture of a dash mount for a Bully Dog tuner for the F250:

1596250649228.png


So my thought is not to have to print that entire shape, but instead just use this location and "appropriate" a design from a popular action camera brand. So, borrowing some parts from a free model on Thingiverse, I came up with this:

1596250857178.png


I learned some things from my initial model so this is an improved housing. The screen cutout is much more precise so only the usable amount of the Nextion LCD, plus about a 2mm border, show through. I also came up with a retention method to hold the screen in place against the front of the housing using this little clip design:

1596251032522.png


The post goes through the mounting holes on the Nextion board, pushing past the angled portion of the tab next to it, and the straight edge locks it in place. I printed several versions of this little tab to get the spacing and size just right. At around 3 minutes a print this was a great use of the 3D printer to get the fine details right before printing the entire model.

I also decided that since I was going to have this level of accurate retention I could make use of the exact positioning and cut a slot for the micro-SD card slot on the board. This would allow updates to the programming and images on the Nextion without having to disassemble anything. Sweet! Additionally I cut a relief in the top of the housing to allow a back panel to slide in and created a small tab on the lid to lock things in place.

1596251328826.png


1596251361147.png


4 1/2 hours later I had this:

1596251648890.png


Because it printed face down the slicer put support material under the rounded edge of the gopro mount. This proved difficult to remove so I might need to come up with another shape here. The clips worked perfectly the first time and I can drop the housing from a height of about 5 inches off the desk before the board will pop loose. I think once everything is done I'll add a small dab of adhesive to cover the post and tab to more permanently mount the screen and keep it from bouncing out on rough roads.

1596251853700.png


Also added this little reinforced opening to route a wire through to make the connection to the screen. Originally I had thought about packing the screen and arduino in one housing, but to keep this compact I'm going to mount the arduino (and the relay board) remotely inside the dash. I sourced some 4 conductor wire that will feed through and connect to the Nextion.

1596252043588.png


Now to print some Gopro style clips and get this thing mounted.
 
Changed my mind on mounting again. :D

Printing the Gopro style mounts worked well, but just looked clunky in the end. It was good to get the dimensions and process down as I might use this mounting method in the future, but for now I decided to make a custom t-track to mount up on the center of the dash. This keeps things modular as I can put together little pods that slide in and out. Redesigned the Nextion enclosure to make it a little stronger and rethought my cable management with the new mounting location.

1598286053849.png


The track matches the profile of the storage compartment on the top of the F250 dash, and has tapered holes for the screws I'm using to mount it with. The holes on the backside of the track allow me to insert a nut and use a small screw to clamp the shrouds in place anywhere that I slide them to on the track. This keeps the fasteners hidden and everything nice and neat. This is a sample of the track as I was getting all of the mounting holes sized correctly:

1598286209966.png


I then did some test prints to get the profile correct and generated the final product:

1598286277829.png


1598286297981.png


This shot is before the track was mounted. The gaps between the dash and the bottom of the track closed up once the screws were put in:

1598286352310.png


I put a little bit on an angle on the track so that the Nextion screens roughly match the viewing angle of the head unit in the dash. Moving on to wiring now...
 
Gallowbraid
Nice work and nice write-ups. A curiosity question - I am considering the purchase of a slightly used Transit van for adventuring. Most have no factory tow package. I am unfamiliar with current CAN systems, but, have heard bad stories about tapping into various factory circuits and the canbus going “crazy.. I have not done any type of coding since early to mid 1970s with Fortran. I am thinking about using the relay board and the Arduino to tap into the tail lamp system (tail and brakes) so the Can system would not see any appreciable change in the lamp amp draw. Main power for the relays would come from the engine battery then to the trailer. In your opinion, Would the Arduino work with an “intermittant” voltage signal (turn signal) and actuate the relays properly. Would the relay board tolerate the heat of a relay engaged for an extended period of time (fail lamps illuminated on a long drive)?
Maybe a direct relay board tie into the factory lights as 20mA relay draw may not be seen by the Canbus?

thanks in advance
 
Gallowbraid
Nice work and nice write-ups. A curiosity question - I am considering the purchase of a slightly used Transit van for adventuring. Most have no factory tow package. I am unfamiliar with current CAN systems, but, have heard bad stories about tapping into various factory circuits and the canbus going “crazy.. I have not done any type of coding since early to mid 1970s with Fortran. I am thinking about using the relay board and the Arduino to tap into the tail lamp system (tail and brakes) so the Can system would not see any appreciable change in the lamp amp draw. Main power for the relays would come from the engine battery then to the trailer. In your opinion, Would the Arduino work with an “intermittant” voltage signal (turn signal) and actuate the relays properly. Would the relay board tolerate the heat of a relay engaged for an extended period of time (fail lamps illuminated on a long drive)?
Maybe a direct relay board tie into the factory lights as 20mA relay draw may not be seen by the Canbus?

thanks in advance

Thanks for the kind words.

As far as tapping into factory harnesses and not having the CANBUS throw a fit it really depends on the vehicle. I've had good luck with most Ford vehicles up to around 2017, haven't messed with anything newer than that. To contrast that I did some work on a 1999 BMW that had multiple local networks running within the factory wiring and it wasn't happy if you even wiggled a wire much less tapped into something. Modern Dodge/Jeep/Chrysler vehicles have multiple networks running internally and at different speeds. If you start providing a bridge between wiring that's on different internal networks hilarity and disaster can ensue. :eek:

Taking a quick look there are several kits on the market for Transits that add trailer wiring and even trailer brake controllers by tapping into the tail light wiring: LINK

If you wanted to go the DIY route and all you're wanting to do is run trailer tail lights you could skip the arduino altogether and just use the relays if you're worried about drawing too much amperage. The factory tail lights could trigger your relays and then you could feed 12v through the relay to the trailer lights. Keep in mind though that normal automotive relays aren't typically designed to operate turn signals, usually a specialized relay (flasher relay) with a thermostatic switch that pulses on and off is used to run the factory turn signals. Normal relays would work, but the frequent on/off would cause them to wear down faster due to their electro-mechanical switching element. "Faster" is relative. Bosch style relays (good ones anyway) are typically rated to last mechanically for 1 million cycles. I've never counted how many times my turn signals flash and my brake lights come on in a day but I bet it would take a long time to get to 1 million (although now I want to know the answer to that question). Electrically speaking it depends on load, but most are rated between 100,000 to 200,000 cycles. Flasher relays skip the electro-mechanical mumbo jumbo and utilize elements that heat and cool to make their connections. They'll last for as long as those elements last (typically a long, long time).

If you're set on using the Arduino there will be a few things you'll need to do:

1. Powering the Arduino requires that you step the vehicle's 12v system down to the 5v that it needs to run. The relay board would require the same. You'd want this power to turn on and off with the Accessory circuit of the vehicle.

2. The input signal you get from the vehicle (turn signals / brake lights) into the digital pins on the Arduino will also need to be stepped down via resistors to 5v. The arduino will absolutely handle this intermittent signal, that's what the digital pins are designed for, monitoring high/low | on/off states.

3. You'll need to decide where you're going to pick up your input signals from. If you tap into wiring that's between the turn signal switch and the flasher relay you'll need code on the arduino to control the "flashing" of the relay you're outputting to because your input signal will be a steady 12v. With this method it would take some trial and error to get your trailer lights to match your vehicle lights as far as the timing of the turn signals flashing.

If you tap into wiring between the flasher relay and the tail lights your code will be different because your input will turn on and off because of the flasher relay. This would make for easier coding and the timing of your relay turning on and off would match your factory turn signals. This would be the intermittent signal scenario.

4. You'd want to look at the rating for whatever relay board you source to determine if it could handle what you're wanting to do. As far as it handling running tail lights on a long trip I would imagine almost any good quality board would have no problem. You're essentially closing a circuit and lighting up an incandescent light bulb. If the trailer had LEDs it would be even less of a strain on the relay. Flashing, or the cycling on and off of the relay would be the thing that would cause the most wear and tear so double check the cycle rating of the relays on the board. A common relay used on those boards is the SRD-05VDC-SL-C, it's data sheet shows that it's rated to last mechanically for 10,000,000 cycles and electrically for 100,000 cycles. However it's maximum cycles in a minute is 30 so it might not be able to match the flashing of the turn signals depending on timing without causing additional degradation of the relay.

By the time you invested in the arduino, relay board, wiring, any connectors, loom, heat shrink, mounting supplies, etc you're probably well on your way to buying a pre-made kit like this one: LINK

But plug and play systems like that aren't as fun as putting together something on your own. :D Plus with the arduino you could violate DOT regulations and get your trailer lights to pulse out morse code messages when your turn signals are on.

All of this ultimately hinges on the fact that control of the turn signals and brake lights in your given vehicle hasn't been turned over to a computer in the vehicle completely. There's a chance that the turn signal switch is just activating programming within a CANBUS module that's then controlling the lights (much like you want to do with your Arduino). That'll change where you'd want to pull your signals from. Sounds like a cool project, post up your results if you decide to tackle it!
 
Since I finally got around to actually mounting the Arduinos in a vehicle I decided it was time to nail down the software side of things a bit more. I made some layout updates, smoothed out some of the interface and added a neat little function for when aux lighting is in use on a forest road. A software developer friend of mine was over today and he helped to optimize some of my code and I'm fairly sure left with a headache after looking at what I'd done. @Scott B. , he'll tell you all about it this weekend...

In previous vehicles where I had physical switches that controlled lighting I would inevitably find myself coming around the corner of some back road only to be met by some oncoming vehicle, hiker or well meaning squatch. Then a mad scramble would ensue as I tried to mash the individual switches that controlled each lighting element before I caused irreparable damage to their corneas. On my arduino system I have a button (marked with a lightning bolt) that when pushed reads the state of all the relays, stores that info and then instantly shuts everything off. The button then changes color to indicated that it has settings saved and pushing it again turns back on all the relays it just powered down. Think of it as a high beam switch but using software.

I plan on mounting the LCD screen in a position on the center console that will be under where my hand naturally rests while my arm is on the arm rest. This should make hitting the top middle of the screen fairly natural and with a little bit of use muscle memory should kick in. I think I may also include a small bump or ridge right above the button location when I 3D print the bezel to make finding it without looking easier.

screen.gif


No more blinding poor Sasquatch.
 
So I just found this thread....

I'm still trying to understand this:

I trade vehicles a lot. It's a bit of an addiction. In most cases I've modified those vehicles, especially electrically (see an example here) and when the vehicle goes to it's new home hopefully the new owner makes use of those additions. It would probably be smarter of me to make a modular system that could integrate into any vehicle thus allowing me to move it as I trade. (As a side note @Scott B. I fully intend to keep the F250 for a while).

:eek:

On a more serious note, is this any easier than hard switches? Personally, I don't care for touchscreen devices on moving (vibrating) vehicles. I prefer a tactile feel / feedback when I touch a control. Also, to me, it is easier to find a switch by feel than to have to look at a spot on a screen.

But, I much prefer the old IBM style keyboards over these new membrane ones.
 
So I just found this thread....

I'm still trying to understand this:



:eek:

On a more serious note, is this any easier than hard switches? Personally, I don't care for touchscreen devices on moving (vibrating) vehicles. I prefer a tactile feel / feedback when I touch a control. Also, to me, it is easier to find a switch by feel than to have to look at a spot on a screen.

But, I much prefer the old IBM style keyboards over these new membrane ones.

I don't know that it's easier. What I've put together here is certainly more complicated than just tossing a switch in the dash and running it to a relay / device. I've got a weird thing for using OEM style switches in vehicles vs the Autozone Rocker Switches that folks cut in all over the place. The downside to using OEM switches is you're restricted to whatever blank spots are in the vehicle and to whatever layout those blanks are arranged in. The LCD gives me one central, clean location for all the "switches" and allows me to lay them out however I see fit. The obvious upside is being able to arrange things in a GUI that makes sense for me and can be updated as I find the need for tweaks. I think with the right design, placement and GUI layout the LCD setup could be as intuitive as physical switches...and maybe more so if we're comparing a single LCD to multiple switches scattered across the dash.

The other major advantage is being able to apply logic to the switch functions. Rather than a simple on/off switch there's obviously the ability to do things like the hot button I described above. I'm also planning on macro or shortcut buttons that enable/disable groups of switches or effects (think microcontroller run christmas light displays).

At the end of the day it also just gives me something new to tinker with and that keeps me from browsing vehicles online that are for sale... :D
 
First off, you failed to answer my original misuderstanding... :p

I like the idea of adding logic to switch functions - could be very useful.

I get what you mean about the cheapo rocker switches. I never cared for the hacked look. :eek:
I assume you know there are factory-looking replacement switches for the Tacoma dash. If you were not aware, you can also get them with a multitude of labels.
 
On to a new Arduino project. In 2015 a base model Tacoma DCSB 4x4 had an MSRP of right around $30,000. You know what that $30k didn't get you in 2015? A thermometer. That's right, the Tacoma left you with your arm out the window wondering what the temperature was. With a properly equipped stereo you'd get to see this:

1607052817456.png


Sure it has temperature on there, and heck, there's even a weather forecast. But it's all dependent on the radio having access to data that's imbedded in a HD radio signal. When your goal is to get away from people and out in the wilderness you're generally not going to go where there's a lot of HD radio signals. On top of that if you do get a signal you might get the weather for a town that's 20 or 30 miles away. We can do better...and I need a new project to tinker with.

Here's what I'm using this time around:

1. Arduino Nano
1607052977678.png


2. Waveshare 1.5 inch OLED
1607052852101.png


3. GY-21 High Precision Humidity / Temp Sensor
1607052954663.png


The OLED has 7 connections to make:

VCC -- Arduino 5v+
GND -- Arduino GND
DIN -- Arduino D12
CLK -- Arduino D13
CS -- Arduino D11
DC -- Arduino D7
RST -- Arduino D8

The GY-21 has 4 connections to make:

VIN -- Arduino A3
GND -- Arduino A2
SCL -- Arduino A5
SDA -- Arduino A4

For both of these components you can actually use other connections on an arduino and define them in the code, but this is what I went with.

After that it's a matter of using a couple of libraries for these devices:

SparkFun Si7021 Breakout Library for communicating with the GY-21
Adafruit GFX library and the Adafruit SSD1351 library for dealing with the OLED
and then some standard libraries for dealing with arduino related functions: Wire, SPI and EEPROM.

After that I used some sloppy code:

#include "SparkFun_Si7021_Breakout_Library.h"
#include <Wire.h>
#include <SPI.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1351.h>
#include <EEPROM.h>

//Variables and pin settings for temp sensor:
//Temperature
float humidity = 0;
float tempf = 0;
int power = A3;
int GND = A2;
float previousHigh = 0; //= EEPROM.read(0);
float previousLow = 0; //= EEPROM.read(9);
float a = 1;
int hourAgo = 0;
int twoAgo = 0;
int threeAgo = 0;
int fourAgo = 0;
int fiveAgo = 0;
int sixAgo = 0;
int sevenAgo = 0;
int eightAgo = 0;

//Create Instance of HTU21D or SI7021 temp and humidity sensor and MPL3115A2 barrometric sensor
Weather sensor;

//Setup OLED Screen
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 128 // OLED display height, in pixels

// You can use any (4 or) 5 pins
#define SCLK_PIN 13
#define MOSI_PIN 11
#define DC_PIN 7
#define CS_PIN 10
#define RST_PIN 8

// Color definitions
#define BLACK 0x0000
#define BLUE 0x001F
#define RED 0xF800
#define GREEN 0x07E0
#define CYAN 0x07FF
#define MAGENTA 0xF81F
#define YELLOW 0xFFE0
#define WHITE 0xFFFF

Adafruit_SSD1351 tft = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, CS_PIN, DC_PIN, MOSI_PIN, SCLK_PIN, RST_PIN);

void setup()
{
// open serial over USB at 9600 baud
Serial.begin(9600);

//Set temp pins as output and set one high, one low to create 3.3v and GND connection
pinMode(power, OUTPUT);
pinMode(GND, OUTPUT);
digitalWrite(power, HIGH);
digitalWrite(GND, LOW);

//Initialize the I2C sensors and ping them
sensor.begin();

//Initialize the OLED Screen
tft.begin();

//Clear the OLED Screen
tft.fillScreen(BLACK);

//Set the previous high and low to the current Temp
getWeather();
previousHigh=tempf;
previousLow=tempf;

}

void loop()
{
//Get readings from all sensors
getWeather();
compareWeather();
printInfo();
clockTimer();
}

void getWeather()
{
// Measure Relative Humidity from the HTU21D or Si7021
humidity = sensor.getRH();

// Measure Temperature from the HTU21D or Si7021
tempf = sensor.getTempF();
// Temperature is measured every time RH is requested.
// It is faster, therefore, to read it from previous RH
// measurement with getTemp() instead with readTemp()
}


void compareWeather()
{
if(tempf>previousHigh){
previousHigh=tempf;
}

if(tempf<previousLow){
previousLow=tempf;
}
}

void printInfo()
{
//This part of the function prints the weather data out to the default Serial Port


// Serial.print("Temp:");
// Serial.print(tempf);
// Serial.print("F, ");

// Serial.print("Humidity:");
// Serial.print(humidity);
// Serial.println("%");

// Serial.print("Previous High:");
// Serial.print(previousHigh);
// Serial.println("F");

// Serial.print("Previous Low:");
// Serial.print(previousLow);
// Serial.println("F");


//This part of the function sends info to the OLED screen
tft.setCursor(0, 0);

//If it's over 80 degrees the text color is red, under 50 it's blue, in between it's green.
if(tempf < 80){
tft.setTextColor(GREEN, BLACK);
} else {
tft.setTextColor(RED, BLACK);
}
if(tempf < 50){
tft.setTextColor(BLUE, BLACK);
}

//Blank Line
tft.setTextSize(1);
tft.println();

//Current Temp
tft.setTextSize(1);
tft.println("Current Temp: ");
tft.setTextSize(3);
tft.print(tempf);
tft.println("F");
}

void printPastTemp(){

tft.fillRect(0, 50, 128, 9, BLACK);
tft.fillRect(0, 50, hourAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 51);
tft.print(hourAgo);
tft.print("F");

tft.fillRect(0, 60, 128, 9, BLACK);
tft.fillRect(0, 60, twoAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 61);
tft.print(twoAgo);
tft.print("F");

tft.fillRect(0, 70, 128, 9, BLACK);
tft.fillRect(0, 70, threeAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 71);
tft.print(threeAgo);
tft.print("F");

tft.fillRect(0, 80, 128, 9, BLACK);
tft.fillRect(0, 80, fourAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 81);
tft.print(fourAgo);
tft.print("F");

tft.fillRect(0, 90, 128, 9, BLACK);
tft.fillRect(0, 90, fiveAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 91);
tft.print(fiveAgo);
tft.print("F");

tft.fillRect(0, 100, 128, 9, BLACK);
tft.fillRect(0, 100, sixAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 101);
tft.print(sixAgo);
tft.print("F");

tft.fillRect(0, 110, 128, 9, BLACK);
tft.fillRect(0, 110, sevenAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 110);
tft.print(sevenAgo);
tft.print("F");

tft.fillRect(0, 120, 128, 9, BLACK);
tft.fillRect(0, 120, eightAgo, 9, YELLOW);

tft.setTextSize(1);
tft.setTextColor(BLACK, YELLOW);
tft.setCursor(2, 121);
tft.print(eightAgo);
tft.print("F");


}

void clockTimer(){
//Add time to timer
a = a+1.19;
//a = a+1200;
//Every ~hour shift the values
if (a > 3600){
a=0;
eightAgo=sevenAgo;
sevenAgo=sixAgo;
sixAgo=fiveAgo;
fiveAgo=fourAgo;
fourAgo=threeAgo;
threeAgo=twoAgo;
twoAgo=hourAgo;
hourAgo=tempf;
printPastTemp();
}
}


to get a display that shows the current temperature and then graphs the temperature for each hour of the last 8 hours:

1607053678939.png


I left it in the truck overnight to get those results. It begins counting for an hour as soon as it's plugged in. Once that hour has elapsed it records the temperature and then starts counting for another hour. Rinse and repeat. If it hasn't been on for 8 hours yet you get a slow progression of bars:

1607053852024.png


1607053860281.png


The other thing it does at the moment is color the current temperature according to a range I've set in the coding. Over 80 and it's red, under 50 and it's blue, in between it's green. I'm still messing around with the visual layout and deciding if I want to add any input driven features, like a button to reset values or change between some predefined screens. Right now it's completely autonomous: give it power and it just works. I'm going to come up with an enclosure and stick it somewhere in the truck. I plan on routing the temperature sensor up inside the shark fin on the roof. Should provide an accurate enough temperature reading and keep it out of the elements. I would imagine the temperature readings will be thrown off a bit as the truck sits in the sun and the plastic of the shark fin heats up, but I really can't come up with anywhere to put it that there won't be some ambient heat off of something... Besides it's really there to answer that age old question that comes up at camp every morning. How cold do you think it got last night?

Is this a needed feature in the truck? Debatable. Is it a neat little project that gives me something to tinker with and prevent me from shopping for new vehicles? Absolutely. :D

Pros and Cons:

Pros:

1. It works, and does what I want it to.
2. Very small form factor, it's going to be easy to mount pretty much anywhere.
3. OLED is very easy to see from any angle and in any lighting.

Cons:
1. Right now I'm using the time it takes to run through the code once and adding a very unscientifically calculated amount of time to get each cycle to take approximately a second. This is what I'm using as a basis of measurement to determine when an hour has elapsed. It's not quite perfect as little things can throw off the timing a bit here and there an an "hour" can actually be anywhere from ~50 minutes to ~1 hour a 5 minutes. I have a fix for this as I could add a RTC module with a very accurate crystal to keep up with the true time. Not sure I want to though as this works well enough and adding another component means more complexity in the circuit and more messy code.

2. The refresh on the OLED is a little slow. Not a problem for text, but the library that updates the rectangles that make up the temperature graph causes a "flicker" when the bars update. Only happens once an "hour" though so it's really not a big deal. If I were constantly refreshing the screen it would drive me nuts. Only way to fix this is to move to a different model of Arduino with more memory that can do some frame buffering and update the entire screen at once instead of pixel by pixel.
 
Last edited:
If you have so much time on your hands, I have some dirt that needs to be moved.........

I've been volunteered to rebuild the in-laws deck. Once I get that knocked out I could help with dirt if it hasn't already moved itself.

Updated the software and came up with a cleaner layout for the information. 6 hours of past data now and indexed to indicate which graph line is 1 hour ago. 2 hours, etc.

Took everything I had hard coded and setup functions to roll through an array of data. Runs faster and updates faster.

20201206_190115.jpg
 
One step closer to being in the truck.

Printed a backing plate for the face of the Kenwood TM281.

1607728046264.png


It attaches to the radio faceplate using the 4 tabs the same way the radio body attaches to the faceplate. This backing plate is screwed to a part I designed to hold the two Nextion screens, the OLED and my CB radio:

1607728107645.png


Put together I've ended up with this:

1607728157109.png


1607728176449.png


The entire assembly is roughly the width of the center console that houses the shift. Should be able to create an enclosure that sits just over top of the center console that will put the radios and the touchscreen LCD's within easy reach with my arm on the arm rest. Hopefully....
 

Attachments

  • 1607728145707.png
    1607728145707.png
    121.4 KB · Views: 68
Back
Top Bottom