DIYEFI.org Forum
http://forum.diyefi.org/

Fred's firmware development diary comments thread
http://forum.diyefi.org/viewtopic.php?f=8&t=58
Page 35 of 35

Author:  Fred [ Wed Mar 30, 2016 9:52 am ]
Post subject:  Re: Fred's firmware development diary comments thread

Keen, but I have my reasons not to. I will once the inertia is there, though. Mean while, those who need it have it, more or less.

Author:  ruzki [ Wed Mar 30, 2016 9:58 am ]
Post subject:  Re: Fred's firmware development diary comments thread

Nah! it´s not working correct.
There is only one fixed duty for all Temperatures no matter what numbers i set.
No Units are showed.
I can not set the Frequency.

closed loop would be great but with adaptive idle advance ..

btw. RPM based dwell adjust would be great...

Author:  Fred [ Thu Mar 31, 2016 9:41 am ]
Post subject:  Re: Fred's firmware development diary comments thread

Ummm, OK, something's wrong, then. Worked for me. I will take a look for you soon.

RPM based dwell is there, but you can only have that OR battery based. Why do you want that? Running into dwell time limitations? If so there is a better feature for that.

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

Fred.

Author:  ruzki [ Thu Mar 31, 2016 1:36 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

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 :indiff:

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 @12V
dwell @300 rpm is 20ms @10V
dwell @850 rpm is 3,5ms @13,8V
dwell @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.

for you pain to do and for me impossible :mrgreen:

Author:  Fred [ Fri Apr 01, 2016 12:10 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

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.

Happy to help, though. What frequency do you want?

Fred.

Author:  Hentai [ Fri Apr 01, 2016 3:28 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

Figured I posted these two to for the current talk on dwell and cranking

Image
Image

Author:  Fred [ Sun Apr 03, 2016 2:55 am ]
Post subject:  Re: Fred's firmware development diary comments thread

Interesting data! Thanks for posting it up! :-)

Author:  ruzki [ Thu May 12, 2016 7:37 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

Great post Hentai ! Thank you !
This is exactly what i have measured.

Georg

Author:  walinsky [ Mon Mar 20, 2017 12:01 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

viewtopic.php?f=8&t=57&start=970#p43470
Two hotglued inline sixes FTW.
They were never hot performers; but boy: do they look great!

Author:  Fred [ Mon Mar 20, 2017 7:51 pm ]
Post subject:  Re: Fred's firmware development diary comments thread

Silky smooth 330hp and a slush box of more smoothness should be a good match for a tired 244 :-D

Page 35 of 35 All times are UTC [ DST ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/