Tephra just said he wasn't sure how he was going to implement it. I was just making the suggestion to make a new axis for fuel and timing that only the look ups for the main fuel and timing maps would be directed to. The the other maps that used the original ignition axis would unaffected this way as the original axis would still exist in their original locations.

I knew he settled on making them the same, just asking if creating an all new set of axis just for these extended tables would work and still allow all the other stuff to work as stock.

 

I don't think anyone thinks that. I just wanted to point those out to the room, in case anyone else has a fire lit under them to play with coil dwell time (and maybe offhandedly suggest to dave that a toggle be added for launch maps to be active at shift, hint, hint).

And yeah, my stuttering car says we're still a little ways off on SD.

 

mrfred's work was actually building on that; taking the analog output from the ECA as an ECU input, and applying (I presume) an interpolation between the primary and alternate maps similar to the octane interpolation between the high and low maps.

The problem with the native signal from the flex-fuel sensor is that it's actually two signals (ethanol percentage and fuel temperature), indicated by resistance or frequency, and there's no native input on the ECU that can deal with that. I was playing around with the idea of building something around an Arduino or basic stamp that did only that (didn't supply a display, etc), but I don't even have a sensor yet (very hard to justify the price).

 

initial beta 96530006 sent to those that emailed me

for those that are interested:

FACT: the ignition routine does LOTS of maps lookups based on the normal Axis's.

This means that we can't modify those axis's without impacting the other maps (EGR, ColdStart, etc)

What I have done is implemented a small routine which does the new axis's lookups at the beginning of the Ignition lookup routine.

So essentially the old axis's stay the same and they are used for the existing extra maps.

I could have left the axis lookup so that it ONLY occurred in the fuel map lookup routine, but I figured it is better to do it as mitsu designed.

 

Got it! I just finished coverting it over to USDM and SD! I will give it a shot in my car tomorrow morning and keep you posted Dave.

v7 is never going to be released at this rate! LOL!

 

lol tell me about it.

i dunno if ill make the BIGMAP a feature of V7 - or just have 2 streams...

Also BIGMAP is totally not compatible with any of jcsbank's livemapping... so sorry about that

make sure you do lots of testing to make sure your getting the timing/AFR you expect zach

 

ruhroh I would ask to keep it two streams then so if we could get livemapping in V7 we could utilize it for SD tuning which is where i think it is most helpful and swap back to whatever release will have BIGMAP.

So, it was breifly discussed, but i know JB and myself mentioned we rescale stock axis values all the time and don't seem to see any issues. Should we expect any consiering where they are used. I will have to post some pics of my rescaled maps. I don't have an EGR but i have never had coldstart issues. Cold ignition timing retard is turned off also.

 

The smiley does not convince me of the sincerity of the apology. *grin* By "totally not compatible", do you mean:

1. it's using some of the space John's code used (that's an "easy" fix, assuming we can find space somewhere for some of the livemap code, it can probably be broken up a bit),
2. that you're no longer using a contiguous space for all the alt-maps (not as easy to fix, but needed to be addressed at some point anyway; we should probably be copying maps to RAM on a case-by-case basis, to conserve memory),
3. or that you're using the memory area that John's code used (probably a lot more finicky to fix)?

Apologies for the questions, but I haven't even looked at what you sent me yet. I'll probably have a chance to look at it by the time you wake up and just respond to my own post.

 

1) not sure, dont know where john stores his stuff
2) yes, but this can be rearranged to store all the alternate maps together, although john will need to find a new memory block to store the "new" bigger maps
3) doubt it

 

What are you doing awake at 3AM, answering questions on the internet?

John's busy farting around with GT-R ECUs now, so I'll have to take a look at the live mapping stuff (I have a personal interest in keeping at least the logging part working, which means I should probably be interested in the rest, no? ). John's code just blindly copies a big 'ol chunk of your alt-maps space from ROM into RAM, rather than being selective, which means there's a bit of space we can recover if we're a little smarter about what gets copied where. Unfortunately, I don't think that's going to give us the additional 800 bytes we need for the expanded tables. Bah.

Has anyone done a comprehensive sweep of RAM usage on the VIIIs (aside from the obvious directly-referenced stuff, the stack, etc)?

The livemap client may need to be updated to handle the change in map size; Eric is pretty deep into that right now, so I'll defer to him; I seem to recall something relating to the map sizes being hard-coded, but I could be wrong (since I don't see John doing a separate build just for the dual-solenoid cars, and they have even smaller maps than us).

 

The change in map sizes isn't an issue with the LiveMap client. That's all handled via the XML and the client has buttons to add/remove extra rows/columns. Just set it up based on your new map size and save to XML.

 

This is awesome, great idea and great work!

 

Awesome. My memory was fuzzy, it's been a while since I looked at the client at all other than for quick bursts of logging.

So now we just need to figure out how to fit these two new ridiculously huge alt maps into RAM, and write a little code to selectively copy them into place. I'm thinking a simple table of location+length for the init code to iterate over for copying to our RAM location, or perhaps ROM location+RAM location+length if we want a little more control over placement?

 

Well I just got back from testing! It works!!! I need to test some more but the initial try works perfect!

 

phenem, if it works for you, it's probably golden, because we all know you're cursed.