CIS under the new rules

[GTIspirit]

Is the OEM DPR input pulse width modulated (PWM) or continuous? I had been thinking that we needed to give it a continuous mA signal.

The Power Module ups that DPR current a bit. I think there are half a dozen settings, but the higher ones are in the 40mA range, IIRC.

Agreed. I believe that a sufficiently negative input (don't remember how much, maybe -10, maybe -50) to the DPR does cut fuel completely, but this would have to be verified.
On the other hand, it would probably run better under racing conditions (if fuel usage wasn't an issue) if the AFR was simply maintained.

Admittedly I haven't hooked up a scope to watch the DPR current control signal, but I do believe it is a bona-fide old school current control. A duty cycle of sufficient frequency should do the same thing. At a high enough frequency, I think around 100Hz, the valve won't respond to the individual pulses. Or you could take a duty cycle output to an appropriate transistor or MOSFET to then get a straight current output to the DPR.

40mA sounds way too much considering the measurements I've made. I increased DPR current by 2mA from around 20mA to 22mA at WOT by maxing out the altitude sensor input and that was enough to richen AFR by almost one point.

I believe -50mA is the max negative current specification and I've measured around -40mA when in overrun and fuel cut is active.

Personally, I think there is very little to be gained by changing the fuel injection control system. There are various means available to reach a desired AFR, albeit by making global shifts irrespective of engine rpm. So a little chip tuning is in order to make rpm dependent adjustments.

And as people above have pointed out, there might not be much to gain from a crankfire ignition system, except to make tuning easier and to make rpm dependent spark timing changes rather than the global shift that moving the distributor makes. So it's possible that there is a little to be gained from improving the area under the curve.

[Flyinglizard]

This is exactly the technology that IT does not need. The HP increase potential cant be more than maybe 4hp at 6500.
We dont need guys with too much free time expanding the dollars vs Hp return. IMHO. Keep it cheap and simple as it was meant to be.
Go play in GT or prod.
The WOT settings can be very close to optimal, both timing and AFR. with the current low tech systems. We dont care about cruise or boost /timing ratios.

[GTIspirit]

This is exactly the technology that IT does not need. The HP increase potential cant be more than maybe 4hp at 6500.

Sorry, but the genie is out of the bottle with the open ECU rule. There is no denying that fact. So why shouldn't everyone be able to ask the genie for a wish, not just the few who play with a newer car that already has a crank trigger? Just asking for a level playing field......

If the comp board follows through on the proposal for competition adjustments then this becomes a moot point because then it doesn't matter if so and so engine can achieve the theoretical power multiplier since the weight will be adjusted to balance out over and under achievers.

[Eric Parham]

The HP increase potential cant be more than maybe 4hp at 6500.

I was thinking 1 or 2, but 4 could be night and day! Thanks for the extra carrot

We dont need guys with too much free time expanding the dollars vs Hp return.

Free time? Never even met her; and if I did, it wasn't me. Anyway, the plan is less $ for more hp -- hence the hope to use MegaSquirt rather than anything proprietary.

Personally, I think there is very little to be gained by changing the fuel injection control system. There are various means available to reach a desired AFR, albeit by making global shifts irrespective of engine rpm. So a little chip tuning is in order to make rpm dependent adjustments.

Well, even if that's all we get, a tad wider torque band and not having to pay for chip tuning (and/or be at the mercy of the chip tuner) would seem worth it to me.

And as people above have pointed out, there might not be much to gain from a crankfire ignition system, except to make tuning easier and to make rpm dependent spark timing changes rather than the global shift that moving the distributor makes. So it's possible that there is a little to be gained from improving the area under the curve.

Ditto.

Sorry, but the genie is out of the bottle with the open ECU rule. There is no denying that fact. So why shouldn't everyone be able to ask the genie for a wish, not just the few who play with a newer car that already has a crank trigger? Just asking for a level playing field......

Indeed. In fact, it would likely be cheaper for most in the long run just to allow free inputs/sensors and a common set of outputs/actuators, rather than force some into these silly work-arounds just because they happen to be trying to make use of an older (generally cheaper) platform. Sometimes it seems like every other kid on VW Vortex has tossed CIS for MS with EFI injectors, obviously because it's less expensive and has a more predictable outcome than trying to re-map the ancient CIS. I fully believe that as soon as someone spends the time to finally get CIS up to speed (assuming that's possible), many nay-sayers will suddenly change their minds and want everyone on EFI -- probably even the carbed cars. If that decision is going to be made, I only hope that it's sooner rather than later.

If the comp board follows through on the proposal for competition adjustments then this becomes a moot point because then it doesn't matter if so and so engine can achieve the theoretical power multiplier since the weight will be adjusted to balance out over and under achievers.

I agree to a point. I think allowing a more even starting point would likely make competition adjustments easier, if only because the theoretical formulas would then be slightly closer to reality. I think some competition adjustments would still be necessary if the ultimate goal is really to level the playing field within a very finite number of classes.

[GTIspirit]

Well, even if that's all we get, a tad wider torque band and not having to pay for chip tuning (and/or be at the mercy of the chip tuner) would seem worth it to me.

Who said anything about having to pay or be at the mercy of the chip tuner?



Well, ok, the pay part will cost me as it's near impossible to decipher the contents of that PROM chip without the code to know what data is used for what purpose. Nothing an EEPROM emulator can't fix.

It is my Don Quixote quest to prove that CIS-E rocks and the only reason people discard it for MS is because they can't tune it as easy as MS.

[Eric Parham]

Oh, that's better Unfortunately, I'm jaded by previous experience. Assuming you can't get hold of some insider info (e.g., source), or someone else hasn't deciphered it before and documented the map, just figuring out what's what could take weeks. Also, since the new rules already allow an all-encompassing ECU, why tune the fuel map without connecting the dots for the ignition map as well? I just wouldn't want to leave anything else on the table.

[shwah]

BTW I have hooked up a scope to the dpr. It is bonafide simple continuous current signal.

[GTIspirit]

Anyone familiar with MCS-48? The big Philips chip in the above picture is an Intel 8049. The PROM to the side is a N82S129/DM74S87. The PROM only contains 256bytes of data in four bit words. Just sixteen lines, how hard can it be to figure out without code? Just take a best guess, change some stuff, and see what happens. Of course not on the car....

BTW I have hooked up a scope to the dpr. It is bonafide simple continuous current signal.

No problem, a duty cycle of sufficiently high frequency will be the same thing, say well above 100Hz.

As a result of the small electromagnetic time constant and the small masses to be moved the actuator reacts very rapidly to voltage changes at its input terminals. The cut-off frequency is well over 100Hz.

Top of page 9 of the above referenced paper, SAE paper 820253 http://papers.sae.org/820253. Well worth the purchase price if you really want to know the intimate details of KE-Jetronic.

[shwah]

what frequency does the pwm for an electronic fuel injection system run at?

[Eric Parham]

Generally less than 100 Hz and varies with engine speed. Can depend on whether simultaneous/batch, banked, or sequential, but I think the max is twice per crank rev. If we assume for the moment that 200 Hz is needed, that would only be met at or above 6000 rpm.

There's probably a way to use the boost control in MSExtra to control it open-loop, but that's only a 6x6 table -- probably too coarse. For the frequency valve of CIS-Lambda, see this interesting thread: http://www.msextra.com/forums/viewto...it=cis#p232211

Now back to CIS-E and/or CIS-Motronic. To use the much higher resolution MS fuel maps, there doesn't seem to be any way to get a mA current signal directly out of MS. I'm now exploring whether we could integrate EACH individual injector pulse from MS and update a continuous mA current signal according to the measured duration.

[GTIspirit]

There's probably a way to use the boost control in MSExtra to control it open-loop, but that's only a 6x6 table -- probably too coarse. For the frequency valve of CIS-Lambda, see this interesting thread: http://www.msextra.com/forums/viewto...it=cis#p232211

Now back to CIS-E and/or CIS-Motronic. To use the much higher resolution MS fuel maps, there doesn't seem to be any way to get a mA current signal directly out of MS. I'm now exploring whether we could integrate EACH individual injector pulse from MS and update a continuous mA current signal according to the measured duration.

This is a good discussion we've got going, gave me an idea I didn't think of earlier regarding MS and control of the DPR.

Anyone know the frequency on the MS boost control output or the duty cycle output?

Rather than re-writing the fuel control functions to control the DPR, just take the pulsewidth output and port it straight over to a duty cycle output, such as the boost control or so-called "Dwell duty %" output.

Then all the tables are tuned in a virtual percentage, e.g. 0%=0us and 100%=100us, or if a different resolution was required this could be scaled by a multiplier. In effect, what I'm thinking is Injector pulsewidth=duty cycle input of either the boost control or duty cycle function. So that instead of using the 6x6 table the output of that table comes from the existing fueling functions. This should actually be pretty easy to do with basic knowledge of C-code. Hmmm.

[Eric Parham]

Anyone know the frequency on the MS boost control output or the duty cycle output?

Don't know yet. I think I read that it was a voltage output that would need to be converted to frequency.

Rather than re-writing the fuel control functions to control the DPR, just take the pulsewidth output and port it straight over to a duty cycle output, such as the boost control or so-called "Dwell duty %" output.

Pulse-width, yes; but not the current RPM-dependent output waveform. That is, if you mean the main fueling or injector signal from MS, I don't think that signal really represents what we need, since it would increase drastically with RPM. Assuming that the CIS metering valve is still connected to the CIS metering plate (most likely required, because I don't think the DPR has enough range/resolution to do the whole job by itself -- although I might be wrong -- does that SAE paper mention the min/max input range?), that would mean that our fueling would be proportional to RPM squared rather than just RPM. The MS signal that contains the most usable info, but currently in the wrong form, is the injector pulse-width itself (which only changes with RPM for fine-tuning, but isn't the main RPM compensation). I think that the CIS metering plate should remain the *primary* RPM-dependent compensator.

Then all the tables are tuned in a virtual percentage, e.g. 0%=0us and 100%=100us, or if a different resolution was required this could be scaled by a multiplier. In effect, what I'm thinking is Injector pulsewidth=duty cycle input of either the boost control or duty cycle function. So that instead of using the 6x6 table the output of that table comes from the existing fueling functions. This should actually be pretty easy to do with basic knowledge of C-code. Hmmm.

I haven't even used MS yet (but will be buying one or two soon), so I might be misunderstanding something here. Again, I agree to a point if we could use the injector pulse-width itself, but the output signal is actually an RPM-dependent waveform (with significantly increasing duty cycle as RPM rise). Or, do you think the DPR could handle the whole job by itself without relying on the CIS metering plate (e.g., disconnect it from the metering valve, or lock the plate all the way up if another MAF is added. . .)? Even if the MS injector pulse-width could be used as the direct input to the 6x6 boost map (can it?), aren't we then limited to 1 of 6x6=36 possible outputs? Hmmm . . . Maybe that IS enough. Finally, what do you mean by "Injector pulsewidth . . . input of . . . duty cycle function". Is that something that MS can already do without using a map?

EDIT: Oh, you mentioned C code. Can we write our own functions in C for MS? If so, that might actually be the best solution. I don't suppose my ancient C 6.0 compiler would do the job... What chip for MS3? Is there a development structure/environment?

EDIT #2: I have to tell you that I'm not very comfortable with the idea of providing a PWM input to the DPR, even if it seems to work, due to longevity concerns. A passive filter might "fix" it, but the time constant required for low-RPM might introduce unnecessary delay at high-RPM. An active filter might be necessary.

[shwah]

There's probably a way to use the boost control in MSExtra to control it open-loop, but that's only a 6x6 table -- probably too coarse.

Considering that the flowplate is still providing a gross map based on mass air flow, and we are talking about a 'fuel trim', which is in a 1x2 table today with the cts resistor approach, it seems this would still represent progress.

[Eric Parham]

Considering that the flowplate is still providing a gross map based on mass air flow, and we are talking about a 'fuel trim', which is in a 1x2 table today with the cts resistor approach, it seems this would still represent progress.

I think the CTS resistors, altitude resistors, and/or Power Module hacks effectively just change one or two values that we think about, but remember that the CIS-E/Mot metering plate basically rides in a single-slope cone (unlike the fancier early CIS/L cones, and there was no fancy CIS-E/Mot cone for US 16V engines, AFAIK -- although I've seen a "Euro" one from VWMS back in the day, which would have cost more than my whole car at the time). So, the stock CIS-E computer is still changing trims several times to compensate for the missing slope changes. With MS, we're talking about nixing the stock computer, so we'd no longer have those stock values either. Thus, 6x6, where one axis is rpm and the other axis is phantom injector duration (assuming looping that pre-output back as an input within MS is already possible), would basically allow only 6 different mA settings within each 1200 rpm band. Hmm . . . so I guess you're right -- it might just be an improvement. But, I sure would like to see a little bit more for our efforts.

EDIT: You know what -- I think it's worth trying! Since the boost control output is already supposedly a piece-wise continuous voltage, and we know the resistance of the DPR (18-20 Ohms?), I think we might already have our continuous mA current output without worrying about the effects of PWM on the seemingly fragile DPR bi-metal actuator.

[GTIspirit]

Pulse-width, yes; but not the current RPM-dependent output waveform. That is, if you mean the main fueling or injector signal from MS, I don't think that signal really represents what we need, since it would increase drastically with RPM. Assuming that the CIS metering valve is still connected to the CIS metering plate (most likely required, because I don't think the DPR has enough range/resolution to do the whole job by itself -- although I might be wrong -- does that SAE paper mention the min/max input range?), that would mean that our fueling would be proportional to RPM squared rather than just RPM. The MS signal that contains the most usable info, but currently in the wrong form, is the injector pulse-width itself (which only changes with RPM for fine-tuning, but isn't the main RPM compensation). I think that the CIS metering plate should remain the *primary* RPM-dependent compensator.

Maybe I wasn't exactly clear. I didn't mean to take the injector output signal, not the physical signal. I was thinking to take the global variable in the code, whatever it's called, for argument sake, let's call it InjVlvPW for injector valve pulsewidth. Make that a global variable so it's available to other functions, and break the connection to the power stage so the injector pulsewidth doesn't go to the drivers. Then instead of taking the output of the 6x6 map for boost control, break that connection in the code so that InjVlvPW takes the place of that output and then goes to the duty cycle driver.

BTW, all modern engine control systems I know of don't use current control, they use a duty cycle to simulate a current. At a high enough frequency the valve doesn't know the difference.

So now with the above change, you'd have to use the throttle plate for open loop fueling, the gross fueling because as was just commented, the DPR current isn't intended to provide full range of adjustment, only a trim. The throttle plate also becomes the MAF input to the fueling functions above, though alpha N might be a better choice.

The more I think about it the more I'm liking this solution. I'll have to see if I can look into the details and sketch up the code changes that might be necessary.

[pfcs]

Not that I don't think you're re-inventing the wheel or spinning them, but a simple LC circuit would output DC if the frequency wasn't too low.
Then, if the DPR resistance is 20 ohms, 1.0v=20mA @100% duty cycle.
Aaah! Not thinking! There would be lag from the capacitance.
Oh well, you guys figure it out. But then....if the cap was small enough................Digifant anyone?

PS: consider that some time spent with a test bench and an eprom emulator would probably be fruitful.
Chop up a CIS E harness. Provide power, warm coolant sig, WOT sig, and a 20 ohm bulb instead of DPR-or maybe 2 bulbs, each thru a diode of opposite polarity. Use a freq generator to input RPM. You really only need to find full load tables so it's not quite a needle in a haystack situation. Look thru the chip's files for a series of rising values as you read across in base 10. Edit a middle value to zero. As you quickly twist the freq knob to the test bed, a bulb will glow when you go thru a very lean or rich point. Once you find one place in the file that affects the output, see if it applies to a certain range of rpms (usually 500-800). If you've hit paydirt, you'll probably find that the next higher bin applies to the next rpm range, etc. You can map your chip pretty fast once you find that first bin. And the stock ECU is damn good, I think.

[GTIspirit]

PS: consider that some time spent with a test bench and an eprom emulator would probably be fruitful.
Chop up a CIS E harness. Provide power, warm coolant sig, WOT sig, and a 20 ohm bulb instead of DPR-or maybe 2 bulbs, each thru a diode of opposite polarity. Use a freq generator to input RPM. You really only need to find full load tables so it's not quite a needle in a haystack situation. Look thru the chip's files for a series of rising values as you read across in base 10. ....And the stock ECU is damn good, I think.

Exactly my thoughts, which is why I was working on this, finally completed. :026: I think that KE-Jetronic has gotten a bad rap because no one realized it has a chip, until now, and most people just throw on the Megasquirt. I believe in the goodness of the KE-Jetronic and so I'll be putting this to good use to decipher the data on the chip to get more fueling exactly where I need it in the rpm range.



Build your own KA-KE-CIS2 Breakout box, or, how to fit 10lbs of stuff in a five pound box.

Detailed pictures of the breakout box build can be found here:
http://s27.photobucket.com/albums/c1.../Jetronic_BOB/
ECU connector actually came from a Digi 2 harness, so this breakout box is actually good for more than just KE-Jetronic, woo hoo!

[pfcs]

Nice job, but how does it work? I expect the pin-outs are taps on each circuit of the multi-plug. Why the second female ECU multi-plug and what's your plan?

[GTIspirit]

The breakout box inserts between the vehicle side ECU connector and the real ECU. What looks like an ECU in the picture above is really just a shell, simply to connect all 25 wires to the length of harness and get the ECU connector. The ECU shell plugs into the vehicle in place of the real ECU and then the cable sleeved wire is long enough to place the breakout box in the passenger compartment. The real ECU will connect to that small pigtail. That way I can drive around with the hood closed and make measurements. In making this I realized that probably every early VW ECU with 25pin connector is compatible. The donor ECU for that side of the connector came from a Scirocco 16V, sometimes referred to as KA-Jetronic. The harness side connector actually came from a Digi 2 engine harness. I made sure that the breakout box contained all the circuits, since not all of these ECU's use all the circuits, and some are tied together internally. So I can actually use this on a lot more VW ECU's than I thought.

For sure, a lot of work, but I'm not a software engineer and so it's easier for me to decode the contents of the PROM chip than it is for me to modify MS code to control the DPR valve.

[VWralley]

"Any ignition system which utilizes the original distributor for
spark timing and distribution is permitted. Internal distributor
components and distributor cap may be substituted. Crankfire
ignition systems are prohibited unless fitted as original equipment."

So as long as the ignition uses the distributor, you are allowed to run anything to control it?