Re:Whittlebeast's RPMxMAP vs Duty function

[robs]

Thanks for that Ryan. I'm not sure if this is what you were driving at, but you're onto something. Internally, MS deals with PW in 2/3µs units. I knew this, but hadn't accounted for it when I solved the equation for VE. That would account for a constant multiplier error. Could well be the breakthrough.

I'm not sure that this is what you were driving at though so I'll waffle on on a couple of other things.

The resolution of Duty% is 100/65535% ~ 0.0015%. Looking at the shortest pulsewidths from the log file does't immediately strike me as chunky: 5.716 5.719 5.739 5.763 5.826 5.882 5.882 5.914 5.916 5.929 -- there are differences as small as 2 or 3 µs. Pretty high resolution. Actually, thinking about it, the resolution is probably only limited further down the pipeline, because it feeds a VE value to the rest of the code, the VE is in tenths of a percent. It wouldn't be hard to calculate it to higher precision. Doubt it'd be of much benefit.

One other thing I haven't mentioned so far. If a value is outside the range of RPMxMAP control points -- lower or higher -- it is treated as if it had that end's value (this is the way the MS2 interpolation code works). To picture it, look at that last graph of mine; imagine horizontal lines joining the end circles on the blue lines-and-circles target graph. That's the target if an RPMxMAP value is ever received outside the range. IOW it's very important that particularly the highest MAPxRPM control point value be above the highest you'll ever reach in running.

Testing on the stim is one thing -- it never stalls. It will be interesting to see if the curve algorithm is good enough for stable idling.

Have fun,

Rob.

[ol boy]

I think you nailed it.. glad I could help with the dim light bulb situations.. lol.

Just driving with a solid map value and a rpm with +- 5 fluctuations I'll see +-8ish us steps. So if your seeing something around 3us steps then that should work for me.

I've often wondered if it was possible to get down to 1us steps with the math or needing to solve to xx.xx VE value instead of xx.x.

So your solving to a VE value instead of straight to duty cycle?

Sent from my SM-G920V using Tapatalk

[robs]

I had two thoughts overnight and, Ryan, you've just put your finger on the more important one.

I'll start with the less important point. The Whittlebeast curve relates RPMxMAP to %Duty. I have been grappling with all these calculations (#squirts, alternating, etc.) thinking that if I get them all correct, the user will be able to change them and the same Whittlebeast curve will maintain the tune. Quite wrong -- fiddling with these values will change the duty cycle; the user will have to adjust the curve accordingly. Not that I'm happy with the curve being wrong.

Now to the more important thought, which follows on from the above. I showed some time back that a given RPMxMAP -> Duty is equivalent to RPMxMAP -> VE. So why are we doing this Duty thing at all? If we just have a simple lookup from RPMxMAP direct to VE, all of this fiddling becomes unnecessary and, what's more, the tune will survive changes to squirts, etc. All we'd be doing is replacing a VE table with a VE curve. Easy too to change the curve into a table later on.

Simpler, faster code, and the same fuelling result.

Almost seems a shame because I'll be throwing out some code I've thought quite hard about (for efficiency and precision), and getting a [0:65535]->percent curve in the INI file wasn't easy. But I'm sure this is a better way and it should be easy enough to have it done today.

Have fun,

Rob.

[robs]

Wrong again!

Wonderfully simple code, but doesn't behave right. If you track a Whittle curve's Duty, it's certain that each MAPxRPM combo will lead to a single VE. However, just because you track a curve of MAPxRPM to VE, doesn't mean that the corresponding Duty graph will follow a thin curve:

fail.png

Probably would have looked OK if I hadn't put that kink in it, so just as well I did.

So back to plan 1. At least I won't be throwing out that code I sweated over. Just have to reconcile the PW units with the req_fuel units and I think (hope) it'll track the curve correctly.

Have fun,

Rob.

[ol boy]

The duty cycle should stay about the same regardless of number of squirts. Could you solve for the duty with out the dead time? Then add the dead time and push that PW value to the injector timer channel?

Sent from my SM-G920V using Tapatalk


Edit.. I played with rpmxmap to VE1 and it is ugly. Anything but a line. Maybe my dead times are to small.

[ol boy]

Robs: Oh man.. one more thing.. can you leave in your baro averaging widget you did 2 weeks ago? Set the battery correction lag factor to 50%. I'm rocking that code right now.

Sent from my SM-G920V using Tapatalk

[robs]

Posted this earlier but it didn't appear. Some glitch in the forum software.

Wrong again!

Nope, that "wrong" was wrong. For Pete's sake!

Andy spared me the EGO doing-in my brain (more than it's done-in already), but I had to wake up to the fact that I'm running a wall wart to the Stim -- logging something around 10V. Dead time adjustments meant I hadn't a snowball's chance in Hell of getting this all to agree. Having finally realised that, I thought it was worth going back to the direct VE lookup and, with dead time eliminated, the output looks much more like it.

Here is VE plotted against RPMxMAP, with the kinky target in red:

ve2.png

And here is the Duty (PW*RPM/1200) plotted against MAPxRPM:

duty.png

With the dead time out of the picture, that's as thin as you could wish for.

Here's the log file in case you want to check it out for yourself:

velog.zip

Ryan: I'll be keeping the changes separate, but will apply both patches to the S19 file I send you.

I'll leave it for Andy to decide whether he's heppy to go with this approach. It certainly feels more "right" to me than trying to sift all the adjustments out of PW to get a VE that will give the desired Duty.

Have fun,

Rob.

[jsmcortina]

My comment from earlier.

When I discussed implementing this with Andy, it was going to be a VE curve vs MAPxRPM. Although, maybe it would be better to use the MAF curve feature.

James

[whittlebeast]

Rob, the last log sure looks like the code would be worth a try in a car. You should be able to pre set the curve based on what the car used to require on standard code.

Assuming you have your injector dead time correct and your motor is a "speed density friendly" motor, it should dial right in.

Andy

[ol boy]

I can pull a few logs and post my rpm/100 x map to duty values.(I think that's right) tell me what math to use and I'll let you know the values.

Running 4 sq alt. Duty should be independent of dead time as the user compensates with the VE table for errors in dead time.

Tell me what I need to produce to help you Rob. With any luck I'll be dead on the freeway this evening on the way home! The worst thing to happen is that it just works!

Sent from my SM-G920V using Tapatalk

[robs]

James: yes VE makes most sense in several ways -- understood by users, central to the firmware's fuelling equation, independent of squirt patterning. In the end the code change is pretty trivial. I expect you would have avoided the pitfalls I stumbled into and had it done in an hour or two, but it has been interesting for me working at a higher level than my previous efforts here.

While I have you, and since I've been racking my brain about it for several days, two questions. What on earth does "divider" represent? Secondly, shouldn't alternate be treating the two banks as having different phased cycles (e.g. 4-stroke [0:720] and [-360:360]) and not preclude both banks being open at the same time? In this case 100% duty would squirt just the same amount of fuel as for simultaneous.

Andy: glad you see it as promising. I'll build a version (with the baro smoothing patch for Ryan) and post it and the .ini file here shortly. I can try it in the car I took the MS out of (though it's battery is elderly). Should be interesting.

Ryan: it's now working with VE, so no need for duty values. For a first effort, I'd just refer to the diagonal of your existing VE table: put the MAPxRPM/100 in the wload list and the corresponding VE value in the VE list. Enable "Whittle" rather than 12x12 or 16x16 and see how it goes. It'll be interesting to hear if you can get it to idle.

Longer term, if it's seen as useful, I could provide Perl scripts to convert an existing VE table to a near-fit Whittle curve and to generate a VE table from a tuned Whittle curve.

Have fun,

Rob.

[jsmcortina]

Even though I mentioned VE, I'm not entirely convinced by it!

Divider is a bit weird, yes.

James

[ol boy]

Lol.. nice.. the blind leading the blind...

Sent from my SM-G920V using Tapatalk


You know you've made it in life when you get a fuel algorithm named after you!

[ol boy]

I can see injector dead time really messing with people trying to use this curve idea. I adjusted my dead time this morning to see the resulting change of the VE table and it was quite a change. I thinks its a lot closers and more accurate than before. What worries me about VE and maybe why James is not entirely convinced is most of my VE table is flat. 20 kpa has values of 90 and 100kpa has values of 120. Boost areas jump to 138 from 150kpa to 200. How important is it to use the proper req fuel value? I selected a lower req fuel to make the VE values larger giving finer adjustment.

What's the guidance or should it just work..

Sent from my SM-G920V using Tapatalk

[robs]

Here is the zip file with the MS2 firmware (not Microsquirt etc.) and a project .ini file (to be put directly in an existing TS project as projectCfg/mainController.ini):

whit.zip

I suggest you:

1. copy an existing TunerStudio project
2. load the new S19 onto the MS
3. quit TunerStudio and copy the .ini file over the top of the project's mainController.ini
4. fire up TunerStudio again

There are probably better ways of doing this, but the above works for me.

In Basic/Load Setting->General Settings, "Fuel Table Size" now has a "Whittle" option. Choose it.
In Fuel Settings there is a new menu item "Simplified fuelling:MAPxRPM to VE". Enter the numbers as per the diagonal of your good VE table -- except for idle, where you should take the VE values where your idle is. I included an egoCorr gauge to the curve editor panel. You could drive while holding load on a control point and noting whether correction is predominantly up or down and adjust the control point accordingly. Shouldn't be too bad to use, but don't run into the back of anyone!

The firmware does include the baro averaging patch.

Happy breakdowns.

Have fun,

Rob.
P.S.: on the VE question, I said "understood by" users, but the right word would be "familiar to". Anyhow, we'll soon find out. If nothing else, it should be a good stepping stone toward a decent VE table.

[ol boy]

It runs! Need to drive it around the block before heading home.

Sent from my SM-G920V using Tapatalk

[ol boy]

Made the drive around the block and the code did well. better than I thought. Even did a little burnout near the end. Here is the datalog and msq. I did as Rob said to do. rpm x map/100 to VE value. Did a dozen random points in the normal driving range and plugged them into the line.

2016-10-21_15.37.15.zip

2016-10-21_15.45.30.msq

about to drive home, see what happens.

Rob: Idle is rock solid. PW moves about by +-10 us. I haven't touched the 12x12 trim table yet. Just works!

Good Job!

[robs]

Good to hear.

I got mine going, and it idled fine too. I had other difficulties, just because I've been running an ancient version of the code with my own little tweaks. Took me a while to work out how to enable the WB sensor, then how to enable it chasing the target. And the MAP reading (with averaging) was much more jittery than before -- I had lag 100 on everything as I've described elsewhere -- but had to put the MAP AE threshold up a long way from where it was. May have to eat my words and enable MAP lag -- or retweak the code.

Didn't take it for a drive -- busy and wet -- but it seemed fine free-revving/heating up the converter in the garage. Unfortunately, my laptop's battery lasts about 5 minutes at the moment, so I can't try for myself, but I'd be interested whether it's as easy as I had imagined to hold to one MAPxRPM setting on the road. Tuning like that is where I think this fuelling method will really shine.

Have fun,

Rob.

[ol boy]

Yes, tuning is really easy. Roll in the throttle watch the green bubble and glance at the AFR. I run 14.7 everywhere below 80kpa from 1000 rpm and above. I did notice that rpm dot seems higher than normal in certain areas which causes PW to shake about, just drive through it. I also switched between 2 sqrt and 4 sqrt with only minor tweaking of the VE line.

Did a few boost pulls and it fattened up like normal.

Need to try this on a single 4 stroke in sequential mode.

Is there a way to switch to "load x rpm" or is it stuck at map x rpm for now?

Sent from my SM-G920V using Tapatalk

[robs]

It's stuck at MAPxRPM for the moment. As I said earlier, easy to make you a special with TPSxRPM. Not sure about "load" since it's a sort of meta-term. I don't think it'd be meaningful to multiply MAF by RPM for example.

I can't even think what a "single 4-stroke in sequential mode" means. Sequence of one doesn't sound very hard! Anyhow, I'm not certain about sequential injection. I think it'll do something if this option is selected, but the decision process in the code leading up to it is fairly convoluted and it doesn't take much to confuse me.

Have fun,

Rob.