Is it too early to say I love you??


Seriously though, now that the awkward moment has passed, a (probably ) noobie question

The Baro, IAT and SST Upshift stuff is already part of the Razorlab basemaps, so to add the super dooper fast logging we just do the entire patch, then do the updating of data as per the rather awesome & simply explained instructions?

Just wanted to be 100% sure

Thanks Rich

 

Finally got home and downloaded the instructions. Am I reading it right that boost is automatically corrected for by subtracting the baro reading?

Nevermind I looked at it in EvoScan and it grabs map and baro from the ecu and then calculates boost from those. Boost isnt read directly form the ecu

 

Honestly, it quickly gets complicated if you start disabling items. Yes, you can. But then you may need to go and adjust all the Priority and PriorityOffset configuration, designed to "time-slice" multiple logging item groups for better efficiency.

It's doable, but it's a pain. If you desperately need more than 20 lines a second, email me.


Yep. When you open up your Base Map with RAX Patch XML installed, you'll be able to see the three RAX Patches that are already present... and install this new fourth one.

When I do the next RA Base Map, I'll probably add RAX Fast Logging to them all. Why not, eh?


Yep. I deliver/log [Baro] and [MAP] items. The "gauge" boost pressure is then just "[MAP]-[Baro]".


Rich

 

If anyone feels adventurous try logging these parameters with the standalone logger and send me your resulting log file so I can try converting it

paramname=RAX_A
paramid=0x8051AC
databits=32
scalingrpn=x

paramname=RAX_B
paramid=0x8051A8
databits=32
scalingrpn=x

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

paramname=RAX_D
paramid=0x8051B4
databits=32
scalingrpn=x

paramname=RAX_E
paramid=0x8051B8
databits=32
scalingrpn=x

paramname=RAX_F
paramid=0x8051BC
databits=32
scalingrpn=x

paramname=RAX_G
paramid=0x8051C0
databits=32
scalingrpn=x

paramname=RAX_H
paramid=0x8051C4
databits=32
scalingrpn=x

 

how about if you disable some items and replace them with others?

 

Sure.

You'd have to replace the "RAX_?_Dat" item, though... and stop logging all of its dependents.

Rich

 

So if i wanted to log let say 4 SST items, I could delete "RAX_A_Dat" line in the XML , stop logging the items under "RAX_A_Dat" and add the SST items to the XML.....?

 

Nope, your logging rate will go through the floor if you do that.

You need to get in there, check out how the RAX logging works, how "Priority" and "PriorityOffset" work, and then carefully design your revised XML.

I strongly recommend taking a backup of the original RAX logging EvoScan XML before doing anything!


[edit] More on Priority/PriorityOffset:

A "RAX_?_Dat" item with Priority="2" means it is only requested from the ECU every 2 lines. There are 2 such items.

A "RAX_?_Dat" item with Priority="3" means it is only requested from the ECU every 3 lines. There are 3 such items.

The rest use Priority="1"... so they get requested every single line.


There is also a PriorityOffset value, which is used to manage the round-robin requesting of the above groups, so you always run the same number of overall requests every line.


If you ditch all that and set everything to Priority="1", you'll get 12.5 lines a second. Still good. But I didnt want to be reading stuff like fuel trims, speed, engine coolant temp and other slow-changing stuff every single time. Hence the optimisation.


Also note... the ONLY stuff that takes any time to perform is the "RAX_?_Dat" item requesting. All the other stuff is just calculated in the blink of an eye. If you add 4 SST requests in place of one "RAX_?_Dat" request, you'll be making more requests each line.

Then there are the priorities to think about!

Rich

 

i tried to move around some items to change up the order in which it was listed in the log, and i also tried to un-check items i did not want to log. this threw it all off lol so what i just started doing is log everything exactly how its displayed in EvoScan2.9 under RAX Fast Logging, and then i open up the log, copy and paste the columns i want/need, and go from there. it doesnt take too long to do this compared to the clarity of the logs we now have. thanks Rich!

 

I only tried it for a second but it didn't look like RPM was being read by evoscan. I will do some more testing in the next few days.

Just checked the logs and everything looks like it's working great. The numbers just don't all display in the evoscan window and it looks like they only update every few seconds. The logs are perfect though and I'm seeing 19 or 20 rows a second with everything logged

 

Yes, EvoScan's screen doesn't update very evenly. I've turned "Log to Screen" off entirely, though - it is a wee bit quicker on my netbook, and uses less cpu (ie. Battery).

Rich

 

This is simply amazing, Rich.

I'm glad I was able to make your life more simple.
(You know what I mean.)

 

Yeah, thanks a million for all the help!

Rich

 

just plain awesome!
SO.. if i enable all RAX patches and up the load ramp rate.. that would be pretty much the next version of RA GST basemap?

 

...and zero out the Exhaust MIVEC Overrun (Actual>Map) table, revise Lower Boundary Timing Map (or one of the ECT-based timing adjustment tables) to fix P050B, tweak the Load multiplier end when TPS decreased by % (hysteresis) value so that IMAPCalcs and MAPCalcs don't seesaw wildly at WOT.

That's what's on my to-do list, anyway!

Rich