Engineers are, for the time being, only human. This applies even more so to executives, and all the other people that make up a modern organisation. Naturally, mistakes are made. Some are minor, while others are less so. It’s common knowledge that problems are best dealt with swift and early, and yet so often they are ignored in the hopes that they’ll go away.
You might have heard the name Takata in the news over the last few years. If that name doesn’t ring a bell you’ve likely heard that there was a major recall of airbag-equipped vehicles lately. The story behind it is one of a single decision leading to multiple deaths, scores of injuries, a $1 billion fine, and the collapse of a formerly massive automotive supplier.
For the average motorist, the speedometer and the fuel indicator are the primary gauges of interest. Owners of performance or modified cars tend to like having more information on the way the car is running. [JustinN1] is firmly in that camp, and built some WiFi-enabled gauges for his Subaru WRX STi.
The gauges run on the ESP32 platform, chosen for its WiFi hardware and its ease of use with the Arduino platform. This makes programming a snap, and interfacing to a smartphone easy. OLED displays were chosen for their good visibility in both day and night conditions, which is important for automotive applications.
[JustinN1] developed both a boost/vacuum gauge and an oil pressure gauge, both useful for keeping an eye on what the engine is doing. Measuring boost is as simple as using an off-the-shelf analog air pressure sensor. The oil pressure sensor is a resistive part, and must is hooked up through a resistor divider to create an analog voltage for the ESP32 to read.
While cars are slowing becoming completely computer-controlled, road vehicles have been relying on computers since the 1970’s. The first automotive use of computers was in engine control units (ECUs) which came along as fuel injection systems started to replace carburetors.
[P1kachu]’s 1997 Subaru Impreza STi, like most cars of this vintage, uses an ECU and provides a diagnostic connector for external communications. [P1kachu]’s Subaru hacking project includes building a diagnostic interface device, dumping the ECU’s firmware, and reverse engineering the binary to understand and disable the speed limiter. If this looks familiar, it’s because we just covered the infotainment hacks in this car on Saturday. But he added information about the communications protocols is definitely worth another look.
This era of Subaru uses a non-standard diagnostics protocol called SSM1, which is essentially a 5 volt TTL serial line running at 1953 bits per second. The custom interface consists of a Teensy and a 3.3V to 5V level shifter. Once connected, commands can be sent directly to the ECU. Fortunately, the protocol has been quite well documented in the past. By issuing the “Read data from ECU address” command repeatedly, the full firmware can be dumped.
[P1kachu] goes on to locate the various engine tuning maps and discover the inner workings of the speed limiter. With cars getting more computerized, it’s nice to see folks are still able to tune their rides, even if it means using Teensys instead of wrenches.
Automotive components that have a hidden secondary function are usually limited to cartoons and Michael Bay movies, but this project that [Jesus Echavarria] created for a client is a perhaps as close as we’re likely to get in the near future. The final product certainly looks like a standard automotive relay, but a peek inside the 3D printed case reveals a surprisingly complex little device. It’s still technically a relay, but it uses a PIC microcontroller to decide when it should activate.
[Jesus] was given the task of creating a device that would fit into the relay box of a vehicle, and serve as a battery monitor to fire off at different voltage set points. The client also wanted the ability to configure such things as how long the device would wait before enabling and disabling the alarms once the voltage threshold has been passed. After showing the client an oversize prototype using a PIC16F88 and switching regulator, he got the OK to move on to a smaller and more cost-effective version.
The final hardware makes use of a 78M05 500 mA linear regulator, a PIC16F1824 microcontroller, and a pair of AQY211EH solid state relays. The standard five pin layout used for automotive relays allows the monitor to get power from the vehicle’s battery while providing two output channels that can be switched on and off from the microcontroller. [Jesus] says an agreement with the client prevents him from sharing some elements of the project (like the firmware source code), but he gives enough information that it shouldn’t be too hard to spin up your own version.
I’ve got a friend who tells me at every opportunity that soy is the downfall of humanity. Whatever ails us as a society, it’s the soy beans that did it. They increase violent tendencies, they make us fat and lazy, they run farmers out of business, and so on. He laments at how hard it is to find food that doesn’t include soy in some capacity, and for a while was resigned to eating nothing but chicken hot dogs and bags of frozen peas; anything else had unacceptable levels of the “Devil’s Bean”. Overall he’s a really great guy, kind of person who could fix anything with a roll of duct tape and a trip to the scrap pile, but you might think twice if he invites you over for dinner.
So when he recently told me about all the trouble people are having with soy-based electrical wiring, I thought it was just the latest conspiracy theory to join his usual stories. I told him it didn’t make any sense, there’s no way somebody managed to develop a reliable soy-derived conductor. “No, no,” he says, “not the conductor. They are making the insulation out of soy, and animals are chewing through it.”
Now that’s a bit different. I was already well aware of the growing popularity of bioplastics: the PLA used in desktop 3D printers is one such example, generally derived from corn. It certainly wasn’t unreasonable to think somebody had tried to make “green” electrical wiring by using a bioplastic insulation. While I wasn’t about to sit down to a hot bag of peas for dinner, I had to admit that maybe in this case his claims deserved a look.
[Big Fish Motorsports] has a vehicle with an adjustable rear spoiler system that broke in the lead up to a big race. The original builder had since gone AWOL so the considerable talents of [Quinn Dunki] were brought to bear in getting it working again.
Cracking open the black control box of mystery revealed an Arduino, a ProtoShield and the first major road block: the Arduino remained stubbornly incommunicado despite several different methods of trying to read the source code. Turns out the Arduino’s ATMega324 was configured to be unreadable or simply fried, but an ATMega128 [Quinn] had proved to be a capable replacement. However, without knowing how the ten relays for this spoiler system were configured — and the race day deadline looming ever larger — [Quinn] opted to scrap the original and hack together something of her own design with what she had on hand.
As ever, I am fighting a marginally winning battle against my 1991 Mazda MX-5, and this is the story of how I came to install a wideband oxygen sensor in my Japanese thoroughbred. It came about as part of my ongoing project to build myself a viable racecar, and to figure out why my 1990s Japanese economy car engine runs more like a late 1970s Malaise-era boat anchor.
I’ve always considered myself unlucky. My taste for early 90s metal has meant I’ve never known the loving embrace of OBD-2 diagnostics, and I’ve had to make to do with whatever hokey system was implemented by manufacturers who were just starting to produce reliable fuel injection systems.
This generally involves putting in a wire jumper somewhere, attaching an LED, and watching it flash out the trouble codes. My Mazda was no exception, and after putting up with a car that was running rich enough to leave soot all over the rear bumper, I had to run the diagnostic.
It turned up three codes – one for the cam angle sensor, and two for the oxygen sensor. Now, a cam angle sensor (CAS) fault will normally prevent the car running at all, so it’s safe to assume that was an intermittent fault to keep an eye on.
The oxygen sensor, however, was clearly in need of attention. Its job is to allow the engine control unit (ECU) to monitor the fuel mixture in the exhaust, and make sure it’s not too rich or too lean. As my car was very obviously running too rich, and the diagnostic codes indicated an oxygen sensor failure, a repair was in order.
I priced up replacement sensors, and a new oxygen sensor could be had for under $100. However, it wasn’t exactly what I wanted, as not all oxygen sensors are created equal. Cars in the 80s and 90s typically shipped from the OEM fitted with what’s called a narrowband oxygen sensor. These almost always consist of a zirconia dioxide cell that outputs a voltage depending on the difference in oxygen concentration between the exhaust gas and the free air. These sensors generally sit at 0.45 V when the fuel mixture is stoichiometric, but rapidly change to 0.1 V in a lean condition and 0.9 V in a rich condition. The response is highly non-linear, and changes greatly with respect to temperature, and thus is only good for telling the ECU if it’s rich or lean, but not by how much. ECUs with narrowband sensors tend to hunt a lot when running in closed loop O2 control – you’ll see an engine at idle hunt either side of the magical 14.7 stoichiometric air fuel ratio, never able to quite dial in on the correct number.
As I intend to switch to an aftermarket ECU in the future, I’ll need to tune the car. This involves making sure the air/fuel ratios (AFRs) are correct, and for that I need to be able to properly measure them. Just knowing whether you’re rich or lean isn’t enough, as often it’s desirable to run the engine intentionally rich or lean at certain engine loads. To get a true AFR reading requires fitting a wideband oxygen sensor. These are a little more complicated.