Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB

Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB (https://www.ft86club.com/forums/index.php)
-   Software Tuning (https://www.ft86club.com/forums/forumdisplay.php?f=88)
-   -   Tactrix EcuFlash Info for BRZ 86 FRS Rom flash update and logging (https://www.ft86club.com/forums/showthread.php?t=62332)

Kodename47 12-17-2014 02:29 PM

Quote:

Originally Posted by Wepeel (Post 2059305)
Whoops, meant to ask what flow ranges are ABCDE. i.e. A=0-10 g/s, B=10-20 g/s,...

And with the addition of E, is the E range higher than the previous D, or did they just increase resolution?

E is further up. In essence the y axis is just extended by 1.

Kodename47 12-19-2014 04:17 AM

OK, so my last little Christmas present to you all. I've re-jigged the ZA1JA01G definition to be a lot more user friendly. The tables have been categorised from the Alpha - BRZ folder and include all the updates above. I have also done versions for your preferences. However, the pressures are all done in bar, not psi and speed is in MPH and not Km/h.


The defs:
ZA1JA01G - Temp: Degrees F / Compensation: %
ZA1JA01G - Temp: Degrees F / Compensation: Ratio (Like ECUtek)
ZA1JA01G - Temp: Degrees C / Compensation: %
ZA1JA01G - Temp: Degrees C / Compensation: Ratio


For those that would like to fine tune:
Speed:
Code:

<scaling units="Vehicle Speed (MPH)" expression="x*.621" to_byte="x/.621"
<scaling units="Vehicle Speed (Km/h)" expression="x" to_byte="x"


Pressure:
Code:

scaling units="bar" expression="x*.001333223" to_byte="x/.001333223"
scaling units="psi" expression="x*.01933677" to_byte="x/.01933677"


I would suggest you go through and check these but I've done preliminary checks and all seem to work out. If I've missed any tables then let me know.

vgi 12-19-2014 01:38 PM

Quote:

Originally Posted by Kodename47 (Post 2062007)
I've re-jigged the ZA1JA01G definition to be a lot more user friendly.

you should have posted the A01B as well since you have it ;) or it wasn't 'jigged'?

Td-d 12-19-2014 03:18 PM

Hey guys - out of action for a couple of weeks, taking a well deserved break with my family after a long year... I'll have a look in the new year, pull in the edits. Been meaning to sort out the categories for a while, but time is an issue.

Kodename47 12-22-2014 02:48 AM

Quote:

Originally Posted by vgi (Post 2062502)
you should have posted the A01B as well since you have it ;) or it wasn't 'jigged'?


I haven't touched the US ROMs I'm afraid mate, it took long enough just doing the one.

vgi 12-22-2014 06:48 AM

Quote:

Originally Posted by Kodename47 (Post 2064736)
I haven't touched the US ROMs I'm afraid mate, it took long enough just doing the one.

Move to US. Lol

D-VO 12-30-2014 01:46 AM

1 Attachment(s)
Here's the B01C that I've been using with the recently added oil temp line. I added scalings for MPH and fahrenheit, along with boost parameter in PSI. There are a few parameters that I have turned off to make reading the logs easier, others are redundant for testing.

ztan 12-30-2014 04:05 AM

Just put a 3Bar MAP sensor in my car (A01G ROM) and altered the scaling at:

<table name="Manifold Pressure Sensor Scaling " storageaddress="1000CC" />

Car wouldn't start with MAP reading at 31-33 kPa in free air.

Turns out the scaling values are actually listed in 3 places in the A01G ROM:

<table name="Manifold Pressure Sensor Scaling A" storageaddress="1000CC" />
<table name="Manifold Pressure Sensor Scaling B" storageaddress="1000E4" />
<table name="Manifold Pressure Sensor Scaling C" storageaddress="11CC20" />

Rescaled all of them and the car started up properly with a normalized MAP reading.

I think the last one at 11CC20 was the critical one used.

Kodename47 01-07-2015 03:40 AM

I had missed @ztan's MAP sensor scaling update. I have now updated the definitions on my download links above.

I have also created the ZA1JA02G ROM definitions based on the above too:
ZA1JA02G - Temp: Degrees F / Compensation: %
ZA1JA02G - Temp: Degrees F / Compensation: Ratio (Like ECUtek)
ZA1JA02G - Temp: Degrees C / Compensation: %
ZA1JA02G - Temp: Degrees C / Compensation: Ratio

steve99 01-07-2015 06:11 AM

Quote:

Originally Posted by Kodename47 (Post 2080672)
I had missed @ztan's MAP sensor scaling update. I have now updated the definitions on my download links above.

I have also created the ZA1JA02G ROM definitions based on the above too:
ZA1JA02G - Temp: Degrees F / Compensation: %
ZA1JA02G - Temp: Degrees F / Compensation: Ratio (Like ECUtek)
ZA1JA02G - Temp: Degrees C / Compensation: %
ZA1JA02G - Temp: Degrees C / Compensation: Ratio

I will add the A02G rom to first post , thanks for defs

steve99 01-07-2015 07:17 PM

ZA1JA02G stock rom and definitions now available.

Thanks @luckykevin and @Kodename47

For now see two post above for A02G definitions.
@Td-d will add to github site after holidays

Kodename47 01-12-2015 08:24 PM

Minor Updates to A01G and A02G Definitions from links above.
Quick ZA1JA01G ROM Defs
Quick ZA1JA02G ROM Defs

SantosGT86 01-19-2015 02:59 PM

Tactrix clone
 
Quote:

Originally Posted by MikeyP (Post 2007747)
Thanks for the comments Steve. These do indeed ship with older software. This hardware is definitely not an exact copy but it relying on our circuit design as well as end user use of our firmware and software in violation of our software license agreement one must agree to during the installation procdess. There are lots of obvious differences just from a quick glance of the counterfeit unit. It has hand soldered parts on the circuit board where the counterfeiters think it doesn't matter, not to mention the part numbers being ground off the chips with a dremel tool so that other thieves don't steal their copy design. We've tested this unit and I can say for sure that some users will have problems in some cases as we've identified several issues with this hardware.

To those who choose to support our small company with their hard earned dollars, we thank your for your support. The sale of our hardware makes possible the continued development of our freely distributed software. Our software and our support will remain free as long as we're able to keep the doors open through the sales of the hardware which we've designed and is manufactured in the USA (Washington & California).

Thanks,
Mike



Hi guys,


i´m new here in the Forum but i was reading here a lot. I´m from Germany and i discided a few month ago from a French dealer an Tactrix, like he said Genuine.


It took about 4 weeks when i recived a package from China. I´ve first tested the "chinese" tactrix pulling my stock Rom but while pulling the tactrix stoped working, it was "dead". After a contact with the dealer and another 4 weeks of waiting i got a new one from China for free.
The new one died installing the Drivers on my Laptop.


So i sended it back and buyed a Tactrix from a "Tactrix" Dealer in UK. After few days i recived the new Tactrix but it was the same chinese shit , with dreamelt Chips. With this one i was able to pull the stock Rom and write a Stage2 EL Rom ok before this one died.

Everybody here say that he sells the original Tactrix but for real they al sell th totis chinese cheep shit. For the last one i have payed 200 euros.
Finaly i was very angry and yesterday i´ve ordered the genuine from US Tactrix webside.


I like this new Rom on my car,it changed a lot.
This Tactrix is a great tool and y can´t wait to get the real american one!

phrosty 01-19-2015 04:04 PM

Tactrix is already reasonably cheap. The things people go through to save a buck!

SantosGT86 01-19-2015 04:16 PM

Quote:

Originally Posted by phrosty (Post 2096785)
Tactrix is already reasonably cheap. The things people go through to save a buck!



This do not belong to save the buck, the only reason is that here in europe is more conftable to buy in europe for custom reasons.


I´ve never looked for cheap fakes. I´ve paied from 150 a over 200 €!


I think the only save way is purchase the tactrix at the original Tactrix Homepage.

dave- 01-19-2015 05:58 PM

Quote:

Originally Posted by Kodename47 (Post 2088256)
Minor Updates to A01G and A02G Definitions from links above.
Quick ZA1JA01G ROM Defs
Quick ZA1JA02G ROM Defs

Just curious on file size differences compared to Td's RR definitions.

598900 Jan 20 09:34 RR ZA1JA01G - Metric & %.xml
599024 Jan 20 09:34 RR ZA1JA01G - Metric & Ratios.xml
834049 Jan 20 09:34 RR_ZA1JA01G.xml

Given you've added additional tables, do your def's have shorter/less descriptions or something which would account for the much smaller file size?

Edit:

Also there are some tables which are shaded pinkish in RR due to unknown axis? Are these correct?
AFR min/max Correction
Fuel Multiplier Display Offset
All the Fueling - Hotstart enrichment

Kodename47 01-20-2015 04:04 AM

Quote:

Originally Posted by dave- (Post 2096918)
Just curious on file size differences compared to Td's RR definitions.

598900 Jan 20 09:34 RR ZA1JA01G - Metric & %.xml
599024 Jan 20 09:34 RR ZA1JA01G - Metric & Ratios.xml
834049 Jan 20 09:34 RR_ZA1JA01G.xml

Given you've added additional tables, do your def's have shorter/less descriptions or something which would account for the much smaller file size?

Edit:

Also there are some tables which are shaded pinkish in RR due to unknown axis? Are these correct?
AFR min/max Correction
Fuel Multiplier Display Offset
All the Fueling - Hotstart enrichment

In the original definitions there are quite a lot of unused old table names ported from older cars, namely boost control, that I removed as they aren't necessary. When I organised the file I found it easier for myself to remove these otherwise there was a large section of text I had to navigate around. Nothing necessary has been lost or removed.

The beta level tables are ones I haven't seen or know how they operate so I left them in the maximum user level state.

Toyota John 01-20-2015 04:20 PM

Quote:

Originally Posted by Kodename47 (Post 2097533)
In the original definitions there are quite a lot of unused old table names ported from older cars, namely boost control, that I removed as they aren't necessary. When I organised the file I found it easier for myself to remove these otherwise there was a large section of text I had to navigate around. Nothing necessary has been lost or removed.

The beta level tables are ones I haven't seen or know how they operate so I left them in the maximum user level state.

How did you remove the unused table names?

dave- 01-20-2015 07:55 PM

Quote:

Originally Posted by Kodename47 (Post 2097533)
In the original definitions there are quite a lot of unused old table names ported from older cars, namely boost control, that I removed as they aren't necessary. When I organised the file I found it easier for myself to remove these otherwise there was a large section of text I had to navigate around. Nothing necessary has been lost or removed.

The beta level tables are ones I haven't seen or know how they operate so I left them in the maximum user level state.

Thanks for the info.

Am I right in saying the opensource def's are still missing a lot of tables compared to other options like ecutek and brzedit? Has any done a comparison between them to get a rough idea exactly how much is different?

If brzedit offers more tunabilty than the current opensource defs, I'll just buy that. I'd consider ecutek (price dependant) if I could edit myself and not have to deal with the Australian Distro but not sure that is possible?

Toyota John 01-20-2015 08:22 PM

Quote:

Originally Posted by dave- (Post 2098648)
Thanks for the info.

Am I right in saying the opensource def's are still missing a lot of tables compared to other options like ecutek and brzedit? Has any done a comparison between them to get a rough idea exactly how much is different?

If brzedit offers more tunabilty than the current opensource defs, I'll just buy that. I'd consider ecutek (price dependant) if I could edit myself and not have to deal with the Australian Distro but not sure that is possible?

Ecuflash has some tables that the retail version of ecutek doesn't and vise-verse. However if you are a big tuna you get lots more maps on ecutek and can requestest any map you want so i am told. They might be beta maps and may get passed down to use some day. I can't comment on brzedit. I don't think many people are using it anymore.

steve99 01-20-2015 08:43 PM

Quote:

Originally Posted by dave- (Post 2098648)
Thanks for the info.

Am I right in saying the opensource def's are still missing a lot of tables compared to other options like ecutek and brzedit? Has any done a comparison between them to get a rough idea exactly how much is different?

If brzedit offers more tunabilty than the current opensource defs, I'll just buy that. I'd consider ecutek (price dependant) if I could edit myself and not have to deal with the Australian Distro but not sure that is possible?

@Kodename47 has merged ecutek and romraider defs to form the most complete defs you will find. for G series roms i believe

Kodename47 01-21-2015 03:40 AM

Quote:

Originally Posted by steve99 (Post 2098717)
@Kodename47 has merged ecutek and romraider defs to form the most complete defs you will find. for G series roms i believe

Yes, I've been comparing the what I have in ECUtek with those available in the existing definitions and finding any missing tables. This is only to get around the "missing" tables in the retail version of ECUtek hence I've only done the G series.

Toyota John 01-21-2015 08:43 AM

Quote:

Originally Posted by Kodename47 (Post 2099078)
Yes, I've been comparing the what I have in ECUtek with those available in the existing definitions and finding any missing tables. This is only to get around the "missing" tables in the retail version of ECUtek hence I've only done the G series.

Hook me up a C ROM:bow:

Kodename47 01-22-2015 10:54 AM

Just an FYI, I've changed some fine learning settings and now it's creating FLKC at low load like 0.1-0.3 etc. I've not changed any tables that should result in that so I was wondering if anyone had done the same? I'm currently on the A01G ROM, based on the fact that the A02G is defined the same I'll assume it's the same. Anyone tried on different ROMs?

What I've changed:
Fine Correction Retard Value - It still retards -1 no matter what I do.
Load Range - I've only adjusted the upper range
Rows and Columns for the FL Table in ROM - I've not set the lowest ranges any lower than stock.

TBH, it's stumped me a little. I was wondering if, like the Injector scaling, that maybe the ECU is using different parameters/settings.

Quote:

Originally Posted by Toyota John (Post 2099223)
Hook me up a C ROM:bow:

Sorry John, missed this. It's all time, of which I have very little at the moment. When my house is done I'll try and copy across the G series definitions to the C series.

Kodename47 01-22-2015 02:02 PM

Following on from my last post, 114BEC seems to tie in with the FLKC retard value I'm seeing. This wasn't a defined address in the A01G/A02G definitions but is in the area of the ROM where all the Fine Learning values are.

I can't deduce the rest by looking through the hex, but one of the other settings I've changed must be the cause or have a knock on effect.

https://dl.dropboxusercontent.com/u/...20ZA1JA01G.jpg


<table name="Fine Correction Range (Load)" storageaddress="114C20" />
<table name="Fine Correction Columns (Load)" storageaddress="114BC8" />
<table name="Fine Correction Retard Value" storageaddress="114BE8" />

<table name="Fine Correction Retard Value A" storageaddress="114BEC" />

ztan 01-23-2015 07:07 PM

I think that if you set the first FLKC load column to 1.0, you'll get corrections applied any time load is in that column (i.e. FLKC only increments in the first column when you are 0.72-1.0 load, but gets applied to the first load column which is 0.0-1.0). We don't know if FLKC incremented at <0.72 load or was only applied at low load.

The stock first load column cell is set to 0.72 so that no FLKC is applied in cells where there is no increment. In theory you could get a knock event between 0.72 and 0.70 which would activate the first column, but this is unlikely as load would be dropping whilst this hysteresis boundary was being crossed.

Kodename47 02-04-2015 03:33 AM

I have re-jigged the A01G and A02G definitions a little and to bring in line I have looked through the B01C definition so that all tables are named the same and are placed into the same categories. This should be a nice addition for those on B01C ROMs.
Download - ZA1JB01C Definition

There are no new tables defined, however essentially it allows direct comparisons as the tables are all now the same naming convention. Those using my G series definitions, it is worth getting the latest update.

dave- 02-04-2015 10:57 PM

Quote:

Originally Posted by Kodename47 (Post 2117693)
There are no new tables defined, however essentially it allows direct comparisons as the tables are all now the same naming convention. Those using my G series definitions, it is worth getting the latest update.

Is there a simple way to convert these to ecuflash xml's?

steve99 02-05-2015 01:09 AM

Quote:

Originally Posted by dave- (Post 2119021)
Is there a simple way to convert these to ecuflash xml's?

Their is a utility in that converts romraider defs to ecuflash defs but your problem is you also need an updated 32bitbase file for ecuflash.

best option at present is do all your editing in romraider and just use ecuflash to flash.

untill tdd get arround to updating the ecuflash defs xand 32bitbase files.

burdickjp 02-10-2015 08:36 PM

I'm having trouble getting commanded AFR/primary open loop MAP enrichment to log correctly on a B01C ECU. Anyone have any luck?

dave- 02-20-2015 05:03 AM

Was posted in another thread but more relevant here, does anyone know the RAM address for the second 02 sensor on an A01G rom?

burdickjp 02-22-2015 10:26 AM

I noticed the 'load' value for B01C Roms is in g/s whereas the ECU tables are in g/rev. I've made a script to produce a new load value based on MAF and RPM, but am curious if the ECU has an address for load in g/rev.

Kodename47 02-22-2015 02:33 PM

Quote:

Originally Posted by bur****jp (Post 2142795)
I noticed the 'load' value for B01C Roms is in g/s whereas the ECU tables are in g/rev. I've made a script to produce a new load value based on MAF and RPM, but am curious if the ECU has an address for load in g/rev.

All load is g/rev. It's probably just a type error.

ztan 02-22-2015 04:32 PM

Quote:

Originally Posted by dave- (Post 2140303)
Was posted in another thread but more relevant here, does anyone know the RAM address for the second 02 sensor on an A01G rom?

I've had a quick look at the OBD call table disassembly but have not tested:
Can you try FFF8D274 and FFF8D278 and report back?

dave- 02-22-2015 07:41 PM

Quote:

Originally Posted by ztan (Post 2143065)
I've had a quick look at the OBD call table disassembly but have not tested:
Can you try FFF8D274 and FFF8D278 and report back?

Will try these later today and report back:

paramname = AFR2
paramid = 0xFFF8D274
isfloat = 1
scalingrpn = x,14.7,*

paramname = AFR3
paramid = 0xFFF8D278
isfloat = 1
scalingrpn = x,14.7,*

ztan 02-22-2015 08:13 PM

Quote:

Originally Posted by dave- (Post 2143222)
Will try these later today and report back:

paramname = AFR2
paramid = 0xFFF8D274
isfloat = 1
scalingrpn = x,14.7,*

paramname = AFR3
paramid = 0xFFF8D278
isfloat = 1
scalingrpn = x,14.7,*

Off OBD Mode 01, PID 15, I'd expect D274 to be sensor volts reading between 0-1V (scaling rpn=x); 1V is rich, 0V is lean. Expect D278 to be AF3 trim (scalingrpn=x).

burdickjp 02-22-2015 09:35 PM

Quote:

Originally Posted by Kodename47 (Post 2142986)
All load is g/rev. It's probably just a type error.

From the logs it looks to be similar in magnitude and value as the MAF logging, so I assumed the issue was related to that.
I'd much rather have a log of load than be calculating it. I guess doing the math with someone else's log could help me determine if my math is right.

Where would I start looking to fix this?

Kodename47 02-23-2015 03:15 AM

Quote:

Originally Posted by bur****jp (Post 2143342)
From the logs it looks to be similar in magnitude and value as the MAF logging, so I assumed the issue was related to that.
I'd much rather have a log of load than be calculating it. I guess doing the math with someone else's log could help me determine if my math is right.

Where would I start looking to fix this?

So you haven't got a parameter for load? Calculating it isn't ideal due to the compensations that are made, there will be slight variances.

What file are you using for logging? Plenty of info on here to check the correct load parameter.

burdickjp 02-23-2015 12:36 PM

Quote:

Originally Posted by Kodename47 (Post 2143621)
So you haven't got a parameter for load? Calculating it isn't ideal due to the compensations that are made, there will be slight variances.

What file are you using for logging? Plenty of info on here to check the correct load parameter.

I got addresses from the 'b01c' addresses file. I can't remember which of the other files I started with, but there were a few things which needed to come over from the addresses file.

dave- 02-23-2015 05:51 PM

Quote:

Originally Posted by ztan (Post 2143260)
Off OBD Mode 01, PID 15, I'd expect D274 to be sensor volts reading between 0-1V (scaling rpn=x); 1V is rich, 0V is lean. Expect D278 to be AF3 trim (scalingrpn=x).

Did some logs driving to work today using your values:

paramname = AFR2
paramid = 0xFFF8D274
isfloat = 1
scalingrpn = x

paramname = AFR3
paramid = 0xFFF8D278
isfloat = 1
scalingrpn = x


http://www.datazap.me/u/dave/rear-o2...g=0&data=29-30


All times are GMT -4. The time now is 07:47 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
User Alert System provided by Advanced User Tagging v3.3.0 (Lite) - vBulletin Mods & Addons Copyright © 2026 DragonByte Technologies Ltd.


Garage vBulletin Plugins by Drive Thru Online, Inc.