nAst1: Progress and Concepts Thread

[robertisaar]

fuel economy calc change:

now 20 gallon tracking, so it will update twice as quckly and with better accuracy. the downside is that if you somehow are planning on using more than 20 gallons of fuel before shutting off the ignition, the counter will rollover, so you'll need to account for that in that situation. i don't think that will be much of a problem.

for an example:

i'll skip a bunch of math, but using LQ1 injectors since they're middle of the road at 22.4lb/hr, every 4.68mSec of injector on-time will increment the counter once. this is regardless of single-fire or double-fire. it's just simply on-time.

now, 4.68mSec is not a lot of time. assuming you idle at 1.17mSec(in double-fire), 4 revolutions(and injections) later, the counter will increment. at an 800RPM idle, that's 13.33 revolutions per second, so the counter will increment 3 times per second. if you log at 9Hz, it will take once every 3 frames to increment. that's at idle, so that seems like a decent rate to me. faster than most, if not all of the trip computers available back in the day, some even now. most are either 1/2 or 1 second updates, not 1/3 second. at higher fuel flow rates, expect it to be proportially faster, up to the rate of your logging equipment.

and here is the interesting part i decided to impliment...

i'll have an adjustable value to wait longer between updates at the benefit of increased accuracy. instead of incrementing that value once every time it should be incremented once, a longer sampling period can be selected. instead of 4.68mSec per increment, can choose a 10X sampling period and the increments will be by 10 counts. sounds odd(and that it won't actually do anything), but it will reduce the amount of positive or negative error that will continuously stack when rounding is necessary. so you'll be able to choose your own compromise between update rate and accuracy. of course, you'll be able to skew the value in the ADX to better match what you see in the real-world as well, since accounting for the effects of injector voltage and min PW offsets into a fuel economy calc isn't a 100% science.

[robertisaar]

more fun with math and an explanation of the "stacking" error:

stacking error is encountered due to the way this calc works. the way the factory trip computers work is that the ECM transmits a couple of values over the datastream on a regular basis, these include two important values: injector flowrate and total amount of time the injectors have been open. now why i can't directly use that alone is the way tunerpro operates. it doesn't have an accumulator to keep track of the number of times that the "total time the injectors have been open" value has rolled over, since it can only store a maximum of 1000mSec.

using the idling with LQ1 injectors example from before, the counter will rollover at 854.7 injection events. at an 800RPM idle.... well, that's 1.06 minutes. at higher fuel flow, it gets even worse. it's very accurate, IF you can account for the rollovers that happen.

so, to get around this, the ECM still keeps track of injector on-time and does the normal factory trip computer calcs/transmits, but now it also watches and keeps track of when this new counter hits it's target BPW for an increment, with the target being defined by the tuner when they input a value that i'm at least temporarily titling "mSec injector on-time to increment fuel usage counter". because i'm keeping track of this value with 16 bits of resolution and a 20 gallon maximum, this allows for the ECM to keep track of fuel usage in 0.00030517578125 gallon increments.

now, because of the way this is calculated, every time an increment occurs, a portion of the injector on-time will be lost. keeping with LQ1 injector theme, it takes 306.88 injector on-time counts to increment the 20 gallon tracker once. since on-time can only be programmed as whole numbers, the closest number is 307. so every increment, .12 units of on-time are lost. i'm going to round here to keep the never-ending trail of decimal points from getting worse, but every 8 increments, 1 injector on-time unit is lost to rounding. 1 injector on-time unit is equivalent to 0.0152587890625 mSec.

note, that is a TINY number and essentially insignificant. but they do stack up eventually. burning through 15 gallons of fuel, 49,152 increments will happen. since 1/8 will lose 1 injector time unit, we can calculate that 6,144 of those events will happen. 0.0152587890625 X 6,144 = 93.75mSec lost due to rounding. that's about 1/3 of an increment to the 20 gallon counter, so total of 0.00010172526041666666666666666666667 gallons that aren't accounted for. note in this scenario, the difference between the intial 307 and 306.88 value was .04%, which is wonderful to work with. larger errors here will cause larger amounts of fuel to go "missing". this is the reason for the longer sample period. sometimes, multiplying by 2, 3, 4, etc will bring the initial error down to good numbers to work with at the expense of update speed. for example, 100 lb/hr injectors = 68.8(rounded) injector on-time units. using 69 is a .29% error. by increasing the sample frequency by 5, you come up with 343.97. diff between 344 and 343.97 = .0087%. updates take 5 times as long, but you're down to 3% of the original error.

nice accuracy, huh? well, in the real-world, injectors aren't perfect devices and their flowrate will change due to time/wear, voltage and min PW offsets, specific fuel gravity, rust, random chance, etc, etc.... but the math behind calculating what they should be injecting can be that accurate.

once you get into monster injectors that require running min PW offsetting at and above idle, this calc will start to suffer and you'll need to change the skew portion of the ADX's equation quite a bit to match real-world results.

[robertisaar]

and disregard a bunch of that, getting the "batched" increments functioning requires a lot more space than i was anticipating, so if usage isn't correct, skew it in either the BIN or the ADX.

[pocket-rocket]

10,000th of a gallon missing. Nice work Robert. And here when I calc fuel efficiency in my truck I don't look at anything past the 100th of a mile (currently 26.58mpg city/country).

Sent from my HTC One X using Tapatalk 2

[TurboGTU]

Man can the processor keep up with all this? Lol . I wanto combine code 59 with $8f and $Df or at least 59 with 4t60e control and have another 59 with 4l60e control. I'm trying to get back in the ecm hack game and I'm decades behind! This nAst1 project is quite a hand full.

[pocket-rocket]

I believe nAst1 started out in concept as something like a cross between code 59 and $DF.

[robertisaar]

10,000th of a gallon missing. Nice work Robert. And here when I calc fuel efficiency in my truck I don't look at anything past the 100th of a mile (currently 26.58mpg city/country).

Sent from my HTC One X using Tapatalk 2

yeah, it's well within the injector error, which is going to be different for every vehicle.

Man can the processor keep up with all this? Lol . I wanto combine code 59 with $8f and $Df or at least 59 with 4t60e control and have another 59 with 4l60e control. I'm trying to get back in the ecm hack game and I'm decades behind! This nAst1 project is quite a hand full.

it seems to.... i've tested the code up to 18,000RPM and beyond 180MPH before and everything still seemed to be perfectly functional.

I believe nAst1 started out in concept as something like a cross between code 59 and $DF.

in concept..... something like that. especially since i started the 59+DF thread a long time ago... i decided to try and make the most of one controller before integrating a second one though. i wasn't aware that A1 had functional 4T60E control from GM until i disassembled and commented a BIN myself. after that, i actually put it on the testbench and enabled the option for it and it has worked exactly as it does with DF. so then i started tweaking..... and after a few months of real-world tests, this thread came about. boost was always in the plan, but it took a while to get everything working correctly for it.

now..... every "comfort" of A1 with a whole lot of track-friendly additions, with some drivability stuff added in as needed.

[TurboGTU]

Like binary porn.

[robertisaar]

MOAR revisioning!

changed up the fuel usage code yet again... decided that since this is simply a trip calc, it doesn't really need to update at high speeds, since that is what the instant calc is for. so now things are much simpler. i even put together a spreadsheet to do all of the math, just input lb/hr or gph rating of the injector and it does everything else.

new example using LQ1 injectors:
flowrate of 3.58GPH
3.58GPH / 3,600,000mSec per Hour = .0000009944444444 gallons per 1mS of injector open time
0.00030517578125 / .0000009944444444 = 306.88mS of injector open time necessary to flow 0.00030517578125 gallons of fuel


note the comparatively large number of injector on-time needed compared to the previous calc. i decided to do the calc in reverse to see what the smallest injector possible to use with this calc is(so 1000mSec per 0.00030517578125 gallons injected), comes out to 1.099GPH, which is the equivalent of a 6.77 lb/hr injector. i think that would cover even fuel injected lawn mowers.

so, real-world update speed will depend entirely upon how much fuel is flowing. injector size won't matter here. idling at .49 gallons/hour is idling at .49 gallons/hour. at that rate, the calc will update once every 13.45 seconds. accelerating pretty rapidly, like at 20.72 gallons/hour, think more like once every .32 seconds.

because of the way the calc works, trip MPG may start out looking like a sawtooth wave but will smooth out pretty soon after. this is due to the way the calcs work(distance and consumption update independantly) and is normal.

[pocket-rocket]

Now, if only we had someone to make a TunerPro RT self tuner version for android compatible with an Ostrich connected via Bluetooth...



Sent from my HTC One X using Tapatalk 2

[robertisaar]

ha, that would certainly be neat to have.... wireless tablet/phone connection to the car at all times.

[robertisaar]

and for distance tracker accuracy:

if you have a setup that produces 24,000 pulses per mile(quite a few applications do), 1/128 of a mile is 187.5 pulses. if you have a 30 tooth VSS reluctor, that means the distance tracker will increment once every 6.25 tire revolutions... assuming a 26.6" tire(such as a 245/55-16), that is once every 43.5ft. with that kind of accuracy, you can get within 3.3% of a quarter mile... and longer distances = higher accuracy. after a mile, potential error is down to .8% and keeps dropping from there. after 10 miles, .08%.

anyways, in the calibration for VSS, you can only enter whole numbers. to correct for this, you'll need(want) to specify a correction factor in the ADX. in the interest of saving program space and processing time, there isn't a quick/easy way to correct for error within the calibration. very simple to do within the ADX though. just set the calculated PPM as close as possible and deal with any calculated (and as a final sanity check, observed) error in the ADX.

i'll have the info to do this in the XDF item notes.



otherwise, it looks like i'll be testing this long overdue update within the hour.

[caffeine]

I've thought it would be cool to write an android app to interface with the ALDL and use a tablet as a gauge cluster with whatever gauges you want.

[pocket-rocket]

That would be nice.

All android phones (to my knowledge) have usb ports on them. Wasn't there a setup for palm for interfacing with ecms years ago?

Sent from my HTC One X using Tapatalk 2

[TurboGTU]

Most palms diagnostic interfaces worked off the serial port. The USB on the palm was just to sync. A good interface would be ALDL to Bluetooth . So now most devices are covered even some Palms.