RAX Fast Logging
Nov 29, 2012, 04:57 AM
#1
Evolved Member
Thread Starter
RAX Fast Logging
RAX Fast Logging
Yes, Christmas comes early in 2012!
I've written a ROM patch that allows you to log 30+ data items at a usable rate.
You can log directly via EVOSCAN - Version 2.9 Revision 0023 (or later).
BIG thanks to:
GET RAX PATCH HERE - Now includes RAX Fast Logging!
The Patch
This uses a "packaged data" approach. On a patched ROM, the new RAX Fast Logging code will bundle up some 32 discrete data items into a 32-byte block of memory. That data can then be bulk-read by a compatible client.
This gets you faster logging, because one "read" operation delivers multiple items.
The Logging Client
EvoScan 2.9.0023 has been given the ability to extract bit-wise data from larger blocks. It requests 4 bytes at a time, then extracts 4 items from each package.
This version of EvoScan now comes with a new “RAX Fast Logging” selection, chosen via the “Select ECU” dropdown box. You simply select it… and start logging from any RAX-enabled ROM.
Logging Speed
RAX Fast Logging + EvoScan will boost logging speed by a factor of 4.
To further optimise things, the default EvoScan configuration for RAX Fast Logging has some "Priority" tweaks, designed to prioritise some data items over others. With this default setup, you should see up to 20 lines of data per second. Note that some data items will only be updated every 2 or 3 lines.
If you strip out the "Priority" optimisations and just log every item on every cycle, you will still see 12-13 lines of data per second.
The Data
All of the usual suspects should be covered. You can log pretty much everything you need, all at once, right out of the box... at 20 lines per second.
There really is quite a lot of data...
There are also some extra items you won't have seen before, to do with load tuning. Those items came from an investigation into Load Ramp Rate. Very useful stuff.
When you download the latest RAX Patch fileset, you'll find that it comes with a comprehensive pdf instruction document. It lists all the logging items supported, value ranges, resolution limits, etc.
One of the nice things about RAX Fast Logging is that it does away with the need to know ROM-specific addressing for the supported data items. The patch collects everything internally, places it in the SAME memory position, in the SAME format... across all supported ROMs.
You can obviously revise EvoScan's scalings and data to suit your particular requirements. For example...
One extra thing worth noting: When you are looking at RPM, LoadTiming, TimingAdv and KnockSum, you're looking at a snapshot of a single ECU "cycle". All four of those items are collected in one go, and requested as one. RPM/LoadTiming should give you the EXACT spark table reference used at that instant, the TimingAdv is the actual timing being used at that instant, and KnockSum is... well, you get the idea. This helps a lot when interpreting the data!
The Future
When it comes to mode23 logging, there are more optimisations lurking out there which could boost data-delivery speeds further. There are also more aggressive client approaches, ie. requesting more than 4 bytes per ECU read.
Such future advancements shouldn’t make RAX Fast Logging obsolete. Its job is to bundle up a complex load of data into a standardised format block of contiguous memory. That operation should slot neatly into subsequent evil schemes for logging acceleration.
EvoScan 2.9 Support
Hamish has put lots of effort into enhancements and bug-fixes for EvoScan. If you haven't upgraded to 2.9, now is the time!
If you do come across any funny issue with the program, please raise an EvoScan support ticket... so Hamish knows about it. You can also find active threads on EvoScan on the forums (eg. here on EvoM and here on EvoX).
RAX Support
If you find a possible problem with any logged item, you can raise it with me right here, or email me (see below). I’ll be happy to double-check the patch's processing to see if there's an issue. Note that you can still log "regular" items along with all the RAX Fast Logging items - you can therefore log your "old-style" items and overlay them on the graph of the new RAX-delivered version. They should be consistent.
RAX Fast Logging is DONATIONWARE!
I've spent stupid amounts of time, effort and fuel developing/testing this patch... including a rather stressful evening unbricking my ECU after a 1-byte coding error. Grr. It's lucky we have sane gun laws in Australia, or my wife would have shot me, the Ralliart and my trusty logging laptop.
If you use RAX Fast Logging and appreciate its loggy awesomeness, please donate - whatever you reckon it's worth to you. My PayPallable email is
raxpatch <at> gmail <dot> com
Enjoy the faster logging! Happy tuning, and stay safe on those roads!
Rich
Yes, Christmas comes early in 2012!
I've written a ROM patch that allows you to log 30+ data items at a usable rate.
You can log directly via EVOSCAN - Version 2.9 Revision 0023 (or later).
BIG thanks to:
- Hamish: for developing the EvoScan support for RAX Fast Logging.
- Golden: for his invaluable expertise on the subject of ECU variables.
- Those ECU guru types who ferreted out our ECU functionality in the first place. You know who you are.
GET RAX PATCH HERE - Now includes RAX Fast Logging!
The Patch
This uses a "packaged data" approach. On a patched ROM, the new RAX Fast Logging code will bundle up some 32 discrete data items into a 32-byte block of memory. That data can then be bulk-read by a compatible client.
This gets you faster logging, because one "read" operation delivers multiple items.
The Logging Client
EvoScan 2.9.0023 has been given the ability to extract bit-wise data from larger blocks. It requests 4 bytes at a time, then extracts 4 items from each package.
This version of EvoScan now comes with a new “RAX Fast Logging” selection, chosen via the “Select ECU” dropdown box. You simply select it… and start logging from any RAX-enabled ROM.
Logging Speed
RAX Fast Logging + EvoScan will boost logging speed by a factor of 4.
To further optimise things, the default EvoScan configuration for RAX Fast Logging has some "Priority" tweaks, designed to prioritise some data items over others. With this default setup, you should see up to 20 lines of data per second. Note that some data items will only be updated every 2 or 3 lines.
If you strip out the "Priority" optimisations and just log every item on every cycle, you will still see 12-13 lines of data per second.
The Data
All of the usual suspects should be covered. You can log pretty much everything you need, all at once, right out of the box... at 20 lines per second.
There really is quite a lot of data...
There are also some extra items you won't have seen before, to do with load tuning. Those items came from an investigation into Load Ramp Rate. Very useful stuff.
When you download the latest RAX Patch fileset, you'll find that it comes with a comprehensive pdf instruction document. It lists all the logging items supported, value ranges, resolution limits, etc.
One of the nice things about RAX Fast Logging is that it does away with the need to know ROM-specific addressing for the supported data items. The patch collects everything internally, places it in the SAME memory position, in the SAME format... across all supported ROMs.
You can obviously revise EvoScan's scalings and data to suit your particular requirements. For example...
- If you read wideband data via rear O2 sensor ECU input, you'll want to plug in the appropriate formula to convert to AFR. You'll also want to align GaugeMin/GaugeMax/ChartMin/ChartMax with "Air/Fuel Ratio (Map)" to get the secondary graphing scale working.
- If you use "Metric Units" mode but prefer PSI to kPa for Baro/MAP/Boost, just delete the stuff in MetricEval/MetricUnits for those items. It'll revert to PSI.
One extra thing worth noting: When you are looking at RPM, LoadTiming, TimingAdv and KnockSum, you're looking at a snapshot of a single ECU "cycle". All four of those items are collected in one go, and requested as one. RPM/LoadTiming should give you the EXACT spark table reference used at that instant, the TimingAdv is the actual timing being used at that instant, and KnockSum is... well, you get the idea. This helps a lot when interpreting the data!
The Future
When it comes to mode23 logging, there are more optimisations lurking out there which could boost data-delivery speeds further. There are also more aggressive client approaches, ie. requesting more than 4 bytes per ECU read.
Such future advancements shouldn’t make RAX Fast Logging obsolete. Its job is to bundle up a complex load of data into a standardised format block of contiguous memory. That operation should slot neatly into subsequent evil schemes for logging acceleration.
EvoScan 2.9 Support
Hamish has put lots of effort into enhancements and bug-fixes for EvoScan. If you haven't upgraded to 2.9, now is the time!
If you do come across any funny issue with the program, please raise an EvoScan support ticket... so Hamish knows about it. You can also find active threads on EvoScan on the forums (eg. here on EvoM and here on EvoX).
RAX Support
If you find a possible problem with any logged item, you can raise it with me right here, or email me (see below). I’ll be happy to double-check the patch's processing to see if there's an issue. Note that you can still log "regular" items along with all the RAX Fast Logging items - you can therefore log your "old-style" items and overlay them on the graph of the new RAX-delivered version. They should be consistent.
RAX Fast Logging is DONATIONWARE!
I've spent stupid amounts of time, effort and fuel developing/testing this patch... including a rather stressful evening unbricking my ECU after a 1-byte coding error. Grr. It's lucky we have sane gun laws in Australia, or my wife would have shot me, the Ralliart and my trusty logging laptop.
If you use RAX Fast Logging and appreciate its loggy awesomeness, please donate - whatever you reckon it's worth to you. My PayPallable email is
raxpatch <at> gmail <dot> com
Enjoy the faster logging! Happy tuning, and stay safe on those roads!
Rich
Nov 29, 2012, 05:15 AM
#2
Awesome work Richard, well done, I tried out your amazing RAX EVOX fast logging, and with EvoScan and by prioritising some dataitems, I can consistently get 20 lines with 35 items = 700 samples per second.
Last edited by evoscan; Nov 29, 2012 at 05:18 AM.
Nov 29, 2012, 06:24 AM
#6
Evolved Member
Thread Starter
Well, we'd need:
[1] OP2.0 standalone logging being able to read and log 4-byte values cleanly. Like, sensibly logging 32-bit-maximum value of 4294967295.
If that works, we could then log 8 x 4-byte "packages".
The log wouldn't contain human-readable data at that point. So we'd also need...
[2] A simple Windows utility that takes a "log9999.csv" file and converts all the 4-byte packages into a readable log file. I'd recommend one that looks exactly like an EvoScan log... so you could just load the file straight into EvoScan's graphing tool & maptracer.
I don't have awesome Windows developer skillz. I did do some of that stuff a while back, but it didn't suit me. So I'm not volunteering, lol.
A nice idea, though.
Rich
[1] OP2.0 standalone logging being able to read and log 4-byte values cleanly. Like, sensibly logging 32-bit-maximum value of 4294967295.
If that works, we could then log 8 x 4-byte "packages".
The log wouldn't contain human-readable data at that point. So we'd also need...
[2] A simple Windows utility that takes a "log9999.csv" file and converts all the 4-byte packages into a readable log file. I'd recommend one that looks exactly like an EvoScan log... so you could just load the file straight into EvoScan's graphing tool & maptracer.
I don't have awesome Windows developer skillz. I did do some of that stuff a while back, but it didn't suit me. So I'm not volunteering, lol.
A nice idea, though.
Rich
Trending Topics
Nov 29, 2012, 07:01 AM
#8
Evolving Member
iTrader: (1)
Join Date: May 2008
Location: New Mexico
Posts: 239
Likes: 0
Received 0 Likes
on
0 Posts
Well, we'd need:
[1] OP2.0 standalone logging being able to read and log 4-byte values cleanly. Like, sensibly logging 32-bit-maximum value of 4294967295.
If that works, we could then log 8 x 4-byte "packages".
The log wouldn't contain human-readable data at that point. So we'd also need...
[2] A simple Windows utility that takes a "log9999.csv" file and converts all the 4-byte packages into a readable log file. I'd recommend one that looks exactly like an EvoScan log... so you could just load the file straight into EvoScan's graphing tool & maptracer.
I don't have awesome Windows developer skillz. I did do some of that stuff a while back, but it didn't suit me. So I'm not volunteering, lol.
A nice idea, though.
Rich
[1] OP2.0 standalone logging being able to read and log 4-byte values cleanly. Like, sensibly logging 32-bit-maximum value of 4294967295.
If that works, we could then log 8 x 4-byte "packages".
The log wouldn't contain human-readable data at that point. So we'd also need...
[2] A simple Windows utility that takes a "log9999.csv" file and converts all the 4-byte packages into a readable log file. I'd recommend one that looks exactly like an EvoScan log... so you could just load the file straight into EvoScan's graphing tool & maptracer.
I don't have awesome Windows developer skillz. I did do some of that stuff a while back, but it didn't suit me. So I'm not volunteering, lol.
A nice idea, though.
Rich
How are you packaging the data into each 4 byte location? I have a decent amount of experience writing small C# windows programs and don't think it would be very hard to convert a 4 byte number into 4 values if I knew how you were formatting them.
Nov 29, 2012, 07:27 AM
#9
Evolving Member
iTrader: (8)
Join Date: Jun 2010
Location: Northeast PA
Posts: 348
Likes: 0
Received 0 Likes
on
0 Posts
Adding databits=32 *might* work to read 4 bytes at a time I don't know if anyone has ever tried.
How are you packaging the data into each 4 byte location? I have a decent amount of experience writing small C# windows programs and don't think it would be very hard to convert a 4 byte number into 4 values if I knew how you were formatting them.
How are you packaging the data into each 4 byte location? I have a decent amount of experience writing small C# windows programs and don't think it would be very hard to convert a 4 byte number into 4 values if I knew how you were formatting them.
Nov 29, 2012, 08:05 AM
#10
Evolved Member
Thread Starter
Sounds cool. But let's leave it until after Christmas. I've just about had enough of "fast logging" projects for 2012, lol.
Got to leave something for the New Year.
Rich
Got to leave something for the New Year.
Rich
Nov 29, 2012, 03:18 PM
#14
Evolved Member
Thread Starter
Okay, here you go...
52370024 RAX Fast Logging
This is purely Fast Logging - I haven't developed the other RAX Patches for that ROM.
Rich
52370024 RAX Fast Logging
This is purely Fast Logging - I haven't developed the other RAX Patches for that ROM.
Rich
Last edited by richardjh; Nov 29, 2012 at 04:05 PM.
