help with microcontroller/electrical interfacing

[_ali]

Hi,

I'm a software person keen to learn more about the electronics/hardware side of things and to that end I've started playing around with programmable microcontrollers (PIC18FXXXXs so far).

As a project I'm working on a wee data-logger type device - I have accelerometers etc working but I'd like to interface with the car too - initially the engine RPM (to build a simple shift light). I'm hoping that someone on here could help me understand the electronics side of this (and maybe point me to a relevant book or two).

My understanding is that there is a tachometer wire going into the stack that caries a pulse every ignition spark and that is what is used to drive the RPM gauge. Is this correct? If so, what circuitry do I need to feed that signal into a digital input on my microcontroller (ie what voltage range is that signal and what else do I need to worry about)? Finally, how easy is it to locate that wire?

All help appreciated - thanks in advance.

Cheers
ali

[Rich H]

Tacho is relatively simple, my experience is the 924, the pulse is (normally) a negative signal, as in it's kept high until the coil charge then goes low to charge the coil, the trigger is then when it goes high again. A zernier diode will filter out some of the noise, the porker uses a 18v zernier diode reverse biased so only the large pulses get through for the dash tacho (Not that it displays over 2k as it's bust!). (Basically it's the wrong way around, the zernier will let a voltage of 18v or more through but blocks the rest) dunno what 18v would do to your PIC though!

I'd use CMOS logic IC's but I can't program for toffee!

You need Robin, but he will slag off your 1970's PICs

[robin]

PICs are crap I tend to avoid them because of their byzantine programming model. That said, if you have one that you're comfortable writing code for, I'm sure it will do the job. These days embedded ARM7 is so cheap and versatile, I don't understand why people would use anything else (though if you want an 8-bit MCU, Atmel's AVR are so much simpler than the PIC).

On the elise the tacho signal to the dash is synthesized by the ECU (i.e. it is not the LT coil feed, thankfully). It's nominally a 12v square wave, but actually at higher RPM it probably won't make 12v and the rising edges are going to be exponential rather than properly square. However, if you cut it off at about 3v and ignore the shape above, it will be square at any RPM.

You don't need a zener (not zenier) diode to filter the pulses.

A high impedance input to a schmitt triggered buffer (or, if you prefer, you can make such a thing with a clever organisation of a couple of NPN transistors) is more than adequate to convert the input 0..12v signal into a logic level square wave.

What sort of construction are you looking for - presumably you're happy with soldering circuits in vero boards?

The most straight forward way of doing this would be:

input -> 10K..1M ohm resistor (use highest value that works) -> 7414 schmitt trigger invertor -> PIC input pin (then count or time the pulses in s/w to do whatever it is you want)

Now, you also need to put a schottky diode after the input resistor to the 7414 power supply and another one down to the 0v. The point is to shunt any voltage above the power supply level into the power supply and anything below 0 into the ground rail - this is just there to protect the schmitt trigger - it's common practice in automotive electronics to protect inputs like this, because you see ludicrous spikes and troughs from time to time (think +/- 50v).

You can further protect your circuit by sticking a 0.1uF 50v non-polarised capacitor in series with the input (i.e. before the resistor) and then a resistor with 10x the resistance of the series resistor to ground. The series capacitor will block any DC (and thus prevent your circuit becoming an accidental path to ground for any stray high voltages). The high value resistor makes sure the input signal remains more-or-less grounded when not being stimulated (otherwise you may get noise triggering the circuit while the ECU is powered off).

(I'll draw a schematic later and post it up).

You can replace the 7414 with any schmitt triggered buffer that you can get, for example, the TI SN74AUC1G17DBVR or Fairchild Semiconductor NC7WZ17P6X are both low cost single or dual schmitt triggered buffers in surface mount packages.

Cheers,
Robin

[Rich H]

Told you he'd slag off the PICs

I assume the zerner (spelt right) diode in my circuit is because it's the LT feed to the coils?

[robin]

Here's the circuit I was thinking of:



(Except I note that I have the 10K and 100K reversed - doh! - so use 10K in series and 100K to ground rather than the way I have drawn it).

Rich, the Zener operation is probably as follows:

If it's reverse biased in line from the coil LT circuit, and the Zener voltage is 18v then when the points are open the steady state 12v obviously doesn't exceed the zener voltage and the far side of the diode will remain at 0v (assuming it's connected to 0v via a resistor, say). Then when the points close, current flows and the zener now sees 0v on both sides - still nothing happens. When the points are released, the current still wants to flow through the LT side of the coil (it's an inductor, after all, and these always work to maintain constant current) - to achieve this, one end stays at +12 and the other end rises in voltage rapidly (it's this rise in voltage that eventually causes the spark to jump across the points); obviously this will rapidly exceed the 18v Zener voltage and some current will flow through the Zener diode and the resistor to ground. This current flow will cause a voltage to develop across the resistor, and assuming this is used as input to something like a schmitt trigger, this can be used to generate a cleaned up switched output that pulses once per coil discharge.

Inductive loads (like fuel injectors, relays and worst of all, ignition coils) are the hardest things to drive or monitor safely from low power eletronics - the voltages can easily be >400V on the low tension side before the points spark (or electronic equivalent in modern electronic ignition systems) - thus I would always avoid tampering with those circuits and instead latch into nice non-inductive signals like the ECU's RPM output

Cheers,
Robin

[Rich H]

The feed is going to the cars original tacho only, used to be directly wired to the coil so should be able to cope.
I'm now wondering if the tacho is actually wanting to see more voltage which is why it bails out at 2k rpm.
Might bypass the zener see if that works, tacho should be able to take it if it was hooked direct to the coil previously.

[_ali]

Thanks for all this info - it's greatly appreciated.

I only really went with a PIC as it had the features I was after (primarily A/D and built-in USB) is quite well documented and easy to solder, although I think I should perhaps pick up a LPC-H2148 Header Board or simialr and have a play with that instead since more than anything the PIC toolchain is proving to be a real pain (I'm trying to get a solid dev environment going on the Mac, ideally without vmware...) Presumably gcc can be used to build arm7 code suitable for these embedded micros?

Cheers
ali

[fd]

I have built atmel AVR code on my mac using the ports environment, works fine and using avrdude you can read/write/program devices no problem, same code and makefiles (old but portable) work on linux also and under cygwin . . . not sure about the arm7 as I tend to stick to devices I can practically use and surface mount stuff is not usable to a vero board botchit person like myself . . . well not as usable as DIL stuff anyway . . . and an ARM7 is OTT for most of my requirements . . .

$0.02

Fd

[robin]

AVR is for many purposes and has the benefit of GCC support so no need for ludicrous PIC tool chain (why aren't they bust already - I mean who develops a processor with an instruction set and memory architecture so complicated that you cannot easily port the world's most portable C compiler to it!).

ARM7 has GCC support also - you can build your own cross compilers if you're brave or you can download the CodeSourcery pre-built binary tool chains for free - they are excellent quality and regularly updated (not that you'll come across many problems compiling against ARMv4t as that's been stable for a decade now I think).

If you're going down the olimex route, the STM32 boards are probably better suited for automotive applications and the CodeSourcery toolchain supports the M3 cortex instruction set (that's the Thumb2 instruction set). Unfortunately they don't support Mac directly, so you would need to look around for some pre-built Mac binaries elsewhere, or build your own.

Fd - the Hxxx series of Olimex boards come on DIL pitch PCBs so you can develop the I/O logic on vero and just solder in the CPU - very neat.

Typically you use JTAG to program these - Olimex's ARM JTAG USB is acceptable - I have made it work on both LPC and STM32 processors - basically no different to avrdude, but supports complete instruction level debugging too.

Cheers,
Robin

[robin]

The feed is going to the cars original tacho only, used to be directly wired to the coil so should be able to cope.
I'm now wondering if the tacho is actually wanting to see more voltage which is why it bails out at 2k rpm.
Might bypass the zener see if that works, tacho should be able to take it if it was hooked direct to the coil previously.

Why is the Zener there, then?

The Zener may struggle with reverse recovery times - but only if it's really beefy part - 2K RPM is only 60Hz, so plenty of time between pulses for the zener to recover.

Just remember - you'll see >400v on this line before the spark fires - so don't be tempted to hook a test light or your fingers up to it

Cheers,
Robin

[Rich H]

Had my high voltage shock for this year thanks, and that came off an aa battery (Plus a swift and decisive lesson in voltage pumps!) I'll whip the zerner out see if that helps, but I have tried a few combinations of signal and it always dies at 2 - 2.5k I think it needs replacing/pimping

As I don't speak any of the languages you mention what is the best way to start learning this stuff, a single microprocessor thing would enable me to ditch loads of chips. I tried PIC and just got totally confused... I could get simple things working but I could really do with a Binary coded decimal converter with bells on it's next to impossible with logic ICs...

[robin]

LOL @ charge pump.

Microcontrollers are tricky to program in their native assembler language as they all have a few quirks that you need to understand. So you can either learn the specific assembler for the microcontroller, which is tedious, but relatively limited in scope, or you can learn C, which is applicable to all modern microcontrollers (i.e. not the PIC ).

The C book that maybe useful to help learn it is the ANSI C by Kernighan and Ritchie (the fathers of the language) is:

http://plan9.bell-labs.com/cm/cs/cbook/

There are plenty of on-line examples for the AVR in particular (avrfreaks.net IIRC) that would give you templates for everything you want to do. There are similar forums for working on the various ARM7 based microcontrollers.

There are potted releases of GCC (the open source & free C compiler that translates your C language input files into binaries to load onto the microcontroller) for the win32 and linux platforms for both AVR and ARM7 - if you're using linux I can help you pull together all the pieces you need for either AVR or ARM7 development.

Cheers,
Robin

[robin]

P.S. If you want to stick to chips, you could always use a big CPLD to do any binary/BCD conversions ...

P.P.S.what BCD translation do you actually need - if it's binary -> BCD, how many bits - I love designing digital logic and can probably knock up a schematic for such a thing if you want some tips ...

Cheers,
Robin

[Rich H]

It's all pie in the sky most likely, but the whole plan is as follows:

Take a tach out diagnostic signal (Square wave, low volts) from the EDIS ignition on the Porker and turn it into a Nixie display.

The nixies have one cathode per number (0-9) and need driving but that is easy with a high voltage transistor and voltage pump.
Max revs is 7000 and it would be good to avoid it counting too fast and being silly a simple frequency applied to the units '0' would probably be best ,to give it a 50%-75% duty cycle perhaps?

Problem I have hit is that 0-9 is easy but once you get to the tens it gets tricky to drive it as BCD chips don't have carry bits as such. Hit them with binary over 9 and they jsut go high on all pins. I had designed a parrallel ripple counter which flip-flopped from count to display on an internal clock, but it was inelegant and unlikely to work really.

Probably a daft idea but it's kept me thinking! I have no idea about nixies in an automotive environment, there was a guy with a nixie speedo on his scooter but I can't actually find any details of how successful it was.

If it works then it would be simple enough to recalibrate it (External calibration would be good) and use it with an encoded speedo drive too, would need a trip meter to go with it mind

Cheers
Rich

[robin]

So you want a nixie frequency counter that counts in RPM instead of Hz and has some rounding on it - i.e display to nearest 10 or 50 RPM as you won't see the least significant digit anyway?

Doddle - I'll stick it in the job queue and have a solution by morning

Cheers,
Robin