Saturday, December 15, 2012

Infrared "Sonic Screwdriver"

This is my first project using a PIC microcontroller and programmer. IMO it's not dramatically different than Atmel/AVR, but I did find it easier to use. MPLabX is pretty cool and I found switching between programming and debugging to be much faster and more reliable.

I did some research on infrared signals (heaps of googling) + played around with the remotes I have at home and found that for most consumer electronics most brands follow just a few common signal protocols. Even different protocols have similarities. The most important characteristics I found are that
  • Most signals are modulated at 38KHz with about a 33% duty cycle.
  • The 1's and 0's are represented by 2 different pulse lengths.
  • There can be a 3rd or 4th pulse length that are special bits used for signaling the beginning of data.
  • Some fluorescent lights give off a modulated infrared light that screws up everything!
Signal Data
I decided that trying to interpret each pulse length and then writing the appropriate bit into memory would be too tricky and not very "universal". Is the "1" pulse on my TV remote the same as the "1" pulse on my AC remote? Instead the microcontroller is running a 16bit timer and measuring the time passed before each bit flip. To transmit the signal it just has to flip between 1 and 0 when the timer value matches what was recorded earlier. The only downside is that this method needs more memory.

To actually read the signal I got a IR receiver. It's pretty cool. Just needs power, ground and a pull up on the signal out pin. It is pretty sensitive and doesn't seem to care what frequency the IR signal is modulated at. The signal output looks like this.
Power button on TV remote gives this signal.

The main differences between using an Infrared LED and a regular red LED are that firstly they require much more current and secondly you might not be using a current limiting series resistor! I tried it and it quickly became pretty dim (you can test it by looking through a camera since most will see IR light as blueish-white). Also the remote controls I opened up didn't have a series resistor.

I found the 2nd point pretty surprising, but it sort of makes sense because when the LED is "on" it's actually on just 33% of the time or whatever the PWM duty cycle is. Basically 33% duty cycle is 33% of the current it would normally draw. It's still much more current than usual, so i'm using an NPN transistor instead of connecting it directly to the microcontroller output pin. The output pin will switch on/off at the rate originally recorded from the remote. The last step is to modulate the signal at 38KHz. To do that the microcontroller is running a separate timer to generate a PWM signal at 38KHz with 67% duty cycle. I'm connecting it to the negative side of the LED (directly! which is probably not good!). The end result is the IR signal has a 33% modulation because when the PWM signal is low (33% of the time) the IR LED is on and when the signal is high (67% of the time) the IR LED is off.

What's left
To finish this I need to
  • Switch to a smaller microcontroller that fits inside body of the sonic screwdriver.
  • Have the uC write the signal data to flash memory instead of RAM.


Monday, December 3, 2012

Every hard drive is dead!

I have a nearly working version that will be in my next post. Nooooope. My next post will be about another failing hard drive.

In a separate computer, so that rules out power supply or SATA controller problems.

If you ever see me madly making backups to every device I can get my hands on, then you'll know it's because every hard drive within 1km of me is dying. Maybe I'm highly magnetized :(..... doesn't explain the corrupted data on the SSD.

Sonic Screwdriver

I'm overdue for an update! Around Septemberish I made my furthest progress. It goes something like this: Attach drill to distributor, run drill, distributor signal read by microcontroller. Then, the microntroller will 1. Spark Coil at when the distributor is at TDC and 2. Send timing data over USART. Using a MAX232 chip and serial>USB converter I can read that USART data with a C# program and display the rpm!

It worked fairly well except for each spark semi-regularly resetting the mc! I think that's just a matter of high voltage messing up what would be a clean power supply.

Delays, Distractions and the evil Computer Demon
I haven't been able to work on it since. Uni work has been time consuming and finding a big free block of time has been difficult. As awesome as this stuff is, there's usually something more important or better to do! In addition I killed my dragon programmer, my laptop has been sent for repair twice (still waiting for it) AND 3 hard drives died on my file server in different ways (WTF??!!). I <3 backups="" br="">
The Plan
I think I've gotten as far as I can without a running engine to play with, so starting early next year I will be directly driving the coils and injectors on my car. It means the car will be off the road while I figure all this out, but it should work out well with the engine swap and new clutch to be fitted at the same time.

Sonic Screwdriver
In the meantime I'm working on another project. You know those cool toy sonic screwdrivers that light up and make sound effects?
Wouldn't it be cool if you could use it to control any device with an infrared sensor? A TV or airconditioner or pretty much anything with a remote control. My plan is to replace the innards with electronics that can record and playback an infrared signal. Yes, you can buy something like this already from thinkgeek but holy crap it's expensive and it's way more fun to build it yourself! I have a nearly working version that will be in my next post.

Sunday, July 29, 2012

50Hz everywhere!

I'm back! Wow it's been a while since i posted anything here. Mostly from being busy, then waiting for parts, then just plain forgetting to update this blog :S

Keeping the news short:
  • I've been able to set up a bigger workspace in the garage.
  • I applied for a mechatronics course and got into uni!!
  • I now own one shiny Mazda MX5! (too dark for pictures right now)

I tested a few different circuits to drive the fuel injectors and ignition coils. Back EMF turned out to be a major problem. I couldn't come up with a way to snub that voltage spike with what i had on hand, so i ended up with a bunch of dead power transistors. Below you can see what happens when i apply and remove power to the ignition coil. It's not a clean on/off because i was just touching the ends of wires together, so you get a switch bounce effect.
I've gotten my hands on some IGBT transistors that are specifically designed for this kind of application, but haven't had tried them out just yet.

Lastly, i've started moving everything onto a protoboard. I've had too many breadboard related problems. It's a real pain when i accidently tear out a bunch of connections while moving the board around. The worst problem is that it seems to act as an antenna for the 50Hz main supply. Even while on batteries it will pick up the signal if anywhere near a power point. 
So far the protoboard seems like a much better option. Also got rid of the intermittent connection issues with the dragon programmer i'm using.

Monday, April 23, 2012

Reading the Cam Angle - Part 1 (Signal Conversion)

If you understand the basics of a 4 stroke engine you'll know that there are 4 states that a cylinder can be in: intake, compression, power, exhaust. Of course there's always the informal: suck, squish, bang, blow if you prefer. If we read the sensors attached to the cam, then we can know when each event happens since the cam position is what determines the state of each cylinder.

On my car the cam sensors are built into the distributor. The first thing I needed was a way to easily intercept the signals and determine their type. I chose to replace part of the wiring with DB9 connectors. This allowed me to easily connect the distributor as standard into the car electrical system or break the connection and attach each DB9 plug to my own circuitry and intercept the signals.

There are two signals which I'll refer to as "inner loop" and "outer loop". The outer loop will pulse once per cam revolution. The inner loop will pulse 4 times per cam revolution. When the inner and outer loop signal offset(phase) is changed, the result is a change in the spark timing. So, when the inner loop pulses occur later in time compared to the outer loop pulses, the spark timing will occur at a later point in each engine revolution.

The Outer Loop
From what I can figure out, it looks like the outer loop signal is generated from a hall effect sensor. The sensor is switched on/off by a small magnet that moves past it on each rotation.

The result is a 0-12v square wave signal that looks like this. The signal is a bit noisy, but I'm not too fussed at the moment.

The microcontroller works with TTL logic levels (0v-0.8v for low/0 and 2.6v-5v for high/1). At first it looks like a simple voltage divider will do what I need. The only problem with that is the assumption that you're always working with 12v, but the voltage output could change anywhere between 8v and 14v mostly depending on how much power the battery and alternator can provide vs demand on the car's electrical system (fans, wipers, radio). The solution is to make your voltage divider out of a diode and resistor. I chose a 4.7v zenner diode because that voltage is within the TTL spec.. I've included a circuit diagram here. I've never used circuit design software before, so it's a bit crap. I didn't get exactly what I wanted in 15 minutes of playing around, but for now it should provide you with an understanding of what I'm doing.
Conversion to TTL voltages
VS1 represents the original signal, and TPdv1 is the TTL output. The end result is a 0v-5v square wave that can switch a microcontroller input pin!

The inner loop
This is generated from a reluctor sensor.

Reading the inner loop signal is a bit more involved. It's an AC signal ranging from +11v to -7v P-P. The wave form isn't a nice sine wave, but that shouldn't cause us any problems. Each wave pulse is generated every quarter turn. Obviously the faster it turns, the higher the signal frequency. The only difference is the signal amplitude will also change with engine speed. The +11v to -7v was recorded while the engine was at it's max RPM. At lower engine speeds the signal could range just -2v to 3.5v.

I started out with the same circuit that I used for the outer loop. When the current is flowing forwards (during the first half of the signal), the peak voltage across the zenner diode can't be any more than 4.7v. When current is flowing in reverse (second half) the voltage across the diode will peak at -0.5v. Ideally it should be 0v, but the diode must have a breakdown voltage of just 0.5v. Below you can see the original signal in red, and the converted signal in blue.
Red: Original, Blue: Zenner

The inner loop - digital
While this new signal is now within TTL voltage ranges it will cross into undefined voltages that are neither recognised as 0 or 1. This can cause really weird problems, so the final step should change this into a square wave. I didn't include a circuit diagram here because it would take me far too long to do. I haven't had the time to learn how to properly use 5Spice yet!

The first thing I did was feed the signal into an optocoupler. I chose a 4N25. The inner loop signal is provided across 2 wires. If I were to connect it directly to a TTL IC, then one wire would have to be connected to a ground point common with IC. This would alter the voltage range of the signal. Because the standard ECU is still using this signal, I chose to leave it intact. The optocoupler will isolate the signal from the rest of my circuitry, giving me a mirror version to work with. The first thing I learned was not to feed the signal in directly. Excess current flow caused 2 spectacular  failures. *POP* and the IC shot straight off the breadboard. I never saw it again! Placing a current limiting resistor before the input worked, but the output waveform was changed. At first it just looked inverted, but flipping it over didn't exactly match the input.
Optocoupler output
Optocoupler output inverted

The signal is still usable, but I thought I was doing something wrong and decided to look into it. I played around with measuring input an outputs while feeding constant voltages and saw that the relation between input and output wasn't linear. Googling reveals that it's skewed according to the optocoupler's CTR(current transfer ratio). I found some more info here

Now that I have a signal I can work with, the last step is to convert it to a square wave. My first choice for doing this was to use a voltage comparator. If I were to use a 2.5v reference then any portion of the signal above that will set the comparator output to a solid 5v, and anything below the reference will set the output to a solid 0v (or as close to those voltages as the comparator can output). Digital 1 and 0. I tried using both an LM393 and LM311 and unfortunately I got some really confusing results. The comparator output would either not change at all or oscillate at a very high speed. Of course I measured the signals going in, and tested the IC's by feeding in various test voltages while measuring the output. I can only assume that I've overlooked something or electrical noise was making them go haywire. In the end I succeeded with an OPA2134 op-amp. 
Woohoo! Digital square wave!

To get this signal I had to make one final change, which was to make my reference 4.9v instead of 2.5v. No, 5v wouldn't work and neither would 4.8v. This I don't understand, but it shows that experimentation pays off. At this point I'm assuming that it has something to with how much current the input signals (reference voltage and optocoupler output) can source/sink, but didn't see either being pulled high or low. I'll need to find out more before I deal with this problem again.

End result: Success! & Strange results to look into.

Edit on 2013-10-01: Fixed mislabeled reluctor

Tuesday, April 10, 2012

Stock engine management system

My car is old school and so the ECU doesn't have any standard way to be reflashed, there is no OBD connectivity, and it actually doesn't have an internal ignition timing map. That's done mechanically with springs and a vacuum actuator in the distributor (which PIT will not use). It's a weird mix of electronic goodness, and mechanical cleverness.

The stock engine management system is made up of two modules, an ECU (engine control unit) and a knock sensor unit. I wanted to get a better understanding of how they work, but couldn't find much information to start with. Perhaps my google-fu is not powerful enough, but there doesn't appear to be any publicly available information on the modules themselves. All i can figure is that the knock sensor was created by Mitsubishi, and the ECU by Denso.

Lets crack them open!
I started with the knock controller. Engine knock is an event that occurs in an engine cylinder where ignition occurs too early and/or in multiple locations causing turbulence which can knock the piston into the side of the cylinder wall instead of pushing it smoothly straight down.
Wikipedia: Sensing engine knock is a complex process which starts with taking audio input from a microphone or piezo sensor mounted on the engine and then isolating a specific sound frequency.

I was surprised by what I found, which was.. not much
The datasheet for the 2 ICs show that they're quad comparators. I expected to see a microcontroller or DSP! Underneath I found another PCB connected by a ribbon cable.
Unfortunately i couldn't remove it without damaging it. No way I could find a replacement and I still need my car to work in the mean time!

Not very interesting, so I decided to move onto the ECU.

I'm most interested in these two ICs. The one on the left looks like some sort of microcontroller, and the one on the right appears to be an EEPROM chip. Surprise, there is no data available for them. I can't even find a pinout. After much googling I found that yes, the one on the left is a microcontroller, but it's a proprietary Denso one. It was probably used in many cars during the 80's. Here I found that at least a few people have successfully hacked them.

"I hacked the Denso MCU a long time ago.
The above board runs the original factory code that is inside the original ECU.
If I leave the code stock (apart from a couple of essential byte changes to swap the mode and ensure the ROM checksum is OK) then the ECU runs exactly as stock.
It's possible to alter anything in the original program or the mapping."

So it seems that some clever people are able to do some interesting things with it, but that's beyond my capabilities. I at least got to learn a couple of things, which was really the whole point.

Fast cars go *whoosh*!

A post for the fellow car enthusiasts. I've had  my car since 2005, it's an '88 Ford Laser TX3. For those of you outside of Australia, you might know it as a Mazda 323/Familia GTX. It's basically the same car, built in the same factory with some cosmetic changes and the ECU tuned for Australian fuel. It has 1.6L injected twin cam turbo engine and a 4WD drivetrain (with centre diff lock!). Stock motor makes 100kw and i'm estimating (based on past dyno run and some later changes) my car is putting out 120kw, which i think decent for a 1150Kg car.

My car with stupid heavy wheels, oops :P

I always enjoy driving it, traction + power = fun. I've focused on keeping the braking, steering, suspension and engine in good running order. I plan on completing an advanced driver course with my wife, and taking it out on a track day.

The future plan: I'm a fan of light, agile cars. I can keep upgrading this car to get where i want.... or i can get my hands on a nice MX5. I won't be able to keep both cars and plan to replace the standard MX5 engine with the one from the TX3. I'll miss my 4WD, but there's a few reasons i want to do this. Easy conversion, the engines are actually very similar, parts are interchangeable and with the help of people who know more than me i should be able to install my more powerful TX3 motor without any expensive customisation. It's lighter which means faster cornering (on tarmac!), braking and acceleration. RWD means less drivetrain power loss. The TX3 should be able to provide heaps of goodies (brakes, big radiator, fuel pump).

Because it's the same motor i expect the PIT project wont really be affected. I might even get some bonuses like the crank angle sensor from the MX5 motor!

Monday, April 9, 2012

PIT project scope

The project started before the blog so there is a bit of a backlog. I'll be playing catchup for a bit!

Background: In order to properly understand the project scope, you'll first need to understand:
- how a car engine works
- the role of an engine ECU
I recommend reading and if you don't know much on this topic.

Scope: The replacement ECU will monitor sensor outputs from the car engine and control the engine components to ensure a smooth running motor while matching or surpassing the current fuel efficiency and power figures. Of course, I'll be happy if it runs at all.
- Cam angle
- Engine air flow
- Intake air temperature (depending on air flow sensor type used)
- Knock sensor
- Engine temperature
- Throttle position
- Oxygen sensor
- Ignition coils
- Fuel injectors

Project Phases:
1. Monitor the signals sent to and from the current ECU to gain an understanding of how it works.
2. Build the PIT system to run in-line as a sort of "man in the middle" configuration between the cam angle sensor and current ecu input. With this setup i can only set a static ignition timing offset. A dynamically set offset is ideal.
3. Finished system. Some sensors replaced with different types. Monitor all sensors and electronically control all possible components.