Garrett Turbo Speed Sensor

[synapse]

Guys, I'm having a tough time getting a Garrett speed sensor setup on an ADL. Has anyone had any experience setting one up with an ECU, logger or Dash?

The sensor is powered by 5V and then there is a 5V output frequency that changes according to the wheel speed.

According to the instructions from Garrett, you are supposed to take the output frequency of the sensor, and multiply it by a factor based on the number of compressor blades in the system.

I've tried to set it up based on frequency and simply did the math to get to table values in a custom calibration, but I still can't get the ADL to calculate any values.

When I take the signal output and put it to an analog channel I get, 4.89V when the turbo is not spinning and, 5.05V when the wheel is spinning at idle. So, I know that the sensor is spitting out some sort of output. I just can't seem to get the math right in the channel, or reading the channel. Do you guys have any ideas? Thanks.

[jhidley]

Can you tell us how many blades the compressor wheel has, the factor (coefficient) that Garret gives you, and the values that you put in the Hz versus RPM custom calibration table?

[Martin]

Ive got it working on an ADL3

for a 12blade turbo 1000hz = 40 000rpm

turbo speed is allready a RPM channel, so if you do a custom cal you can have freq converted to RPM for this channel

Dig sensor setup Samples = 5

The Dig input`s specs wont allow you to go up the freq you want but the sample teeth is acutally a divider on the input freq. So even thought the Freq and RPM output figures are normal, if you up the samples you make the divider bigger thus allowing you to run to higher frequencies. (its done internally)

Turbo speed is 0.1hz (3276.7hz) res that will give you 196 600rpm at (16bit plus sign = max of 32767)
If you want to read higher than 196krpm then just put it in a GP channel and run the GP channel through Advanced maths for the calibration then you force it to 32bit which wont have the 32767 roof.

[synapse]

Thank you guys, this is such great input. I finally got it to work. It appears, unless my settings are wrong, as though there needs to be a minimum speed before the sensor outputs a Freq that the ADL can read. So, at idle on a 2.0L T3/T4 60-1 .63ex Garrett, there isn't enough wheel speed to output any info. However, once the engine revs then it displays an output. My frustration was in expecting some sort of output at low speeds, I should've just rev'd the engine . . .

It is a 14 blade turbo and what has made it challenging is that the 480/blade number is not round. Garrett's instructions say that the sensor outputs a square wave 5V freq that is 1/8 the sensor input (14 pulses/Rev). Garrett's sensor divides the input frequency of the sensor and divides it by 8. If the pulse/rev could take fractional numbers then I could just input 1.75 (14 blades/8), but it can't, so on to the custom cal.

My settings for 1hz=34.28 RPM are: Speed input, Custom calibration, frequency, sample=100, 29.2hz=1000 RPM, 292hz=10,000 RPM

If something looks off that is contributing to why the ADL isn't processing low shaft speeds, please let me know, your help is much appreciated.

[Martin]

Why do you make sample so high? it will make the updates slow. high sample will give you slower updates but better resolution. lower sample the inverse of that. BUT, if the turbo is doing very high RPM you wont really notice high sample. Maybe give 100 a try, ive got mine at 5. Maybe post some logging?



Ive run the same speed sensors on a Bosch MS 15.2 Diesel ECU and they also do not read at low RPM. Its not the device that you put them into, im sure its the sensors that doesnt read at low rpm.

[synapse]

Why do you make sample so high? it will make the updates slow. high sample will give you slower updates but better resolution. lower sample the inverse of that. BUT, if the turbo is doing very high RPM you wont really notice high sample. Maybe give 100 a try, ive got mine at 5. Maybe post some logging?

Very good point Martin. My goal will be to log in order to measure differences in very slight control changes. So I will have to try and see just what the logging resolution looks like with the different sampling.

One other thought is that since the sensor electronics basically divides pulses by 8 to generate the frequency, would it make sense to try using pulses/rev=blade-count and sample teeth=8? This would be instead of setting up a custom cal. Would that even work, or am I interpreting sample teeth the wrong way?

[jhidley]

I ran into the same problem with trying to measure engine RPM on an ADL3. There is no divisor for pulses per revolution, so it won't work for most 4 cycle engines.

A couple of comments about entering data points into the custom calibration table (transfer function). Since the sensor you are using is perfectly linear (it better be), you only need two data points. Since you know that the pulse frequency is going to be zero when the turbo is stopped, it makes the most sense to have your first data point (0,0). Then the second data point can be at any RPM. This makes it easier when you are trying to find the correct conversion factors since you only need to ever change one number (of the four).

292Hz = 10,000rpm is correct.

I would also turn the sample averaging down to 10 or so. Having it set to 100 may smooth out the changes in turbo RPM too much.

[jhidley]

No that won't work. The Sample Teeth setting is another type of averaging function. From the help file:

This screen specifies the calibration for a wheel speed channel.

Since wheel speeds are normally derived from a toothed wheel the calibration can simply be entered by specifying the number of teeth per rev and the wheel circumference.

Sample Teeth
The number of Sample Teeth specifies over how many teeth the reading will be averaged. This may be necessary if the teeth are unevenly spaced, or higher resolution is required for high speed signals, otherwise the number of sample teeth should be set to 1.

Increasing the number of sample teeth will reduce the signal update rate since the channel value is only updated each time the number of sample teeth have passed.

To avoid fluctuating readings due to unevenly spaced teeth the number of sample teeth may be set to the number of teeth per rev. In this case the channel value will only be updated once per rev. This may be too slow for some applications.

[synapse]

Thank you Jack. I will let you guys know how the sampling goes.

[Scott@FP]

I have a lot of experience with this type sensor (we sell the equivalent Jacquet unit), it is easy as pie for an ECU, I don't know if the sensor setup for an ADL is any different.

The ECU can only display whole RPM to 20,000, and the dig input is limited to 6000 Hz, so we have to use a divider somewhere. Someone else can fill us in on ADL input limits as I don't know for sure.

For measuring RPM in whole thousands, just remember the unit outputs one pulse for every 8 blades, so in your digital input setup, select RPM, then under calibration use number of blades/8*100 or *1000 (dig in cal can only be a whole number, no fractions allowed).

For instance, for a 14 blade wheel, use either '175' (14/8*100) or '1750' (14/8*1000) for the calibration number. The '175' can then be used in Sensor Setup/UserX to display RPM in thousands plus hundreds by setting up the sensor cal and adding a decimal place; (unitless 1 dec place 0=0.0, 200=200.0 will display up to 200.0K RPM), or use the 1750 as a 1-to-1 for whole thousands.

BTW if anyone is trying for shaft speed based boost control you MUST use the unitless 1 decimal place sensor output. Its tricky but it DOES work.

Also if you get no signal till 10K RPM and/or you get spikes in the logs at high speeds, chances are the sensor gap is too SMALL, not too large. Gaps closer to 1mm work better than .5mm or under.

The sensor output has a period of 100 uS of at least 4v differential for anyone who needed to know.

EDIT: DL'ed and looked at the ADL software, I don't understand why Turbo Speed or a Rot Speed with pulses per rev * 100 of your blade count/8 wouldn't work to display speed in thousands.