Firmware developent status

[AndreyB]

Usability: working on a way to download log files via rusEfi console.

[AndreyB]

http://rusefi.com/wiki/index.php?title=Manual:Software:Trigger now has a catalog of supported triggers

[AndreyB]

I am pretty confident that I've fixed the nasty #200 bug, but my battery is totally drained so no validation yet. Also ordered a 2/10/50A charger

[AndreyB]

[video][/video]

[AndreyB]

I am mostly done with all the boring but good stuff I need to take care of. There is hope to be back active in about a week

[kb1gtt]

Your going to have to show me that trick.

[AndreyB]

I am back

MPX4100 map sensor is now one of the pre-defined MAP sensors.

[AndreyB]

new feature: analog tachometer output



https://sourceforge.net/p/rusefi/tickets/217/

[AndreyB]

Just fixed a major bug in console connectivity, update to latest version is recommended if you get a red LED while trying to connect console.

[AndreyB]

new console feature: live graph. See the last 10 seconds of any data point. use right-click to enable.

Also more data points.

[AndreyB]

New command:
blipidle IDLE_POSITION DURATION_MX

for example,
blipidle 90 3000

would blip idle valve to 90% open for 3 seconds. This command is useful while tuning acceleration enrichment.

[AndreyB]

New feature: Instant RPM acceleration graph, will re-shoot same thing in English a bit later:

[video][/video]

[RasPL]

Is there fuel cut under deceleration ? (Tps position below 5% or map <30kpa and rpm>idle_rpm) And also DC value to which is seted up idle valve pwm pin(or steper motor)when engine is not in idle state ?

[AndreyB]

Is there fuel cut under deceleration ? (Tps position below 5% or map <30kpa and rpm>idle_rpm)

There is no complete fuel cut logic at the moment.

There is not-completely-finished deceleration fuel reduction (should be same code as acceleration, just not finished). There is also fuel film logic which I am was not able to tune for myself yet.
See https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/controllers/algo/accel_enrichment.cpp

And also DC value to which is seted up idle valve pwm pin(or steper motor)when engine is not in idle state ?

Nothing like this yet.

Would you be able to make some progress around these areas?

[RasPL]

I can try

[AndreyB]

https://sourceforge.net/p/rusefi/tickets/84/

It is now possible to send multiple commands at once:

[puff]

great feature!
adding script support will make setting up the board from scratch even easier!

[RasPL]

Will be great to add java console command wait xxxx ms just to test some actions for which time delay is necessary i.e idle testing

rpm 1200
wait 1000
rpm 800
wait 1000
rpm 1000

[AndreyB]

I've copied your last message to https://sourceforge.net/p/rusefi/tickets/207/

[AndreyB]

Will be great to add java console command wait xxxx ms just to test some actions for which time delay is necessary i.e idle testing

That's a good idea - https://sourceforge.net/p/rusefi/tickets/230/

[AndreyB]

Small usability progress: https://sourceforge.net/p/rusefi/tickets/234/

[AndreyB]

Just moved CAN messages to their own thread http://rusefi.com/forum/viewtopic.php?f=5&t=959

[AndreyB]

Usability: I've decided to just show all these formulas with current live values in console. LaTeX for java helps

Work in progress:

[AndreyB]

New command: idlebench
This command would activate idle valve solenoid so that you can confirm it's buzzing, even while the engine is not running. Also available as a button on the console:

[AndreyB]

I am trying to get smooth operation at least while idling. First step - multiple ADC measurements and averaging.

#define ADC_BUF_DEPTH_SLOW 1
CLT StDev = 0.0580959549, IAT StDev = 0.041446413, VBatt StDev = 0.1482153634

#define ADC_BUF_DEPTH_SLOW 4
CLT StDev = 0.0442683459, IAT StDev = 0.0393963408, VBatt StDev = 0.101382051

#define ADC_BUF_DEPTH_SLOW 8
CLT StDev = 0.0102597835, IAT StDev = 0, VBatt StDev = 0.0635807235

All this while car is parked - engine not running

Time RPM CLT IAT vBatt
RPM °C °C V
0.0102597835 0 0.0635807235
593.06 0 13.5 13.1 11.88
593.191 0 13.5 13.1 11.87
593.32 0 13.5 13.1 11.84
593.452 0 13.5 13.1 11.88
593.588 0 13.5 13.1 11.83
593.719 0 13.5 13.1 11.87
593.851 0 13.5 13.1 11.9
593.988 0 13.5 13.1 11.85
594.119 0 13.5 13.1 11.82
594.251 0 13.5 13.1 11.83
594.38 0 13.5 13.1 11.82
594.501 0 13.5 13.1 11.87
594.631 0 13.5 13.1 11.82
594.763 0 13.5 13.1 11.86
594.892 0 13.5 13.1 11.86
595.022 0 13.5 13.1 11.83
595.144 0 13.5 13.1 11.87
595.276 0 13.5 13.1 11.84
595.405 0 13.5 13.1 11.8
595.536 0 13.5 13.1 11.82
595.658 0 13.5 13.1 11.87
595.784 0 13.5 13.1 11.8
595.913 0 13.5 13.1 11.86
596.054 0 13.5 13.1 11.81
596.182 0 13.5 13.1 11.85

[kb1gtt]

What should it be, and does it have real world noise? For comparison sake do you have this compared with DMM or DSO Quad?

[AndreyB]

Got a request for low low pulse non linear injector control https://sourceforge.net/p/rusefi/tickets/269/ in addition to current voltage correction.

How is this usually parameterized? squirt amount (grams) to squirt duration (ms) curve? Theoretical squirt (ms) to correction (ms)?

[kb1gtt]

So the question is

How is this usually parameterized? squirt amount (grams) to squirt duration (ms) curve? Theoretical squirt (ms) to correction (ms)?

I would say first we should start to consider the tuning tables differently. The load VS RPM table is a kind of catch all, and should be tuned last. There are several lower level compensation tables that need to be tuned before the load table is tuned.

The short version is to implement the tables shown here http://injectordynamics.com/chrysler_injector_characterization/ where you have look up tables that allow for more accurate conversions between PWM to mG. However I don't fully agree with this, as it assumes consistent combustion energy from the fuel variations caused by additive like E85, MTBE, etc. As well it assumes consistent pulses with different viscosity's caused by differences in temperature, fuel type, etc. However it's certainly a step in the correct direction, and will allow better chances of obtaining a smooth idle with a larger injector. Also when implemented, plan for doing this kind of compensation on a per injector basis. AKA staged injectors on a V8 is 16 injectors. Also keep in mind that this entire load table thing is a hack, where you smash unknown tolerances into one ball park variable. See below table from injectordynamics that shows how injectors typical vary at low pulse widths.

Fuel_Mass_Conversion_Chart_3.png (34.28 KiB) Viewed 28584 times

Longer version below.

This question perhaps goes down the rabbit hole further than you may want to go. The generic load vs RPM table was largely done to allow kind of good-ish compensation under a variety of conditions. It was intended to allow the small processors of the 80's and 90's to kind of squish a bunch of compensation data into one calibration table. You didn't really care that you had 10 sources of error where some errors in the + direction, others in the - direction, that caused the final variation(s) of fuel PWM, you could make it "work" with this one table. You often had to dump some extra fuel to stay running, but it worked either way. However modern micro's have much more capabilities these days, so more complicated algorithms exist, and people are starting to look for them. The good news is that rusEFI has the physical capabilities to do this.

At it's core, the load table is really tuning for one of two things. Either people are tuning for peak power, or peak efficiency. For simplicity sake, we'll assume everyone here wants peak power. However don't forget if you are real competitive, at times, you'll want peak efficiency as it provides a fuel weight advantage. AKA know your fuel weight, predict how much you need and run dry as you come across the line. This means lighter vehicle while racing, resulting in faster turns, etc. I guess a very large group of people would also tune for things like minimal carbon footprint, minimal NOx emissions, etc. Point being you typically want multiple load tables. So even this one catch all table, has variations. Lets not forget that below it, you often have these sub level compensation tables. Then occasionally those sub level compensation tables have compensation tables.

At some time you start to wonder, when should you jump from a table driven approach to a different approach.

Peak power is largely a balancing act between spark timing and AFR/charge. AFR/charge is largely determined by PV=nRT. Your valve over lap, intake and exhaust restrictions, etc are going to change your VE which changes your predicted amount of air charge to be used during the combustion. Also keep in mind that your VE will even change based on power vs efficiency tunes. AKA the burning fuel left in your cyl will create different pressure levels in your intake and different levels of cross contamination as some of your overlap will cause some exhaust gasses to back feed into the intake. Efficiency burn will typically have less, or more of this kind of overlap. So your VE will change just by changing your fuel and spark advance. AKA compensation tables on top of compensation tables, on top of compensation tables. It all depends on what kind of tolerances you are willing to tolerate.

Keep in mind that injectordynamics also suggests getting a batch of injectors and balancing them, such that the properties from one injector to the next are the same, as most after market tuning software will only have one table, so you have to compensate for the injector variations via physical means. To get accurate injections, you either need exact injectors, or you need compensation data on a per cyl basis.

The issue you have with trying to tighten the fuel injector pulse down to smaller 0.XXXmS ranges is that you also need to decrease the sources of error from other things in your tuning table. I would say we should start to think of the RPM vs Load table as RPM vs Combustion energy table. Keep in mind that if you fill up on 87 octane, in the states you'll often have a blend of up to 95 octane. If you have less 97 octane being consumed at the fuel stations, the refinery's simply tap off more of the 85 which causes it to grab a bit of the other octanes. However in the EU they have much tighter tolerances on the range of octane you'll actually get in the fuel. This variation in fuel alone will change your tuning table. Also don't forget that E85 with it's sensors, or MTBE additive, or ethanol blends will all have different tuning tables. Then if you use race fuel.....

Any how, you can keep doing table mods on table mods, and consuming RAM and ROM space, or at some point you can make the jump and change from memory space to CPU cycles. I suspect that before long, we'll want to start considering the equation based approach, such that instead of entering tables, you enter cycle size, intake restrictions, exhaust restrictions, etc.

[stefanst]

Since you're talking about error sources, I have one more:

Static fuel pressure vs. dynamic fuel pressure:
Dynamic:
Flow rates for injectors are characterized depending on pressure differential (rail-intake). Most older cars with EFI run a return style fuel system where the fuel pump feeds the rail directly (via a filter of course) and then there is a pressure regulator at the other end of the fuel rail that returns fuel back to the tank. This would be considered a pressure relief valve. This regulator is usually referenced to intake manifold pressure, and by doing so maintains a more-or-less constant pressure differential across the injectors.

Static:
Some cars run a static fuel pressure. AFAIK this is usually done on vehicles with return-less fuel systems. Here we have a FP regulator in the fuel tank or close to it which maintains fuel pressure in the line leading to the fuel rail. The fuel rail is dead-headed, usually with a pulsation damper at the end. In this case there is no manifold pressure reference available for the FP regulator, so it maintains a static fuel pressure.
AFAIK static systems were introduced to deal with some hydrocarbon emissions issues created by return-style systems.

Here's the problem:
As the pressure in the intake rises, the pressure differential across the injectors is reduced. This means that the measured injector flow rate only applies to one pressure row in the VE map. All other rows have to make up for higher or lower pressure differential and resulting fuel flow by artificially increasing or decreasing the VE value. These maps are easily identified by their typical steep increase of VE values along the Y-Axis.

A rough first estimation of flow rate is proportionality to square root of pressure- meaning if you quadruple the pressure differential you double the flow.

So here is another area where a compensation table would be helpful in order to get to a 'truer' VE map.

[AndreyB]

Static fuel pressure vs. dynamic fuel pressure

Thank you - it's https://sourceforge.net/p/rusefi/tickets/274/ this way it's not forgotten!