Ralliart (AUS) ECU Stuff For Dummies
#16
Evolving Member
Join Date: May 2010
Location: Oakville, ON
Posts: 315
Likes: 0
Received 0 Likes
on
0 Posts
I have a question! Once i read from the Ecu for the first time and save the ORIGINAL map "which i did" do i need to reload this ORIGINAL map back onto the ECU before writing the GST maps onto the ECU?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
#17
Evolved Member
Thread Starter
I have a question! Once i read from the Ecu for the first time and save the ORIGINAL map "which i did" do i need to reload this ORIGINAL map back onto the ECU before writing the GST maps onto the ECU?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
Rich
#18
Evolved Member
iTrader: (8)
Join Date: Apr 2003
Location: Georgia
Posts: 2,138
Likes: 0
Received 0 Likes
on
0 Posts
I have a question! Once i read from the Ecu for the first time and save the ORIGINAL map "which i did" do i need to reload this ORIGINAL map back onto the ECU before writing the GST maps onto the ECU?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
What i did was i read from the ECU saved the original map, then loaded the GST 2.5V map REPLACING the original map. is this correct?
Second Question: Once i have written to the ECU using the GST map 2.5 and want to change this to another GST map 2.6.1 beta, would i just "WRITE" over the existing GST 2.5 map OR follow my original step and REPLACE the map with "2.6.1" altogether by reading the ROM ECU then writing to the ECU again?
Lets say starting from the begining:
1. Read the stock ecu
1a. save the image as your stock backup image
2. Close the open image that you read and saved form the stock ecu
3. Open the GST 2.5 base map that matches your setup in ecuflash
4. Flash the GST 2.5 base map
5. Months go by and GST 2.6 base map comes out
6. Open GST 2.6 base map in ecuflash
7. Flash GST 2.6 base map
No need to re read and save between flashes once you have save your original rom or have a modified rom you want to save.
#19
Evolving Member
Join Date: May 2010
Location: Oakville, ON
Posts: 315
Likes: 0
Received 0 Likes
on
0 Posts
Perfect explanation thank you. I will only "write" from now on. I did save my original ECU map which im happy. So from now on no more saving just reflashing!
The purpose of the READ step is to download a copy of the current rom in the ecu to the running copy of ecuflash. From there you can save the map, edit the map, whatever you want.
Lets say starting from the begining:
1. Read the stock ecu
1a. save the image as your stock backup image
2. Close the open image that you read and saved form the stock ecu
3. Open the GST 2.5 base map that matches your setup in ecuflash
4. Flash the GST 2.5 base map
5. Months go by and GST 2.6 base map comes out
6. Open GST 2.6 base map in ecuflash
7. Flash GST 2.6 base map
No need to re read and save between flashes once you have save your original rom or have a modified rom you want to save.
Lets say starting from the begining:
1. Read the stock ecu
1a. save the image as your stock backup image
2. Close the open image that you read and saved form the stock ecu
3. Open the GST 2.5 base map that matches your setup in ecuflash
4. Flash the GST 2.5 base map
5. Months go by and GST 2.6 base map comes out
6. Open GST 2.6 base map in ecuflash
7. Flash GST 2.6 base map
No need to re read and save between flashes once you have save your original rom or have a modified rom you want to save.
#21
Evolved Member
Thread Starter
#24
Evolved Member
Thread Starter
Rich
#26
Evolved Member
Thread Starter
#27
Evolved Member
Thread Starter
Attached is my current standalone logging file. A few items of note...
Logging Speed
By logging some items only occasionally, you can greatly improve your logging speed. That's what "sampgroup" entries are for... group a number of items into a sampgroup and OP2.0 will only update them "round-robin". The more items you put into one sampgroup, the less frequently they will update.
I've thrown a bunch of slow-changing items into sampgroup=1, and paired up some others into sampgroup=2 and sampgroup=3, so they log every other cycle.
By doing this, the headline items (rpm, load, WGDC, knock) get updated 13 times a second. Others get updated around 6.5 times a second (Boost, TimingAdv, TPS, AFRMAP). The rest only get updated once a second or so.
These are just my personal preferences. And they do change - it depends on what I'm focusing on. Like, I might swap TimingAdv and WGDC in and out of a sampgroup, to get best resolution on what I'm actually tuning. It's all compromises.
Dummy Fields
I've jimmied in some extra fields to make life easier when loading .csv files into EvoScan's "Log and Power Graph" tool. They don't slow things down any. The end result is than only the "time" heading needs a name-change, to "LogEntrySeconds". Just be careful what editor/spreadsheet app you use to change it - some change the .csv format in ways EvoScan doesn't like.
Also, More work is needed to get these .csv files loading into the Map Tracer tool - but I don't use that anyway.
External Wideband
This config sets up my Innovate LC-1 analog sampling via the OP2.0 onboard ADC, via the unused Pin 8. I spliced the relevant wire into my OBD extension cable - simple and effective.
The "type=adc" style sample does not seem to slow down the logging at all. I have no idea how fast your logging cycle will take if you switch over to "type=ascii" or "type=inno" (assuming you can even get that to work - I never could).
Bugs and Issues
There is something funny going on with the 2-item sampgroups. Occasionally, they seem to take three cycles to update instead of two. As yet, I'm not sure why. Perhaps it comes from the way OP2.0 performs its update phases with multiple sampgroups? It may work better if all sample groups have EVEN "intervals" - my 7-item sampgroup might need further hacks, I mean, enhancements.
Maybe this will give you ideas for your own setup. If you spot any problems with this file, give me a shout! If you know of a way to do things more gracefully, like the dummy entries, I'd love to hear it. I dislike having to bend stuff to make it work a certain way. I know that it's bad... but it's so much fun.
Rich
Logging Speed
By logging some items only occasionally, you can greatly improve your logging speed. That's what "sampgroup" entries are for... group a number of items into a sampgroup and OP2.0 will only update them "round-robin". The more items you put into one sampgroup, the less frequently they will update.
I've thrown a bunch of slow-changing items into sampgroup=1, and paired up some others into sampgroup=2 and sampgroup=3, so they log every other cycle.
By doing this, the headline items (rpm, load, WGDC, knock) get updated 13 times a second. Others get updated around 6.5 times a second (Boost, TimingAdv, TPS, AFRMAP). The rest only get updated once a second or so.
These are just my personal preferences. And they do change - it depends on what I'm focusing on. Like, I might swap TimingAdv and WGDC in and out of a sampgroup, to get best resolution on what I'm actually tuning. It's all compromises.
Dummy Fields
I've jimmied in some extra fields to make life easier when loading .csv files into EvoScan's "Log and Power Graph" tool. They don't slow things down any. The end result is than only the "time" heading needs a name-change, to "LogEntrySeconds". Just be careful what editor/spreadsheet app you use to change it - some change the .csv format in ways EvoScan doesn't like.
Also, More work is needed to get these .csv files loading into the Map Tracer tool - but I don't use that anyway.
External Wideband
This config sets up my Innovate LC-1 analog sampling via the OP2.0 onboard ADC, via the unused Pin 8. I spliced the relevant wire into my OBD extension cable - simple and effective.
The "type=adc" style sample does not seem to slow down the logging at all. I have no idea how fast your logging cycle will take if you switch over to "type=ascii" or "type=inno" (assuming you can even get that to work - I never could).
Bugs and Issues
There is something funny going on with the 2-item sampgroups. Occasionally, they seem to take three cycles to update instead of two. As yet, I'm not sure why. Perhaps it comes from the way OP2.0 performs its update phases with multiple sampgroups? It may work better if all sample groups have EVEN "intervals" - my 7-item sampgroup might need further hacks, I mean, enhancements.
Maybe this will give you ideas for your own setup. If you spot any problems with this file, give me a shout! If you know of a way to do things more gracefully, like the dummy entries, I'd love to hear it. I dislike having to bend stuff to make it work a certain way. I know that it's bad... but it's so much fun.
Rich
#28
Evolved Member
iTrader: (2)
Join Date: Feb 2008
Location: Paris, TN
Posts: 1,904
Likes: 0
Received 0 Likes
on
0 Posts
hey Rich,
If i understand things correctly, you're using pin 8 on the OpenPort 2.0 to standalone log your LC-1 AFR, but you have to resort to the 2.5mm -> Serial -> USB adapter chain in order to log your LC-1 AFRs in EvoScan, right?
I saw you had a tread on EvoXForums concerning standalone logging w/ the 2.5 male to male cable, but didn't look like you got a solution to make that work? Is that why you opted to splice into your obdii extension cable?
Thanks
Rob
If i understand things correctly, you're using pin 8 on the OpenPort 2.0 to standalone log your LC-1 AFR, but you have to resort to the 2.5mm -> Serial -> USB adapter chain in order to log your LC-1 AFRs in EvoScan, right?
I saw you had a tread on EvoXForums concerning standalone logging w/ the 2.5 male to male cable, but didn't look like you got a solution to make that work? Is that why you opted to splice into your obdii extension cable?
Thanks
Rob
#29
Evolved Member
Thread Starter
Yep, that's right. There's a ticket open with EvoScan asking for a way to log the OP2.0 "ADC" stuff in EvoScan, but I won't hold my breath.
But for now, what I need is working very well - so I reckon I'll resist!
Rich
Last edited by richardjh; Jun 6, 2011 at 10:46 PM. Reason: shizzles and giggles