Double-check 0x8051b0...

Perhaps a address typo?

Rich

 

paramname=RAX_C
paramid=0x8051B0
databits=32
scalingrpn=x


I'm going to go ahead and add the calculations for the rest of the parameters and see if any others look off... But not tonight

 

TravisF, Can you email me your ROM? I'd like to double-check the patch feeding the data to you!

raxpatch {at} gmail <dot> com

Rich

 

I'll send it when I get home tonight, but it worked fine when I tried it with Evoscan the first time.

 

In EvoScan 2.9, there's a "LogHide" option. It's true for the DAT items. You can easily make it false, and check out the data coming into RAX_C_Dat on EvoScan in the logs, vs. OP2.0 standalone...

Rich

 

Looks like the problem is almost for sure with the standalone logger grabbing 4 bytes at a time. I logged the 8 packages using evoscan and loaded them into my program and everything got converted perfectly so I know my formulas are correct. I'm going to try splitting up the 8 x 4 byte packages into 16 x 2 byte packages. If that works then it probably won't be worth doing standalone logging with this patch since we'll still have to log 16 addresses.

Also, I must be blind but I can't find any way to load an external log into EvoScan to try graphing data. How do I do it?

 

Just a quick note to say that I'm getting over 1600 samples per second with this patch, roughly 8x faster! I got a fast laptop with SSD disk and disabled "log to screen" option.

As fast as my Evo...

 

Whoa, that's insane!

How many lines a second?

Rich

 

It's changed in ES 2.9.

• Hit the button, "Graphs / Logs, ...."
• Button in bottom left corner, "Load Log #1"
• Choose your CSV
• Hit the "Chart" tab, top left.
• Choose your items to log.

You may need to scroll down on the RHS to find the Chart at the bottom.

You may also want to DISABLE all the other panes, ie.

- Ctrl-1
- Ctrl-2
- Ctrl-3
- Ctrl-4
- Ctrl-5

...and just leave the logging panel (Ctrl-6).

Rich

 

Great work Rich!

I too am working on a small python tool to convert standalone log files to Evoscan compatible files. I'm even parsing the standalone time and converting it properly so the dyno for instance will be accurate.

I would be interested in getting this faster logging patch going for 58010005 and bake the conversions in my tool. Since I standalone log 24/7 I'm making it a simple batch script that copies all the csv logs from the flash drive and moves them to a "processed" folder ready for Evoscan or other map tracers. I'm going to simply toss an Autorun config on the flash drive to always copy over the latest and greatest logs whenever the Tactrix gets plugged in. Then basic rules can alert me if knock > 3 is found during any batch processing for instance. Nothing too fancy just scratching a personal itch more than anything.

Again good work with the patch and keep it up! Will donate for 58010005 after the new year once things settle down.

 

That sounds awesome. The standalone side of things could do with some love, that's for sure.

As TravisF noted, OP2.0 firmware may well have issues with raw 32-bit logging. We might need to read 16-bit packages - only half the efficiency of EvoScan, and that's before we take the OP2.0 slower logging into account.

So... we will have to use some "sampgroup" optimisations to get decent rates out of the key items. My suggestion to TravisF (in a recent email) was...

STFT
LTFT In Use
sampgroup=1 (infrequent)

LTFT idle
LTFT Cruise
sampgroup=1 (infrequent)

Load
IPW
EVERY CYCLE - IMPORTANT STUFF

Air/Fuel Ratio (Map)
Rear O2
sampgroup=2 (every other cycle... matches Baro/MAP)

LoadTiming
TimingAdv
EVERY CYCLE - IMPORTANT STUFF

Knock Sum
RPM
EVERY CYCLE - IMPORTANT STUFF

Baro
MAP
sampgroup=2 (every other cycle... matches AFRMAP/Rear O2)

ActiveWGDC
MAF Volts
sampgroup=3 (every third cycle... see also TPS/APP & IAT/WGDCC)


InVVT (target)
InVVT (actual)
sampgroup=4 (alternates with ExVVT)

ExVVT (target)
ExVVT (actual)
sampgroup=4 (alternates with InVVT)

TPS
Accel Pedal Position
sampgroup=3 (every third cycle... see also ActiveWGDC/MAF & IAT/WGDCC)

Intake Air Temp
WGDC Correction
sampgroup=3 (every third cycle... see also ActiveWGDC/MAF & TPS/APP)

Speed
Battery Level
sampgroup=1 (infrequent)

Coolant Temp
Manifold Air Temp
sampgroup=1 (infrequent)

MAPCalcs
IMAPCalcs
sampgroup=5 (alternates with MAFCalcs/ChosenCalc)

MAFCalcs
ChosenCalc
sampgroup=5 (alternates with MAPCalcs/IMAPCalcs)


With that, we might get 10 lines a second (if we're lucky). If it's lower than 10 lines a second, we could ditch the MAP/MAF stuff, and maybe MIVEC too. If you only log those when you are actually tuning load/MIVEC, it would free up bandwidth for the rest.

This is just me tossing ideas out there.

Rich

 

I just tried splitting RAX_C up into 2 16 byte reads using:

paramname=RAX_C_1
paramid=0x8051B0
databits=16
scalingrpn=x

paramname=RAX_C_2
paramid=0x8051B2
databits=16
scalingrpn=x

and rebuilding RAX_C = (RAX_C_1 >> 8) | RAX_C_2;

Looks like RPM, Knock, and TimingAdv are all reading correctly now!

 

Good work man

That was the last lingering question on my mind. Now I want!

 

Over 40 lines/sec, peaking at 45! How about that?

 

<expletive> <expletive>!

Gotta get me a new laptop!


Sounds like you no longer need the EvoScan "priority optimisations" I built in. Try this:


- Take a backup copy of "DataSettings\Mitsubishi EvoX Mode23 RAX Patch.xml".


- Revise "RAX_A_Dat" to "RAX_H_Dat" logging items, and make each one of them have...

Priority="1"
PriotityOffset="0"


That'll get every data item logging every single cycle. Your lines/second will drop... but you'll get smoother MIVEC and Boost graphs.


40+ lines a second. Pretty awesome...

Rich