as a follow-up to the configuration of the NVH software regarding atopic23527.html">wheel imbalance, I had two more follow up questions about the configuration of the software setup for pre-OBDII:
1. TACH RPM
- Does the software expect 1 pulse per ignition and calculates RPM from that?
If not, what is the expected input signal?
Maybe an override for pulses per crank revolution would be good for some odd waste spark systems?
2. Calculated wheel speed / Gear ratios
- Is there any way to make deal with/compensate for torque converter slippage?
If so, how?
- The reason I am asking is that 60s-80s sometimes vehicles do not lock the torque converter at all, and later ones often only in overdrive.
Regarding this, it would be awesome if you could engineer the software to couple a GPS input for ground / road speed.
From that, a (more) accurate tire and propshaft speed could be obtained rather than with the gear ratios, and it would be less clunky to obtain I believe.
Hello and thank you for the post
Regarding Tach RPM
An ignition pulse/trigger can be used to determine engine rpm.
For conventional ignition you can use 0.5 pulses per revolution (i.e. non-wasted spark)
1
For wasted spark ignition, this would be one pulse per revolution
One pulse per revolution would also apply where our optical sensor (Opto) is used. Here we place a piece of reflective tape on the crankshaft pulley which triggers a 0-5 V pulse from the Opto
The “pulse per RPM” dialog box above can be configured up to a maximum of 100 pulses per revolution so as to accommodate a multitude of speed sensors to derive RPM
Moving onto Calculated wheel speed / Gear ratios
You raise a valid point when “calculating road speed” as we do not allow for Torque Convertor slippage (This applies to CVT transmissions too)
One option is to keep engine speed low and off load during road test so as to keep slippage to a minimum (not ideal and impractical if our vibration is related to load)
I am going to assume 60’s to 80’s auto may not include an input shaft speed sensor? Or, a provision to use our optical sensor aimed at the input shaft (I guess we can hope)
I ask because if we can determine input shaft speed, we can use this signal as our RPM input upon which to determine road speed as we are downstream of the torque convertor
On the flip side, if we can obtain both engine and input shaft speed, we can determine torque convertor slippage. We have discussed this at length using math channels in this forum post
You will have to scroll down to “Image 8” but it does show what is possible where we have both engine speed and input shaft speed with good resolution
If road speed accuracy is absolutely vital to our diagnosis, we can cheat and use an optical sensor aimed either at the drive shaft (to the road wheel) or the prop shaft (gearbox output shaft) as our RPM signal and then use custom vibrations and correction factors to find vibration orders
The following link uses this approach for EV’s but it does explain the process which you can apply to ICE’s viewtopic.php?p=103941#p103941
In this scenario, we are downstream of the torque convertor and therefore accommodate for slip
Here is another option using microphone narration to highlight areas in your recording where you can announce engine, road speed and estimated load (I.e. “I am hill climbing”) topic23068.html
I hope the above helps and I agree with your suggestion of a GPS sensor input for road speed. I have no doubt that such a device would make an awesome accessory for our NVH and PS7 software
(I have said too much already)
Ok, thank you especially for pointing out the "pulses per revolution"; I somehow missed that.
I understand without OBDII we are in no man's land and need to think outside the box to obtain input :}
For now, I have been trying to replicate issues in 3rd or 4th when the converter locks; interesting idea with the optical sensor, too!
Hopefully the GPS will become available very soon!