apalrd wrote:
Some eTPU controllers set the TCR2 resolution to 0.1 deg/bit, which would mean any angle must be rounded to the neatest 0.1 degree. Motohawk uses 1/16th instead, so 0.0625 deg. I believe they are accurate to at least 1/2 degree (this is the spec for the system I worked on), the worst-case error will probably be when interpolating across the missing tooth gap as there is an 18 degree window without a physical tooth (with 60-2). Misfire uses the times of physical teeth, and doesn't rely on the crank interpolation. Of course, eTPU can only interpolate from the crank signal so a bad crank signal will always cause some timing error.
The eTPU code doesn't work like that...but I don't know how Motohawk presents. What you set effectively is a clock speed and need to get no more than 1024 tics between teeth at whatever RPM is your min and that give you a resolution of (degrees between teeth/1024) * (min rpm/rpm).
Yes misfire is based on physical teeth, but as I said that is based on the sensors ability to detect the teeth. All of the hall sensors I've ever checked jitter or bounce around when reading a constant rpm wheel tooth location. VR sensors, at the sensor itself, read the tooth location more accurately than I can measure error, but it's possible the conditioning circuit adds error.
apalrd wrote:
I've never particularly liked VR sensors because the interface circuit is more complicated, but I've never had any problems with them either.
Programmers and HW designers never do.....but they are much much more accurate so us MEs love them
apalrd wrote:
The MS code must be checking something, because we tried MS before going to Motohawk and couldn't get it to synchronize to a 12-1 trigger wheel on a single cylinder engine. This resulted in extremely poor starting, and when it started it would occasionally lose sync. With the TPU based controllers it synchronizes with no problems.
hmmm....that might be the down side or the averaging scheme, it can't react to rapid rpm changes like you see on a single during cranking?
The eTPU code has no issue with it either as long as a VR or high quality Hall pickup is used.....once I changed sensors there was basically nothing I could do to make it break sync other than drop below the threshold RPM so it could time-out between teeth. Really good.