27.09.00.02 was discontinued by Harley Davidson in the beginning of 2021 and should NEVER be used by anyone. Yes it has big flaws in it and HD updated everything in early 2021 to 28.02.00.01. Anyone currently trying use a 27.09 calibration is doing a disservice to everyone who get it. To upgrade as quickly as HD did cost them big as they must re-certify everything all over again and thats big money to do it, so do not think for a minute there was no reason to update it right after it was released in production.

 

thanks for the info Steve!

 

As a follow-up to several PM sent to me I will explain the Knock system used by HD since 2007 on all the EFI bikes. There are two types of knock in basic terms, the first is knock and the second is Learned or Adaptive Knock. These are used on ALL Delphi based systems in a HD since 2007. There is very little difference in how these are setup between a TC, RevMax, EVO and the current M8's. In order to understand them it's best to keep them separate for basic understanding.

Knock is reported and has a set of limits. So you can look at just that knock by itself, So if the tool being used is only showing that knock report, then that is all you are going to see. It in NO way means that Adaptive Knock is not there or being used it only means your not seeing it!

Adaptive Knock is the amount of knock that has been learned and store in the ECM to be used much the same as Adaptive fuel values are used in the fuel system. This has it's own set of limits. This amount does not get tossed away each time you start the engine, it stays from engine start to engine start and cannot be cleared out. It has to be learned out over engine run time.

There is much more to all of this, but this should give all of you a basic understanding in general of how it works, and just because you cannot see something doesn't mean it's not there.

 

But you can see adaptive retard when you compare your logs to the spark tables, correct. And you can also zero out the adaptive table, therefore disabling it altogether, correct?

 

Not a true statement all the time. It all depends on what you are being showed. Just because you see a signal in a log how do you know which one you are seeing? There are thousands of things that can be reported out of the ECM and about 100 of those are for various knock items. Unless you know which one you are getting, you just have to hope for the best. There are reports for Total Knock Retard per cylinder, for just the knock retard without Adaptive and on and on and on...............

 

This inconsistency is what makes it frustrating when trying to tune via the log file.
But, unless I am looking at this wrong, there does seem to be useful correlation within the data frames. For example on a single data log line/ frame: I can see the ECU react to a spike in
Spark intensity by pulling timing at a certain RPM , MAP, and TP. I average this date out for the whole log. If I get > than 1 degree of timing pulled for any RPM MAP cross section , I adjust the Spark Table accordingly.

Am I going about this correctly?

just trying to learn 😀

-Steve

 

Understand that everyone wants to learn but some times that's not possible when dealing with unknown data logging equipment. I've brought this up before but its a real kick in the nuts if you do not pay attention to it. If you take 120/RPM you will find how fast the data from your logger has to give you the correct data. So lets say your talking about 3000 RPM for an engine speed. That's 120/3000= 40 Ms. That means in order for your data to be accurate you need a frame of data every 40 Ms, if your device does not give you that, then what are your really seeing? Now what most do not know is the ECM does not send all the data at one time, when you request data it send it back in many small packets of 7 bytes at a time and it takes roughly 20 packets to build one frame of data. So how long does it take for all 20 packets to come in to the device? The ECM reads the data and sends it for each packet one at a time so all 20 packets are not read all at once. They are spread out over time. So if the engine RPM is changing during the time it take to get all 20 sent then does it really all go together?

All this means is that we have spent lots of time coming up with methods to handle the incoming data to know what does and does not go together and there is not one simple do this answer, as it takes a fair amount of computer processing power to evaluate what your getting at any one point in time. That evaluation is changing all the time based on what it see's both in the data and how long it took for the data to get there. What we do that no one else does is roughly triple the data speed over what the ECM does to begin with, no one else does this. This gives us a huge advantage over what anyone else does but it also means hoe we do what we do will most likely not work for anyone else's product because they donot get the high speed data we do.

As an example the factory HD ECM with 27 02 software would only send the data out at roughly 1.8 fps. At 1000 RPM the engine is firing each cylinder 8.33 times per second. So what are you really seeing when you only get data at 1.8 and the engine is running at 8.33?

 

Interesting…depressing, but interesting 🤔. So it seems the faster you can figure out how to correctly assemble the 7 byte packets, the more accurate picture you will have. Also seems like the can bus isn’t helping with only a 7 byte packet size?

Anyway, think I may have to take a closer look at the TTS.

-Steve

 

A good idea. The TTS is so far advanced in what it does and how it works. Strange Steve C is the only one helping with the technical stuff.

 

I’ve learned a ton and am very grateful for his time. Maybe it’s time to start a new topic / thread … torque based ETC ? 😁