output scheduling resolution

[AndreyB]

This is a thread to discuss http://rusefi.com/articles/pwm_performance/

See also http://rusefi.com/wiki/index.php?title=Development:Software:performance

[erich]

The real test will be to make about a dozen timers all running with slightly different periods at the same time and check the jitter then.
Also make each handler burn a hundered clock cycles or so to get a more realistic load.
Assuming you want to be able to control an eight cylinder engine you need eight injector timers and eight spark timers running all the time.
At 8K RPM to get 1/2 degree spark accuracy you need about 10us timer jitter or less. To get accurate fueling you'll need somewhere between 1us and 10us precision which depends on the size of the iuunjectors. The larger oversize the injectors are the more precision you'll need.

Running a single cylinder engine on pure software timers is easy. Run an eight cylinder one is a whole 'nother story.

Just so you know, I've been doing real time systems of both hard and soft varieties for over 25 years preofessionally. I currently write drivers for a large multinational semiconductor company. I love this stuff.

[AndreyB]

At 8K RPM to get 1/2 degree spark accuracy you need about 10us timer jitter or less.

Different people have different opinions on what degree accuracy in actually needed. Should it be 0.1 degree or should it be 2 degree. It's really tempting to simply declare that lower precision would be good enough

I will update the test code, I only have 8 channels on my analyzer but that should be enough to get an idea.

PS: welcome to the forum

[AndreyB]

I had to remember the times when division operation was unacceptably expensive... Anyway, new division-free implementation gets 4us precision with a 1MHz fast irq handler, attached file has a snapshot of six channels of different frequencies.

[AndreyB]

And now with another fix it loos like 2uS precision?

100Hz signal times:
5.00025ms
5.00025
5.0005
5.00025

111Hz:
4.5045ms
4.504
4.50425
4.50425
4.50425
4.50475

200Hz signal times:
2.5005ms
4.99750
2.5005
2.50025
2.500
2.50025

10KHz wave:
50us
50us
50us
51us
49us

50KHz
10us
10
9
11
10
10
10

100KHz
4us
6
4
6
4
6
4
6
4
6

[erich]

If you can keep jitter under 2us when doing the processing you need to do then you're golden.

[roflcopter]

This doesn't exactly cover the resolution of the scheduling, but more the way in which it handles multiple threads at once.

After looking through your implementation in scheduleOutput, it would seem that using the sleep functionality to execute the dwell time that the injector should be turned on. The issue that this poses is that while the system is waiting for one injector to need to be turned off, it can miss when another can be turned on, it isn't clear to me how exactly you got around that from looking at the code. If you'd like to explain how you accomplished that, I would be greatly appreciative.

[AndreyB]

This doesn't exactly cover the resolution of the scheduling, but more the way in which it handles multiple threads at once.

After looking through your implementation in scheduleOutput, it would seem that using the sleep functionality to execute the dwell time that the injector should be turned on. The issue that this poses is that while the system is waiting for one injector to need to be turned off, it can miss when another can be turned on, it isn't clear to me how exactly you got around that from looking at the code. If you'd like to explain how you accomplished that, I would be greatly appreciative.

The resolution data here is NOT about the "sleep" implementation, but to answer your question:

So, in the sleep implementation (not the one measured here ) there is one thread per each injector. While one thread has turned the injector on and went to sleep for the dwell time on this injector, another one does whatever it wants to do - maybe also sleeps, maybe awaits for the 'semaphore' signal which triggers injector ON. So, part of the answer - it's not the same thread for all of them, each one has it's own thread.

If the question is about what happens if two threads need to do something at the exact same moment, like if one needs to turn off it's injector while another one needs to turn on it's? Obviously we have one CPU so they cannot work at the same time. One would do it's job while another one would be delayed by say 100 CPU ticks (because the job is so easy it should fit in 100 ticks). Good news is that 100 CPU ticks is 0.001ms and we do not care if we are 0.001ms late

[roflcopter]

I... should do more reading before asking questions. haha

After reading some more about the OS you are using, it appears to simulate the multiple timer threads that I am using hardware timers for, so it's essentially the same solution, just with more overhead. It's nifty to see how the two approaches come to the same conclusions through different methods.

[AndreyB]

As a recap, here is a table of time requirements for different angle precision and different RPMs



The spreadsheet is public @

[AndreyB]

Finally the single-timer "hybrid" scheduler is ready: http://rusefi.com/articles/pwm_performance/hybrid.logicdata

Not sure how to apply proper statistics to this logic analyzer report, but worst jitter I see in the log is 5us.

[kb1gtt]

I think we should discuss how we want to measure this timing accuracy. For example 1mS is probably reasonably close to the min pulse you would want for many applications so this would be 1mS +/- 5uS? Also if we look for .1 degree accuracy the max rpm with a 5uS tick would be 3.3krpm. I get that like this. tick/5x10^-6s x 1rotation/3600deg x 60s/min = 3.3tick-krpm or if we aim for .2deg that changes to 6.6krpm. As well we should include some margin for xtal ppm variations.

Does it make sense to measure timed signals based on a 1mS and rotation based signals on max rpm?

[AndreyB]

By the way, in the beta version of their software Saleae has added CSV data export - here is the same report as CSV http://rusefi.com/articles/pwm_performance/2014may13.csv

That should allow some processing in Excel or above. StdDev? Average? Not sure. Good question. I guess we really need to know our constraints in order to answer the measurement methodology question.

Can we afford a single instance of 1 degree jitter per minute @ 6K? I guess it's all about knock.

[UnaClocker]

1 degree isn't a big deal, besides the fact that you should be tuned more than 1 degree away from knock, knock at 6k isn't going to damage anything. It's lower RPM knock that has the time to do damage. What kind of injector resolution are you looking at? I believe the original MS1 had a really grainy 100µsec on it's batch fire injection. Which was good enough. I think their current setup is doing 1µsec per sequential injector. Have you guys got sequential yet?

[AndreyB]

So far I was under an impression that ignition timing is way more important than fuel injection duration or timing precision, but that's the same scheduler anyway for both. Same ~1uS precision for injector/coil on event and ~1uS precision for injector/coil off event. With up to ~5uS jitter, at least with the current testing methodology.

So unless anyone objects let's declare that we are in a good enough place right now?

We have sequential already, that's one of the few things we have from day 1.

[UnaClocker]

heh, fuel is way more important than spark advance. You can be way off on spark advance and never notice, whereas if you're running crazy large injectors, at idle, you need every bit of resolution you can get to keep it from oscillating. But yeah, sounds like you've got this.

[kb1gtt]

am I correct in saying there are three specs we want for comparison. Time around 1mS +/- blah and best crank angle resolution at 6krpm also at 1krpm. Many engines only rev to 6km so why not use that as the baseline. As well idle is often around 1krpm perhaps down to 500 rpm but basically most engines can do 1krpm. So why not use that as the baseline. Other rpm's can be my noted but let's establish a baseline for consistency sake.

That said what are acceptable limits for those three specs? Would 1mS +/- .1mS be good enough? What range would be ok, then good and what is the max that would be useful? Then at 6krpm what degree accuracy is ok, good, best? Then again for 1krpm ok, good, best?

As it stands now we are 1mS +/- .or .005mS 6krpm, .182 deg and 1krpm is .030 deg. There will be some more induced error based on xtal ppm but not much.

6krpm is 2.7778x10^-5 sec/deg. So 5x10^-6 sec is .182 deg per tick.
1krpm is 1.6668x10^-4 sec/deg. So 5x10^-6 sec is .030 deg per tick.

Are these specs ok, good or best categories?

[kb1gtt]

Hmmm, we should probably also add a graph or something like that that shows the crank angle accuracy vs RPM. Basically any time you are above that .2 degree accuracy, you may want to know it such that you can compensate for it in tuning. As it stands now, the accuracy up to 6k is below .2 degree so it's not really important for people to think about. However if you rev to 9kRPM, you might want to pay attention to the detonation barrier and might want to retard the timing a pinch more to compensate for the tolerance.

[mobyfab]

RPM vs tick rate, giving the precision:

https://jsfiddle.net/X64Rb/8

It's in JS so feel free to modify calculations or add more values.

You can also export to images.

[AndreyB]

Thank you for the script and the great link!

[Nobody]

heh, fuel is way more important than spark advance. You can be way off on spark advance and never notice, whereas if you're running crazy large injectors, at idle, you need every bit of resolution you can get to keep it from oscillating. But yeah, sounds like you've got this.

Both are important... On my car 2* of advance is the difference between knock/detonation and fine, fuel as long as your not ragged lean it will be a little more tolerant. Fuel quality of course throws both statements out the window if bad.

As far as really large injectors it's the characterization that's critical:
* injector offset vs. voltage (offset is delta between open and close time)
* injector flow vs. pressure (you flow more when under high vacuum).
* short pulse adder - this is adder to calculated open pulse width, in which you compensate for non-linear region.

There is more with injectors but I'll leave it at this.

As far as timing, any timing vs. IAT and ECT?