Screenshot from working DMA live map/log + Tephra V5
#16
Well above you mention only having the high octane maps in ram, I think thats all anyone would want to be changing anyway isn't it ?
So if we only have the std and alt maps high octane tables, does that give enough free space to get things working, correctly / safely ?
I am not complaining, in any way shape or form, just throwing idea's out there, that could make your program more flexible.
So if we only have the std and alt maps high octane tables, does that give enough free space to get things working, correctly / safely ?
I am not complaining, in any way shape or form, just throwing idea's out there, that could make your program more flexible.
#17
Evolved Member
Thread Starter
I would want two sets in RAM and keep the low octane in ROM as well I think, and I think there should be enough space in most 7/8 to do that, I've not followed the recent developments on the ones that lack the space for V5 though.
#18
#19
Evolving Member
Join Date: May 2007
Location: Edinburgh, UK
Posts: 121
Likes: 0
Received 0 Likes
on
0 Posts
This sounds very useful. I'm installing a water/meth injection system next week that will run on V5 alt maps. I have 96530006. Live tuning would save a lot of time and hassle. Great work.
#21
Newbie
iTrader: (1)
Join Date: Dec 2006
Location: in my car
Posts: 63
Likes: 0
Received 0 Likes
on
0 Posts
I have a working test of Tephra V5 + DMA logging + DMA live mapping of the alternate fuel, timing, boost and injector scaling maps which are now stored in RAM which is automatically refreshed from ROM if the ECU is reflashed, reset or disconnected.
In the screenshot the left part of the screen is the logging baud rates/directory/start/stop/edit logged items etc. In the right part there are the addresses and size of the block in ROM and RAM that contains the alternate maps. Also the logging address is presently set to the base address of the MUT table, but this can be fully customised - you could upload a logging table to RAM if you like and edit it in Ecuflash with the engine running. The area to the lower right is where you choose the Ecuflash file we're working on.
Start logging... edit alternate maps in Ecuflash... hit ctrl-s to save... hit write in Evo Live Map to write and optionally verify. All with the engine running and without using up a reflash.
Questions?
In the screenshot the left part of the screen is the logging baud rates/directory/start/stop/edit logged items etc. In the right part there are the addresses and size of the block in ROM and RAM that contains the alternate maps. Also the logging address is presently set to the base address of the MUT table, but this can be fully customised - you could upload a logging table to RAM if you like and edit it in Ecuflash with the engine running. The area to the lower right is where you choose the Ecuflash file we're working on.
Start logging... edit alternate maps in Ecuflash... hit ctrl-s to save... hit write in Evo Live Map to write and optionally verify. All with the engine running and without using up a reflash.
Questions?
What rom are you using?
#24
Evolved Member
Thread Starter
I've been testing this on my own car, but the real test came yesterday with a Green and 780cc injectors, neither of which I've mapped for before. Once all the mechanical issues were sorted out the live mapping worked really well, and the process was much quicker despite me not being familiar with these parts. There were two issues:
After reflashing the CEL flashed and the car wouldn't start properly (I had RAM maps selected). Pulling the middle ECU plug forced a clear of the RAM and it copied it from ROM again and all was well. It seems that a reflash does not completely reset the ECU and clear all the RAM. A minor issue, but one I'd like to look into. The CEL was flashing even though valet mode was disabled, so Tephra's RAM variables may be overwritten by a reflash and then not refreshed either.
The second issue was one of convenience. Whilst my realtime app does logging, I don't have any live display in it at present, so I was switching between Evoscan to log, stopping logging, changing data in Ecuflash, switching to my app to write the tables, then going back to Evoscan. If one app could do the live display of logged data and live mapping then it would just need it and Ecuflash open. On a small (1280*800) laptop screen that would help a lot and reduce switching between apps in a bumpy car.
After reflashing the CEL flashed and the car wouldn't start properly (I had RAM maps selected). Pulling the middle ECU plug forced a clear of the RAM and it copied it from ROM again and all was well. It seems that a reflash does not completely reset the ECU and clear all the RAM. A minor issue, but one I'd like to look into. The CEL was flashing even though valet mode was disabled, so Tephra's RAM variables may be overwritten by a reflash and then not refreshed either.
The second issue was one of convenience. Whilst my realtime app does logging, I don't have any live display in it at present, so I was switching between Evoscan to log, stopping logging, changing data in Ecuflash, switching to my app to write the tables, then going back to Evoscan. If one app could do the live display of logged data and live mapping then it would just need it and Ecuflash open. On a small (1280*800) laptop screen that would help a lot and reduce switching between apps in a bumpy car.
#26
Evolved Member
Thread Starter
I will think about adding a routine that forces a refresh of the RAM maps on reset. I believe this reset is called after reflashing, but presently it doesn't erase the RAM contents.
#27
Evolving Member
I'd love nothing better than a single program that can datalog, edit tables, maptrace and tune in real time. Instead of working on separate endeavors like EcuFlah, Evoscan, Real Time Tuning etc.
Although a complicated and time burdening endevour it would not only lead to more productive results per tuning session but it would eliminate the plethora of questions, bugs and complications surrounding the use of several other programs:
I see it as a collaborative effort between evo4mad, jcsbanks, Tephra, MalibuJack and Colby. These and others have contributed a substantial amount of their time to helping everyone with an evo, and still do. There are probably others I have not mentioned who could work on this development team. I see so many intelligent minds posting here, but only recently have I seen some take initiative to get organized by creating tutorials and threads that serve as resources. Someone needs to sticky Jack or all Trades 2Byte thread for instance...and there are a few others like it.
I see a couple ways to go about this:
Although a complicated and time burdening endevour it would not only lead to more productive results per tuning session but it would eliminate the plethora of questions, bugs and complications surrounding the use of several other programs:
- "Can't see my rom-->HELP"
- "How do you rescale injectors?"
- "Problem logging in EvoScan"
- "Need Definition File for..."
- "Where is 2byte mod for rom id..."
I see it as a collaborative effort between evo4mad, jcsbanks, Tephra, MalibuJack and Colby. These and others have contributed a substantial amount of their time to helping everyone with an evo, and still do. There are probably others I have not mentioned who could work on this development team. I see so many intelligent minds posting here, but only recently have I seen some take initiative to get organized by creating tutorials and threads that serve as resources. Someone needs to sticky Jack or all Trades 2Byte thread for instance...and there are a few others like it.
I see a couple ways to go about this:
- Moderators could sticky a poll to gauge interest and if enthusiasts would be willing to finance/donate money toward the project.
- If there isn't enough financial support from those on the forum then those still interested in working/financing the project would be given access to a private section of the forum (or an entirely new site be it be the case) whereby those who contribute toward the effort will reek the benefits.
Last edited by R. Mutt; Apr 17, 2008 at 06:03 AM.
#28
Evolved Member
Thread Starter
It is a nice idea, but I'm not wanting to take money off people so that I can pick this up and drop it as I like, otherwise it becomes a job and another of life's pressures. I have enough of that with my main job. I have too much money and not enough time! I'm happy to share any and all of my work though.
I will try to put a little graph display of some of the logged data items vs RPM in my app, so you can do a run through a gear and instantly see the knock and boost at a glance for example. I end up doing this in Excel. I really like the knock vs RPM feature on my Pocket PC logger. I couldn't get the scrolling graphs to work on the PC though using the same code.
I will try to put a little graph display of some of the logged data items vs RPM in my app, so you can do a run through a gear and instantly see the knock and boost at a glance for example. I end up doing this in Excel. I really like the knock vs RPM feature on my Pocket PC logger. I couldn't get the scrolling graphs to work on the PC though using the same code.
Last edited by jcsbanks; Apr 17, 2008 at 06:03 AM.
#29
Evolving Member
true...it's sometimes enticing to get paid to do something you enjoy as a hobby, but then it becomes more of a burden than a joy when people demand results.
#30
Evolved Member
Thread Starter
I have done this and it works as intended so that the RAM maps are refreshed after Ecuflash has done a read/write/compare as well as when the power to the ECU is cut. HOWEVER, it also does it when the ignition has been turned off for more than a few seconds which is undesirable as in these cases I wish to preserve the RAM map contents. Unless anyone already knows I need to work out which routines are called only after an ECU/battery disconnect or a write (when there is a solenoid pulsed, however, this doesn't happen after a compare or a read).