silver_evo

Hello guys!

Im back in visual studio again after ECUFlash hack 1.38. Hehe. This time ive got some great ideas.

1. DMA Logging is fast.
2. Reading the LC-1 input from the Rear O2 ADC.
3. Use Live mapping to create a semi-closed loop tuning tool.

Ok so to use this program here is what you NEED!

1. TephraMod V7 96532706
2. LC-1 Wired into REAR o2 ADC
3. Ability to switch to ALT-Maps

Here is the basic loop for my program.

1. Create or load your car (the current rom file and the target afr rom file)





2. Now on to the tuning. When you load your 'car' the program does the following things.

- Reads The High OCT Fuel map from the ROM (Needs to change to the ALT-Fuel Map)
- Reads the Load and RPM Axis
- Creates a RAM Address table

3. The Main dialog appears and you click connect. The program does the following.

- Connects using 15625 Baud connection
- Reads the RAM ALT-Fuel map from the ECU
- Begins DMA sampling the RAM Mut table



There is a debug mode to make sure the program wont make your car go 17.xx at WOT

Once TPS Limit and Load Limit are exceeded the program freezes the UI to go into correction mode.
The following happens in correction mode:

- The Actual AFR is read from the Rear O2 ADC.
- The Desired AFR is read from the TargetAFR.bin High Oct Fuel Map (Needs to chage to ALT High OCT)
- A Correction Factor is calculated
- This correction factor is made up of the four (4) Load/RPM cells that the current load/rpm are at.
- The program bi-linear interlopates the AFRMAP value.
- The Correction is applied to this calculated AFRMAP value
- The Corrected AFRMAP is weighted (x1/xtotal^2) and stored in a correction list.
- This process continues until the Load or TPS drop below the Limit again.

Once Control is returned to the UI, the Apply correction and Discard Correction buttons are enabled.

Apply Corrections will write the Correction Table into the RAM ALT Fuel Map.
Discard Corrections will clear the table.

Save ROM will write the 'corrected' fuel map values into the rom file so it may be flashed into the ECU.


A few problems with the program so far...

- All the data logging is hard coded. All mut request are hard coded. If you use a different 1-Byte Load Factor or have a custom RAM Mut table, this wont work.

- The Correction factor may be too large and cause over-shoots in AFR. Several Runs back to back while applying corrections will make the over-shoots smaller and smaller until the error margin is acceptable. How ever i have not noticed this.

I test ran the program today, all went as expected. Data was collected. AFR's were corrected and weighted. Applied back into the cells.

The Result : My afr was SOLID 11.3-11.4 for about 3000 rpm. I had mis-coded the 1-Byte Load Factor at 1.2 (I use 1.4) So i was correcting the wrong cells. Luckly i was at 11 psi so the load was not in the 220-260 range, it was down around 160ish. This made the 1.2x load difference not as noticable. The program is fixed and tommorow i will try again. Will post results soon!

The Goal is to be able to edit a Fuel map in ECUFlash and have the numbers actually mean something. My old stock injectors and 25psi boost with a TBE had me at 7.4 (which is 0xff) in the fuel map. AKA Maximum fuel!

I dont know if this program will actually help or hurt fuel maps. I guess if your in the ball-park and you want the easy way to dial it in

ziad

iTrader: (1)

---

ziad

iTrader: (1)

darn the FF crashed and lost post. anyway can i please have a look at the code, as i have rewritten the whole DMA logger and this is a feature that i would love to have in it too.... best use of DMA i think. and working of urs would save me writing from scratch. my email is my username at mztec dot org

i am happy for you to look at the code/actual program as well... the code is in VB.net and a slight mess.

silver_evo

I'll include the VS2008 project when i post the finished executable. Let the community tear my project up

Should be posted tommorow afternoon after i give it the last test run.

Evo_Jay

iTrader: (17)

A couple things. Do you need to have DMA logging and Live map on/working ROM?

Also, can this be used with a zeitronix, instead of a LC1 wired into the rear o2 ADC?

logic

iTrader: (2)

This is exactly what I've been hoping someone would tackle ever since John original posted about the DMA implementation. Good stuff! Are you considering doing automatic on-the-fly correction, or are you thinking of sticking with a manual sample/apply/repeat approach?

Evo_Kid: the sample rate for MUT is abysmal. Even with DMA, I'd probably bump the baud rate up to 62500 before messing with this.

As for the zeitronix instead of LC-1, it'd probably just be a matter of changing the interpretation formula (ie. same thing you'd have to do with EvoScan) and rebuilding the project; if he implemented it the way I think he did, exposing that as a configurable formula (or drop-down list of choices) shouldn't be difficult.

silver_evo

Logic -
I think that the automatic correction would be a great idea, the only problem i can forsee with it would be the program will auto-correct a cell and then immediately sample and try to correct again before the engine has time to flow enough to show the change in the WBO2. I could add a delay time into the program to prevent rapid corrections of cells. I would estimate around 50 mSec would be sufficient. The other option which i think is better for having all corrections averaged into the fuel map is to record all the corrections in the table, just like before, but once the engine is out of a cell area group, apply the corrections to those cells. Functionally this is the same as waiting until the end and pressing Apply Corrections, because corrections are applied after the engine is past that area.

I don't think the WBO2 and sampling rate are fast enough for on-the-fly corrections and a effective feedback loop.

For those wanting to use the Zetronix wideband. Search for the instructions on using the LC-1 w/o the serial connection. There is much information about using the Zetronix Wideband with the Rear O2 ADC. Then the only change to my program is just the formula for Converting X to AFR (eval).

I will change the baud rate to 62500 also. (FAST!)

One last question i have is the BIGMAP live map has a command for

This allows the ECU to read the 0xe0, 0xe1, or 0xe2 command and transfer into DMA mode. Im thinking of reducing this time delay.

Ceddy

Nice work!


The Sleep command is bad with coms, its very inaccurate at less then 100ms.
I ran into problems with Sleep with my MUT Logger.


I made a Delay like this and it worked well even on my 466 MHz Laptop.

jcsbanks

Nice work!

I think I got sleep down to about 2 depending on baud rate, 10 was just conservative (and also inaccurate from the sounds of the above).

silver_evo

Yeah those use the same timer. For doing high res timer ops you need to use QueryPerformanceCounter and QueryPerformanceFrequency. I use them for the main timing in a PhysX/DirectX 10 Engine i made. Any other timer request use the standard windows timer (innacurate!)

On another note : I need to go back over the code. Im not getting any results with the program. I dont know if the write commands are failing (i doubt it) or if the correction factor is off. I targeted 11.3 and i landed at like 10.7-10.9. Which is safe, but not what i want.

The interesting factor is that my original afr was 10.7-10.9. My correction routine takes the coefficient table (2x2) for the current cells and weights them so the table reflects the current rpm/load. Now if you do this over an entire rpm/load range, some cells will be correct (high weight) and some cells will be unchanged (low weight). If you average them all together (like my program does) then the result will be wrong. Im going to go back over my functions and theory behind this and re-code a little. Will post back later!

Also my correction factor does the following :

I did all the algebra and decided that

float CorrectionFactor = ActualAFR / TargetAFR
float newAF = ( CurrentMapAFR / 128 ) * CorrectionFactor
unsigned char newAFRMAP = newAF * 128

I dont know if the divide by 128 is the wrong way to correct. I know in the past it was

NewMAPAFR = OldMAPAFR * (ActualAFR / TargetAFR)

But that seems wrong to be because the MFPW uses (AFRMAP/128) as a coefficient.

Any ideas?

ziad

iTrader: (1)

u can comment out the sleep.... it does not matter atleast on stock baud. btw at std baud. i am getting 34+ lines of info per seconds and each line has 13-15items logged. so DMA is reasonably fast.

u could even make it faster by having the items repeated in the ram mut table, eg and seeing its a ram mut table its quite easy to save the current table and upload the customised table
rpm,ign,load,afr,knock, rpm,ign,load,afr,knock, rpm,ign,load,afr,knock etc

my idea was to sample data for say 1sec (loadBaroTemp if temp is over 25deg) and then increase timing a little. and then sample.... if all clear for 1 sec then increase again until knock...

obviously that works more on a solid state dyno.

but if your case what you can do is put say a max correction... lets say 0.4 (for fuel) or 3 deg (for timing) and either up or down till you are close and then when you are within 0.4 of the target AFR you can then decrease the correction factor until u are close to 0.1 afr.

btw my program evaluates a given formula... do a search for mcalc or similar expression evaluators.

l2r99gst

iTrader: (2)

You have to be careful with any ignition auto-tuning when you are using a fuel that isn't knock limited. For example, auto-tuning ignition on E85 wouldn't work. You would pass MBT and start beating your bearings. Keep going and risk throwing a rod.

Auto-tuning fuel is definitely a good idea. Auto-tuning ignition needs to be done carefully. If the program could analyze change in acceleration (dRPM/dtime) and tune from that, if it were accurate, it could help to find MBT.

silver_evo

Yeah, i would be very very cautious of Ign timing auto tune. I had the code to read the maps from ROM/RAM, but i decided to just delete them. It was not a good idea. Timing doesnt really change a lot anyways. Fuel can change from one month to the next! Weather

ziad

iTrader: (1)

yes u are right there, i was only thinking of my own car (which is a problem) currently i do use a knock limited fuel... but auto tune timing at only low load areas like say upto 160/180 load... after that i think it will get too dangerous. plus u do not want to do it all the time though... only just when tuning, once done forget about it.


i wont run closed loop fuel/ign via any pc based program.

P.S talk about weather.... it can change up here during the day... like going from 29*C to 14*C during the day haha

sub7

I hope this feature will port to 90550001, continuity from John's DMA work.