Another couple of hours on the design this evening. Added the output drives and removed un-necessary buffering on the analogue inputs after a slight change of heart.

Not sure if convention is to use flyback diodes on injectors to limit voltage when they switch off so added to the design just in case (I can always leave them out). They will switch off faster without, but may not cope with the voltage levels. I'll pull a standard ECU apart & have a look.

I've gone for self protecting output mosfets for all of the standard stuff. I've used these a fair bit and apart from the 100A versions (which have gone off the market) I've never blown one up yet.

for those interested:

http://www.cdd.co.uk/stuff/ECU_schB.pdf

_________________
If at first you don't suck seed, try drier grain.

Final(ish) bit of research, for the triggers.

Firstly, if anyone has any info on hall effect sensors and opto sensors commonly used by other manufacturers I'd be grateful. Particularly driving voltage and what typical pull-up resistor to what voltage. I'm mainly concerned with the magnetic sensors on the Celica at this stage but want to allow all options for the future.

The following are G1 (cam sensor) vs NE (crank sensor) vs IGT (ignition locked to 0 degrees)

1000RPM (ish)





2000RPM (ish)





4000RPM (ish)



I would have liked another more accurate sample at 4K RPM but the turbo was glowing very brightly by this stage running with no advance


From experience of the link G3, these sensors normally have a threshold voltage specified which rises with RPM in order to avoid spurious triggering. I would hazzard a guess that the correct timing point is at the zero crossing, so arm when it goes above the threshold then trigger as it falls past 0.

Checking the above timings.

1K RPM.

Period for 180 degrees = 29mS (1035 RPM)
Cam crosses zero at -4.1mS or -25.5 deg.
Crank crosses zero at -0.45mS or -3 deg.

2K RPM

Reriod for 180 degrees = 14.25mS (2105 RPM)
Cam crosses zero at -1.8mS or -22.7 deg.
Crank crosses zero at -0.25mS or -3.2 deg

4K RPM

Reriod for 180 degrees = 7.5mS (4000 RPM)
Cam crosses zero at -1.1mS or -26.4 deg.
Crank crosses zero at -0.15mS or - 3.6 deg

So my guess sems to stack up.

Unfortunately, the method of arming at a set voltage then triggering on zero crossing isn't compatible with other sensor types.
For optimum verstility, the trigger signals should feed into analogue inputs then the method of detection can be dealt with in software. Unfortunately this would require the software to periodically sample which will limit resolution / accuracy to the sample period. At 9000 RPM would require sampling at 18uS interval for a 1 degree resolution, probably about the limit of capability of the processor with all it's other tasks and I would like to do better.

My original plan was to have circuitry external to the processor providing a digital signal which can then feed an interrupt to start a timer within less than a microsecond giving much greater timing resolution. The question is whether I can get away wth switching at a fixed level above zero without skewing the timing massively as RPM changes.

So, lets pick 1V as a sample point (1/2 division up = 1/2 amplitude at 1KRPM)

1K RPM. Crank trigger at -0.75mS or 4.7 deg
2K RPM. Crank trigger at -0.35mS or 4.4 deg
4K RPM. Crank trigger at -0.2mS or 4.8 deg

So, in practice, it would appear that the error isn't massive. A fixed error over the entire RPM range isn't a problem anyway as it will be removed by calibration. An error which varies with RPM would be inherantly dealt with by mapping as long as they are consistent, but would give some stange effects when comparing maps from another ECU. Anyway, looks like it's within a degree anyway so no problem.

_________________
If at first you don't suck seed, try drier grain.

According to the date on your screen shot analysis you have also cracked time travel Chris, congratulations......

_________________
Don
GT4DC Chairman
1994 Toyota Celica GT-Four ST205WRC JDM 269bhp @ 0.9bar
1994 Toyota Celica GT-Four Special GT 590bhp @ 1.8bar
1989 Van Diemen RF88/89 Formula Ford 1600
2008 Nissan Patrol GU 3.0L ZD30DDTi 154bhp

Must have been the really hot cup of tea I had earlier

_________________
If at first you don't suck seed, try drier grain.

One last bit of research.

I was not 100% happy with the situation for talking to the host. There aren't enough pins on the main processor for both canbus and RS232, so I was considering whether to switch between them, or whether to communicate with a laptop via canbus - either making an interface or going OBD2 and using a readily available lead.

Anyway, after looking to see if the was a device to go via the I2C bus, I stumbled on this little gem, the FT201X, which provides in interface between USB and I2C.

http://uk.rs-online.com/web/p/processor ... s/7570023/

Not available in through hole sadly, but not a vast number of pins and not the most minature so may be do-able.
A bit more searching revealed a low cost module version available which may well provide the answer. Order for an evaluation one about to go in.


http://uk.rs-online.com/web/p/processor ... s/7570054/

_________________
If at first you don't suck seed, try drier grain.

Ahh, just remebered, I have a spair MR2 turbo gen 3 ecu you can cannibalize (if you are unable to source the connectors etc..)

_________________
St205 WRC - Running sweet.

looking at the two processor way of doing this Chris,

I see many key inputs that are / wiill come from the ( what I'll call the slave cpu ) that I beleive would be better on the master.

firstly, gate the TDC and cam postion, to turn each engine cycle into the full 720 degrees, then deal with ignition & injector pulse as four calls through the same chunk of code and do this on the master.

by freeing injector and ignition i/o on this master cpu to be able to watch closer stop light, and throttle closed sensor. this are key things to react to, on each cycle., and doing these items along with TPS postion, AFM/MAP sensor, will allow smoothing, or jitter correction, whilst still allowing up each loop iteration, recalcualting of the next set of fire parameters.

letting the slave decide the inject and fire signals going to which plug ( or by-pass if using a dizzy ) and injector. ie. these things are slow and predictable. and other low sample rate of air temp, water temp can be done on slave.

decoding, the hardware interface on the slave, keeps the code on the master generic, and maintained irrespective of the hard interface needs. ie coil on plug or dizzy being a good example. sequential or twin or all injectors being done at same time.

other spare io on the master can allow safety watching, ie you already mentioned knock, but what about lambda and EGR temps ? these are and should be key things to alter data that is independant of the hard interfacing slave cpu IMO.

thoughts ?

_________________
--

Darryl

Interesting alternative view. Different engineers go about things in different ways.

My way of looking at it is that the ignition / injection is the high speed part of the task. Predictable, yes, slow, no. At 9K RPM 1 degree is 18.5uS. IMO it would make sense to use the faster processor for this. The dspic I've used has more timers / output compares than the pic18 so hopefully some of this will be done in hardware anyway.
Bear in mind, even the slow PIC18 is 10 times faster than the original ECU, but the original had enough hardware timer functions to remove the burden of accurate timing from software.

Also, I would like the software upgradable via the PC port. not many (if any) pic18's support this at 3.3V. Even if so, if the thinking is done in the quick one, I would then have to handle upgrading 2 chips, one via the I2C port. My plan is to put all the logic on the quick processor and make the slave an 'i/o expander' type of thing.

Unless I'm missing something, the only reason to connect the brake light to the ECU is to cut power when braking. A pain for anyone who left foot brakes (I don't). Possibly useful as a safety feature, maybe one Toyota could have donw with a couple of years ago
Throttle closed is superfluous IMO (not wired into my link ECU), this can be derived from TPS.

Looking at what I've got earmarked for the low speed chip:

RSO/RSC - idle valve. May have been better on quick chip but the I2C communication should be quick enough to get a stable idle.
INT - intercooler pump.
HT - O2 heater
TPC - boost sol. As idle, I2C delay shouldn't be a problem.
TVIS - (185 only)
FPR - (fuel pump speed)
FC - (fuel pump on/off)
THW/THA/THAM - temperatures aren't going to change that quick
Ox - (O2 sensor) - this would have gone on the quick one if there was space, however it's not a fast changing signal and may benefit from a bit of pre-processing anyway.
TE1/TE2 - may get used for other things yet.
SPD - (speed sensor) not something which affects split second decisions in the ECU. Measurement timing can be done in slave and pass a speed value.
LEV - (intercooler full)

Wideband is an extra signal which I will hopefully feed in in place of AFM to the master. I don't see any need to run the AFM even on a standard 185, the turbo pressure sensor is effectively a MAP sensor. For an application requiring AFM, then I would feed the wideband in via the slow processor and live with the delay.

p.s.
As another thought, I once did a job many years ago where I split the logic between 2 processors to get enough I/O. It was effectively an interface between 2 systems so it seemed logical to make one processor handle each, then pas information between the 2. I got my fingers burnt badly, as the system upgraded over time, I kept finding I needed to get at variables which were held on the other processor and had to keep expanding the communication between them until it became uwieldy and unworkable.
I've always avoided making the same mistake since, hence just using 1 as an I/O expander with a simple communication structure which will not need to change.

_________________
If at first you don't suck seed, try drier grain.

I would guess that stop light refers to the "your engine expired" light rather than brakes

Coolant temp would seem to be missing from the low speed input list - oil temp might be another input along with provision for fuel pressure to provide safety measures

One thing that strikes me.
Although a lot of the low speed stuff is low speed it is required for final output determination. I can see a lot of that having to be mirrored in the main calculation area. For eg water temp doesn't change quickly but it's value will be required for every injection cycle so it's value needs to be local. You can't go fetch it every cycle on I2C ......

One way I see around that is to have the secondary processor handle trim calcs based on the low speed inputs. You then only need to mirror a fuel and ignition correction in the fast loop and arrange a "background" process to update corrections in a timely fashion
This gives you the possibility of complex correction from these inputs while maintaining a fixed comms load - you only ever need to get two correction values. Downside is the correction tables are distributed across chips

My plan is to read all sensors from the slow chip in the background and store the values in local memory, the same background function will also update the outputs from local storage as to what their required state is. Full update each way will probably be every few miliseconds.

Coolant temp is THW by the way, I listed all the temperature probes on one line.

The other big thing Toyota missed IMO (not as big as fuel pressure though) was fuel temperature. A 10 degree change in this will affect mixture just as much as 10 degree air temperature. Seems strange to sense one and not the other. If you could assume fuel was the same temperature as ambient air, then you wouldn't need to make any correction for air temp. Unless, or course, the standard ECU looks at temperature rise across the turbo and just compensates for this.

My plans to monitor a wideband and cross check against target AFR table would show up fuel pressure problems and allow engine protection. Wouldn't be as quick acting as reading fuel pressure directly.

_________________
If at first you don't suck seed, try drier grain.

Assuming fuel is at ambient seems a reasonable proposition for a road car. Possibly with an offset for pumping increase. The ECU does have ambient temp (until you bin the air box and suck in all that lovely pre-warmed air

What sort of size slave mcu are you going for? (pin count wise)
I have a stack of 18F4620 (through hole of course) dunno if they would be any good for what you have in mind...

http://ww1.microchip.com/downloads/en/devicedoc/39626b.pdf

_________________
St205 WRC - Running sweet.

Bigger memory version of the 4525 I use quite a bit. Needs the LF version for running at 3.5V though.

_________________
If at first you don't suck seed, try drier grain.

ahh, I don't use the LF

_________________
St205 WRC - Running sweet.

Timescales slipping already I had a decent quantity of paying work to do so have been a bit busy to make progress on this.
Following a good discussion with Daryl and Steve in the pub last week, I have decided to revisit the knock sensor side of things. This is the main area lacking completely in most low end ECU's and where a real advantage can be gained. Accurate and reliable sensing of the very early stages of detonation and quick response will allow mapping much closer to the edge of optimium power and ecconomy knowing that the ECU will step in and save the day as it starts crossing the line.

Initial searching has shown up just one device made by TI the TPIC8101. Sadly only available in surface mount, but it is at least the old fashioned big & butch type which I can handle.
From what I can see, this device has a very narrow bandpass filter at the knock frequency (the standard knock sensor does this anyway) and then integrates the amplitude during the knock window rather than peak detecting as I have done thus far.

https://dl.dropbox.com/u/8316230/ecu/TPIC8101.pdf

https://dl.dropbox.com/u/8316230/ecu/TP ... aining.pdf

The question is which system is better ?

Some further research.

A very interesting article which pre-dates the TI chip.
http://www.ti.com/lit/an/spra039/spra039.pdf

An interesting post which incidentally throws up another chip HIP9011 which looks a direct replacement for the TI one.

http://forum.aempower.com/forum/index.php?topic=29603.0


As an aside, I remember Datajon talking about ion sensing on the spark plug. Not something I'm looking at including at this stage, but who knows in the future.

http://www.max-boost.co.uk/max-boost/in ... tation.htm

Unfortunately I haven't found any discussion about the merits of integration vs. peak detection. I would be interested to hear opinions.

My own thoughts are that a detonation will produce a single pressure wave that will produce a short sharp 'ding on the bell' i.e. a short high peak. Background noise will be fairly constant over the whole period.
So, for example, a system with 5mS knock window and a 1mS 'ding on the bell' at double amplitude of background will produce an increase of 20% on an integrated signal, thereby reducing 'signal to noise' and making the system less acurate.
On the other hand, a short transient background noise will produce less chance of a 'false alarm' on an integrated system.
Also, my experience of the Toyota sensor is that the 'ding on the bell' lasts the length of the knock window anyway.

Taking a step back & looking at the bigger picture, I would be inclined to go with an 'off the shelf' chip which can be set via software to suit any engine. If the chips available use integration rather than peak detect I suspect R&D has shown it to be the better answer.
The downside is it used SPI rather than I2C so needs 3 more pins for this, plus a pin for 'knock window' timing. I have the option of using SPI for configuration only from slave chip and use the analogue output to feed to the high speed processor.

_________________
If at first you don't suck seed, try drier grain.