Logging Speed etc

@steve@versatune Is there any ETA on faster logging through VT? I know you had mentioned your car was up and running. Currently it takes a lot longer to get good logs with all the data we want especially with bigger hp cars. I know there has been talk about this for a very long time. Cobb has given up on our platform and I love some of the VT features but slow logging is a killer.

 

It's in the pipeline. It's a ton of work because it's custom assembly code that has to be hand coded for each calibration. On MS6, it's not a bid deal, but MS3 and newer platforms have lots of different calibrations.

 

does ms6 logs faster than the ms3?

 

Same logging speed. Fewer calibrations, so less effort to implement

 

what is an example of a calibration? i understand there is a similar issue with logging (or any type of logging) on the rx-8 platform?

 

Logging rate is limited by the ECU software and hardware. These are very small embedded processors running a real-time OS that has to service a lot of interrupts on time every time to fire injectors and spark plugs. You can't delay firing a plug because someone wants to know the boost pressure on a microsecond resolution. The CAN bus has a finite bandwidth as well. OBD-II cables make a difference too. J2534 cables like VersaLink, Mongoose, Tactrix, etc. log at max speed allowed by the ECU. ELM based or ELM emulated cables like OBDLink are a little slower, and bluetooth logging is much slower due to the latency of bluetooth.

In order to increase logging speed, custom code needs to be written to send multiple PIDs per request, as the number of requests/second is limited. Doing that once is not that big of a deal. Doing that hundreds of times is a big deal.

In the 10 years that I have been tuning Mazdas with VT, I have never been unable to get the logging data I needed with the stock logging rate. I treat high speed logging as a nice to have, but not a necessity.

A calibration is an iteration or version of the ECU code and data tables specific to a single model, year, geo region, Fed/Cali emissions, and configuration. N3Z2EU00013H6020 is an example of an RX-8 calibration ID. Each one has a slightly different version of the code and data. You can't cut and paste custom code mods from one calibration to the next. And if you get it wrong, you brick the ECU. So each calibration needs to be tested on a live car which requires coordinating with beta testers around the world. This is massively time consuming.

MS6 did not have an auto trans or many options, so there were few calibrations.
MS3 - still no auto trans, but lots more options and two generations of ECU.
CX-7 - manual, auto, AWD, FWD, trim packages, and two generations of ECU.
RX-8 - manual, auto, 4 port, 6 port, 5 spd, 6 spd, trim packages, a complete shitshow of revisions to address engine failures and emissions, and two generations of ECU.

MS6 has like 4 relevant calibrations globally
MS3 has dozens of calibrations globally
CX-7 has scores of calibrations globally
RX-8 has 100s of calibrations globally

If we get over some of the major hurdles we are working on now, we may circle back to this. It comes down to prioritzing resources to serve the largest number people and solve the biggest problems first.

 

Hurdles with the speed platform or other platforms?

Sampling frequency (requests per frame/per second) is the kind of variable that's platform independent, unlike other things such as fuel/timing/any other tables.

 

PIDs/s is dependent on the processor speed which is different for each generation. Newer Skyactiv ECUs consistently deliver 200 PIDs/s.