5% on the real Intergrator values is really wishful thinking. Since the VE cells are one size and the Adaptive cells are another you end up having to understand that if you crossing an edge things are going to happen. Take your bike if your happy with how it idles and start to log data when you first fire it up in the morning and then allow it to just sit and run, NO input from you at all. Now after about 4 - 5 minutes it should be fully warmed up and just stop the log and shut the bike off. You want to make sure it has run long enough to get up to about 300 F before you shut it off if it's air cooled, and long enough both fans have cycled off and on a few times if water cooled. Now review the log of the Integrator and Adaptive values and lets see what you've got. Your good with Excel so just graph the results so we can all see them.

I should add you should be logging at least the following information

RPM
Desired idle
MAP
O2 voltage F
O2 voltage R
Integrator
Adaptive
TPS %
Engine Temperature
Base Pulse Width

 

I hope this question doesn't get lost.. Are the sensors connected to the ECM via the bus with each one having a DA convertor, which would make sensor data collection a serial process, or are the sensors connected directly to the ECM (still probably serial, but maybe parallel read)? When I've looked at my logs, I've always assumed the data was aligned ...

 

First I think DA means digital to analog. I suspect you mean A2D, analog to digital.

The connection to the sensors is analog. The ECM has A2D on it.. Whether there is a single multiplexed A2D or 2 separate A2Ds is likely moot as the exhaust is sampled at different times. Exhaust stroke for each cylinder is at different times. I could easily see A2D conversion times in the 100 us range tho.. Way faster than max RPM on a HD.

 

Sticking with sensors and sample rates and busses for now then, from the schematics all of the sensors have their own inputs, looking at the pin out for the 6 pin diag connector that looks like a tuning device plugs into the canbus which is serial.

The question becomes how does the ECU pack up the various signals and communicate them to the device - e.g. individual packets of individual sensor readings as and when, or a whole frame of readings assembled by the ECU from all the sensors at a snapshot in time?

 

I think this all goes back to how the ECM gets it's data to run the bike compared to how the ECM reports data to us.

Not all tuners report the data the same way. Some have used the stock strategy and some have changed how the packets are reported. So, to really compare them. The different devices need to be compared which might not fit into the discussion.

 

Good thinking.. How does ECU report data? If everything is broken into packets where each individual bit of data has it's own packet then the packet rate may need to be high and packet transmission gets in the way of data synchronization, even if the data is timestamped.. Collisions on the data buss (really don't know occurance) will loose data and skew the measurements. If it's large packet that contains everything, the overall packet rate and data rate may be slower but at least in the one pack, all of the measurements were taken close to the same time.. The good thing about bigger packets is less overhead.. Each packet has some amount of bytes added for communication.

So is getting the packet rate up better if the data is skewed?

 

Other than to feed the obvious speedo and tacho, was the ECU actually designed to give out all of these signals in the first place, or is this all aftermarket add-ons?

 

You are talking about two things now that need to be separated. Inputs and when they are read and stored, then output of the data from the stored data. The ECM only reads the inputs when instructed to do it. While a sensor maybe outputting a reading all the time, that does not mean it is getting used or stored. This is why I tried to point out the differences earlier on, in sensor response times and accuracy.

Outputting of data can only be as good as the stored data and the only way I know to see what is going on is to run high speed data so we can see when updates to the stored data are happening. This is not something that you, the consumer is ever going to have for the most part. So you are only going to get to see what Delphi gives you, unless, you get in and rewrite the code to change how it works. The Data comes out in what I would call small packets. These packets are predefined in the code so when you ask for packet #1 you get what Delphi put in packet #1 UNLESS the code has been rewritten. The speed at which packets can come out is limited by several things because the data buss is shared to run the rest of the motorcycle. In order to turn up the speed of the data you have to make changes in the normal operation of things and TTS is the only one doing it. We've tried to get the data output as fast as the ECM and data buss will handle and still allow the motorcycle to operate.

The packet size is fixed and the time it takes to transmit the packet, is pretty much fixed as well. This is why TTS uses various Data Types to collect data. If you ask the ECM to send over packets 1- 10, you have to wait for all those to come, to build a frame of data. This is what you, the consumer see's as one frame of data. The truth is that frame was built from several packets that came out in a serial fashion over time. If you take too long the stored information in the ECM may have been updated in between packets being sent. It's all about time and in this case speed is your friend.

The 4 pin connector bikes (J1850) are much slower than the 6 pin connector bikes (CAN). This is why most systems log data at 2 fps for 4 pin and 10 - 12 for 6 pin. They are limited to what Delphi has the buss set for.

 

This can be seen by collecting data with different tuning systems. You can see how a faster tuning device might make a sacrifices to the output to the speedo and gear light in order to help speed up data reported by ECM to logger.

 

So in regard to data skew, can we assume that one line in a log is going to have the MAP, current RPM, pulse width, CLI etc etc from one particular engine cycle ...or is that the problem? and just how big a problem might that be if for example there are 50 cycles per second at 6000rpm but only 14 lines in the log for that second? presumably the maximum skew would be about 3 or 4 cycles, or 80ms

...more for the J1850