Project Logs

Collapse

• even more TPMS

  PyDrew • 05/05/2021 at 10:47 • 0 comments

  A challenge that (most?) TPMS systems avoid is figuring out which wheel has low tire pressure. Keeping track of the pairing of a tire's sensor device id and its installation on the car would go out the window the first time the tires are rotated. Typically, the sensor has a single axis accelerometer to determine if the tire is rotating. One piece of information I came across mentions that if a sensor contained a two-axis accelerometer and was added to the data packet, a TPMS system could determine left from right. And by monitoring the signal strength, determine which sensors were farther away (rear) and which were closer (front). I did come across at least one company who is offering this capability but I haven't been able to determine if that chip ever made it into a TPMS sensor. The manufacturer, NXP, also has a great article on the science & math behind determining roll, pitch and yaw from an accelerometer.

  A low-power device that spends most of its time sleeping is optimized for sending data creates a challenge in receiving information. And the only situation where the sensor is available for either testing or reprogramming is when it's moving in a difficult to reach, enclosed space. Instead, these devices take a page from the RF ID playbook and can be activated from an external power source: the signal itself being sent to its low-frequency receiver. There is little mention of how this is accomplished other than it operates at a 125kHz. Since the TPMS sensors also send information with changes in pressure, many hackers test by dropping the TPMS sensor into a garden pressure sprayer. With only a few pumps, these can reach a psi of 40 or more.

  In my application, I would happily trade sensor life for a more frequent and consistent rate of pressure readings. Dropping the frequency from every 90 seconds to every 30 might cut the lifespan of a TPMS sensor to 3 or 4 years. But I haven't found a publicly available datasheet which provides enough information on how to build a low-frequency transmitter that could be installed in close proximity to the tire on the vehicle to accomplish this. Yet.

• TPMS

  PyDrew • 05/04/2021 at 18:46 • 0 comments

  With a RaspberryPi installed in my Jeep, expanding the project's capabilities was quite tempting. What other data could I capture? Fuel level? Speed or wheel spin? Tire pressure?

  Tire Pressure.

  As mentioned previously, tire pressure is definitely an important aspect of off-roading. And while mandated on all vehicles in the US since 2008, it was definitely not an option when my MJ was manufactured in 1988.

  When power is discussed relating to wheels, the focus is on the engine and drive line. So I long wondered how TPMS sensors got their electrical power.  I had guessed a self-winding watch mechanism using the tire's rotational energy but, as it turns out,  the sensors simply run on a self-contained battery.

  But this is still a pretty amazing engineering challenge. A sensor has to have wireless communication capabilities (something that is notorious for its power consumption). And be durable as it is subject to rotation and vibration. And light-weight enough not to significantly change a tire's balance when rotating. And be able to operate without requiring replacement as inside a tire isn't the easiest place to service on a regular basis.

  By reducing the frequency of sending data, the solution is a compact device that runs for 10+ years. Data is only transmitted when the tire is rotating and, even then, on an infrequent basis of about every ~90 seconds. In addition, the data packet is very minimal -- only 22 bytes -- which also reduces the time needed for each transmission. Most have just a 4-bit microcontroller.

  One can certainly buy an aftermarket TPMS system. And  some that replace the valve stem cap instead of a sensor inside the tire (although those are just waiting to be lost in the mud some where).

  But where's the fun in that?

  TPMS sensors operate on 433MHz which is a frequency band specifically allocated for low-power devices. And with the advent of software defined radios, receivers for this frequency range are readily available (and cheap); the RTL SDR seems to be the go-to for hackers but others with the same RTL2832U chipset work too. But with no published standard for low-power devices, decoding is a bit of a forensic exercise. Luckily, the open-source project rtl_433 has a community which has worked on collecting a database of devices over the past 6+ years. Including many TPMS sensors.

  These sensors are readily available and range in price. But in light of no standard, there is a proliferation of devices which are not interchangeable between systems. Combining device manufactures, car manufactures and model years creates almost endless variations so picking one that works with rtl_433 is a bit of a challenge. After trying (and returning) several sensors, I decided to splurge on MaxSensors which can be programmed to mimic an impressive list of cars - from a Ford Escort to a Ferrari. It does require a special programming device, but seems that are always 1 or 2 listings for used ones on ebay or mercari at any one time.  And the Gen2 version claims signal strength sufficient for use in 12-ply, 40" tires.

• a digression into tires

  PyDrew • 05/04/2021 at 04:18 • 0 comments

  For those who have been off-roading, the following is probably TLDR; feel free to skip to the next post about TPMS systems.

  Maximizing traction when off-roading is the name of the game. And lowering tire pressure is the easiest of things to improve traction. Dropping the tire pressure allows the tire to "flatten" out, opening the tread pattern (better for dirt and mud) as well as increasing the cross-section contact patch.

  While going from 30 psi to 20 psi doesn't look like much tire deformation, it can nearly double a tire's traction.

  Too low of a tire pressure, however, runs the risk of unseating the tire's bead, the metal wire built into the tire that creates an air-tight seal against the rim ). If this happens, it isn't the end of the world as it's an easy fix even on the trail; jack up the tire, use a ratchet strap to push the bead against the rim and use an air tank or onboard compressor to fill the tire. But it's a pain and definitely brings the entire off-roading convoy to a halt for a good half-hour. On stock rims, I tend to "air down" to 15 psi without much risk of this hassle.

  After-market "bead lock" wheels allow the tire pressure to go even lower by providing an inner seat in addition to the outer one; effectively clamping the outer bead between the rim  (green) and another plate (red) bolted together (yellow). This is a single beadlock configuration as the inner bead does not have a similar attachment; tire pressures can be lowered to 10 psi or lower

  Little Bo is soon getting Hutchinson Rock Monsters with Toyo Open Country Mud Terrain 33s. That is to say double beadlock rims, whereby the beads are held in place against the rim using a hefty 3/4" piece of rubber sandwiched in between two piece rims. (pictures to follow)

• Powering the Pi

  PyDrew • 04/14/2021 at 12:12 • 0 comments

  Tying in a 3A dc-to-dc convertor to the ignition switched power is simple and works great. A manual transmission (especially when crawling over rocks) increases the risk of rebooting unexpectedly when the engine stalls and needs restarting. And while there are reports of corrupted SD cards due to reboots, mine seems to not care that it gets shut off and on and off and on.

  I've explored a few different other options and here are my thoughts...

  • Tapping into power not switched by the ignition and adding a power switch just for the PI is straightforward.  Even if accidentally left on for a day or two, the RaspberryPi isn't likely to drain the battery completely. The battery, when it was installed, is rated at 40Ah; at 12 volts, that's 480 W. At maximum, the Pi consumes 2.5W (500mA @ 5V). Factoring a 50% margin as the battery ages, that's 4 days.
  • Battery-based uninterruptible power supplies (UPS) like PiJuice seem to be cost effective solution for an in-car application. As are super capacitors (low leakage, high capacity) -- such as the Juice4Halt hat -- that allow the Pi to keep running for the few seconds needed between stall and restart or for a graceful shutdown. Either of these off-the-shelf versions seem reasonably priced enough to dissuade me from trying a roll your own solution. 

  • Similar to the above hats which run a microcontroller in low power mode to monitor the situation and decide whether to use battery backup or shutdown the Pi, there are some pretty easy software and/or hardware changes to use a standard arduino in this manner. Teensyduino are my favorite which has its own low power library but an off-the-shelf arduino uno/mega has a similar library. Add in some hardware modifications of disabling the power LED and replacing the onboard regulator with a low drop out (LDO) version can drop the power consumption even further. Tutorials can be found here or here. But, as above, there are some pre-built solutions that are hard to pass up since they are also reasonably priced and the hardware lifting has already been done; SleepyPi2 seems to be the best of this breed as it includes all the software utilities and solid documentation.

  While it hasn't arrived yet, I went with the SleepyPi and will share my hands-on thoughts when it does.

• Form factor

  PyDrew • 04/14/2021 at 03:44 • 0 comments

  While my MJ has many upgrades, I do still like the retro aesthetic so it's important to find a place for the RenixPi without it looking totally out of place. The interior of an MJ is minimalistic by today's standards: just a couple of levers for heating/cooling plus a 1-din sized radio. But, even so, the dashboard is bulky and doesn't leave much room for a display where it is easily visible. The space between the gauges and the radio/heater is curiously blank. The panel is styled as if it was intended to display something, although beyond an upshift indicator light (on the mirror panel to the left of the steering wheel) and a small digital clock, it is empty. 

  While the raspberry pi could be tucked behind the dash, it turns out that the behind the panel is mostly empty space and just large enough for a raspberry pi. While I was able to find a used panel on ebay, a 3D printed version gives more flexibility in the placement and mounting of an lcd screen and the Pi.

  Software updates would be easy by configuring the Pi as an adhoc or access point wireless network, but just in case, I routed usb and micro SD card extensions down so that they're easily reachable underneath the dash.

  The fuse panel is just to the left of the clutch pedal but there is easier access to both switched power via the clock's connections or unswitched by tapping into the cigarette lighter (which I had already replaced with usb charging ports).

• ECU, M/T vs A/T and ABS

  PyDrew • 03/29/2021 at 03:46 • 0 comments

  With all the different variations of the Cherokee, Wagoneer and Comanche, it's no wonder that AMC struggled through the 1980s. The Comanche alone had 9 different trim lines, two different bed lengths (a short at 5' and a long at 8') , two different engine sizes and either a manual or automatic transmission. Add in all the different combinations of the Cherokees and Wagoneers options available, it doesn't seem that AMC believed in economies of scale.

  Renix created electronics that supported both the 2.5 and 4L engines as well as for the automatic transmissions and anti-lock braking systems of that era. Currently, the RenixPi project supports the 4L engine decoding only as the MJs were never offered with ABS and my MJ has a manual transmission.

  If anyone is interested in support for A/T or ABS, please leave a comment. Happy to implement if it's of value to others; otherwise, I'll be focusing on Little Bo' : )

• Reference implementation

  PyDrew • 03/28/2021 at 15:49 • 1 comment

  Unfortunately, my Jeep isn't parked near my workbench so using it to test my decode logic (and eventual display) wasn't going to be feasible. And sitting in the driver's seat isn't the most comfortable of development environments.

  Instead, I opted for using a PyCom ESP32 running micropython to create an ECU simulator. And used NickInTimeDesign's Renix Engine Monitor II+ as the reference implementation to verify the accuracy of the simulator.

  And, to simplify development even further, I was able to use the same Python ECU simulator on my Mac to send a byte-stream to a socat created virtual serial port so that it could be used to develop and test the RenixMonitor decoder application without even having to keep a breadboard with jumper wires nearby.

• Connecting to the Renix ECU

  PyDrew • 03/28/2021 at 14:18 • 0 comments

  The physical connector is a standard molex connector with their 0.093" pin configuration. ebay has a pair of plug and receptacle with pins for $10; if you're already placing an order to digikey where you're already paying for shipping, the plug portion is just $2 and pins are 10 cents each. If you prefer, you can print your own with the STLs include in RenixPi on GitHub. 

  The electrical specification for the Renix ECU is a very common output  of many ICs: open collector to ground (eg I2C). 

  With a pull-up resistor, the (inverted) UART signal can be seen. And along with a transistor and another pull-up resistor, it can be decoded.

• Renix ECU Serial Data Stream

  PyDrew • 03/28/2021 at 10:59 • 0 comments

  The serial data stream that the Renix ECU produces is a 30-byte long frame of data and can be read by any UART interface (arduino, pycom, raspberrypi, etc). To identify the starting sequence, there is a 0xFF marker immediately followed by a 0x00 start.

  Simple enough, except when a measurement is 0x00 or 0xFF. In the former case, a value of zero is only valid if not preceded by a 0xFF marker. And in the latter case, if the measurement value is the maximum value of a byte (ie 0xFF), it must be sent twice.

• Diagnostic Protocols and a Thank You

  PyDrew • 03/25/2021 at 17:54 • 0 comments

  While the On Board Diagnostic (OBD) protocol was established by SAE in 1979, it wasn't until 1994, when California emissions regulations mandated it be included on all vehicles, that it became the industry standard now known as OBD-II.

  Between 1979 and 1994, most companies used some portion of the OBD standard. Renix did not, charting their own path with a proprietary format.

  While some commercially available diagnostic tools were made for mechanics, the protocol was never published. In 2012, a video by Phil Andrews of the RenixPower forum demonstrated his hard work in decoding the protocol.

  Following that, Nick Grisley of NickInTimeDesign started developing the Renix Engine Monitor in 2016 and has been generous to share the source code as an open source project. There are several videos on his website that show the extensive sleuthing that was needed to arrive in his latest iteration. I've purchased one and I've been very impressed, it works great!
  

  This project is an extension of both Phil and Nick's tremendous efforts and would not have been possible without them.

View all 12 project logs