96530706 + DMA +LiveMap + SD - working
 

OK, finally just ironed out a couple mistakes on my part and flashed my car with 96530706 with DMA, live mapping, and SD. It fired right up and I took it for a quick cruise and everything seems to be fine. I did some brief boosting and things seemed to be good as well...the AFR seemed to want to stay leaner a little too long, but I haven't tuned anything yet (may just need some asynch vs tps delta addition).

Just wanted to report that it all seems to be working well. I have moved the SD maps (MAP VE and RPM VE) to RAM and everything was running fine fom RAM. John's latest LiveMap app allows live tuning of these tables, so tuning SD should be a breeze.

I'll reserve the next post for instructions and XML code to add to your TephraMOD-96530706-v7t6.xml to setup the RAM maps, etc.


Eric

1. Obtain the 96530706 v7t6 ROM from Tephra and donate to him.
Note: If you had already downloaded 96530705 v7t5, delete that and the Tephramod XML for it (or rename the ROM ID in the ROM and the XML files for it). The reason for this is that both ROMs are labeled as 96530706, but some of the tables were moved around and if try to use ECUFlash to work with v7t6 and you already have v7t5 and it's XML, you will start getting some weird table readings from the different inherited XML files.

2. Follow logic's instructions on how to patch DMA to this ROM.

Add one more table to your XML for DMA that will be helpful. This table shows the complete alt map space, which is the block of ROM that John copies to RAM for the DMA and live mapping. This is the place in the ROM where the Tephra alt maps reside as well as the place where we will have to copy any maps that we want to run from RAM and live tune. Also, you can setup a custom MUT table in RAM in this space and set the location in John's LiveMap app to log from that RAM MUT table.

3. Follow mrfred's insructions on how to patch SD to this ROM. Read the first two posts.

4. Follow these instructions to add the SD maps to RAM:

First, add these XML defs to your TephraMod-96530706-v7t6.xml:

The RAM SD MAP VE and the RAM SD RPM VE are just copies of your SD tables from mrfred's patch in step #3. Just make these RAM maps identical to your ROM maps. I categorized them the same, so they should show up under the same category in ECUFlash.

For the pointer maps, change the values to what is shown below. Note that I have added the default values of the maps to the definition, so that you can easily change back:

https://www.evolutionm.net/forums/at...hmentid=137794
In case the pictures can't be read:
FFFF A7A6
FFFF A7C0
FFFF A7D8

Now, open up the 'alt maps space' that is included in the definition that I posted in step #2. We need to add the table headers to the RAM SD maps that you just copied above. Copy the headers as I have them shown below (they must be copied to the exact location, since we are defining them in the pointers above):

https://www.evolutionm.net/forums/at...hmentid=137795
In case they can't be read:
MAP VE - load header: FFFF 886C FFFF 990A
MAP VE - kPa header: 0002 0000 FFFF 886C
RPM VE header: 0200 FFFF 886C

5. Setup a RAM MUT table. This step is optional, but highly recommended, as you can customize the items that you want to log and setup the LiveMap app to log only these items.

Notice in the last screenshot above, that I have shown the location of my RAM MUT table. I start at 0xA740 in the table. All you have to do is start adding the variables that you want to log. For example, the first entry in my table is FFFF 840B, which is 1-byte load for this ROM. Next is FFFF 8BD9, which is timing. I will show you how I have mine setup in the next step, where I will show a screenshot of how I have my LiveMap app configured for logging. You can change these to whatever you like to log and setup the LiveMap app to log those with the correct
equations.

6. Download (updated 7/23/09) the latest version of LiveMap with configured XML files. For reference sake, I have included the main settings below, but this should already be configured for you.

Data tab
Main table is for logging your MUT table. This can be either your default MUT table in your ROM or a custom MUT table you create in RAM, which I just explained in step #5 above. Here is how my LiveMap app is configured based on that MUT table above:

https://www.evolutionm.net/forums/at...hmentid=137796
Just go down the list based on the entires in your MUT table and add the name, unit, and equation to correctly log.

Rom address - this is the address of the alt maps space
Set this to 00 03 7b 00

Ram address - this is the address for the start of the RAM block where the alt maps space is copied
Set this to FF FF a0 00

Bytes to copy - This is the size of the alt maps space
Set this to - - 08 00

Logging address - This is the address to log for your MUT table
Set this to FF FF A7 40 (for custom MUT table as I have shown in step #5)
Set this to 00 03 62 00 (for default MUT table in ROM)


Setting tab - This is where you configure the location of your RAM map data. Set it to the screenshot below and click 'Save to XML'.

https://www.evolutionm.net/forums/at...hmentid=137797
If the screenshot can't be read, the values are as follows:

Ram fuel
Set this to a0 4d

Ram ignition
Set this to a1 8d

RAM RPM VE
Set this to a7 de

RAM MAP kPa
Set this to a7 b0

RAM MAP VE
Set this to a7 c8

RAM Inj size
Set this to a0 40

Note: On the VE/Inj tab there is a little text box to enter your map sensor scaling for the sensor you are using. I have included some common examples for popular sensors. If you will be reading/writing the SD maps to RAM with live tuning, change this to the correct value for your sensor. For example, the OMNI 4-bar should be set to 0.4045. All of the correct settings can be determined from your MAP 16bit scaling as shown in mrfred's post in step #3. (For now, I don't think the sensors with a complex equation will work for this box...it can easily be coded, but it isn't in it's present state.)

Also, there the graphing page has hard coded values. Perhaps in the future, someone (maybe me if I can learn VB better) can setup this page to handle the chart and text boxes to show the data for whatever you want to log.

Keep in mind, though, that your logs still log whatever you have set on that data tab. It's just the chart tab that is currently hard coded.


Eric

nice :)

I really want to get V7 out this week sometime.. been busy :(

Subscribed!

Interesting... I have been toying with the idea of switching to SD lately, i have the 0006 rom ready to go just haven't had the time to fiddle with it... I still need to read up quite a bit as I am not too familiar with the whole SD thing yet...

Nice result, I'll be moving to this ROM once I have a few more miles on my engine and the base map a little closer to where it needs to be.

Sounds like you have a brand new ECU :D

Sweet, glad to hear live-mapping is working for at least one other person. ;)

I think we still need a consolidated how to on tuning SD. The info seems a bit scattered around. Great to see more support on this though

OK, I have upated post #2 with the instructions. It may seem like a lot at first and a bit daunting, but feel free to ask questions. It's really not that bad.


Eric

I had it working for a while until I stuffed my car... :P

Absolutely! :) Again, can't thank you enough for all of your work on this stuff...as well as mrfred, tephra, logic, and others.

Once I am done tuning, I wouldn't mind adding a quick tuning guide to this thread or maybe even a new thread.

Quick and dirty steps, though:

1. Have your boost sensor and MAT sensor installed and loggable. Do some logs with your MAF still active. Do a lot of cruising, trying to hit as many cells as possible, with a lot of data points per cell (the longer the log the better). Also, do a few pulls so that you can reference the load and AFR that you are hitting with your MAF still in place and controlling things. Then plot a 3-D chart of mapvsRPM, with VE as the data. For VE, use the formula: VE=100* Load/(MAP*(298/(273+MAT))). Make sure you are logging baro+temp compensated load.

2. Use the above data to set your intial MAP VE and RPM VE tables.

3. Apply the SD patch and log. See how your trims look now compared to before. Basically, what you are shooting for is to make your load match to whatever it was before the SD patch. If you idled at 30 load, you should now idle at 30 load with SD. If your third gear pull was 300 load peak, tapering to 240 load, with a flat AFR of 11.5, then that is what it should be with SD as well. The idea is to have identical loads between the two. If the loads are different, then you tweak the MAP VE or RPM VE tables until they match as well as possible. Any fine tuning for idle and cruise can be verified with the fuel trims.

That's it. You're done. Now, take off that MAF, install a nice big intake pipe and filter and tune for more power.


Eric

This I have a question on. Initially you need the MAF in order to get usual load values your car reaches. If you take of the MAF then later add some cams maybe, would you have to put the MAF back on and tune on the MAF then switch to SD again?

any change in the airstream should/will affect the VE.

No. You only need to do it one time to setup SD to mimic the loads for your MAF based system.

After that, when you mod further, you just compare your loads/VE from before/after the mods. For example, new cams will increase your VE, so you should see leaner AFR values with your new cams on SD. Just adjust the VE tables until you reach your old values in your before log.

In essence, this way, you can see how much your VE increased due to your new mods and whether they are working. If you ever put in a mod and your VE goes down, then that isn't a good mod. :)


Eric

You can also use SD and live mapping to start up a brand new engine that has never used a MAF if watch the lambda and trims and adjust the injector size to suit. You can preprogram your fuel map to your desired AFRs and then balance injector size and VE to make it happen, based around a 100% midrange VE. It has even been done without live mapping.

I had a Subaru to map last week. It had a misreading MAF sensor due to APS CAI, and injectors, it was also maxxing out the MAF sensor. I would have killed to have SD and live map like on the Evo for that. It took 5 hours when 30 minutes would have dialled it on an the Evo.

Nice job guys, I've had the live map ROM since John released it for the 5.10 & LOVE it!! It's time to move on to the new ROM now.

A big thanks to ALL that made this possible:beer::beer:

I see. Thanks for the explaination. It is how I had initially thought. If you add on some mod to your car then there would theoretically be places where your AFR strays from what's in your ROM's map.

So the idea behind the initial MAF to SD routine is so that you don't start off with values that will get you 14.0 AFR under boost, for example... it seems. (I still have yet to setup SD on my car, but am very eager to).

Logic,
Looking at your post again for adding Live Map to the 96530706, it looks like you put the boost maps(bdel & wgdc) in RAM as well. Am I correct in assuming this?

Well, John did it, and I just copied his work. ;)

But yes, you should be able to adjust the alternate boost maps as well; there's just no obvious interface for it in the client. You'd have to make your changes in the ROM with EcuFlash, save them to disk, then push them with the client; it's a little dodgier, but it should work.

Ideally, of course, someone would add support for those addresses to the client. :)

Just for the record, the full list of alternate maps (from my post alone, l2r's post above adds the SD stuff as well) that are usable in RAM are injector scaling, high-octane fuel, high-octane timing, BWGDC, and BDEL (the last two should be sufficient for both load-based and PSI-based boost control, in case anyone is wondering). Technically, everything between 3B700 and 3BEFF in the ROM (ie. most of tephra's stuff) is copied to RAM, but that's only half the battle; you then have to change code to reference the new RAM addresses rather than ROM, and for quite a lot of stuff in there, it's really not worth the trouble and added complexity.

Hey guys....I just edited post #2 above the livemap step #6. I tested writing to RAM today and it wasn't working. I think I may have missed something in the LiveMap config, since this latest release was initially setup for the 885 ROM. I will go through everything and find what I need to update and update post #2, if necessary.

If I can, I will just compile a new LiveMap app with all of the XML files already setup for you.


Eric

Sweet, I'll hopefully switch over this weekend & try it out. I think that I will get the car running on Speed Density as well!

Keep up the good work guys{thumbup}

I f***ing love you. (no homo)
If you end up at the S.O. you will have beers on me for this..!
{thumbup}


I'm wondering about the SD stuff though, I have everything on the car needed to run it. But I haven't had a MAF on this car in almost 2 years now... Having airflow #'s and temps constantly fudged by the maft-pro is getting OLD. Like... Yeah ok ecu... I'm at 260 load at 28psi on a 3076R ... no. I can flow 360g/s at 260 load? I was just tuning another 05 with the stock turbo and about 19psi ---taper--> and he's hitting 250-260 load. at 250g/s...

How bad is it going to be to fudge my way through this without a MAF / live mapping?

Or am I just going to hit load limits and have to rescale things... a lot.

OK, I need someone to host the new LiveMap app. I am still working on it, but I compiled a new one, with charting. Also, I noticed that the ms in the logging isn't in this source code I have. So, I am going to add that as well. I'm about to sit down now and figure out the ram writing issue.

So, when I am done with all of this, who can host it for me? The files zipped up are going to be just too big to post here.

sending pm :)

I just remembered that my ISP (comcast) gives hosting space. I forgot that I set that up a while back. So, once I finish the new LiveMap app, I will give the put it there and post the download link.


Eric

EDIT: Less talking more reading for me.

Did you download v7t5 previously?

If so, get rid of that tephramod xml file and try again.

Eric, just fyi: if you end up needing space to share stuff like that, you can always put it up on the wiki somewhere. It's not the most convenient place to host that kind of thing (mediawiki's file management support, frankly, sucks), but it's there if we need it.

EDIT: Again more reading less talking.

Show us some screenshots.

So, you completely removed the old v7t5 xmls?

OK, the writing is now working in the LiveMap app and I have compiled a new exe. I will upload to the Wiki with all of the pre-configured XML files and provide a link in post #2.

And, just an FYI: I had to update the DMA/live-mapping instructions, thanks to a bug that l2r99gst found. Updated instructions are here, and if you've already applied the original instructions I posted, a quick-fix to correct the error is posted here.

The problem isn't serious, but it means that only logging and reading from RAM work; writing to RAM fails completely. It means that changes made to the fuel/timing/SD tables can't be written to the ECU live (but can still use EcuFlash to do it) until the fix is applied.

Sorry about that, folks. At this point, though, I think everything relating to the DMA code has been tested and appears to be working as well as John's original code did. Until we find the next bug, of course. :)

(Edit: Eric beat me to it. ;))

My next question is this... is the SD patch dependent on the DMA / Live mapping stuff? Or will the SD portion work BY itself.

SD is independent of DMA/LiveMap.

The SD tables are the same between 96530006 and 96530706. The only reason I asked about v7t5 is because if you had that in the past, then you have to get rid of it's XML file (or completely rename the ECU ID in the ROM and the XML file).

We'll wait for the screenshots of what you are seeing...maybe that will explain what's going on.

EDIT: More reading less talking.

Everything looks fine to me from your screenshots if you are looking at a 96530706 ROM that isn't patched for SD yet. Which ROM is that in the screenshots? Is it one that is supposedly patched for SD? I bet that it is just a plain, old 96530706 ROM.

I think you know this, but just adding the XML definitions for the SD tables isn't adding the patch. You have to copy the table data from a known patched ROM into your ROM.


Eric

I've never patched a rom that had what looked like an endian problem / or scrambled table. It usually meant the table it was showing, was not defined correctly. So I just copy right over this crap? REALLY? Oh then I am just a total F idiot. Any time I have previously seen what looked like 6555333 number strings in tables they were not correctly defined in the xml. (IE: I boned something adding the code or patch)

So I'm just an idiot. I just flash w/e right over this stuff and it's fine? :lol:
{pcfreak}:banghead:

Yep, just apply the patch instructions that mrfred gave right over what you see in the tables. The weird values are from the scalings that are used for the tables.

For example, look at the first table in your screenshot. This is blank area in the ROM that just has FFFF hex code.

But, that table is defined with certain scalings. The left column is defined by the Map 16bit scaling. It likes you are using one that is x*.3333 for the JDM 3-bar map sensor. FFFF (hex) = 65535 (dec). 65536*.3333=21843. That's exactly what's showing in your non-patched table.

The right column is handled by a scaling that is x*(5/32)*.596. 65536*(5/32)*.596=6103. That's what you are seeing in the right column.

So, yeah, it probably looked a little screwy at first, but that's how a non-patched ROM looks. Also, the last table in your screenshot is one of the actual patch tables (not the tuning tables). Mrfred didn't include anything for the left column. You just need to copy the right column.


Eric

Just a quick update. I went for a long cruise to start tuning my SD. I have idle and cruise just about perfect (trims are right where it was with the MAF, very close to 0). WOT is close to perfect, but haven't tuned that yet. That's my next step. Everything was almost spot on just with my initial settings from my MAF based logs.

It could be in my head, and I will have to study the logs to see, but during a normal low throttle (low map), 2000-2500 RPM cruise, it almost seems like I am getting very rapid but small fluctuations in power...almost like very minute changes in throttle or timing feeling. Sort of like a non-smooth feeling. It's hard to explain. Has anyone else that has converted to SD experienced this at all? Like I said, it may be in my head since I am overly sensitive since I just switched, but I was just curious if anyone has any input.

Just as some notes, I am using tephra's map averaging. I haven't tried with that off yet. I have also increased the asycnh accel vs tps delta table by 8 points across the board (suggestion from John). Overall, I would say I am 90% there, just from one quick tuning session. Of course the LiveMap app helped with that.

On a side note, I am learning VB and I am coding up some changes to the LiveMap app. I am trying to set the charting page so that it automatically grabs what you are logging from the data tab and uses those formulas to show over to the right of the graph. Right now they are hardcoded. If I can do that, then I will look at the chart itself as well.


Eric

I followed your instructions and got this loaded on my car last night, but didn't have time to get started on any tuning. It seems to be all working so far, and the MUT table in RAM is a nice touch - I have one set of values in the live map app logged from the MUT table in RAM, plus the standard MUT table still in ROM so I can still log with Evoscan if I want to. Hopefully over the weekend I'll get some time to work on the tuning and can then report back.

Big thanks to all those who have contributed to this, for me it's a real step forward in what's possible with a stock ECU :cool:

Eric, you may just be feeling closed loop working, I could feel it when I had heat range 9 plugs on a heavily tune Subaru in cold weather, but not otherwise on any other setup. It is possible to have the long term fuel trims near to zero but with some areas still positive and some still negative, but if you're plotting STFT over MAP vs RPM you should see anything funny. It might settle after your trims stabilise. I didn't feel it on SD on my Evo though.

I have a 96530006 rom that is DMA and tephra modded.

I tried to add the alt maps space definition you gave and when I pull it up the entire table is FFFF.
Is it supposed to be that?

That is where the alt maps are located in ROM isn't it? So the entire thing shouldn't be FFFF.

edit: I guess the 96530006 is different from the 96530706. I went with the address that was hard-coded in the Evo Live Map (38b00) and it seems okay now.

edit2: I further confirm 38b00 is the start address for alt maps space in 96530006.
On my 'alt maps space' table the value in 38b40 is 0x0039.
Alternate Injector Scaling address starts at 38b40. I changed the scaling of that table to hex16 and its value is 0x0039.

Yes, 96530706 is different than 96530006.

Btw, I tested my new version of LiveMap today and it actually worked. For now, I have the graph set itself up with the first 17 items that you have listed in the config table on the data tab. Then, next to the graph, I have the labels and text boxes grab the name and values for the first 17 items from that table. Next to the value box, I have a checkbox that shows/hides the item's curve in the chart.

I will post it up later if anyone wants to take a look at it. I may try to add some more coding to it as well.


Eric

Sounds good. I have everything ready just waiting on the AIT connector and some ecu pins. I didn't want to cut up the Maft Pro wiring, just in case something went south.

And then my AC compressor locked up out of the blue yesterday. So I'm still a little ways out from being able to try it. The rom is ready. Looking forward to your newerest version of live mapping where it grabs your items for the chart. (Since you hard coded the omni and I'm using JDM MAP)

So please post it when you are done fooling with it.

Is there a way to run this map without the air intake temp sensor reading, that is, reading the temp from the maf sensor?

If you want to run SD, then you need an AIT sensor somewhere in your UICP or IM.

OK, since I'm not sure how much time I will have this weekend to do anything, I will just post up the .exe that I tested out, just in case you want to give it a look or use it before I get my final version out. I'm sure there are bugs in it, and I was messing around with the lines in the graph for some of the items, but here it is. Once I get a final version out, I will update post #2 with it.

Just add this to where you have your LiveMap installed and run this .exe instead.


Eric

OK, I went for a couple long cruising sessions today to tune my SD. This 1800-2400 RPM range issue isn't just in my head. I'm looking at my logs now in Logworks. I think there is just rapidly changing VE in this area that I'm not accounting for in my VE maps yet or something. It's weird that it's just this small RPM range at a small map range, too.

If I am at a low throttle and slowly going through this range, I get the issue. The log verifies it by a very slightly bumpy RPM line and a pretty bumpy IPW. The IPW line is a bit jagged up and down, but just through that little RPM/MAP range. Once I get past it, it's fine, or if I go through the range at higher throttle, it's seems to be fine. I've tried a bunch of combinations of RPM VE and MAP VE, but nothing seems to have worked yet.

I just started studying the logs, so maybe I will find something, but just wanted to post up, in case anyone has an idea or similar experiences. I don't think most people will be in this range, but I tend to shift and cruise so I am just above 2000 RPM, so I hit this range a lot.

EDIT: OK, I think I have narrowed it down to 65-85 kpa/1800-2400RPM. Both of those have to be true for the issue to show itself.

Here are three areas of that log to illustrate what I mean. It may be hard to see with a lot of crap here, but the bottom half of the graphs are the area to look at. I have two markers for the RPM range, which are dotted red and blue horizontal lines. The IPW is a light blue, load is red, RPM is light purple, map is blue:

https://www.evolutionm.net/forums/at...hmentid=137997
This is right after a shift, coming into the problem area. Even though I stay in the RPM range here, once the map drops below 65kpa, everything smooths out. Notice the jagged IPW in the trouble area.

https://www.evolutionm.net/forums/at...hmentid=137998
The left side shows the trouble, the right side shows normal. Notice once I get over the RPM range, everything smooths out nicely.

https://www.evolutionm.net/forums/at...hmentid=137999
This one shows a good example of a nice smooth IPW on the left side of the graph. Then, when I cruise through the trouble RPM zone at the right map, you can see the jagged IPW and even a couple areas of jagged RPM. It almost feels like very minute repeated fuel cuts.

Besides this one little nuisance, everything else drives 100% perfectly. WOT is perfect, idle is perfect, cruise is perfect outside this particular RPM/MAP zone. LTFT Lo and Mid are right around 0. As long as I can figure this out, it will be 100% done.



Eric

Is this new pc app universal for live map or is it specific to the v7t6?

It looks like you got a good start on SD. I started on getting mine running as well but still have more to do.

The LiveMap app is univeral, but it needs to be setup for each ROM with all of the correct locations, etc.

Ok, thanks

I did not see this and a considerable part of my commute was under these conditions.

Load looks a bit bumpy there as well as RPM which is probably effect rather than cause.

A few things I thought of:

What about logging 16 bit MAP in this area to see if there is more noise?

Could there be electrical noise in the MAP signal or even cam or crank position sensors? Do you have your MAP signal routed near sources of noise?

I don't think is near the over-run fuel cut off or closed loop thresholds which probably have hysteresis on them anyway.

I may be off base, but the outputs of the SD calculation are load and IPWload, since they work normally most of the time that is why I'm suspecting electrical noise.

Odd one though!

Well, I'm using the OMNI 4-bar map sensor, which is usnig the stock MDP harness. So, there isn't any unusual routing or induced interference on my part.

I was thinking about logging a better resolution map. The map in the logs is pretty much dead flat, but the resolution isn't that great. I do agree that the load looks a little bumpy as well, but not as much as the IPW would suggest. That's what strikes me as odd. Nothing else in the log really indicates what is going on here. The only thing I could possibly think of is that the map is fluctuating there, like you suggested, but I can't see it without the 16-bit resolution.

OK, so the next obvious question in case I can't find it....what variables do I log for 16 bit map? I remember seeing a discussion on this somewhere, so I will start searching.


Thanks,
Eric

16 bit MAP is the input to the axis "SD MAP sensor VE and calibration" table, so IIRC how the Mitsi ECU works (I'm afraid it is getting displaced by other junk) it will be in the header.

From a log you should be able to replicate the calculations that the SD conversion uses from the two VE tables, RPM and MAP, so you know what the non temperature compensated load will end up as. Thing is, if it works with expected load values in all other situations, I can't see why it would be wrong. Junk in = junk out hence why I wondered about interference, but using the stock wiring would suggest otherwise.

Could the timing be funny in this area? Might be worth using more or less, turning closed loop off etc to see if it goes away.

Timing is the dark blue line at the top of the logs. It is in a transitional area and I was thinking about just blocking that area as a test. However, I think my loads are matched pretty well from my MAF logs, so this should be the same area that I was hitting previously.

OK, I should have enough to try now at least. Thanks for the input.


Eric

Eric,
Not sure what I did wrong, but while the car is on (not running) and I am watching the charting, knock goes up as i press the gas pedal, and rpm is constantly hovering @ 5000. Oh yeah, and it wont start, but I just attributed that to me not having my ve dialed in at all.

Can I email you my rom and xml and have you take a look at them. I am 99% sure they are all right.....i spent an hr changing everything and double checking. Either that, can you email your rom and xml so I can compare them since I know you are busy? My email is tom04841@juno.com

Sounds like you don't have your RAM MUT table setup like mine. You have to setup your LiveMap app (the big table on the data tab) to match the variables that you want to log.

So, for example, if you want to log 1byte load, timing, knock, map, etc, etc, etc, then your RAM MUT table has to have those variables in the correct order and your data tab has to have the correct formulas in order.

Just post up a screenshot of your RAM MUT table and the first page of your LiveMap settings.

Also, for the not starting, if you are switching from a different ROM, make sure you change the periphery to allow your immobilizer to work.


Eric

http://img23.imageshack.us/img23/7514/rammut.png

http://img31.imageshack.us/img31/5186/evolive.png

There ya go. See anything fishy?

That looks OK to me. Is this going into your Galant? Or do you have an Evo?

If it's an Evo, I'm not sure what is wrong...if it's in your Galant, I would have to guess the wiring harnesses and sensor pins are in different locations?

Its in my Galant. wiring isn't the issue.....i have been running 9055 for the past 6 months without any issues. Can you send me a copy of your rom so I can try it out?

OK, I did a log with 16 bit map and it's still pretty smooth during the jagged IPW. The 16 bit map varies maybe by 1-2 kPa. So. something isn't quite adding up.

Just for testing purposes, I turned off Tephra's map averaging and reworked my VE tables to try to even more closely match my MAF logs. The issue did seem to become a little less noticeable, but the logs still show the jagged IPW for no apparent reason.

I will read through the original SD threads, but how is the IPW calculated with the SD patch, so that I can log everything and see what is the cause? Here is a screenshot of a log with the 16 bit map. In 0.15 seconds, the IPW goes from a low of 2.80ms to a high of 4.40ms (shown in the boxes in the screenshot). In 0.08s later, back down to 2.80ms, and then 0.08s later back to 4.40ms again. The MAP shows about a 1.5kPa difference and the RPM shows about a 50 RPM difference. Everything points to the fact that the IPW should be the same, yet it is jumping up and down like this. Once I get out of the culprit RPM/MAP range, the IPW smooths out. At idle, it is dead flat.

https://www.evolutionm.net/forums/at...hmentid=138096

Does anyone else running SD see this issue at all? Mind posting up a log of a cruise going through low to high RPM, lower to higher map?


Thanks,
Eric

I haven't Played with this since last weekend so i'm not quite that far yet. I haven't been able to get enough fuel in it to make it out of the driveway yet, It stays way too lean & goes leaner on throttle tip in. I increased Async_vs_TPSDELTA to no avail. I got a xml put together today & the 96530706 ready to load . May give it another shot tomarrow, live map will help a bunch.

Do you think having a Rescaled Airflow/HZ Raw scaling table could create problems with trying to dial in SD? The reason I ask is because of the Alternate tuning method using the MAF compensation table.

Make sure you don't have the load limit removal patch in place. That was my issue when I was first testing this for mrfred, and based on your description, it sounds like your issue as well.

It's the patch where you put 0x0009 to remove the 380 load limit. You have to put that back to it's stock value.

By the way, I found the IPW calculations I was looking for in John's thread about maf pulse to IPW:
However, I think I will need John to translate that for me and what had changed in the SD implementation. :) I need to get to the bottom of why my IPW is so jagged in that map/rpm range.

I have searched for the code to put in the xml file, but can't find it. Can you post it up so I can double check my rom as well?

Nope, I just double checked & it is reset back to stock (0x2bA1) I'm going to load the new ROM with a stock Airflow Hz Scaling table in this afternoon when I wake up & play with it some more, It's probably something simple:)

Set to 0x0009

<table name="Set to 9 to remove load limit" category="Misc Limits" address="27824" type="1D" level="1" scaling="Hex16"/>

gear head - If you are talking about your maf scaling table or smoothing table, then yes that will affect SD.

I should post up a new version of LiveMap that automatically charts and displays data for up to 34 items from your data tab. Each item will have a checkbox to chart it or not.

Just have one more thing to figure out-how to autoscale the graph after an item is unticked. It already auto scales when ticked, but stays at that scale when unticked. I think I know how to do it. If I can figure it out and test today, I will post up the new .exe later.

Edit: OK, I think I have it all figured out. I will give it a test today after work and post it up if it works.

Thanks for the input Eric, I got fuel now:) I just need to find a decent amount of time to get this thing dialed in. If I come across anything similar to what you are experiencing I'll post up a log.

OK, here is my latest revision of the LiveMap exe. Just copy this to the folder you are running your current LiveMap from and run this exe instead. I'm still going to go back and change the colors of the curves to make sure all are dark enough to be read, maybe get rid of or add different line symbols, etc, but for now, this should help you with charting, and at the very least, with live data display.

Here are couple of screenshots to show what is going on. First is my Data tab, which shows the config table. Notice the entries in that table. The second screenshot is the chart tab, which labels the curves and live display text boxes based on that table. The evals also come from that table. The checkboxes next to each live display data text box is whether you want that data charted or not.

https://www.evolutionm.net/forums/at...hmentid=138179

https://www.evolutionm.net/forums/at...hmentid=138180


Eric

Thanks for the updated live map app, it's much better being able to select the graphed items. I only wish I knew some VB programming so I could add some useful updates myself rather than relying on others to progress the development of this.

One thing I noticed last night, and I'm not sure if it's a mistake I made yet or not, I have the analog output from my LM-1 connected to the 2nd Lambda sensor input to allow logging. Using my current ROM (9626009 with Live Map added) this works fine. When I switched to my created 96530706 (with Live Map & DMA, but not SD added yet), the value no longer reads back from the ECU in the live map app. I'm pretty sure my addresses are correct, using the RAM MUT table, and the hardware deefinitely works as swapping back to my old ROM has it working again straight away. I should have thought last night and tested with just the straight 96530706 logging via Evoscan, to see if the error occurs after the DMA code is added or if it exists in the original tephra ROM, I'll test that tonight if I get a chance.

Eric, there have been so many changes to your ECU, I wondered whether you were able to test an SD ECU as mrfred posted for your ROM to see if that did the same?

The other problem is I didn't write any of the code for your ECU and it is feels so long ago since I coded & tested this I literally cannot remember.

From memory, the SD calculation interferes with very little which is why I would hope to exclude it as a cause with minimal logging or running dummy values through a simulator.

MAP is measured 10 bit, used as an input to the MAP VE and calibration table, the interpolated result is used. This is multiplied by the RPM VE and the result stored in a variable that usually would limit the load. From this the ECU calculates another variable that is used for IPW (MAFMULTIPWARMUP or something like that), but I don't interfere with that.

The two NOPs in the MAF routine reroute the code so that what used to be the load and IPW limits are instead written to the two variables.

The rest is just error removal etc.

So the actual calculation can be validated at the time your having the problem as:

Load is proportional to MAP VE output * RPM VE

If you see this rule being obeyed during your IPW glitches then I don't think it is from the SD patch unless mrfred did something differently to how I coded it, or something else you're doing is interfering.

As said, depending on the spec of your car I'd go to as near a standard ECU as possible that will run your engine and just put the SD patch on and see whether it still does it.

Sorry I can't pinpoint your problem easily.

Thanks for the input, John. I will eventually figure this out. :) I was just trying to hopefully eliminate as much of the standard troubleshooting routine as possible. I will start back at the beginning with a fresh SD ROM patch only and test again. I may even point the VE maps back to the ROM addresses to see if that makes any difference. I have several things to test...just wanted to maybe take a shortcut to the solution.

To help me out, I am hoping others that test 96530706 can post some logs as well. At least that way I can pinpoint whether it's something with the SD patch on this ROM or not.

By the way, I'm sure my VB code isn't that great, but I updated your LiveMap app (see above), so if you are tuning any Evos in the future and don't have time to update the app, I have updated the charting page to automatically grab the values for the text boxes and charts, with the ability to turn on/off each item in the chart.


Thanks,
Eric

Look like some ace updates Eric!

I wondered if the second load value (the IPW calc one, it is MAFSOURCEMAINxMAFMULTIPWARMUP) may not be being updated, but apart from the NOP I think I just used the ECU's code to calculate this from MAFSOURCEMAIN.

Yeah, that's why I was asking about how the IPW is calculated, but I think I first have to do what you said and test a fresh ROM with just SD and go from there. If that has the same problem, then hopefully someone else can test this ROM as well and post logs. If they too have this issue, then I can ask mrfred to look at the SD code once more, to make sure that nothing is awry. Obviously, if I or others test this ROM as OK somehwhere along that path, then I know it's something in my ROM.

Is there any way to log the MAFSOURCEMAINxMAFMULTIPWARMUP? Any kind of a RAM address that holds that calc?

I'll hopefully be in a position to test this in the next week or two; I finally got my IAT sensor installed last weekend, so now it's just a matter of finding time to get the wiring done.

Thanks. That will help me on my quest of solving this problem.

In the meantime, what do you guys think about a black background for the LiveMap chart? Is something like this better, or do you prefer the white? Also, here I put in major gridlines for the Y axis. Good/bad? You can see a comparison screenshot on the previous page:
https://www.evolutionm.net/forums/at...hmentid=138204

Since I have the code working how I want it now, I am going to clean up the colors and symbols on that chart so that all of the colors are visible. I may make one exe with a white background and one with a black background.


Eric

Yes it will be loggable, you'll find the address in the few lines of code around the second NOP in the MAF routine.

Haven't officially tested this yet, but all I did was change the colors, so I don't see them not working. Here are two different exes...one for the white chart background and one for the black chart background. I tried to choose better colors and when I reused them, I added a symbol to the curve.


Eric

OK, here is the code for my ROM around the second NOP (at 0x2781C). Do you remember which variable would be the one that would hold MAFSOURCEMAINxMAFMULTIPWARMUP? Don't go out of your way to figure this out, though. I know you're busy and you didn't patch this ROM. Maybe mrfred can jump in here and answer.

I may just try flashing a new ROM today with only SD for a quick test.

The nop makes it run the code in the following lines, so FFFF89B4 is read and then written to FFFF89AC, so FFFF89AC is the one to log. You will probably want to log the low and high bytes. You should see it move in proportion to load at a steady coolant temperature, but I never logged it.

However, the SD patch if working properly should be just writing to MAFSOURCEMAIN in the nop before this one we're discussing, and MAFSOURCEMAINxMAFMULTIPWARMUP. If the values during your glitch are smooth and follow what they should be based on your MAP and RPM VE at that point, I struggle to see how it is SD patch related.

I never used MAP smoothing and would recommend you don't also for SD, it will kill the transient response which is crucial on SD, you'll end up with large lean holes.

I'm going to give this another go this weekend....I can post a log or two. Any particular format you want to see? I have been using logworks to view the DMA logs, as I'm sure you are doing the same, so posting a screenshot of a log graph or charts is no problem. I wouldn't mind some constructive criticism myself, setting up Speed Density is still new to me...I'm an old carburator guy;)

Yeah, just try to get into the 1800-2500 RPM/65-85kPa range and show some screenshots of those conditions. Traveling through it slowly would be good. I just want to see if others are seeing the same thing as me or if it's just something on my end...maybe I just need to analyze my VE tables some more?

Anyway, here is a new log. This time I used my old v5.1 tephrarom with DMA/livemap. I didn't put the SD maps into RAM though, since I already have them tuned from the previously logs with v7t6.

I flashed the car and went for a cruise to go gas up. It actually seemed a lot better...but I did notice the slight hesitation, jerkiness, so I knew the issue was still there. Here is the log, with 89ac+89ad included (MAFMULTIPWARMUP).

https://www.evolutionm.net/forums/at...hmentid=138218

Looking at the bottom half of the log, the top black line is TPS, then one down is MAFMULTIPWARMUP, 1byte load (red), IPW (light blue), 16bit map (light gray?), and 2byte RPM angling up through them.

I put vertical markers to show the trouble area. Again, like clockwork, it starts at about 85kpa/1800RPM and lasts until 65kpa/2500RPM. The other lines are bumpy as well, but what I would expect to be normal. Nothing jumps as much as the IPW does...MAFMULTIPWARMUP does seem to slightly coincide with the jumpy IPW, but not entirely, and it doesn't seem to be as much. So, it's very confusing as to what exactly is going on. The VE is relatively flat in this area as well, so any interpolation shouldn't be too big of a jump...but maybe that's where I need to concentrate again. I remember making a 3-d chart from my 2 VE tables and comparing this exact area to the 3-D chart from my MAF log and everything is very close.

I will leave this v5.1 ROM in for a couple days of driving and see if I notice it as much as the v7 ROM. If so, then I guess I will try a plain old stock ROM, patched with SD. Hopefully, in the meantime, a few others using 96530006 with SD can post some logs as well.



Eric

Good graphs, but the only one that looks funny is the IPW, so it doesn't show the SD variables misbehaving, and I'm starting to think this is not related since the SD is just changing the variables you've logged and they are working. I'm afraid it will need testing to the point where you have a proven stock(ish) ECU setup that doesn't do this, and then add back in the minimal elements of the SD conversion to see if it then reappears.

It is a bit tricky with the labels and colors to see what the STFT and Narrowband O2 (which is close coupled, fast and great for seeing oscillations around stoich) does during this time. Have you tried turning closed loop off to see if it still does it?

STFT is the sawtooth in the graph, just above center. There looks to be no correlation with the jagged IPW and the STFT. I agree that it may not be the SD patch entirely, but this issue only came about when converting to SD. It may possibly be some other patch interfering with SD or just a coincidence that it showed up when I made the switch, with no correlation. To be sure, I will also flash back to my MAF ROM to test.

I have not tried turning off closed loop, but will add it to my list of things to try. Since the weekend in just about here, at least now I can try all of these things. I plan to have this tested a million ways before the weekend in over. :) I want to install my 4" intake and filter, but want to iron out this small issue before committing to full time SD.

John,

Quick question for you:

Did you only change the asynch_vs_TPSdelta table or did you also change the asynch_vs_RPM table as well? I notice the latter has 0's in the 1500, 2000, 2500 RPM bins.

I added 8 to all of the bins for the TPSdelta table, as you mentioned. I think I tried adjusting the RPM table as well to be sure this wasn't the issue, but I don't think that helped.

Your IPW issue is at steady throttle, so nothing to do with acceleration enrichment, but yet I just adjusted the TPS delta table. You may be better adding more than 8 to the bins, but I would try without MAP averaging first.

OK, thanks. Yes, map averaging is already off. I just did a log with full time open loop, so I am going to analyze that now.

Edit: Just analyzed that log and the issue still persists. So, seeing that this is happening during open loop as well, this must be issue with my VE tables. My VE analysis pre-SD showed a relatively flat VE in that area and I had it matched up well, but maybe I need to readjust my bins for more detail and control. Looking at my tables and creating a pseudo 3-D map from them, there are no jumps in VE going through that range that would seem to match the jumpy IPW, though. So, I still don't really understand where this jump (or fallout of IPW) is coming from. I say fallout of IPW because upon analyzing some of the logs further, it almost seems like the IPW is following a nice curve or path, then just dips down, then recovers, then dips, etc. Interesting to say the least.

For my map bins, I have 10, 40, 50, 70, 100, 170, 200, 408 (Omni 4-bar). These were chosen based on areas of changing VE, where interpolation would cover the values in between. But, I am thinking of maybe adding a 60 and 80/85 to see if I can get better tuning for this specifc area only. Maybe I can change one at a time and see if it helps, hurts, or doesnt affect this issue.

Anyway, thanks for all of your input, John. I have a lot to test this weekend.

Eric,

Can you post a zip of the whole directory for the new livemap? I just unzipped the EXE to the folder were the older version was and it did not work.

Joe

You probably don't have the new XMLs for the VE maps. Go to post #2 in this thread and download the zip there. Then you can use the new exe.

OK, I think I finally found the correlation. I think it has to do with Maf Hz. I logged 2-byte Maf Hz and went for a cruise/log today. When I zoom in on Maf Hz to provide sufficient resolution, Maf Hz seems to almost completely correlate with the jumpy IPW.

I will have to re-read John's thread on the full path to IPW to see if he talks about it, but how is the Maf Hz calculated with the SD patch? John, if you read this, and know off the top of your head, let me know. Mrfred, if you read this and know as well, any help would be appreciated.

I'll try to post some screenshots to show what I see after I am done looking over this entire log.

OK, here is a screenshot that shows what I am referring to. I have the Hz zoomed in quite a bit, so that may be exaggerating the correlation, but the jumps/dips in Hz are about a swing of 10Hz in the 150 Hz range. It may just be a combination of everything: map, map ve, rpm ve, hz, stft, all playing their own part. But, I don't understand why it happens in this one specific map/rpm range though:

https://www.evolutionm.net/forums/at...hmentid=138274

The Maf Hz is the jagged line on the bottom...the IPW is the jagged line just above it.


Eric

Eric, I'm noticing the same hesitation/jerkiness that you are experiencing as well.
I'm going to play with it some more before I post a log.

That actually makes me feel a little better and gives me hope that it's not my ROM or something that I have done to it.

Maybe it's something just with 96530006 since John hadn't noticed anything in his ROM. I'm curious if others using SD have experienced something similar. I think Creamo3 in the other thread may be experiencing something similar with a different ROM, but I haven't seen any logs yet.

Well, I made some progress today, still have a ways to go though.

Eric, attatched is a DMA log saved as .log file that can be viewed in Logworks if you want to see if the same problem is there. I can defanitely feel cruise is rough in the same RPM window that you are describing, kpa in that window is a bit lower than yours probably due to altitude.

Any chance the jitter in the MAP is just the cylinder pulses?

A lot of guys that run speed density tend to get the MAP off the manifold and onto a line. The flexibility in the line combined with the volume of air in the line help damp out the pressure variation generated by the dynamic nature of the IC engine.

The pulses are likely to be most prevalent in mid throttle conditions where the pulses are strong from higher engine speeds, but the throttle still posses as a throttling device to drop average plenum pressure but not greatly reduce pulse transportation.

Eric, I'll have to read the other thread as well to remind myself what filters are on it and the exact calculation, but MAF Hz is part of the IPW correlation. MAF Hz is calculated from the MAFSOURCEMAINxMAFMULTIPWARMUP, so I suspect you'll also have some jitter in the load value as well when you look closely, but maybe the MAF Hz calculation amplifies it if RPM also starts to jitter.

I think at this airflow/engine speed/pressure you have some resonance or you're picking up pulsations. I did not see this with the JDM MAP sensor in its original place. Perhaps it has a slower response time, perhaps it has a different diaphragm arrangement to the MAP sensor you're using.

So, we'll look at the MAF Hz calculation & filters, you can think about your MAP sensor. I doubt that mrfred has done anything different with the code, otherwise you'd have a systematic offset or problem, rather than a resonance at a certain point.

https://www.evolutionm.net/forums/ec...tor-pulse.html

From the first post in that thread:
AIRFLOW=MAFSOURCEMAIN/TIMEBETWEENCASPULSES, used to lookup MAFSCALING, MAFSMOOTHING, TEMPBAROAIRFLOWLOOKUP to give MAFsmthsclgfactorxINJSCALING

AIRFLOW is like LOAD*RPM then.

MAFSCALING is doing part of your VE compensation, but it doesn't seem steep at about 150Hz, but any RPM fluctuation induced could amplify the problem.

The filtering is done before load is calculated, we could change the filter level and make it smoother, but this may reduce transient response elsewhere - CORRECTION - see next post.

Since I no longer have my car (although I am adoring the new one ;) ) I cannot do detailed logs in this area to prove categorically that the JDM 3 bar sensor fixes it.

Do you have an option to borrow or try or switch to a JDM 3 bar or do you want to play with the filter which I can find for your ROM?

The filtering is done based on previous and present MAF sensor pulse counts, but it is done BEFORE we replace the values with our SD calculations, so there is NO FILTERING with SD, so no filter to adjust.

So two options, you could use Tephra's MAP averaging (if he has made it adjustable, I never tried it) and see if there is a good compromise that makes it smooth without killing throttle response, or you could look at the MAP sensor hardware you're using and if you don't need more than about 30 PSI you could use the JDM sensor (need to confirm with other's logs that it doesn't do this) or identify other sensors that don't jitter like this.

Gear head - thanks for the logs. I will take a look later today when I get a chance.

John - thanks for the help and insight. I actually re-read that thread and was going to ask about the filter for Hz.

I have another thought, that may or may not help much at all. I was thinking about flattening the maf scaling and maf smoothing table (maf smoothing is already just about flat) in the area of concern. Since we have the map VE and RPM VE tables to adjust, we shouldn't need the maf scaling table (which is basically another VE table) to add in another source for error. Sort of like the reverse of your easy speed density thread, except just target the 125-225Hz range.

As far as the map sensor: I have tried tephra's map averaging and the issue was still present. I have also logged 16 bit map and the variation was subtle during this...maybe 1-2 kPa deviation. The only thing that remotely seems linked so far is the Maf Hz. RPM does seem jittery as well sometimes, but I think this is a side effect of the IPW being jittery, so an effect rather than cause.

So, I'll give the maf scaling thing a try and see if that helps the issue at all. I hope this doesn't scare people off though. I have been running this patch for more than a week now and daily drive the car with it. Everything works fine outside this small range, but obviously something is a amiss and I would like to figure it out.

Thanks for your help, John, as always. Enjoy your GTR. :)


Eric

Thanks for the log. I just took a look and you seem to have the same issue as me, in pretty much the same exact area as me. I also noticed one example in your log at a higher RPM/kpa as well. But, for the most part, that same exact RPM/kpa range seems to give you a jumpy IPW as well.

I will be a bit busy today, but I will try some things out and keep reporting back with any results. I think my next round of tests will involve the maf scaling table as mentioned in my previous post.