EFI University
Electronic Fuel Injection Tuning Forum
|
| View previous topic :: View next topic |
| Author |
Message |
Pantera EFI
Joined: 12 Feb 2005
Posts: 1266
Location: So. California
|
 Posted: Thu Jun 26, 2008 10:31 am Post subject: The Spark Instant, Injection Instant, etc. LAG and JITTER |
 |
|
A great amount of interest has been seen in the ability to
measure the occurrence of "Lag & Jitter" within an EMS.
I believe that EFI101 members could all take part in an agreed
method to test for the anomaly.
A standard needs to be set!
So, I ask, what would be an easy, accurate, field test, method ?
Lance |
|
| Back to top |
|
 |
Turboivo
Joined: 09 Mar 2006
Posts: 669
Location: Bulgaria
|
| Posted: Thu Jun 26, 2008 2:26 pm Post subject: |
|
|
Great idea Lance!
So, here is my proposal :
1. Two standart multitooth discs patterns- 36-1 and 60-2
2. As RootesRacer suggested in one of the deleeted threads - testing at few fixed advance angles between 2 teeth but not 10, 20 or 30 degrees for 36-1 and not 6, 12, 18, 24... degrees for 60-2 wheel.
3. Fixed or maped dwell??? or CDI?
4. If strobe light is used it should be set at 0 (no delay) so there should be visible degree markings on the crank pulley or on the flywheel. Same about the stationary markings.
5. If 2 channel scope is used there should be the multitooth pattern as well as one of the ign. channels.
6. RPM range from idle (about 1000min-1) to 5-6K. Acceleration rate - fastest possible by hand/foot. No gear engaged or dyno run.
7. Sequentional ignition ? |
|
| Back to top |
|
|
furpo
Joined: 06 Aug 2004
Posts: 1082
Location: Mt Maunganui, New Zealand
|
| Posted: Thu Jun 26, 2008 4:27 pm Post subject: |
|
|
I would think that we would be better off by generating a signal rather than using a trigger wheel. The ECU would be bench tested rather that tested in situation.
As we generate the signal we can provide a TDC reference to a scope. To shift the trigger wheel position we can just shift the TDC signal and modify the timing offset in the ECU.
I am not up to date with electronic testing standards. Is there an accuarcy standard which can be modified? What does the Alexander Long patent state to measure increased accuarcy?
Roger
_________________
don't mind me, i always need help |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Thu Jun 26, 2008 5:03 pm Post subject: |
|
|
| furpo wrote: | I would think that we would be better off by generating a signal rather than using a trigger wheel. The ECU would be bench tested rather that tested in situation.
Roger |
I disagree, ALL systems like this function GREAT with generated input triggers, this is where they really shine.
You will never see anything remarkable as far as inaccuracies go with a generated trigger waveform, its a dynamic waveform that makes the system inaccurate or more specific, variation in rotational rate across a single revolution, or partial revolution. It its precisely the variation in rate that causes the problem, eliminate the variation with a generated trigger and you prove nothing other than the ECU is functional.
Its when you give the ECU a waveform that comes from a real engine, particularly one with low rotational mass that you see timing scatter and acceleration lag/deceleration lead. |
|
| Back to top |
|
|
furpo
Joined: 06 Aug 2004
Posts: 1082
Location: Mt Maunganui, New Zealand
|
| Posted: Thu Jun 26, 2008 5:14 pm Post subject: |
|
|
Surely with a generator you can simulate this. You can put a fixed acceleation rate in and it will do it.
Roger
_________________
don't mind me, i always need help |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Thu Jun 26, 2008 5:25 pm Post subject: |
|
|
| furpo wrote: | Surely with a generator you can simulate this. You can put a fixed acceleation rate in and it will do it.
Roger |
Yes, you could frequency modulate the trigger, but you would have to be careful to synchronize the modulation with the cam or crank "synch" event.
In the end someone would complain that the test is not real world since it doesnt control the prime mover (engine) as a closed loop system does.
I would subscribe to this method if a clear rotational model specification could be specified. |
|
| Back to top |
|
|
scottieFAST
Joined: 14 May 2005
Posts: 52
Location: rio rancho, nm
|
| Posted: Thu Jun 26, 2008 10:27 pm Post subject: shiz |
|
|
What about testing it on an engine?
_________________
Peace,
Scottie
Motiva Performance Engineering
2420 Comanche Rd. NE Suite H-3
Albuquerque, NM 87107
505-883-8388 |
|
| Back to top |
|
|
Turboivo
Joined: 09 Mar 2006
Posts: 669
Location: Bulgaria
|
| Posted: Fri Jun 27, 2008 12:08 am Post subject: |
|
|
| Quote: | | You will never see anything remarkable as far as inaccuracies go with a generated trigger waveform, its a dynamic waveform that makes the system inaccurate or more specific, variation in rotational rate across a single revolution, or partial revolution. It its precisely the variation in rate that causes the problem, eliminate the variation with a generated trigger and you prove nothing other than the ECU is functional. |
Completely true. When an engine runs, time between teeth is changing all the time. It's surprise when you swap your test bench with an engine and your ECU works like scrap. When a cylinder misfires or gets late/early advance it slows/accel. the rotation speed. Same when compression/work cycles are passing. This could not be imitated on a test bench. One last drawback is when on test bench(signal generator) yor standalone sees only rpm changing. All other inputs are constant. |
|
| Back to top |
|
|
alexander
Joined: 15 Aug 2006
Posts: 154
Location: California
|
| Posted: Fri Jun 27, 2008 1:01 am Post subject: |
|
|
| Turboivo wrote: | | When a cylinder misfires or gets late/early advance it slows/accel. the rotation speed. Same when compression/work cycles are passing. This could not be imitated on a test bench. |
Of course it can; you just need a simulator that provides that as a parameter.
After the infamous last jitter thread, I've been working on a set of crank simulation software/hardware that allows you to model all sorts of different situations (e.g. misfires, asymmetric crank triggers, misshifts/mechanical overrev). I've even been looking at some form of closed loop modeling; with fuel injector/ignition events feeding back into the system (for measurement, or parameter tweaking).
None of it's done/working, but it's been putting my thoughts that direction. It would be nice to have something that flexible. |
|
| Back to top |
|
|
Turboivo
Joined: 09 Mar 2006
Posts: 669
Location: Bulgaria
|
| Posted: Fri Jun 27, 2008 1:40 am Post subject: |
|
|
| Quote: | | It would be nice to have something that flexible. |
Yes, it would be... BTW think the big manufacturers of EMS for automotive industry should have that kind of high-end simulation software. What about the firms in standalone market? |
|
| Back to top |
|
|
MRMRacing
Joined: 23 Jun 2008
Posts: 11
|
| Posted: Fri Jun 27, 2008 6:26 am Post subject: |
|
|
I have a test simulator with elctronical signalgenerator (gas pedal for rpm) for most trigger patterns, but some things like transienthandling and deceleration is not working on the bench. Andvanced systems use fuzzy logic and it acts different in real world. So some testings I had to give up and use on an engine instead. Also alot of other parameters is involved in timing, some use the software to "predict" and help the tooth reading specially when there are few teeth. Other parameters like ignition advance during acceleration may be built in and not software selectable.
I would use an engine running 60-2 and use extra sensor (pulse per cycle/36-1/60-2 and more) connected to the tested ECU and logg the scope with the missing teeth from the running ecu. The you get an accurate reference point. And if selecting non sequential ignition meaning you use distributor most system will generate spark without the cam sensor connected. Just power them up and wire the crank sensor, easy set up but you need alot of different ECU's
Just my idea... |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Fri Jun 27, 2008 7:35 am Post subject: |
|
|
| MRMRacing wrote: | I have a test simulator with elctronical signalgenerator (gas pedal for rpm) for most trigger patterns, but some things like transienthandling and deceleration is not working on the bench. Andvanced systems use fuzzy logic and it acts different in real world. So some testings I had to give up and use on an engine instead. Also alot of other parameters is involved in timing, some use the software to "predict" and help the tooth reading specially when there are few teeth. Other parameters like ignition advance during acceleration may be built in and not software selectable.
I would use an engine running 60-2 and use extra sensor (pulse per cycle/36-1/60-2 and more) connected to the tested ECU and logg the scope with the missing teeth from the running ecu. The you get an accurate reference point. And if selecting non sequential ignition meaning you use distributor most system will generate spark without the cam sensor connected. Just power them up and wire the crank sensor, easy set up but you need alot of different ECU's
Just my idea... |
Lets not over-complicate this, what we need is something that models an engines rotational rate open loop, we are trying measure static and dynamic timing accuracy, not test an ECU's tuning.
After thinking more about it, I am beginning to think about Furpo's suggestion, and to specify a purpose built signal test generator which meets this groups requirement.
therefore I suggest the following:
1) A device that will output a programmed timing wheel digital pattern as a hall output (0-5v). Tentative patterns are 60-2 and 36-1 as these the most common crank synchronized triggers.
2) Device shall output a 1 tooth wide synchronization pulse at the beginning of the devices 720 degree pulse stream, this output shall be used for synchronizing oscilloscopes independent of the ECU, and may be optionally used by the ECU for cycle synchronization. the phase polarity of this output shall be the opposite of the crank pattern output so that its rising or falling phase is 180 degrees out relative to the crank pattern waveform, thus insuring reliable synchronization, should it be used in the ECU.
3) Device shall model "crank synchronized" sinusoidal rotational speed variations, with some random rate variation consistent with real world low mass engines. A captured crank waveform could be used as the basis for this feature. I suggest a 4 cyl model becuase the sinusoid is simpler.
4) Device shall model an engine accelerating and decelerating at a constant rate in RPM/sec/sec. This control should be in the form of a potentiometer controlling the rate, and a push button switch shall be the trigger, where off is decel to idle, on accel to max RPM limit.
Thats all I can think of for now, this generator could be constructed using some off the shelf computer board, and its function would mainly consist of software. |
|
| Back to top |
|
|
furpo
Joined: 06 Aug 2004
Posts: 1082
Location: Mt Maunganui, New Zealand
|
| Posted: Fri Jun 27, 2008 2:52 pm Post subject: |
|
|
Unfortunately I have not an electronics expert so can not provide any practical input as to how to build a signal generator.
My background is in concrete durability research. The biggest criticism of research is that the methodology is neither repeatable nor reliable.
I would have thought that the most important parameter is the reliability and the repeatability of the test to avoid the results being dismissed. The ability to record and reply a signal as many times as you want would be handy to test a given ECU under the exact same conditions.
Roger
_________________
don't mind me, i always need help |
|
| Back to top |
|
|
wroom
Joined: 23 Jun 2008
Posts: 7
|
| Posted: Fri Jun 27, 2008 4:29 pm Post subject: |
|
|
| furpo wrote: | | I would have thought that the most important parameter is the reliability and the repeatability of the test to avoid the results being dismissed. The ability to record and reply a signal as many times as you want would be handy to test a given ECU under the exact same conditions. |
Good point. A proof without repeatability is no proof.
But one could also argue that a more practical test bench with an engine could show repeatability in a behaviour, although it is impossible to get "bitexact" repeatability in the tests.
When testing something, one has to think about what aspect to look for in the test.
Looking at testing different ECUs interpretation of sync inputs, and producing strobes for ignition and injection - Then it may be the aspect of testing the systems in paralell that is most important. "How do the different systems respond to the exactly same dynamic condition"?
And that bitexact repeatability of a specific logged test pattern stimuli and response may be less important.
Is the test purpose to show repeatability in response to a dynamic condition?
Or is it to show that the systems response to a dynamic condition is correct?
Then, how to define "correct response"?
To do that, one has to know and understand the operational paradigm that the system is designed for. And one may also need to know a little about the internals of the system to prove if the system is giving the correct response or not.
And for commercial systems this information might be near impossible to get at.
One has also to take into consideration that different ECUs have different "realtime bahaviour". So there will be differences caused by when things are calculated, and how often, and also if there is a priority queue that affect the output because of how the ECU decides how important different tasks are.
So the realtime behaviour is partly what we want to know from the test. And partly a more or less unknown factor for what result we will get.
So, when testing a "black box" system that has operational mechanisms that are unknown, it is very difficult to verify the correctness of the a certain test output.
Say that we where to test a points ignition system in paralell with an electronic dwell ingition system that operate from a hall sensor.
The points will move somewhat linearly with the engine speed, and the electronic dwell ignition will act from a trigger event at a certain time, and calculate the engine speed from the trigger frequency. (And maybe also from the trigger frequency rate).
It is easy to see that if the clutch is disengaged during the dwell cycle, the points ignition will output a dwell time that relates to a drop in rpm during the dwell time, but that the electronic dwell ignition will go on it's timer and output spark earlier than the points ignition.
And another electronic dwell ignition system may well look at another trigger event after the one that initiated the dwell cycle and reasess the timeout of the ongoing dwell cycle based on a new calculated rpm.
Yet another electronic ignition system may reasess the timeout of the dwell cycle on both measurements of different frequency before and after the dwell cycle was first initiated, and also on different rate of rpm. Even more complicated - The system may take into consideration the mass dynamics of the engine, and possibly rule out a certain indata as being a sensor error because of the impossibility of the engine accelerating/decelerating that quick. And so on...
And the system may take care of minimum dwell for proper combustion, which will affect the ignition timing. And the system can follow the paradigm to maintain cylinder balance by f.ex. maintaining the same ignition point over a full engine cycle, or it may follow the paradigm to achieve fast response to the dynamic operating conditions. Or maybe it evaluates knock sensors, ion sensors, or any other functions that may be in the control loop.
So, the point is that we are looking at a nonlinear dynamic system, and want to asess the correctness of a variety of different real time control systems that we can know for a fact will respond differently.
So the value in looking at the result of running a static test pattern is small, and possibly misleading.
Conclusively:
What need to be assesed in the test, is the correctness of the systems response from a known stimuli, based on full knowledge about what should be expected. And not that two systems produce bitexact test logs.
Therefore i think the best test setup may be running different systems in paralell on stimuli from a real engine. And that one can change which of the systems that will actually control the engine.
By running the systems on a real engine, a variety of, (real), test cases can be processed. And by running the systems in paralell, one can look at the test log to see how they react to the same test stimuli. |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Fri Jun 27, 2008 11:32 pm Post subject: |
|
|
wroom,
Not sure exactly what you are trying to say in your post, its pretty wordy and covers a lot more that what most of us have in mind.
To reiterate, MOST of us want to see the ignition timing accuracy of an ECU under real world idle, and accelerating conditions. This is the point of contention, nothing else.
We assume that the ECU more or less does the right thing with respect to its sensory input, what is needed is to qualify the trigger related timing errors. This is the fundamental to timing accuracy.
If a set of trigger waveforms can be digitally generated, either through an accepted synthesized pattern, or through a direct digital recording, that signal can be played/played back over and over without depredation or need to run parallel systems for direct comparison.
I would be happy with a micro-controller based generator that has a repeating synthetic trigger set, which simulates varying idle speed, and throttled engine acceleration rate.
In short what I do care about is the spark instant timing.
What I dont so much care about is dwell control, control algorithms ETC, these parameters are too subjective, and compare apples to oranges. |
|
| Back to top |
|
|
scottieFAST
Joined: 14 May 2005
Posts: 52
Location: rio rancho, nm
|
| Posted: Sat Jun 28, 2008 11:37 am Post subject: timing scatter |
|
|
I still like the idea of using an engine.
_________________
Peace,
Scottie
Motiva Performance Engineering
2420 Comanche Rd. NE Suite H-3
Albuquerque, NM 87107
505-883-8388 |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Sat Jun 28, 2008 12:54 pm Post subject: Re: timing scatter |
|
|
| scottieFAST wrote: | | I still like the idea of using an engine. |
Using an engine IS the bottom line, but for apples to apples timing comparisons, you need a repeatable test for non subjective results.
If someone just posts a video showing the timing jumping around, people will step forth with all sorts of reason the video, the triggering, the engine and the test is flawed.
Put two ECUs on the same exact trigger waveform and all the above banter will melt away. |
|
| Back to top |
|
|
MRMRacing
Joined: 23 Jun 2008
Posts: 11
|
| Posted: Sat Jun 28, 2008 2:35 pm Post subject: Re: timing scatter |
|
|
| scottieFAST wrote: | | I still like the idea of using an engine. |
Yes this is right, the crankshaft is accelerating and deceleration during the crank turn, no simulator can reproduce this, (I am not an electrical engineer but beleive so) using an real engine doing this with two systems at the same time you can still get an accurate comaprision. Smart systems do more than just count teeth so using a signal generator will not work. |
|
| Back to top |
|
|
Turboivo
Joined: 09 Mar 2006
Posts: 669
Location: Bulgaria
|
| Posted: Sat Jun 28, 2008 3:26 pm Post subject: |
|
|
I'm not a proffesional in that matter like you guys, but still dont get the point of not testing on real engine. If tooth wheels are the same, if there is cam synchronization, same ign. advance and almost same rate of accel/decel of same number cyl. engines then both ECUs timing accuracy will depend exclusively on code used. Isn't that correct enough for our tests?
Today we made more precise test on our 1.6L Lancia NA engine with 36-1 wheel and sequential ign/inj. Whole ign table was set to 13 degree advance. We used Ferret 84 timing light set to "zero". We've got repeated visible approx 2 degree retard during free acceleration(no load and 70-80%TPS) from idle to 3.5-4K rpm. There are stock 0, 5 and 10 deg markings on the flywheel. It was surprising for me there wasn't ign. advancing on deceleration!?
So far it's satisfying result for us as our code is still in development phase and we still don't use compensation for accel/decel rate.
What do you think guys about that simple test procedure? I think the major drawback here is that one has to visualy determine the ign. jitter magnitude.
Regards to all. |
|
| Back to top |
|
|
RootesRacer
Joined: 04 Apr 2005
Posts: 460
Location: Arvada, Colorado
|
| Posted: Sat Jun 28, 2008 3:57 pm Post subject: Re: timing scatter |
|
|
| MRMRacing wrote: | | scottieFAST wrote: | | I still like the idea of using an engine. |
Yes this is right, the crankshaft is accelerating and deceleration during the crank turn, no simulator can reproduce this, (I am not an electrical engineer but beleive so) using an real engine doing this with two systems at the same time you can still get an accurate comaprision. Smart systems do more than just count teeth so using a signal generator will not work. |
So you dont think a "generator" can be created that mimics the crankshaft accelerating and decelerating?
I am an electrical engineer and know how to create equipment that can reproduce a digitally recorded waveform.
Forcing the test to use a real engine requires each ECU to be well tuned to that engine or else the tuning of the ECU will impact the timing results. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
©2007 EFI University |
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
