Novak Conversions Jeep Wrangler TJ engine mounts

Custom microprocessor (Arduino, Pi, etc) Jeep project thread

From a different SPAL guide I have on hand:
View attachment 569281
...

Edit: Note that this is a SPAL aftermarket fan, and I believe the PWM % logic is inverted in the OEM fans. Might have to test to be sure.

I'm really glad you posted all of this, and THANK YOU. But the first line in this table is particularly interesting because it suggests the 122Hz I could get with the Arduino Uno R3 (or any ATmega328P board)....and possibly even the default 490Hz, would have been perfectly fine....at least for an aftermarket SPAL fans. And I don't have any good reason to think the OE fan wouldn't have the same tolerance.

I got a teeny little OLED display and I'm gonna put the main control variables and fan speed output on it, as well as OBD2 comm status. So if things go wrong I'll at least have a decent idea why without having to plug in a laptop. I've got my eye on a little enclosure with a clear cover so I can see the display inside.
 
Funny enough, I've been thinking about this exact sort of setup, except using one of the Silverado 15" PWM fans and a simple fan shroud with the Burndown bracket. Just being able to command the fan on at least a minimum speed any time the air conditioning is running would be worth it.
 
  • Like
Reactions: freedom_in_4low
just something I found - I was thinking about going ahead and using bluetooth for the ECT control and then falling back on LCT control (which only requires local sensors) if the comms failed. It would save me a bit of wiring and not have to get into the vehicle harness at all, but Bluetooth has turned out to not be an option because reasons:

1. The ELMduino library I'm using supports Bluetooth "Classic" but doesn't support BLE (Bluetooth Low Energy)
2. The Arduino Nano ESP32 has an ESP32-S3 chip, which only supports BLE and does not support Bluetooth Classic.

From what I've read the o.g. ESP32 supported both, which is what led me down a few hours of wasted research time full of example code where people clearly used the bluetooth classic library on an ESP32 chip. It was also confounded by the fact that someone contributed a bluetooth library named exactly the same as the official Arduino library, so I had installed and included that one and kept getting compile errors trying to use functions that didn't exist in that library.

I haven't completely abandoned the idea of a wireless method of interfacing with the ELM327/OBD2...if I got a Wifi OBD2 scanner I could wifi to it. I'm gonna do a little research and see if any of the wifi Elm327 modules will support multiple devices on them. That would make it so I could have a cooling fan AND run the Torque app at the same time.

I haven't heard anything from Sparkfun on the UART - OBD2 board. I ordered an OBD2 reader with an RS232 interface on a DB9 connector. I'm still going to try to intercept the UART pins directly but I'm not the most skilled solderer so if the traces are concealed or just too small for me to work with, I can get a TTL - RS232 converter board at $10 for a pack of 3.
 
Another possible option for interfacing with the PCI bus directly if going the ELM327 route proves too problematic: https://github.com/laszlodaniel/CCDPCIBusTransceiver?tab=readme-ov-file

i don't know why that didn't come up when I was searching before. The ELM327 only entered the chat because I couldn't find enough to go directly to the bus.

The solution you post will work for Uno (probably R3 and before) and Mega boards. Now that it seems I could use an Uno for this project (since the fan will take a wider range of PWM frequencies), my Uno R3 would work just fine.
 
I was highly overoptimistic about the idea of soldering into a commercially manufactured board.

Turns out the OBD2 to rs232 scanner I got uses the small version of the chip so the pins are on a 1.27mm pitch instead of the 2.54mm that hobby parts use. There's not a snowballs chance in hell I'll be able to put anything on those pins.

1000002482.jpg


If I want to use this I'm gonna have to use an adapter in between so I'll be going TTL to RS232 back to TTL. I don't know how to tell what scanners use the large format of the chip without buying them and taking them apart so I'm probably not gonna keep looking for one.

I ordered a Vgate icar pro wifi OBD2 scanner so I'm gonna try that next.
 
  • Wow
Reactions: Zorba
Spent this morning figuring out how to use this display (Values are just placeholders).

1000002498.jpg


Then spent way too much time this afternoon trying to figure out why the sketch that worked perfectly on the Uno R3 kept locking up the Nano ESP32 in a boot loop. At one point it got so bad even the bootloader wouldn't free it up and I had to use the firmware programmer to unbrick it.

I got it fixed though I'm not sure I found a smoking gun. What I *think* was happening was
1. On the Uno, my averaged temperature variables re-initialized to zero on every execution of the loop. On the ESP32, it seems to hold it's value from the last cycle so it grows every program cycle and I need to actually assign it to zero before adding all the samples together.
2. At some point it becomes something that mathematically doesn't work in my NTCsensor() function, likely the natural logarithm of a negative when it overflows and wraps around.

Would have been quick to figure out with a line by line debug like I'm used to but if Arduino supports that I haven't figured out how to to do it yet.

Hope to have some time to get it connected to the Wi-Fi OBD2 scanner tomorrow.
 
  • Like
  • Love
Reactions: hear and Rickyd
It's connecting, and it pulls data, but only for a few seconds and then the ELM stops responding and it doesn't update again.

1000002504.jpg


1000002505.jpg


I don't plan on using TPS but it makes for easy troubleshooting because I can change the value sitting in the garage without driving or even starting the engine. If I can get it to actually update continuously then I'll start working on the values I actually care about.
 
Last edited:
  • Like
Reactions: Rickyd
Frustrating day. Not much actual progress other than just eliminating reasons why I'm not getting a continuous data stream from the PCM.

I get responses to the first 9 polls I make (after the initialization commands and the automatic first poll of PID 00 which returns the first group of supported PIDs, bitwise encoded. Doesn't matter if it's one PID or multiple, doesn't matter if I wait a second between getting a response and the next poll or just going rapid fire as soon as the response comes in, so it's not a time thing. I tried that thinking maybe the constant polling was overwhelming any of the components.

I get the same behavior when I plug the elm327 into my truck, so it's not just the jeep. My torque app works just fine with the elm327, indefinitely, so it's not the scanner.

Working theory at the moment is that there is a read buffer that isn't being cleared and it just happens to take 9 polls to fill it up. I know it clears the serial input buffer on every poll but I need to dig in to both the WiFi and the ELMduino libraries to see if it's a different buffer to clear. There is a code example for using Wi-Fi but it's clear the focus was TTL and Bluetooth so I can't assume anything about how well it's been proven out using Wi-Fi.

I also need to look into the WiFi library to see how to check the connection status after it's been established, to see if what's actually happening is losing the WiFi.
 
I hate days like that, where you're 98% done with a project, and you run into a brick wall and spend hours, days, weeks trying to figure out one dumb little thing. I'm in the same boat on one of my hardware/software projects, temporarily (I hope) on hold for a few months.

Hang in there, and thanks for keeping us up to date.
 
I hate days like that, where you're 98% done with a project, and you run into a brick wall and spend hours, days, weeks trying to figure out one dumb little thing. I'm in the same boat on one of my hardware/software projects, temporarily (I hope) on hold for a few months.

Hang in there, and thanks for keeping us up to date.

I spent WAY too long debugging some silly python today, all because I was checking for `if __name__ == '__main_': (note the missing dunder after main). That took forever to uncover. I couldn't figure out why it wasn't even logging. Turns out it wasn't ever even running.
 
I spent WAY too long debugging some silly python today, all because I was checking for `if __name__ == '__main_': (note the missing dunder after main). That took forever to uncover. I couldn't figure out why it wasn't even logging. Turns out it wasn't ever even running.

That kind of thing *is* the trouble with ALGOL descendant languages - which are most of them these days.
 
Good news and bad news.

Bad news first - I think the wifi thing is a dead end. After digging into the Issues section on the GitHub for the ELM327 library I'm using, there are a number of reports of issues with using Wi-Fi adapters. I didn't see them previously because the developer closed them with the comment that he has no plans to do anything about it, and I was looking at only the open issues before today. Wish he'd have taken down the WiFi example code since he knows it doesn't work, because it's mere presence is what led me to believe it would work. Inadequate research on my part, I guess.

Good news is I got charged for the uart to OBD2 card and got a shipping notification, so I can go back to the hardwired plan A.
 
Good news and bad news.

Bad news first - I think the wifi thing is a dead end. After digging into the Issues section on the GitHub for the ELM327 library I'm using, there are a number of reports of issues with using Wi-Fi adapters. I didn't see them previously because the developer closed them with the comment that he has no plans to do anything about it, and I was looking at only the open issues before today. Wish he'd have taken down the WiFi example code since he knows it doesn't work, because it's mere presence is what led me to believe it would work. Inadequate research on my part, I guess.

Good news is I got charged for the uart to OBD2 card and got a shipping notification, so I can go back to the hardwired plan A.

Be the change you want to see. Fix the docs yourself and submit a pull request.
 
Had a different idea for a means to control a fan recently: Klipper.

Klipper is an open-source 3D printer software much like Marlin, except that it runs on a Raspberry Pi and interfaces with a control board (instead of just running on the control board itself) and also optionally networks directly to a PC via WiFi or Ethernet for user input/control/monitoring (through Moonraker). It is designed to be adaptable to just about any 3D printer, from the basic bedslinger to the oddball "winch cable" printer.

Klipper also has a "none kinematics" option that allows for the software to control things that aren't 3D printers. It has built-in support for a number of different heater, heater fan, cooling fan, thermistor/thermocouple, etc. read and control schemes, some of which would perfectly apply in our scenario.

You would need a control board (like a BTT Octopus Max EZ), a Raspberry Pi 4B (1 Gb min, more if you want a screen/camera), and the associated fan/coolant sensor hardware. When setting up Klipper, you would simply define the printer type (aka the jeep) as "none kinematics" to tell it it isn't running a printer, define a thermistor (the coolant temperature sensor, may need to change type or otherwise convert the resistance scale to a supported thermistor), define a cooling fan (perhaps as temperature_fan), wire the PWM signal to a fan port (need to confirm that the Octopus switches low, not high), and then fill out the control scheme. Most Klipper temperature control schemes are PID, and these are tunable at the click of a button, meaning you wouldn't need to estimate the ki, kp, and kd; you could just simply let the controller decide for itself what the best parameters are by letting it test itself.

The RPi and controller could then be used to run dozens of other functions at the same time if you wanted to add them in the future. For example, you could eliminate the thermostat and replace it with a servo or stepper-driven flow control valve so you can precisely control the coolant temperature via Klipper. Or you could add a thermistor in the cabin and then allow PID control of the cabin heater and air conditioner so you could set a cabin temperature rather than just a blend door position just like in a modern high-end car. Or even control an EHPS pump. And you could add a screen so you can monitor and control without connecting to a PC.

https://www.klipper3d.org/Config_Reference.html
RatOS is probably the easiest way to get a Klipper config started, but it can be done manually as well.
https://os.ratrig.com/docs/introduction/
 
Novak Conversions Jeep Wrangler TJ engine mounts