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?

 

You just write - once - whichever ROM image you want to use. In theory, you never need to "read" again...

Rich

 

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.

 

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!

 

Is there anything different to do for US ralliarts? Besides downloading the correct GST map...

 

No, I'm pretty sure it's all the same - but it's kind of hard for me to check!

Rich

 

Lol ok. Thanks for the great writeup. Saving a lot of people headaches

 

Rich, are you using MODE 23 addresses now in your stand alone logging script? I think the one posted does not use MODE 23.

Cheers,

Mike

 

Yep, I sure am. It's just not called that in the OP2.0 "logcfg.txt" file. The "type=mrmacan" setting tells it to use what is known around the traps as mode 23 style.

Rich

 

Thanks Rich, I just noticed the remarks at the top, I think I might be using a very old version of your script.

Cheers,

Mike

 

No worries. I'll post up my current one when I get the chance.

Rich

 

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

 

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

 

Hi Rob.

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.

Exactly. My OP2.0 firmware doesn't actually speak LC-1. I believe there's a new f/w version around now, so maybe when I'm feeling brave I'll flash it to the Tactrix box and see if they've sorted out the LC-1 protocol issue.

But for now, what I need is working very well - so I reckon I'll resist!

Rich

 

hah! "If it ain't broke, don't fix it!"


thanks for the info man!