output scheduling resolution

It's all about the code!
Post Reply
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

output scheduling resolution

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
erich
Posts: 21
Joined: Tue Sep 03, 2013 4:55 am

Re: output scheduling resolution

Post by 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.
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by AndreyB »

erich wrote: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 :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by 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.
Attachments
faster_fast_irq.logicdata
(687.54 KiB) Downloaded 1712 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by 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
Attachments
faster_fast_irq.logicdata
(687.57 KiB) Downloaded 1587 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
erich
Posts: 21
Joined: Tue Sep 03, 2013 4:55 am

Re: output scheduling resolution

Post by erich »

If you can keep jitter under 2us when doing the processing you need to do then you're golden.
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: output scheduling resolution

Post by 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.
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by AndreyB »

roflcopter wrote: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
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: output scheduling resolution

Post by 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.
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by AndreyB »

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

Image

The spreadsheet is public @
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by 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.

Image
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3730
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: output scheduling resolution

Post by 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?
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by 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.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
UnaClocker
Posts: 46
Joined: Tue May 13, 2014 12:14 am
Location: Tacoma, WA

Re: output scheduling resolution

Post by 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?
Brian from Tacoma, WA
84 Dodge Rampage
01 PT Cruiser
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by 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.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
UnaClocker
Posts: 46
Joined: Tue May 13, 2014 12:14 am
Location: Tacoma, WA

Re: output scheduling resolution

Post by 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.
Brian from Tacoma, WA
84 Dodge Rampage
01 PT Cruiser
User avatar
kb1gtt
contributor
contributor
Posts: 3730
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: output scheduling resolution

Post by 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?
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3730
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: output scheduling resolution

Post by 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.
Welcome to the friendlier side of internet crazy :)
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: output scheduling resolution

Post by 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.
Last edited by mobyfab on Sun Feb 19, 2017 8:01 pm, edited 1 time in total.
User avatar
AndreyB
Site Admin
Posts: 12902
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: output scheduling resolution

Post by AndreyB »

Thank you for the script and the great link!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: output scheduling resolution

Post by Nobody »

UnaClocker wrote: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?
Post Reply