A to D to Memory circuit

Need to expand your spec. a bit. How many analogue inputs? What resolution do you need? How fast?

My feeling is that there's probably a microcontroller (eg PIC), or possibly a 'programmable relay' (simple PLC) type device, that will do the whole job (A/D inputs & control outputs), but we'd need to know what the total I/O spec. is, and what you're budget is.

I'd have to go back and look at the wiring diagram again, which I don't have right next to me at the moment, but I think I'm looking at about 10 inputs. The engine runs on 6 cylinders and what would determine my resolution would be the camshaft position sensor. AFAIK it's an optical device with a perforated disk that rotates with the camshaft and has a index notch and notches for certain degree increments, but again I don't have the schematic handy at the moment so I'll have to get back to you.

Figure 6 cylinders at 10,000 RPM is 1000 "cylinders" per second, and each cylinder has to have a fuel injector event and an ignition event, accurate to +/- 0.5deg (preferably). 128 KHz might do the trick, no? Is this asking too much of a home-brew circuit?

Blimey...factoring in that lot with what you said in the initial thread e.g. 'I have some knowledge of electronics, but not enough' ....
I'd have to say i feel you haven't a snowball in Hell's chance'.

I'm not trying to put a damper on it...just a sense of reality to save yo wasting a load of time and money... You are looking at a serious professional level electronics project.

It'd be like me trying to machine a 6 cylinder engine block when I've never used a mill ...but I have made an electric golf trolley.

Maybe there's a way of hooking up a laptop to the existing ECU?

Anyhow... good luck

Del

Let's do a 'back of a fag packet' calc (or 'order of magnitude' if we want to be posh)

10,000 rmp at 0.5 degrees = about 7000,000 increments a min..but x 6 for 6cyl and x10 for 10 inputs

This is about 420,000,000 data per min ... so divide by 60
7,000,000 data per second to process...

Now processing analogue data inst quick..but heck lets say 10 clock cycles per item of data... heck you've still got to stuff it into external memory..but let's just ignore that (sue me ! )

you see we've ended up with 70,000,000 cycles per sec.... 70Mhz .
This is a bit quicker than 128khz!!!

Right ... Knowing me I've probably screwed up the maths... but I've been incredibly optimistic in my cal'c so I'd guess it's a non starter for any homebrew system.

Del

Of course... not all your data is happening ever 0.5 degrees... it maybe happening once a cycle..but if you are measuring pressures or such like it's still going to be a hell of a lot of data at a pretty quick rate.

Anyhow you can put your own numbers int my calculation and get a feel for the required speed.

(PS Pls don't anyone shoot at my crap calculation ..it's just a look see..)

Del

Like what John says....

Loads of microcontrollers will do it...you need to define .
1. How many inputs you want.
2. How often you want to sample/record these inputs (or act on the information they contain)
3. How many outputs, and what you want them to do.
4. How much info you want to store.

You then take the info from 1,2 ,3 & 4 and try and find a microcontroller which will do all that at the required speed. It sounds like you are almost building an ECU for the engine which is no trivial task....
Maybe you can obtain data/circuitry for an existing one...and use that?

Put it this way..I design microcontroller based control circuits for a living and I'd consider it a bit of a challenge... 'cos not only do you have to design and build a circuit which will have to operate in an extremely hostile environment you will also have to program the sucker .

I'd seriously suggest playing with an existing ECU first..there is probably loads of data out there for 'em...the petrol heads love re-programming these things for more revs, nicer noise, worse economy etc .

Del

Del, you've got a lot of it right - over however many posts that just was - I was doing a hell of a job mixing up my inputs and outputs... the only input I have that will need to have a fairly high resolution would be the camshaft position sensor. Everything else is just an aggregate measurement of engine condition (coolant temp, oil temp, oil pressure, oxygen sensor (x 2), throttle position sensor, intake manifold pressure, intake air temperature, mass air flow sensor, fuel pressure, fuel temp, etc...

Don't mind me, I've spent the last couple weeks with a head cold - I think it's made it all the way to my brain.

My intentions are to build the data input unit, which will gather all the info and store it in a computer-accessible memory, which will be analyzed by a computer (an actual AMD/Pentium powered "computer" computer, either laptop or micro-atx) and then an output unit which will control the fuel/spark timing and a few other gadgets and will receive info from the computer. (6x spark coils, 6x fuel injectors, 2x variable camshaft timing solenoids) The analysis and control will be done on the fly by software, so the input and output circuits can pretty much be "dumb" circuits that don't have to do any calculating and such.

And a note on my calculations:

360° at 0.5° increments is 720 "ticks" per revolution, at 166.6‾ revs per second (10,000 rpm) that's about 120,000 "ticks" per second (166.6‾ * 720 = 120,000)

Ah, if most of the data is once a cycle rather than air flow mapping or continuous pressure measurements, you may be in with a chance... I spose you can just have 10 A/Ds and get them to interupt the PC/micro or let the PC/micro to scan 'em as is appropriate ... the 0.5 degree is a resoultion rather than a sample rate (stupid Cat )...

Still rather you than me , have fun

Del

Hmmmm back in 79 i designed the basics for one of the first ECU for a car and it was a very complex task, as I think Del has pointed out!!

It can be simplified no end though if you use the microprocessor interrupt inputs WHEN you need the 0.5* resolution...

i.e. I suspect the ½ degree resolution would only be needed around top dead centre, so you could use a counter to count up all the pulses for the 350 degrees (700 pulses) before issuing an interrupt to the micro and get it interested in where the crank is...

So that would reduce the sampling needed for each of the 6 cylinders.

The other inputs such as air mass flow, temperature, throttle angle, engine temperature, exhaust Lambda O2 sensor, speed, etc... needed to determine the injector pulse width and timing from the engine 'map' for your engine, are all relatively slow changing inputs, so you can get away with sampling some of them only once a revolution etc...

Still, for someone who acknowledges their lack of electronics expertise, I would add that its a no-brainer of a task...

John.

Go out and buy a custom ECU

http://www.autronic.com/

http://www.motec.com.au/

http://www.haltech.com.au/

http://www.enginemanagementsystem.com/

http://www.wolfems.com.au/home

http://www.diy-efi.org/

What air sensing are you running?

MAP (Manifold Absolute Pressure)

Air Mass Flow Meter (air vane and thermal wire)

water temperature?

O2 sensors

Knock Sensors

TPS (Throttle Position Sensor)

Crank Angle sensor

Spark timing/advance

Battery voltage

Auto gearbox control

Injector drivers and timing control, select between batch and sequential control

fuel pump control

After all that, are you going to do your fuel maps from a 2D bar graph, or 3D.

2D is at X-RPM you will dose Y-ms of injection pulse

3D is at X-RPM with Y-throttle% you will dose Z-ms of injection pulse

Then the similar for cylinder sparking. where you have duration and Advance/Retard

Do you want to redesign the wheel from scratch or buy something already built and that you can hook up to a laptop/PC yourself, and all the "dark-arts" hidden inside a shiny box?

I'm buying the shiny box, possibly the MoTeC ECU

Megasquirt:http://www.bgsoflex.com/megasquirt.html

For what you try to do, you'll need a full ECU. Don't reinvent the wheel, just use it. Or you can setup a PC with AD board and program it in C, BASIC or whatever you know. You'll have enough GHz to do any calculation.