ECMspy, megalog tunning

[strmvt]

OK Tuners here is my 1st set of maps and data log that I got a constant 100 AFV on. Question is by taking a look at it should I try a few more logs to get it "perfect" or just stay with what I got? Also working with the timing should I make any adjustments as I haven't messed with anything timing wise with Ecmspy. I can e-mail the log and maps to you for a closer look if you'd like. Just pm me your info.


Front Map

Rear Map

Megalog

 

[Code_4]

Strmvt...how does it feel/ride? I think perfect means you are happy with it...nothing less and nothing more. You map looks very similar mine as far as your values go.

I think I finally figured out the best way to attack mine. I am just logging a lot of rides and hitting the RPM ranges where it is flat, boggy or jumpy. After about 6 or 7 sessions where I only tune with Very Hard and only in one 500rpm window I am really liking what I am getting. The bike is running smooth, power delivery is dead on and at a constant RPM the bike is not jumpy. I think my mistake was leaving my ranges wide and megalog was making too many changes at once.

Anyway, that is my 2 cents. Also I went and did the Tuner Pro thing. My thoughts are if I were a professional racer I might make the effort to tune with that. However, I am not and this method is quick/easy and the results are pleasing me.

 

[strmvt]

Ya she pulls like a freight train thru all the gears no real place to get top speed out of her w/o the possibility of running into some po po. She feels good no stumbling at 2500-3k rpms no decel popping. I was locked at 99.6 afv before I started logging so I was close as it was. I've tried Tunerpro and ecmread. No idea what exactly I need to do with Tunerpro I have the bin files and can load em I think but I can't get ecmread to work I have the mono stuff installed and get a "the procedure entry point g_malloc0_n could not be located in the dynamic link library libglib-2,0-0.dll" error anyways I'm happy with how she feels. maybe if I could get another opinion or two lol I might be satisfied lol

 

[strmvt]

another Q once I've got the maps/AFV @ 100 should I turn off open loop learning or leave it on? Currently I have it as off after I got 100% afv. Also should I leave the O2 sensor on or off. Thanks Tuners =P

 

[Hammel13]

does anybody have a starting point for me i have an -5 xb12r with a race pipe, K&N and breather re-route. I bought the bike like this and i downloaded a race ecm map into it. I get some pinging under a load does anybody know what would cause that?

 

[rham]

Hey guys, I saved my original map to program filesx86/ecmspy/kennfeld but the only thing in there is a dummy file. When I go to open map in ecmspy the file has a lock symbol on it. It opens in ecmspy and says its saved under the kennfeld folder but it doesn't appear when I go to the folder. Also I ran a log but can't find the files from it and have no mega anything folder under ecmspy. Any help would be greatly appreciated. 2006 Ulysses XB12X

 

[rham]

Update, the megalog and datalog folders do exist within ecmspy but also have a lock icon you can only view them by going through the load map dialogue box in ecmspy not through my computer/ecmspy and there doesn't seem to be any data from the log in them.

 

[dallasb]

are you using windows 7?

 

[rham]

OK, I got everything to run by running ecmspy as administrator but when I go to save the analysis that was run by Megalogviewer it says "error saving msq. file, see log file for details". Any ideas? Thanks

 

[sidefx]

I dont know if this has been posted yet but I have a macbook with bootcamp with windows xp installed. I have no programs on xp just using it for tuning.

I have the xopti usb data cable and did my first couple data logs. From a 15 mile ride I'm missing a bunch of cells in the high rpm area. I noticed that there is a lot of lag between the bike and the computer. Also I get transmission timed out and then it reconnects.

Is this a problem with my macbook and usb cable?

 

[rham]

OK, almost there. I tuned my uly with megalogger and burned the new maps. It seems to run smoother but has a hard time starting. Do I need to adjust the cold start enrichment because the only adjustments I made were after the bike reached operating temperature with CSE at 100%? Thanks and sorry for the numerous posts of questions that I finally answered by trial and error.

 

[rham]

Ok so it ran awsome for about two days and then start backfiring on takeoff and running rich as hell in cold idle or any idle for that matter. I followed the instructions to a T so I have no idea. Pasted megalogged file to rear cylinder, made front cylinder the same plus two and now the thing will hardly start after two days. I'm going back to the orignal eprom because it actually made the bike move when I let off on the clutch instead of bog down and die. I think I might try flashing a copy of the original ecm with some race data and switching off the active exhaust. If anyone is still looking at this part of the forum I'd love to hear you're feedback even if it's critical.Thanks

 

[ich]

As long as you do not remove all log records that are written with acceleration enrichment or deceleration fuel cut active, ve analyzer's results will never be correct. It's also recommended to edit the equations mlv uses to calculate corrections. These include a fake/calculated wb-o2 afr value, which should be removed. Using ego correction only is fully sufficient.

 

[xoptimizedrsx]

wrong (again) ich....

I run dual bands both pipes.

spot on corrections.

you can do it with ecmspy

ecm momo (2 ways)

Tunerpro rt 3 plus ways (if you do a csv export and change a couple files) then set MLV to use Load for tps. It will then use the accel data and decel data in account and adjust accordingly

you can do it with a LM logger as well.

done it every way all are stable. some just do it faster than others to final map needed.

Thats the cold truth... off to go to PC engineering class now...

 

[ich]

what ******** is that (again)?

seems we all are airheads, it's just mr. smartass cobb who's got the insight.

mlv does not use accel and decel, nor warmup. that's why the engine byte is there in megalog. feel free to ask phil. i did, i know. you just proved you didn't.

i'm in this business for too long now and i can easily see through you. you do not have the slightest clue of what you are blabbering. barfing up fragments that shall appear knowing, but what comes up is puke only.

 

[xoptimizedrsx]

http://www.ideasandsolutions.biz/MegaLogViewer/veAnalysisFAQ.html#gego


They are for filtering purposes... so it does use them but to tell it to ignore the data in that area... see link above.

old ecmspy didn't record any of these remember. mono does and so does Tunerpro Rt with the correct adx.

 

[gunter]

Sorry to interrupt your most interesting and valuable discussion, but it seems to me, some clarification is required.

MLV evalutates Gego to calculate map adjustments. Gego is ego correction in "pure" megalog (as written by Megatune), and is either ego correction or AFV (depending wich area is active) in all EcmSpy versions. The engine byte although is present only in the Palm PDA version or the Mono version of EcmSpy (or, more generally, where binary log data are stored and converted to csv later).

Acceleration fuel enrichment or deceleration fuel cut is not added to Gego (which will be AFV under these conditions). But as the amount of fuel changes as soon as one of these corrections is applied and as none of them is reflected in gego, these records must be skipped in VE analysis. This is especially required if the default MLV adjustment term (that factors a "fake" WB-O2 AFR derived from NB-O2 sensor voltage into the cell adjustment formula) is not changed or a wideband sensor is used. In accel condition the (fake or actual) AFR correctly indicates a rich mixture (or a lean mixture during decel), which MLV will try to hold up by adjusting the fuel map, although the map has no effect on the actual mixture at this point, which is fully controlled by accel enrichment instead. In decel conditions a second problem appears: due to fuel reductions mixture might get below ignition limit, and in sequence lead to an invalid "very lean" misreading of the O2 sensor.

MegaSquirt-I firmware sends a block of data when triggered, which is explained here:

http://www.megamanual.com/files/ini/megasquirt-I.ini

A part of special interest is the output channels definition as shown below:

[OutputChannels]
; The number of bytes MegaTune should expect as a result
; of sending the "A" command to MegaSquirt is determined
; by the value of ochBlockSize, so be very careful when
; you change it.

deadValue        = { 0 } ; Convenient unchanging value.

ochBlockSize     =  22

secl             = scalar, U08,  0, "sec",    1.000, 0.000
squirt           = scalar, U08,  1, "bits",   1.000, 0.000
engine           = scalar, U08,  2, "bits",   1.000, 0.000
baroADC          = scalar, U08,  3, "ADC",    1.000, 0.000
mapADC           = scalar, U08,  4, "ADC",    1.000, 0.000
matADC           = scalar, U08,  5, "ADC",    1.000, 0.000
cltADC           = scalar, U08,  6, "ADC",    1.000, 0.000
tpsADC           = scalar, U08,  7, "ADC",    1.000, 0.000
batADC           = scalar, U08,  8, "ADC",    1.000, 0.000
egoADC           = scalar, U08,  9, "ADC",    1.000, 0.000
egoCorrection    = scalar, U08, 10, "%",      1.000, 0.000
airCorrection    = scalar, U08, 11, "%",      1.000, 0.000
warmupEnrich     = scalar, U08, 12, "%",      1.000, 0.000
rpm100           = scalar, U08, 13, "r100",   1.000, 0.000
pulseWidth       = scalar, U08, 14, "ms",     0.100, 0.000
accelEnrich      = scalar, U08, 15, "%",      1.000, 0.000
baroCorrection   = scalar, U08, 16, "%",      1.000, 0.000
gammaEnrich      = scalar, U08, 17, "%",      1.000, 0.000
veCurr           = scalar, U08, 18, "%",      1.000, 0.000
blank1           = scalar, U08, 19 ; Raw inputs, as they come from MS.
blank2           = scalar, U08, 20
blank3           = scalar, U08, 21

At offset 3 an "engine" byte is emitted, which reflects the various engine states (cranking, starting, warmup, running, accel, decel). How this byte is set up is documented in the Megasquirt firmware itself, available here:

http://www.bgsoflex.com/v2.98/megasquirt.asm

The engine byte is used by MLV to identify and then skip data records invalid for VE analysis, because of the reasons mentioned above. The meaning of the engine byte is also shown in the lower right of the MLV window, as shown in this screenshot:

If this bar does not appear, then the engine byte is not present in the log, accel/decel conditions will not be recognized by the MLV software and fuel map adjustments will calculated incorrectly.

So far the good news. Now the bad news: accel and decel as signalled in ECM runtime data does not necessarily cover the full period they are active. So instead of using simply the "accel (decel) active" bit, we have to use the actual correction that gets applied. Depending on the threshold, this procedure might widen the gap that's created by MLV skipping records, and decreases the number of records evaluated for VE analysis. X-tau effects, if taken into account at all by the DDFI firmware, remain completely unwatched too.

 

[ich]

cheers for explanation. how is the byte set up, if there's no flag available in ecm output?

 

[xoptimizedrsx]

And from Phil when he looked at the Datalog I sent directly to him.

so you dont think I wrote it ask Phil yourself...

I sent a tunerpro complete data break down and a for Mono mls log for him to view and he sent back this. which is what Gunter said it is using it...

This is what he replied below:
"Hi Mike,
MLV uses the bits of the Engine field to determine if Accel or Decel is active and will filter those. My first thought was that your logs are probably not setting the bits of that field, but in the log you sent it looks like they are set. I'm not sure if they are being set to the same mapping though. So if they are, it would be filtering. I would hope so, or it would be filtering good records.

Alternatively a custom filter could be set up."


Thanks for a very clear post Gunter thats better than I would have explained it.

 

[gunter]

how is the byte set up, if there's no flag available in ecm output?

Whenever possible we try to make use of the flags, as Megatune would do. DDFI doesn't flag cranking, ASE and warmup. Cranking is calculated from rpm, threshold is about 600 rpm IIRC. ASE is ignored, we use warmup instead. Warmup gets off if WUE is below 102.0%, which seems a bit high for me, but might be okay. Running is triggered by a flag, as is decel. Accel is set according to the flag or if accel correction is above 100%.