Adventures in fan control
-
The hypothetical fan has a tach pin that pulses high twice per revolution. There are two ways to get the RPM: 1. Count the actual pulses it makes in a minute and divide by two (or a fraction of a minute and factor accordingly) 2. Count the time (in microseconds probably) between pulses and use that to extrapolate the RPM. There are 6e+7 microseconds in a minute, so working with that, you divide it by twice the duration of the pulse. 2 has an obvious advantage in that it doesn't require you to sample for a significant period of time before you get a value. In fact, you can get a value each revolution since there are two pulses. The problem with 2 is it doesn't work? My RPMs come back as like 5-7 on a 1700RPM fan being run at full power. I've had other people eyeball my code and my math. There's nothing wrong with it. So I've got some sort of theory of operation problem. You'd think a fan would be relatively simple, but it stumped me.
To err is human. Fortune favors the monsters.
-
The hypothetical fan has a tach pin that pulses high twice per revolution. There are two ways to get the RPM: 1. Count the actual pulses it makes in a minute and divide by two (or a fraction of a minute and factor accordingly) 2. Count the time (in microseconds probably) between pulses and use that to extrapolate the RPM. There are 6e+7 microseconds in a minute, so working with that, you divide it by twice the duration of the pulse. 2 has an obvious advantage in that it doesn't require you to sample for a significant period of time before you get a value. In fact, you can get a value each revolution since there are two pulses. The problem with 2 is it doesn't work? My RPMs come back as like 5-7 on a 1700RPM fan being run at full power. I've had other people eyeball my code and my math. There's nothing wrong with it. So I've got some sort of theory of operation problem. You'd think a fan would be relatively simple, but it stumped me.
To err is human. Fortune favors the monsters.
Overflow? Clock tick period? If this is shorter than you expected, you will get silly results if you try to time between two consecutive pulses. If the rising edge isn't high / sharp enough, it could be triggering early or late? But of course, sticking a scope probe on the pulse may change the results ... :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Overflow? Clock tick period? If this is shorter than you expected, you will get silly results if you try to time between two consecutive pulses. If the rising edge isn't high / sharp enough, it could be triggering early or late? But of course, sticking a scope probe on the pulse may change the results ... :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
I check the overflow condition by short circuiting with an early return if old_tick_us is greater than tick_us if that makes sense. In that case I just don't use that reading. I've verified I'm getting the ticks because I've tried #1. I've even tried taking a sample only every ten revolutions (20 ticks) and counting the duration between that and the initial tick and I don't get better results - can't remember what they were and I'm getting a friend's help to test since I don't currently have a power supply that can run a fan - one is on order. Edit:
OriginalGriff wrote:
If the rising edge isn't high / sharp enough, it could be triggering early or late?
I missed this somehow when I first read your post. Interesting. The only thing that makes me doubt it is the RPM readings I'm getting are so bloody low - single digits when they should be four digits. It makes me think there's a deeper issue.
To err is human. Fortune favors the monsters.
-
The hypothetical fan has a tach pin that pulses high twice per revolution. There are two ways to get the RPM: 1. Count the actual pulses it makes in a minute and divide by two (or a fraction of a minute and factor accordingly) 2. Count the time (in microseconds probably) between pulses and use that to extrapolate the RPM. There are 6e+7 microseconds in a minute, so working with that, you divide it by twice the duration of the pulse. 2 has an obvious advantage in that it doesn't require you to sample for a significant period of time before you get a value. In fact, you can get a value each revolution since there are two pulses. The problem with 2 is it doesn't work? My RPMs come back as like 5-7 on a 1700RPM fan being run at full power. I've had other people eyeball my code and my math. There's nothing wrong with it. So I've got some sort of theory of operation problem. You'd think a fan would be relatively simple, but it stumped me.
To err is human. Fortune favors the monsters.
Not knowing what hardware you are using, just a thought that maybe irrelevant - but have you got any components (capacitors/inductors that in conjunction with resistors or internal resistance of other components) that may have accidentally created a filter that is tuned to roughly the frequency you would be expecting and either attenuating the signal or passing it to ground? Maybe an idea to use an optical isolator to separate the output signal totally from the inductive load of the fan motor???
-
Not knowing what hardware you are using, just a thought that maybe irrelevant - but have you got any components (capacitors/inductors that in conjunction with resistors or internal resistance of other components) that may have accidentally created a filter that is tuned to roughly the frequency you would be expecting and either attenuating the signal or passing it to ground? Maybe an idea to use an optical isolator to separate the output signal totally from the inductive load of the fan motor???
I do share a ground with the fan but they are on a different power supply than the MCU that is taking the reading. There aren't any components in the circuit other than a level shifter, which I know can handle these frequencies because I routinely use them with I2C devices. Edit: I should add, I am getting all the ticks because method #1 in my original post works.
To err is human. Fortune favors the monsters.
-
The hypothetical fan has a tach pin that pulses high twice per revolution. There are two ways to get the RPM: 1. Count the actual pulses it makes in a minute and divide by two (or a fraction of a minute and factor accordingly) 2. Count the time (in microseconds probably) between pulses and use that to extrapolate the RPM. There are 6e+7 microseconds in a minute, so working with that, you divide it by twice the duration of the pulse. 2 has an obvious advantage in that it doesn't require you to sample for a significant period of time before you get a value. In fact, you can get a value each revolution since there are two pulses. The problem with 2 is it doesn't work? My RPMs come back as like 5-7 on a 1700RPM fan being run at full power. I've had other people eyeball my code and my math. There's nothing wrong with it. So I've got some sort of theory of operation problem. You'd think a fan would be relatively simple, but it stumped me.
To err is human. Fortune favors the monsters.
-
Can't you just output the duration between pulses, in order to discriminate between a measure error or computation error?
"In testa che avete, Signor di Ceprano?" -- Rigoletto
The only reason I haven't done that yet - admittedly part of it is laziness - is it complicates the code and I'm not sure what readings I should be expecting as I have no practical concept of a microsecond vs a spinning fan.
To err is human. Fortune favors the monsters.
-
The only reason I haven't done that yet - admittedly part of it is laziness - is it complicates the code and I'm not sure what readings I should be expecting as I have no practical concept of a microsecond vs a spinning fan.
To err is human. Fortune favors the monsters.
-
The hypothetical fan has a tach pin that pulses high twice per revolution. There are two ways to get the RPM: 1. Count the actual pulses it makes in a minute and divide by two (or a fraction of a minute and factor accordingly) 2. Count the time (in microseconds probably) between pulses and use that to extrapolate the RPM. There are 6e+7 microseconds in a minute, so working with that, you divide it by twice the duration of the pulse. 2 has an obvious advantage in that it doesn't require you to sample for a significant period of time before you get a value. In fact, you can get a value each revolution since there are two pulses. The problem with 2 is it doesn't work? My RPMs come back as like 5-7 on a 1700RPM fan being run at full power. I've had other people eyeball my code and my math. There's nothing wrong with it. So I've got some sort of theory of operation problem. You'd think a fan would be relatively simple, but it stumped me.
To err is human. Fortune favors the monsters.
If method 1 works and method 2 does not, then there is either an error in the time recorded or an error in the maths. You should be getting about 17000 microseconds between pulses. How many did you get? (60s/1700 rpm = 0.035 s per rotation = 17000 microseconds per 1/2 rotation)
