RPM measurement via pulses of rectifier

[brammekeuh987]

Hi

I was looking for ways to get the RPM of a PMG generator (3 phase in this case), by counting the pulses of ripple which are generated behind a rectifier. I came up with a circuit which seems to do the job, see schematic.png. Consequence of beiing dependend on the ripple, is that there cannot be a lot of capacitors behind the recitfier. But this should be an issue for my application.
It basically is a kind of mix between an integrator/differentiator with an zero crossing detector (stage 1 ) followed by a schmitt trigger (stage 2). The range of interest is withing 10% to 100% of the generators maximum speed range. You can change this in the schematic by changing genFactor.
Final stage to get the RPM is planned to be done by an Arduino Uno or another type of microcontroller and can be done (in my view) on two ways:

• Use an interrupt routine and measure the time inbetween two interrupts, this time is proportional with the RPM of the generator so you can use a converionfactor and be done --> downside is that at high rpm you get a lot of interrupts, and maybe you don't need to know every 10ms what the current rpm is
• In the current schematic the on/off time ratio of the output pulses is about constant but the frequency varies along with the frequency. I'm looking for a way to get an analog value from this, which could be send to the ADC of a micro converter. I'm not there yet, but for now I'm thinking about to this singal through some kind of electronic circuit that generates a fixed pulse on a rising or falling edge, this can go to an integrator and than you have kind of the signal what you need. This generates a triangle wave, where you can reduce the riplle by using a capacitor

The schematic:

• As seen in bode_magRed_phaseBlue.png it functions as a band pass filter with it's chosen frequency around 10 Hz --> the generator varies between 0 and 50 Hz. The lower the RPM, the lower the amplitude of the voltage and hence also the lower the ripple which we can detect. I don't really care when it is going really slow (let's say below 0.1 Hz) so as a starting 'ideal frequency' 10 Hz was considered: to give some boost to the low rpm / low voltage amplitude signal, and to cancel out the 50Hz/60Hz main power interference as much as possible. 
• on10percent.png shows the signal after the rectifier on 10% (where white noise and 50hz noise is added). Output is still very clean ( )
  
• on100percent_1.png and on100percent_2.png you can see the responses when it is at 100%
  
• the KiCAD file is included, I put all the libraries of the components in the file.
  

Questions:

• I haven't built it yet. So any remarks / improvements on the current schematic?
• Any other alternatives to get the RPM into the micro controller?
• Any practical, poor man's solutions to the rising edge detector with integrator. I know you can do this with flip flop's, you also need a clock and so on...
  

[Zero999]

I haven't read the entire original post, but I've looked at the schematic.

U1 has no DC bias. Scratch that. I missed the 0V connection on the +input.

Remove C5. It makes the Schmitt trigger less effective.

[Dave]

Are you unable to connect directly to one of the phases from the generator? All three of them essentially bounce from one diode drop below your ground to one diode drop above your supply voltage.
All you need is to divide and clamp that voltage and you can process it digitally. Add a Schmitt trigger if you want the cherry on the cake.

[cantata.tech]

• Use an interrupt routine and measure the time inbetween two interrupts, this time is proportional with the RPM of the generator so you can use a converionfactor and be done --> downside is that at high rpm you get a lot of interrupts, and maybe you don't need to know every 10ms what the current rpm is

Interrupts shouldn't be used that way.

All that you want to do is increment or decrement a memory variable to count the pulses and not much else.

Then take that information and display it in your main UI section far from the actual Interrupt Handler. Use the 'volatile' keyword when defining your variable.

[langwadt]

• Use an interrupt routine and measure the time inbetween two interrupts, this time is proportional with the RPM of the generator so you can use a converionfactor and be done --> downside is that at high rpm you get a lot of interrupts, and maybe you don't need to know every 10ms what the current rpm is

Interrupts shouldn't be used that way.

All that you want to do is increment or decrement a memory variable to count the pulses and not much else.

Then take that information and display it in your main UI section far from the actual Interrupt Handler. Use the 'volatile' keyword when defining your variable.

of course interrupts should be used that way. At such low frequency it would take forever to get any kind of resolution just counting pulses

[brammekeuh987]

I haven't read the entire original post, but I've looked at the schematic.

U1 has no DC bias. Scratch that. I missed the 0V connection on the +input.

Remove C5. It makes the Schmitt trigger less effective.

Thanks, C5 has a value of 0, it was there to inspect the effect and you're right it doesn't add any benefits!

Are you unable to connect directly to one of the phases from the generator? All three of them essentially bounce from one diode drop below your ground to one diode drop above your supply voltage.
All you need is to divide and clamp that voltage and you can process it digitally. Add a Schmitt trigger if you want the cherry on the cake.

Thanks!
Yes I can connect directly to a phase, but I don't exactly know what you mean. Do you mean like rectify the signal of one phase, followed by a sufficiently big condensator. Than add a voltage divider to this result and use the lower voltage to calculate the RPM?

• Use an interrupt routine and measure the time inbetween two interrupts, this time is proportional with the RPM of the generator so you can use a converionfactor and be done --> downside is that at high rpm you get a lot of interrupts, and maybe you don't need to know every 10ms what the current rpm is

Interrupts shouldn't be used that way.

All that you want to do is increment or decrement a memory variable to count the pulses and not much else.

Then take that information and display it in your main UI section far from the actual Interrupt Handler. Use the 'volatile' keyword when defining your variable.

of course interrupts should be used that way. At such low frequency it would take forever to get any kind of resolution just counting pulses

Thanks!
Counting the pulses over a fixed period of time is also an option to determine the result. I agree that on my way it takes too many interrupts in the routine to calculate a value, so it isn't an elegant solution. I'm therefor looking for a way to get it in the analog inputs.
Regarding the low frequencies: It's therefor that I prefer to use the ripple after the rectifier: it's the highest frequency signal available

[cantata.tech]

of course interrupts should be used that way. At such low frequency it would take forever to get any kind of resolution just counting pulses

The pulses seem to take 150ms by my reading each.

You only need to sample for a second and there are rolling average functions where you countback 5-10 seconds and use the pulses from that period.

I'm not sure that "forever" applies here. I've not seen computer algorithms for calculating that way.

[langwadt]

of course interrupts should be used that way. At such low frequency it would take forever to get any kind of resolution just counting pulses

The pulses seem to take 150ms by my reading each.

You only need to sample for a second and there are rolling average functions where you countback 5-10 seconds and use the pulses from that period.

I'm not sure that "forever" applies here. I've not seen computer algorithms for calculating that way.

then you haven't looked very much, it it totally standard and used everywhere, something like a rev counter or speedometer would be pretty useless if it showed average over 5-10 seconds

if you buy a frequency counter it'll be called something like reciprocal counting
https://edadocs.software.keysight.com/kkbopen/how-does-a-frequency-counter-work-583405490.html

[mikerj]

The pulses seem to take 150ms by my reading each.

You only need to sample for a second

Think about how poor the resolution would be with a one second gate time. With a 150ms period the actual speed is 400 RPM.  In one second you'd get 6 entire pulses, giving you a displayed value of 360 RPM.   It would remain at 360 RPM until the period reduced to just under 143ms, when the reading will suddenly jump to 420 RPM.

Reciprocal measurements are the only useful way of measuring frequency on a signal with such a slow period.  At higher frequencies switching over to pulse counting may yield better results, and this is what many frequency counters do.

[cantata.tech]

then you haven't looked very much, it it totally standard and used everywhere, something like a rev counter or speedometer would be pretty useless if it showed average over 5-10 seconds

Well that's how the code works.

Injector Pulse counting on older cars to give fuel consumption works on 1-5 seconds range.

Analog Speedometers work at about 250ms.

Typically they were no faster than that.

In software, the range that you want to measure from is a constant that's put in code and can be changed.

I've made my own speedometers and tachometers so I know that measuring a single pulse is not an accurate way of working.

Set up a variable with the time in milliseconds that needs to be averaged for and use an interrupt counter to count pulses.

Change the constants to suite the application.

It's called a moving average system.

[langwadt]

then you haven't looked very much, it it totally standard and used everywhere, something like a rev counter or speedometer would be pretty useless if it showed average over 5-10 seconds

Well that's how the code works.

Injector Pulse counting on older cars to give fuel consumption works on 1-5 seconds range.

Analog Speedometers work at about 250ms.

Typically they were no faster than that.

In software, the range that you want to measure from is a constant that's put in code and can be changed.

I've made my own speedometers and tachometers so I know that measuring a single pulse is not an accurate way of working.

Set up a variable with the time in milliseconds that needs to be averaged for and use an interrupt counter to count pulses.

Change the constants to suite the application.

It's called a moving average system.

counting injector pulses would be pretty pointless since it a fixed number per revolution of the engine, how long the pulses are is what is important

no one said you couldn't average the measurement. The point was that for such low frequencies you have to measure time between pulses,
not count pulses over time

[cantata.tech]

counting injector pulses would be pretty pointless since it a fixed number per revolution of the engine, how long the pulses are is what is important

Actually, not at all. Injector pulses are determined by range of variables including 'load' aka the accelerator-pedal (TPS) and about 20 other settings. It's not fixed at all.
 
As for "counting", in an Industrial setting, it's generic term that can mean a range of things. Basically, it's assigning numbers to observations.

In this setting it means "counting" how long the Injector is open for.

It's counting the milliseconds the Injector is open so that the fuel flow can be determined.

That's the typical automotive meaning of the term "counting injector pulses". Not to know how many there were because that's already known.

Equally, in this example, it might be worthwhile knowing the amount of time that voltage or current is over some particular threshold. I don't know but it's my guess that it's more than likely.

[langwadt]

counting injector pulses would be pretty pointless since it a fixed number per revolution of the engine, how long the pulses are is what is important

Actually, not at all. Injector pulses are determined by range of variables including 'load' aka the accelerator-pedal (TPS) and about 20 other settings. It's not fixed at all.

the number of pulses is fixed, the pulse width is not

As for "counting", in an Industrial setting, it's generic term that can mean a range of things. Basically, it's assigning numbers to observations.

to deliberately make it ambiguous and confusing?

[cantata.tech]

to deliberately make it ambiguous and confusing?

If you are standing in front of a machine in an Industrial setting, then it isn't generally ambiguous or confusing as to why it's there. It must have a purpose.

Yes, sometimes the names of machines can be ambiguous and confusing. Especially when they come from different countries that use different languages. It's just something that people have to deal with. It might be called one thing if it comes from one country and by a different name if it comes from another.

I don't think it's deliberate in most cases.

[peter-h]

Yes this is how I would do it.

Block the DC with a cap and then zero-bias the signal (perhaps at 1/2 rail) so you can detect zero crossings, and feed them to a comparator.

You can extract a very small ripple that way so no issue with caps after the alternator. In most alternator scenarios there is a battery there doing the smoothing.

Then you can use whatever method to measure the period. Measuring the frequency will also work but will take longer to achieve a given resolution, so this is for you to work out.

Most CPUs today have loads of timers which can be set up to measure the period automatically. I've done exactly that to measure a 400Hz signal (for LVDT emulation, emitting two other signals which are phase-locked to this reference). Minimal software involved - just an ISR on the zero crossings.

[Dave]

Are you unable to connect directly to one of the phases from the generator? All three of them essentially bounce from one diode drop below your ground to one diode drop above your supply voltage.
All you need is to divide and clamp that voltage and you can process it digitally. Add a Schmitt trigger if you want the cherry on the cake.

Thanks!
Yes I can connect directly to a phase, but I don't exactly know what you mean. Do you mean like rectify the signal of one phase, followed by a sufficiently big condensator. Than add a voltage divider to this result and use the lower voltage to calculate the RPM?

No, feed it into a microcontroller input pin and then inside use a counter module to measure the frequency. Newer microcontrollers usually have very adaptable timers/counters which will allow you to do that efficiently, without wasting CPU cycles on countless interrupt routines.

[brammekeuh987]

Thanks, I learned a lot about fuell injection systems .

So as I assume that the general consensus is to just feed the digital signal (the output of stage 2) to the controller

Are you unable to connect directly to one of the phases from the generator? All three of them essentially bounce from one diode drop below your ground to one diode drop above your supply voltage.
All you need is to divide and clamp that voltage and you can process it digitally. Add a Schmitt trigger if you want the cherry on the cake.

Thanks!
Yes I can connect directly to a phase, but I don't exactly know what you mean. Do you mean like rectify the signal of one phase, followed by a sufficiently big condensator. Than add a voltage divider to this result and use the lower voltage to calculate the RPM?

No, feed it into a microcontroller input pin and then inside use a counter module to measure the frequency. Newer microcontrollers usually have very adaptable timers/counters which will allow you to do that efficiently, without wasting CPU cycles on countless interrupt routines.

I read that for this purpose you can use the 'Input capture feature'. I got it from John Wasser's answer on this post: https://forum.arduino.cc/t/how-do-i-measure-the-time-between-voltage-pulses-accurately-with-an-arduino-for-diy-efi-project/947830/2
I guess that is what you mean with an 'efficient way of counting'.

The downside of the direct input in to the controller is that the controller is also busy with a lot of other stuff which blocks interruptions (eg during I2C or SPI communication, the interrupts are blocked). So with the regular interrupt, the time registered time could be 'delayed'. As I understand the Input Capture feature correctly: the timestamp is stored in a separate Input Capture register outside your CPU. So whenever a pulse comes during a moment the interruptions are blocked, the correct value is still stored and will the interruption flag will be processed when the interrupts are alowed again. You just need to retrieve it before the next pulse hits the input, because it'll overwrite the register. Since the fastest pulse train has delays of 15ms, the maximum time the CPU can do for one loop is than also 15ms, which should be manageable.

Yes this is how I would do it.

Block the DC with a cap and then zero-bias the signal (perhaps at 1/2 rail) so you can detect zero crossings, and feed them to a comparator.

You can extract a very small ripple that way so no issue with caps after the alternator. In most alternator scenarios there is a battery there doing the smoothing.

Then you can use whatever method to measure the period. Measuring the frequency will also work but will take longer to achieve a given resolution, so this is for you to work out.

Most CPUs today have loads of timers which can be set up to measure the period automatically. I've done exactly that to measure a 400Hz signal (for LVDT emulation, emitting two other signals which are phase-locked to this reference). Minimal software involved - just an ISR on the zero crossings.

Just to be sure, you mean something like the circuit in attachment?
The downside is that at generating factor of 10%, only the noise is left (if you compare it to the output_stage1 of the original post, it's quite messy).
As for processing of the output signal, I guess you mean the same as the Input Caputre feature mentioned above?

I was looking myself some more in the direction of converting it to a analogue signal, like an ADC. I asked it to chatGPT, just for testing, and it actually gave some good hints:

• a frequency to voltage converter (FtoV): the chips alone are already quite expensive and way too precise for my application, in general they are also for higher frequencies (khz - Mhz)
• different implementations of (different kinds of )integrators followed by low frequency pass filters. But these are too slow in adapting/response

So in order to implement the integrator I need to get something which is of 'faster frequency' than the original, in order to maintain responsiveness.
Therefor I was considering to use the time lag between the output_stage1 and output_stage2. If you compare pictures on100percent_2 and on10percent from the original post, you see that the time lag of hitting a certain voltage, is proportional to the frequency. This is a pretty short time, so when you fill up a small capacitor (start of filling = output_stage1 above a threshold voltage, stop = output_stage2 above the same threshold voltage) and afterwards measure the voltage, you have a voltage inverse proportional to the frequency. After this filling up you can use a simpe sample-and-hold circuit (sample = output_stage2  at max voltage, hold = output_stage2 = 0V) which feeds the analog input of your controller.
I don't know if the above makes any sense or would work. Anyone an idea?