Accuracy of the frequency reading - too 'noisy' reading

[ceties]

Hi,

I am measuring frequency of revolution = rpm of a camshaft.

I am using method 1 and method 3

My card is 6221 with 80Mhz timebase.

The TTL pulses come from IRC mounted on the camshaft.

If I switch the IRC to 3600 pulse per revolution I would expect the reading error to be at 3000rpm max 7rpm (see calc bellow)

Err=fx*fx/(fk-fx)

fx= FreqCam*ppr=3000/60*3600=180e3Hz

fk=80e6Hz

Err=406Hz=7rpm

So why does my signal has so much of noise? See picture. The amplitude of the noise for method 1 is around 400rpm and for method 3 150rpm. For now I use moving average filter but I want to know what is going wrong.

Thanks

[Stefo]

Hi Ceties,

One possible reason (for me far the most common) is that signal from IRC is noisy. Try to enable digital filtering, and I'm convinced it should get better.

regards,

stefo

[ceties]

I can try that tomorrow. But I checked the signal quality and it looks like TTL ethalon.

[Stefo]

it depends on what did you use to check the signal. It is enough if the noise pulse si 12.5ns wide. If you used scope, you would need to sample faster than 80MS/s (better 160MS/s) and zoom very closely to the edge. Just then you would be able to see those noisy pulses.

[ceties]

Thanks Stefo, I will definitelly give it a chance but I don't think that this is the reason. If it was counting fake pulses I wouldn't acquire the whole period but from the graphs you can see that it is exactly one period of revolution (the graph ends at the same point as it starts) and one can see exactly 3 "double-waves" since it is three cylinder engine. Plus there is a pulse multiplier before the signal goes to my board that as I believe has electronics to avoid the bouncing.

[ceties]

I turned the digital filter ON...and...nothing happened (I tried all the supported settings). So that was not the reason. I am still wondering if the accuracy as I calculated is right or where the problem is.

[Stefo]

hmmm.... in this case, I would say that your signal could be really like this. If I should just brainstorm with you, It might be something to do with manufacturing precision of encoder. Or maybe your control system. But having spikes like 400 RPM seems to be way too much for both.

To eliminate those options, you could measure analog signal with high-speed scope. But you would really need something like 80MS/s, and you would need to measure few revolutions to analyze signal.

unfortunately, I'm out of ideas 😞

[ceties]

I conducted one more test. I used function generator with 180kHz TTL pulse (which equals to 3000rpm of the camshaft with IRC = 3600pulses). What I got with the Method1 is attached. There are basically just four values read 180180, 179775, 180586, 179372 which equals to the counted edges = 444, 445, 443, 446. I don't understand how it could count 446 edges but apart from that it is expected result and even with 446 still OK (although the formula says that the max error is 406Hz with 446edges it results into 628Hz=11rpm).

So the accuracy expectations are ok as well as the DAQ card (it has no failure).

But how can I have such a noisy signal than. As I said before I aparently acquire the whole period so I do not have any false TTL pulses.

[John_P1]

The width of the pulses coming from the IRC is going to have more variance than the pulses coming from your function generator (the 7 RPM error that you calculated assumes an ideal TTL signal at a perfectly consistent frequency).  Variance in the signal itself would explain why method 1 (inverse of a single period) is more "noisy" than method 3 (inverse of the measured time for a specified number of cycles).  Method 3 is essentially just averaging multiple consecutive period measurements together before inverting to obtain frequency.

The measurement from the function generator looks pretty good.  With an ideal 180 kHz input you should expect just the two possible measured frequencies:

    80 MHz / 445 = 179775

    80 MHz / 444 = 180180

It looks like an extra pulse of the timebase was counted during one of the periods that we would have expected 445 pulses, giving a measured frequency of of 179372 (80 MHz / 446).  The extra pulse may have been counted if it occurred while the input signal was transitioning between .8V and 2.2V.  Something like this:

       

So, I think the noise that you're seeing with the IRC is just the variance in the output of the IRC. The more accurate reading on the function generator confirms that the card is performing adequately.

Best Regards,

[ceties]

Thank you John for your insight. I really apreciate that. Let me rephrase it because I am not sure if I fully understand. Since the engine has some rotational irregularities some of the pulses will have longer/shorter width than the other ones. That's ok and is not a reason to see the peaks in the frequency signal. The reason is that quality of the IRC output. Even on constant frequency the IRC would probably output slightly different widths of the pulses.

Do I get it or the key is the irregularities itself?