as you remember, i had to merge two codes together.One code had the improvements in the wheel decoder and the other had idle.Maybe something went wrong by merging this two together

Quote:

RPM based dwell is there, but you can only have that OR battery based. Why do you want that?

AND would be good .. why? because it would improve cold starts especially when car is running on e85.I was messing around with cold start for years until i found out that my orig. ecu has this feature. dwell @300 rpm is 15ms @12Vdwell @300 rpm is 20ms @10Vdwell @850 rpm is 3,5ms @13,8Vdwell @850 rpm is 5ms @12V

Quote:

I think you're wrong about the frequency, but I will admit that it's a horrible pain to do.

I had not remembered that, but good for you! It's possible you did, or maybe I'm wrong. Or maybe something else. We'll sort it out.

I see. That's an interesting problem, and one worth modeling properly. I've thought about it before, but I hadn't thought about it in the context of cold start, and higher potentials required to jump the gap then. What we've got for a given coil is an operational space in 2D dimensioned by Voltage and Dwell, with an output of HT Voltage and energy, dumped into a spark over a period of time determined by a number of factors. Where in this space we can run has a number of bounds. First is the hard bound, we can't dwell our coil past saturation or it'll cook in short order, or burn out a driver. The next bound is thermal, how much energy is lost into the coil, and how quickly it's dissipated for the given installation environment. The higher the dwell, the closer to this wall you get, often reaching it prior to reaching saturation if operated in a sustained fashion. The final bound is an acceptable ignition probability level, which at low cylinder pressures such as idle or overrun, can be obtained with as little as 0.5ms on a modern coil. Raise the cylinder pressure a bit and you suddenly need more dwell to generate enough Voltage to jump the gap.

Re frequency, the pain levels are two fold:

1) Raw interface to the registers requires some basic math to be done to figure out the frequency from the parameters supplied to the module in the MCU. This is a pain, but not too bad if you are doing it in source and have the manual open.

2) Doing it in hexadecimal using a bad quality editor in a bad quality tuner. This is a pain, no matter what you're editing. The process is something like: Find which block your config is in. Find the ID of that block. Find the offset in that block. Find the conversion from real unit to stored integer/bits/whatever and then from that to hex, enter the hex, flash it, reset it, see if it worked.

1 can be solved with a little more abstraction (yet to be done), 2 requires a lot more work to improve, however if 1 is sorted, then 2 is easier, too.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum