DIY closed loop

[Oldskool]

I know some of you will think I'm bonkers but for those who (like me) enjoy this sort of thing here is an idea for a home made closed loop system.

I started thinking about this after I picked up a s/h stepper valve and controller and I wondered whether a programmable microprocessor control is really necessary on a basic carburetted motor, especially when I've got the little LED lambda display I already built, I figured there ought to be a way to drive the stepper from the display output lines "the old fashioned way", in other words using TTL (transistor transistor logic).

So here's what I've come up with.

The motor appears to be a two phase bipolar design, so I originally looked at using a shift register and a couple of H bridges to control it, but then I saw there are some pre-made little stepper driver modules available for about £2.50. So that's a no-brainer and I immediately ordered one.

The driver module has three main control inputs, one dictates the step rate of the motor providing one step each time the input goes between high and low, the second is also a high/low trigger which changes the direction of the motor, one way is high the other way is low, and the third disables the motor drive when a logic low input is applied.

So below is my schematic - the 555 chip provides a square wave to the step input and can be adjusted from about 0.5 Hz right up to stupid fast (note, I know the schematic is incomplete there needs to be some capacitors and a few other things to make this all work).

So that's half a second per step, not per revolution. I don't know the step angle of the motor yet but half a second per step ought to be way slow enough that damping the loop is well within range.

The gauge lights the display by grounding the cathodes of the LEDs. So I figure each LED connection can provide a logic low signal when the LED goes on. Using two chosen LEDs at appropriate points in the lean to rich scale I need to drive the motor one way when the chosen "lean" LED goes out, and drive it the other way when the chosen "rich" LED comes on. In between these points I need the motor to stop.

The connection from the "rich" LED means the direction pin of the driver module ought to see a logic high when the "rich" LED is off (if it doesn't I'll have to add a pull-up resistor), and then a logic low when that LED comes on to reverse the motor direction.

To stop the motor when the mixture is anywhere in between the two LEDs I think I can use an XNOR logic gate. That will provide a logic high when both LEDs are either on or off together (so the motor is enabled in those conditions) and a logic low when only one of the LEDs is on; which will be the "lean" LED in practice (so the motor is disabled when the mixture is showing between the two LEDs).

In case the motor doesn't respond quickly enough, apart from increasing the 555 frequency, I could also add some additional connections from adjacent LED bases to run the motor in half step mode on marginal mixture conditions and full step on more severe deviations (so the motor spins faster as the mixture goes further out of range).

Anyway, here it is, bonkers right ?

[Gilbertd]

I don't see a problem with it. It might be worth you having a chat with Gordon (Gordonjcp) as he seems to be thinking along similar lines to you (see http://www.lpgforum.co.uk/viewtopic.php?f=29&t=13929) although knowing Gordon he's probably considering going the opposite route and incorporating an Arduino or similar.

[rich r]

Are you sure you want to use a 555? They're not very stable, particularly with temperature. Might be better off using some other form of square wave generator. Although I guess in this application the actual frequency is massively critical.

I'd use an Arduino if I was doing it. I've just got one set up monitoring my coal-fired central heating system to control the radiator pump to try to optimise things a bit.

[LPGC]

There are commercially available controllers that don't need (nor have facility) for setting up using a laptop (I know you can use a laptop, just saying!), never had one to bits and would suspect they too use a micro-controller, otherwise would expect them to be similar to what you're building.

I don't see a problem with what you're doing either, all clever stuff(!) but the usual type system ability of adjusting stepper speed accordingly with rpm might be advantageous / a microcontroller would make it drastically simpler to have the usual type ability to 'jump back to default metering position' when a change in throttle position is seen - even when TPS isn't connected, most systems jump back to a set position when a big change in rpm is noticed such as a gear change / auto gearbox kickdown. This sort of functionality not necessary as long as engine, mixer and reducer are all suited well enough.

Simon

[rossko]

In this day and age, a microchip costs much the same as a 555. It's capable of performing additional support functions - RPM safety shutdown, tank level display - and adding finesse like sensor failure detection and overrun fuel cutoff. Even for a one-off hobby project, development using something like a Picaxe chip isn't that difficult. There's no reason you can't replicate all or some of that in hardware alone, but really it is likely to take more effort than a soft-centered solution.

Worthy of study is the old Lucas 4CU / Bosch L-jetronic EFI system, petrol injection implemented in individual transistors. Not that you are injecting, but the wonder is all the little subcircuits monitoring temperature, RPM, airflow, throttle position etc., each contributing to a hardware 'algorithm' to calculate fuel demand. Clever analogue folk could add temperature or altitude corrections to the 555 circuit in a similar way.

[rich r]

Indeed - an Arduino Micro for example is about 15mm x 40mm (fits in a DIL socket) and costs £3. For that you get a fast processor that's dead easy to program (assuming you can manage simple C), 32K of Flash, 2.5K RAM, 20 digital input/output ports, 7 PWM ports, 12 analogue input/output ports, power regulation (up to 20Vdc) and USB interface and so on. Plus you can test and simulate the code on your computer until you're ready to set it free standalone. If you get something wrong you can just correct the line of code and try again. If you put it on a pcb (or veroboard!) but make a mistake with the wiring, you can often just remap the pins in software and pretend you meant to do it that way.

It really is the way that hobby electronics has gone - I started off in the 1970s as a kid, then in the 1980s with 555s and BC108s before moving on to Z80s and 6502s, did a BEng Electronics degree in the 1990s working with 68000 and DSP processors, then had a brief flirtation with PIC before getting swept up by the Arduino. Because it's aimed at people with limited electronics and programming skills, it's extremely easy to get going - but incredibly powerful to use as basis for far more complex things.

[Oldskool]

Sorry chaps I didn't get a topic reply notice and only just saw posts.

I actually quite enjoy programming and I've done stuff with processors. My mate three doors up is into Arduino, in fact he was round here on Wednesday scrounging in my parts boxes for something he's doing with an anemometer.

But my thought here was not "is it desirable to have a microprocessor?" it was "is it necessary...."

The open loop system I'm running at present seems pretty well adjusted now but it drifts "off mixture" under certain conditions, so I'm just looking for something to keep it line, not to manage the entire configuration. Also I rather like the idea of being able to whip out a screwdriver and tweak the set-up rather than having to re-code it via USB.

It will need something to disable it until the motor warms up, and I can see that not having a "return to default" function could perhaps be a bug on start-up.

I reckon the 555 should be OK. It will be sitting behind the dashboard, not in the engine bay.

Anyway, I'm going to built it and find out.

[rich r]

Stick a trimpot on one of the analogue inputs so you can adjust it with a screwdriver You'd be able to build in 'if' statements to detect conditions such as startup and drift very easily.

But yes, I do see your reasoning, and it won't take long to put together - even if it just proves the concept before you reimplement it with more bells and whistles on a microcontroller at a later date.

[Oldskool]

Stick a trimpot on one of the analogue inputs so you can adjust it with a screwdriver

LOL implement it all in software and then crowbar it back where we started with good old analogue.

But yeah that's kind of it. It'll be clunky but as a part of the learning curve I'll see more easily what's going on "real world" style.

.............did a BEng Electronics degree in the 1990s working with 68000 and DSP processors..........

We have a couple of pinball machines here from around 1980 with 6800 Motorola series processors which I think are the 68000's predecessors, 8 bit parallel 1KHz but fast enough for what they do.

You have to burn a separate eprom for the program which we've had to do a couple of times, luckily the binaries are openly available. We fancied having a go at some modifications but the source code isn't available and I don't think we would have got far anyway because apparently they programmed them straight into assembly code !

[rich r]

I used to program 68000 assembly code a lot on the Atari ST and Commodore Amiga when I was in my teens. Did a little bit of freelance work for some games that never quite got released sadly. 6800's not too bad to turn from machine code back into assembler and figure out what's going on, but 68000's miles easier due to having 16 bit opcodes, loads of registers and no accumulator to make it awkward It was always fun to run some game or other in a debugger watching for the lives counter, then replacing the subtract opcode with NOP - 'no operation'. Which even 25 years on, I can remember is $4E71.

[Oldskool]

That's funny you still remember it. I've never messed with assembly code. Is there some sort of de-compiler for 6800 machine code ?

[rich r]

Yes indeed. As with most processors with relatively simple instruction sets an opcode in assembler (eg move.w #4,d0) assembles becomes a set of bytes in the 'assembled' machine code program. On 8-bit CPUs such as the Z80, 6502 and 6800 it's pretty much one byte to one opcode, with the data for that byte being in the next byte. It's entirely possible to program directly in machine code, just by doing the 'assembly' manually. In fact the back of the manual for the ZX81 and Spectrum had assembler to machine code tables. Where using an assembler makes life easy is that you can use labels (for jumps, data structures etc) rather than having to remember absolute memory locations, and some shorthand ways of doing things like indirect addressing without having to do all the offset calculations yourself. Better assemblers can optimise code, but that of course makes disassembly into something useful a pain.

Have a look at the table on page 3-2 in the 6800 reference manual, and Appendix A to see how the assembler opcodes convert to bytes - ftp://bitsavers.informatik.uni-stuttgar ... _Nov76.pdf

Might have to dig out an ST emulator and have another play with 68000 again now I can't be bothered to go up in the loft to get my real ST or Amiga down!

[Oldskool]

Just to let you know - I've finished rigging it all up on a breadboard and it works fine. The 555 seems to interface with the stepper controller just nice and there's lots of speed control.

I had a small issue with the LED driver chip outputs being open collector type and the chip also having an internal current limiter for the LEDs. So with those two things combined plus the voltage drop across the LED junction from a 5v supply I was getting a (not) logic signal of 3.5 ---> 3.00v as the LED connections went active.

To solve that I put a 10K resistor across the LED and a 1K in series which brought the signal to 4.9 --> 0.06v. So that's going to provide a pretty stable reference I reckon - it does make the target LED very slightly dimmer than the others but you have to look really hard to notice that. If I was bothered I guess I could try 50 or 100K instead, but hey.

The other little snag was that the stepper driver "enable" pin is pulled down internally to 0v and giving it logic high disables it rather than enabling it, so I really needed an XOR gate not an XNOR. For now I just used another XNOR gate as a signal inverter.

I wondered whether to go straight ahead and build it in permanent hardware or try it on the motor like this first - I guess it's probably better to try it like this first in case I need to solve any issues with voltage spikes etc.

I'll let you know.

[LairdScooby]

Sounds like you've pretty much got there but i'll add this bit in anyway, just in case you find you might have a need for it for some reason.
In addition to the stepper motor driver chips, you can also buy Darlington transistor array chips, usually with 8 Darlingtons built in. This would give you much more current switching capability directly from the LM3914 (or whatever LED driver chip you're using) via the Darlington array. Here's a few to choose from :

http://www.ebay.co.uk/sch/i.html?_from= ... y&_sacat=0

Also there is a high-spec version of the 555 available, if memory serves it's the 7555 which to all intents and purposes is a military spec 555 timer with enhanced stability and extended operational temperature ranges. It's also slightly less sensitive to supply voltage decoupling causing spurious triggers but running in astable mode they are pretty much eliminated anyway.

Looking forward to your report on how it functions in the "real life" test-bed aka the car!

[Oldskool]

OK thanks, I'm only using the LED driver outputs as logic l/h source at present so won't need transistors on them unless I get ideas to expand the functionality.

I just haven't had any time to try it on the motor yet but over Christmas should be a chance with a bit of luck.