The modern internal combustion engine is an engineering marvel. We’re light-years ahead of simple big blocks and carburetors, and now there are very fast, very capable computers sensing adjusting the spark timing, monitoring the throttle position, and providing a specific amount of power to the wheels at any one time. For the last few years [Josh] has been building a fully-featured engine management system, and now he’s entered it in the Hackaday Prize.
The Speeduino project is, as the name would suggest, built around the Arduino platform. In this case, an Arduino Mega. The number of pins and PWMs is important — the Speeduino is capable of running the fuel and ignition for eight cylinder engines.
The Speeduino is designed to do everything an engine control unit can do, including rev limiting (although if you’re building your own ECU, why?), and reading ethanol sensors. Right now [Josh] is working on a beta run of the Speeduino designed for the 1.6L Miata. That’s an excellent platform for firmware performance tuning, and there’s still a lot of work to be done on the firmware side of things before everything’s all set to go. Still, this is a great project and sure to impress the bros at track day, bro.
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.
If you are working with OBD2 hardware or software, it’s easy enough to access test data, simply plug into a motor vehicle with an OBD2 socket. If, however, you wish to test OBD2 software under all possible fault conditions likely to be experienced by an engine, you are faced with a problem in that it becomes difficult to simulate all faults on a running engine without breaking it. This led [Fixkick] to create an OBD2 simulator using a secondhand Ford ECU supplied with fake sensor data from an Arduino to persuade it that a real engine was connected.
The write-up is quite a dense block of text to wade through, but if you are new to the world of ECU hacking it offers up some interesting nuggets of information. In it there is described how the crankshaft and camshaft sensors were simulated, as well as the mass airflow sensor, throttle position, and speedometer sensors. Some ECU inputs require a zero-crossing signal, something achieved with the use of small isolating transformers. The result is a boxed up unit containing ECU and Arduino, with potentiometers on its front panel to vary the respective sensor inputs.
[Charlie Miller] and [Chris Valasek] Have just released all their research including (but not limited to) how they hacked a Jeep Cherokee after the newest firmware updates which were rolled out in response to their Hacking of a Cherokee in 2015.
FCA, the Corp that owns Jeep had to recall 1.5 million Cherokee’s to deal with the 2015 hack, issuing them all a patch. However the patch wasn’t all that great it actually gave [Charlie] and [Chris] even more control of the car than they had in the first place once exploited. The papers they have released are a goldmine for anyone interesting in hacking or even just messing around with cars via the CAN bus. It goes on to chronicle multiple hacks, from changing the speedometer to remotely controlling a car through CAN message injection. And this release isn’t limited to Jeep. The research covers a massive amount of topics on a number of different cars and models so if you want to do play around with your car this is the car hacking bible you have been waiting for.
Jeep are not too happy about the whole situation. The dump includes a lot of background for vehicles by multiple manufactureres. But the 2015 hack was prominent and has step by step instructions. Their statement on the matter is below.
Under no circumstances does FCA condone or believe it’s appropriate to disclose ‘how-to information’ that would potentially encourage, or help enable hackers to gain unauthorized and unlawful access to vehicle systems.
Back in the mid 1980’s I worked at a company called Commodore Business Machines, a company that made home computers where our annual Superbowl was the Consumer Electronics Show in Las Vegas the first week in January.
Some time in November a Datsun Z would get parked in the front lot and then not move until whatever snow mounds that got plowed over it melted sometime in early spring. Ultimately I would have it towed leaving behind a sad little pile of rust and nuts and bolts. With a bonus check in hand for finishing the newest computer on time I would go buy another used Z and repeat the cycle.
Climate Change and Rust
These days the old Datsun Z’s; 240Z, 260Z, 280Z, 280ZX, are somewhat rare, probably because they were real rust buckets even when new. After having sacrificed a few myself in search of the next home computer I set out to rescue one for old times’ sake. I really did love the car so I made it my project to restore one. Now I have a total of three Z carcasses, an engine, and a transmission all sitting out back and an almost finished Z in the garage.
Since I had torn the engine down to its bare components I took the opportunity to make some changes: increased the size of the turbocharger, increased bore and stroke of the cylinder/piston, improved the fuel distribution, and improved the flow of air with things like porting the heads and an inter-cooler.
[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.
[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.
As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.
[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)
The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.
Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.
A car from 1940 would have been an almost completely mechanical device. These days though, a car without electricity wouldn’t run. It’s not the engine – it’s the computers; the design details of which automotive manufacturers would love to keep out of the hands of hardware hackers like us. [Mastro Gippo] wanted to build a small and powerful CAN bus reverse engineering tool, and the Crunchtrack hits it out of the park. It’s a CAN bus transceiver, GPS receiver, and GSM modem all wrapped up into a single tiny device that fits under your dash.
[Mastro] has a slight fetish for efficiency and tiny, tiny devices, so he’s packaging everything inside the shell of a standard ELM327 Bluetooth adapter. This is a device that can fit in the palm of your hand, but still taps a CAN bus (with the help of a computer), receives GPS, and sends that data out over cell phone towers.
The device is based on the STM32 F3 ARM microcontroller (with mbed support), a ublox 7 GPS module, and an SIM800 GSM module, but the story doesn’t stop with hardware. [Mastro] is also working on a website where reverse engineering data can be shared between car hackers. That makes this an excellent Hackaday Prize entry, and we can’t wait to see where it goes from here.