I am in the process of building a standalone Atmega328P-PU based circuit which, among other things, is supposed to read and interpret several different 12V signals from my car's electric circuits.
I've put together a voltage divider for this, and it's doing what it should, in putting non-harmful voltages through to the Arduino's input pin(s):
I've also put in a diode, because the signals I want to read and interpret are vital to the car running properly, so I want to mess with them as little as possible.
I've put the circuit shown in the picture on a breadboard, and I have hooked it up to my car's battery. It's working and Vout always stays within what the Atmega could tolerate on its input pins. Even when the engine is running and the battery gets 14.5 volts from the alternator.
Now the only problem is that I talked to a trained car mechanic the other day, and he has told me that a car's voltage can be over 40 percent higher than the nominal 12 volts, for example when the ignition is turned over and the engine is started. This would mean it can be up to 16.8 volts, which would cause my voltage divider to feed up to 5.67 volts into the Atmega. Considering that the "regular" diode I've already got in my circuit reduces Vin by about 0.7 volts, that would reduce it to about 4.4 volts... but that's kind of getting pretty close to the 5.5 volts that are the maximum of what the Atmega can take.
If I put in stronger resistors, I could take all that into account, but then Vout would be less than 3 volts at normal 12 or 12.5 volt operation, so the Atmega wouldn't know that there's a signal coming in at all, right?
So I was thinking about putting a 4.7-volt Zener diode into my circuit, but given that I haven't really done much with zener diodes so far, I am struggling to figure out how to connect it to the voltage divider so that it will keep down the voltage.
You could simplify the circuit, get better overvoltage protection and have less load on the car's signal.
I would suggest using 2 resistors, 22K/15K for your divider which provides 4.865V at Vout for 12V at Vin.
The external diode is not needed.
The internal protection diodes will protect the Atmega328P-PU's input for anything up to 27V at Vin. The 22K part of the divider will limit the current to <=1mA.
The nominal voltage of a Zener occurs at a particular current given in the datasheet. At low current, like what you will get from your divider, the Zener voltage will be much lower; possibly more than 1 volt difference.
Zeners are also very limited in the current they can handle, so they are not usually used as protection devices. In this example, a Zener may be a useful improvement over the built in diodes in the Atmel chip.
dlloyd:
You could simplify the circuit, get better overvoltage protection and have less load on the car's signal.
I would suggest using 2 resistors, 22K/15K for your divider which provides 4.865V at Vout for 12V at Vin.
The external diode is not needed.
The internal protection diodes will protect the Atmega328P-PU's input for anything up to 27V at Vin. The 22K part of the divider will limit the current to <=1mA.
For Vin = 27V, I=(27V-5V)/22,000Ω=1mA.
+1, except for the ratio.
A car battery when charging is supposed to be ~13.8volt, but can sometimes be higher.
I would calculate for 16volt.
e.g. 22k:10k
The 22k resistor protects to at least 22volt positive AND negative if you consider 1mA internal pin protection diode current safe. I would add a 100n cap across the 10k resistor (pin to ground) to kill spikes and to give the A/D a stable voltage to sample from.
A better way is to use a ~15:1 divider and the more stable internal 1.1volt Aref.
A 100k:6k8 divider with 100n cap across the 6k8 protects to + and - 100volt.
Do NOT use a diode or zener diode. They introduce non-linearity.
Leo..
I agree ... except the protection is actually 22V above the 5V rail (+27V) and 22V below GND (-22V). Nothing to fear with using the internal protection providing you stay within 1mA max. Atmel themselves don't mind using it with just one resistor connected to 110-240VAC mains.
If the zener and it's series 100 ohm resistor are from the analog pin to GND and is NOT conducting because the analog pin is< Vzener, why would it introduce non- linearity ? (if it is NOT conducting)
dlloyd:
I agree ... except the protection is actually 22V above the 5V rail (+27V) and 22V below GND (-22V). Nothing to fear with using the internal protection providing you stay within 1mA max. Atmel themselves don't mind using it with just one resistor connected to 110-240VAC mains.
The Arduino could be off. Then VCC is 0volt. Then the protection diodes start conducting at + and - 0.5volt. Protection has to be calculated for this situation.
A 5.1volt zener is 100% useless in this case.
raschemmel:
If the zener and it's series 100 ohm resistor are from the analog pin to GND and is NOT conducting because the analog pin is< Vzener, why would it introduce non- linearity ? (if it is NOT conducting)
Zeners have leakage. More when they reach the zener knee point. When measuring a 12volt system, the voltage divider outputs about 4-4.5volt. Close to that kneepoint. If there is a 22k resistor between battery and analogue input, zener leakage could have influence on the readout.
Leo..
That would give me 3.43 volts at 12 volts, and at 16.8 volts, which would be the 40 percent spike that the car mechanic was talking about, there would still only be 4.8 volts fed into the Arduino.
The signals I am trying to tap into are
the car's GALA speed signal. It's a 12V/0V square wave with a fixed peak to trough ratio. The wave becomes shorter as the car speeds up and longer again when it slows down.
the reverse gear signal. This is a simple, "flat" 12V signal which can be tapped into at the fuse panel.
the car stereo's volume knob, which is basically a 12V phase-shifted rotary encoder.
Speed signal and volume knob signal will be handled using interrupts on pins 2 and 3.
I'm building a standalone, Atmega328P-PU based device that will switch the car stereo into mute in reverse gear (by means of toggling a relay that switches GND through to the stereo's mute pin). The mute will be sustained for 20 seconds after you've put the car back out of reverse. The mute can also be deactivated if you turn the volume knob rotary encoder five notches when the car is standing still. Also, if during the 20 seconds you pull back into traffic and go faster than 12 mph, the mute will also deactivate itself.
The point of this muting device is to make sure the beep of the parking sensors can be heard when backing. Most newer cars with factory parking sensors have this, and with the functions that I am trying to replicate.
The idea with the diodes in my drawing was that I don't want any currents from the Atmega influencing the square wave of the speed signal, because some other electronic components of the car might need it (although ABS brakes and engine control unit get their own signals from the wheels and the transmission).
Also, I imagine the electronics inside the stereo (expensive factory sat nav system with color screen, as in, expensive to replace) are kind of delicate, so that it's probably a good idea to be careful when connecting its rotary encoder to my circuit. On the other hand, the stereo will probably have its own built-in voltage spike protection, so that I won't have to expect any overvoltages coming from the rotary encoder volume knob.
It might be impossible to achieve proper frequency response with a resistive divider that has high resistance values and lower resistance values might adversely affect the original signal.
It would be really good to know the maximum frequency and minimum pulse width for 1) and 3).
It would also be good to know the maximum load (current) these signals can drive.
dlloyd:
It would be really good to know the maximum frequency and minimum pulse width for 1) and 3).
It would also be good to know the maximum load (current) these signals can drive.
Maximum pulse width is infinite, when the car is standing still. Minimum pulse width goes towards 1 ms, perhaps less, at highway speed. But my system isn't supposed to do anything anyway at higher speeds.
The "interesting" pulse widths for my purposes are 50 ms at 12 mph,
and 115 ms at around 5 mph. I've figured them out by putting the car on a lift and accelerating in forward gear, with an oscilloscope hooked up to the speed signal.
Here's a snapshot of what the speed signal actually looks like:
I've replicated the signal using another Atmega328P-PU on a breadboard by means of simple HIGH/LOW bit banging. I can manipulate the pulse length with an analog rotary pot. This signal is fed into my standalone circuit to mimic the real thing.
The mute will deactivate itself when it detects a 50 ms pulse width on pin 2 (using the pin's interrupt, listening for RISING events) in forward gear. It will assume that you have pulled back into traffic, in which case you will probably not want to wait 20 seconds for your music to come back on. And it just adds another layer of technical sophistication to the whole thing...
The reason why the mute is supposed to stay on for 20 seconds at less than 12 mph is so that the sound doesn't go on and off all the time while you're still maneuvering backward and forward in a parking space.
If the car is in reverse and the mute has been dactivated by turning the volume knob at standstill, the mute will be switched back on if the Atmega detects that the car is moving backward. This is done when 115 ms pulse length is detected, or 5 mph. I am thinking about reducing it to 2 or 3 mph and the corresponding pulse width, to increase safety. Maybe I will just make it so that it kicks back in when any pulse width lower than infinite is detected.
Ok, so I put in a "lab day" today and hooked up my circuit and a number of Arduinos and breadboards to my car.
For the flat-12V reverse signal, a high resistance setup seems to work. I've fed 12 volts from the car battery into the Atmega using a 30k/12K voltage divider, and the Atmega picks it up, no problem. I suspect that voltage spikes will be more likely on the reverse gear signal than elsewhere.
With the speed signal, I've had no luck with any kind of setup with "big" resistors. The speed signal just seems to be too weak for anything in the tens of kiloohms. So then I connected the Atmega to the speed signal with a 5K rotary pot, and that's the only thing that gave me a signal that the Atmega picked up. I'll try again tomorrow with a breadboard voltage divider using 1K and 0.5K resistors. Even at 16-volt spikes, it will put no more than 5.33V onto the Atmega's input pin.
My guess is that the volume knob will also need small resistors to pick up its rotary encoder's pulses with the Atmega. I'll try 1K/0.5K for that as well.
Oops. Reading back some of the posts, and saw that OP wants to detect digital signals.
In all my posts I assumed analogue battery voltage measurement. Sorry bout that.
For digital signals, just make sure the divider still outputs more than 0.6*VCC (3volt) when the car battery drops to ~10volt. A 2:1 (e.g. 30k:15K) divider should be ok.
The biggest value sets the fault current for protection. As explained in previous posts, keep it under 1mA.
Always add a 100n ceramic cap from pin to ground to kill fast spikes.
Try to understand that overvoltage is not damaging a pin. Overcurent is.
A 15k resistor connected between a 12volt battery and NO resistor to ground will NOT damage the pin.
When pin voltage reaches 5.5volt, the internal pin protection diodes conduct the fault current to the 5volt rail.
Those diodes are tiny, so fault current should be kept <1mA.
Leo..
MorganS:
I may have skimmed the topic too quickly but are you sure the speed signal is 12V? It's more likely 5V for the car computer.
Yep, I've connected a multimeter to the speed signal wire that goes into the back of the stereo, and which I will also use for my circuit. The signal alternates between 12V and 0V. It will "look" like 5 or 6 volts on the multimeter at higher speeds, but when the car is moving very slowly, you can see the multimeter go up and down between 12V and 0V.
Also, I've been able to find out that the speed signal for the car stereo is generated by the car's speedometer/instrument cluster and then sent over to the radio harness in the center console. The instrument cluster generates this signal using raw data from a sensor on the transmission. It's a wild guess, but maybe that already means that there's some built-in protection from within the instrument cluster's electronics.
The speed signal is used by a couple of control units, for example the engine control unit and the automatic light beam leveling unit. The ABS brakes have their own wheel sensors, but need the speed signal as well, I think. So whatever I do, I will have to make sure my Atmega circuit won't mess up the signal. There are anecdotes of cars like mine running like a bag of bolts when there's a wiring fault on the speed signal wires.
By the way, it's a '2000 Audi A4 sedan. They're relatively "gadget friendly" for your own creations, because that was one of the last model years where they didn't have everything controlled by Controller Area Network (CAN bus) yet.
