Hello
I am working with a computerprograme for my rolling road and I think that I have the calculation for the rpm on the rollers wrong. How would you do it? I have 4 pulses/r and the card do a read every half second.
I also have great problems with torque reading. It gives a very unsteady reading. Do anyone have any ideas have to stabilize it?
Problems with rpm and torque reading
15 posts
• Page 1 of 1
by Tony » Wed Sep 19, 2007 6:46 pm
Pulses are read 120 times per minute
Therefore, pulse count = rpm/120
RPM = pulse count x 120
But there will be four pulses generated every revolution
RPM = pulse count x 120/4
RPM = pulse count x 30
The way to fix the unsteady torque reading is by averaging several readings in software. There are two ways to do this, the simple way works if the problem is not too bad.
The unsteady readings could arise because of mechanical vibration or electrical noise getting into the torque measurement, and is fairly normal, and to be expected.
Take a number of readings one after the other and add them together. Then divide the total by the number of readings taken. In binary arithmetic, dividing by two just means shifting the binary number to the right. Here is a very basic example of how to average four readings:
Set totalizer to zero
Add reading to totalizer
Add reading to totalizer
Add reading to totalizer
Add reading to totalizer
Shift totalizer right two times (divide by four)
The more readings you average, maybe 4, maybe 32 or more, the smoother the result will be, but the response to any torque changes will be slower.
If simple averaging does not work well enough, a running average can be calculated, but that is slightly more complicated. Try the simple averaging method first, it may be all you need.
In some engine dyno monitoring software I once wrote for someone, I read torque 1,600 times per second, and used a running average of 16 readings so that torque was updated 100 times per second. That was more than sufficient to produce a dead smooth noise free curve on the computer screen with twelve bit resolution. Yet it was sensitive enough to pick an occasional spark plug misfire with a slight wiggle in the torque curve.
Therefore, pulse count = rpm/120
RPM = pulse count x 120
But there will be four pulses generated every revolution
RPM = pulse count x 120/4
RPM = pulse count x 30
The way to fix the unsteady torque reading is by averaging several readings in software. There are two ways to do this, the simple way works if the problem is not too bad.
The unsteady readings could arise because of mechanical vibration or electrical noise getting into the torque measurement, and is fairly normal, and to be expected.
Take a number of readings one after the other and add them together. Then divide the total by the number of readings taken. In binary arithmetic, dividing by two just means shifting the binary number to the right. Here is a very basic example of how to average four readings:
Set totalizer to zero
Add reading to totalizer
Add reading to totalizer
Add reading to totalizer
Add reading to totalizer
Shift totalizer right two times (divide by four)
The more readings you average, maybe 4, maybe 32 or more, the smoother the result will be, but the response to any torque changes will be slower.
If simple averaging does not work well enough, a running average can be calculated, but that is slightly more complicated. Try the simple averaging method first, it may be all you need.
In some engine dyno monitoring software I once wrote for someone, I read torque 1,600 times per second, and used a running average of 16 readings so that torque was updated 100 times per second. That was more than sufficient to produce a dead smooth noise free curve on the computer screen with twelve bit resolution. Yet it was sensitive enough to pick an occasional spark plug misfire with a slight wiggle in the torque curve.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
by Tony » Thu Sep 20, 2007 4:42 pm
First monitor the waveform coming directly out of the speed pickup with an oscilloscope, it must be a completely clean solid constant waveform.
Measure the frequency of these pulses on a digital frequency counter, and make sure the software is showing exactly fifteen times this frequency as RPM. If not, the software is most likely the problem. For example:
Roller 1,000 rpm = 4,000 pulses per minute = 66.66 Hz on frequency counter
66.66 Hz x 15 = 1,000 RPM from software
Measure the frequency of these pulses on a digital frequency counter, and make sure the software is showing exactly fifteen times this frequency as RPM. If not, the software is most likely the problem. For example:
Roller 1,000 rpm = 4,000 pulses per minute = 66.66 Hz on frequency counter
66.66 Hz x 15 = 1,000 RPM from software
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
by Sandra » Fri Sep 21, 2007 12:19 pm
Okay. So if I measure the frequence from my sensor and it show 66.66 Hz, then the RPM on the rollers should be 1000. Am I correct? Because that is not the case with my rollers, so maybe that is one of my problems.
I use a distributor (without braker) from a car as my sensor, can that be the problem?
In your formula you take 66.66 * 15, where are the number 15 coming from?
I use a distributor (without braker) from a car as my sensor, can that be the problem?
In your formula you take 66.66 * 15, where are the number 15 coming from?
- Sandra
- Posts: 38
- Joined: Thu Aug 18, 2005 1:15 pm
- Location: Sweden
by Tony » Fri Sep 21, 2007 5:03 pm
66.66Hz (cycles per second) = 4,000 (cycles per minute) from the distributor
4,000 cycles per minute = 1,000 rpm because there are four pulses per revolution (60/4 = 15 hence the 15:1 relationship)
The car distributor should work fine, just connect a suitable resistor where the ignition coil usually goes, and there should be some lovely rectangular pulses as wide as the designed in distributor dwell time.
It looks like the signal may be getting to your circuit board o/k, but something is still not quite right. What value pull up resistor and voltage are you using on this distributor? and Is the rpm just reading wrongly, or is the rpm jumping around wildly all over the place? And what type of counter timer chip, or micro controller, is this signal going into?
There is a 15:1 relationship between measured frequency (cycles per second) and rpm. And there will be a 30:1 relationship between what your electronics counts and rpm, because your electronics measures over half a second not one full second. It will count up to either 33 or 34 pulses each half second at 1,000 roller rpm.
When it is working properly the way you are doing it, the displayed rpm will jump randomly twice per second between 33 x 30 = 990rpm and 34 x 30 = 1020 rpm. When the rollers are running at a steady true 1,000 rpm.
Although doing it this way is very simple, it has two disadvantages. It only reads rpm twice per second, and there will always be a 30 rpm random jumping of the measured rpm. But get it working like this first, and fix whatever other problems there are with the torque measurement.
4,000 cycles per minute = 1,000 rpm because there are four pulses per revolution (60/4 = 15 hence the 15:1 relationship)
The car distributor should work fine, just connect a suitable resistor where the ignition coil usually goes, and there should be some lovely rectangular pulses as wide as the designed in distributor dwell time.
It looks like the signal may be getting to your circuit board o/k, but something is still not quite right. What value pull up resistor and voltage are you using on this distributor? and Is the rpm just reading wrongly, or is the rpm jumping around wildly all over the place? And what type of counter timer chip, or micro controller, is this signal going into?
There is a 15:1 relationship between measured frequency (cycles per second) and rpm. And there will be a 30:1 relationship between what your electronics counts and rpm, because your electronics measures over half a second not one full second. It will count up to either 33 or 34 pulses each half second at 1,000 roller rpm.
When it is working properly the way you are doing it, the displayed rpm will jump randomly twice per second between 33 x 30 = 990rpm and 34 x 30 = 1020 rpm. When the rollers are running at a steady true 1,000 rpm.
Although doing it this way is very simple, it has two disadvantages. It only reads rpm twice per second, and there will always be a 30 rpm random jumping of the measured rpm. But get it working like this first, and fix whatever other problems there are with the torque measurement.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
by Sandra » Sat Sep 22, 2007 3:44 pm
I use a distributor with a hall sender. The power supply for that is 5v. I connect the distributor to a USB experiment interface board from Velleman. A have a friend whoi are writing the program for me in C#.
The rpm is reading wrongly, it jumps a little bit to but I think it is because of the reason you wrote about.
The rpm is reading wrongly, it jumps a little bit to but I think it is because of the reason you wrote about.
- Sandra
- Posts: 38
- Joined: Thu Aug 18, 2005 1:15 pm
- Location: Sweden
by Tony » Sat Sep 22, 2007 8:36 pm
Ok Sandra, if it is randomly jumping up and down by 30 rpm that is to be expected. At 1,000 roller rpm that is only +/- 1.5% and at higher roller rpm even less than that.
This is happening because the measured count is always going to have one count uncertainty, and you are multiplying that by thirty to get rpm.
One way to fix it is to have more than four pulses per roller revolution. If you had for example, forty pulses per revolution instead of four pulses per revolution, you would only need to multiply by three, not thirty. The reading would then jump up and down by only three rpm.
If this rpm jumping really worries you, a solution is to fit a pulse generator onto your shaft that puts out a much greater number of pulses per revolution. 120 pulses per revolution would only jump 1 rpm. And 360 pulses per revolution could be divided down in software by three, instead of being multiplied, and would jump less often, and when it did jump, it would only be by 1 rpm.
You could probably make something yourself using a large sprocket with some sub multiple of 120 teeth (perhaps 120, 60, 40, or 24 teeth) using either a hall sensor or an optical sensor. A better way would be to buy a proper commercial incremental optical shaft encoder.
There are a vast number of different types, and different manufacturers, and the prices vary a lot too. Just make very sure that it has proper ball bearings and a suitable continuous speed rating.
Some of the cheaper ones are intended to be used only with a control knob, and are definitely not suitable for continuous high speeds.
This is the brute force "hardware" solution to solve the frequency jumping problem, and assumes fairly simple electronics that just counts pulses over a fixed time interval and displays the count as a direct rpm reading.
But there is another completely different "software" way to go about all this that has many advantages. If software is your thing, or you know a friendly software geek, that is prepared help you, this will be much better.
More in my next post.
This is happening because the measured count is always going to have one count uncertainty, and you are multiplying that by thirty to get rpm.
One way to fix it is to have more than four pulses per roller revolution. If you had for example, forty pulses per revolution instead of four pulses per revolution, you would only need to multiply by three, not thirty. The reading would then jump up and down by only three rpm.
If this rpm jumping really worries you, a solution is to fit a pulse generator onto your shaft that puts out a much greater number of pulses per revolution. 120 pulses per revolution would only jump 1 rpm. And 360 pulses per revolution could be divided down in software by three, instead of being multiplied, and would jump less often, and when it did jump, it would only be by 1 rpm.
You could probably make something yourself using a large sprocket with some sub multiple of 120 teeth (perhaps 120, 60, 40, or 24 teeth) using either a hall sensor or an optical sensor. A better way would be to buy a proper commercial incremental optical shaft encoder.
There are a vast number of different types, and different manufacturers, and the prices vary a lot too. Just make very sure that it has proper ball bearings and a suitable continuous speed rating.
Some of the cheaper ones are intended to be used only with a control knob, and are definitely not suitable for continuous high speeds.
This is the brute force "hardware" solution to solve the frequency jumping problem, and assumes fairly simple electronics that just counts pulses over a fixed time interval and displays the count as a direct rpm reading.
But there is another completely different "software" way to go about all this that has many advantages. If software is your thing, or you know a friendly software geek, that is prepared help you, this will be much better.
More in my next post.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
by Tony » Sat Sep 22, 2007 9:46 pm
There are two fundamentally different ways to go about measuring revolutions per minute.
The obvious intuitive way is to just count how many times the thing goes around over a full minute. That is slow, because it takes a full minute to get a complete reading. If the speed has changed at all in that minute, the result will not be accurate.
So instead, you decide to measure revolutions over say six seconds, and multiply the count by ten. That updates much faster, but the problem being the multiplication process. The readings will always change in steps of ten rpm.
But there is a completely different way to go about all this. Suppose you just measure the time period it takes for one complete revolution. You get a fresh reading every turn of the shaft, so it will follow speed changes extremely rapidly.
This is called reciprocal counting, because as the speed goes up, the time period actually measured goes down. The measurement works rather like a stop watch, very fast pulses are turned on and off every shaft revolution, and a counter counts upward in increments of time. The smaller the time increments being counted, the higher the speed resolution can be made.
So you might get a reading of something like 60 milliseconds per revolution, and that works out to 1,000 rpm.
60mS = 0.06 seconds = 60/1000 revs per second = 1/1000 revs per minute (exact time for one full revolution)
Or you could make the same measurement in microseconds (60,000uS) to give extremely fine speed resolution, and get it updated every turn of the shaft. The performance of reciprocal counting can be vastly better for measuring dyno roller speed than just counting pulses over a fixed time interval. But it requires a fast period counter and some software gymnastics to convert a time period back into roller rpm. But if you can do it, it is by far the better way.
The only real problem doing this, is that as rpm falls, the measurement period per revolution obviously lengthens. At zero speed, time stretches out to infinity, and your electronic stopwatch will overflow. So reciprocal counting always has a minimum roller rpm that can be measured. Software can take care to detect this minimum overflow speed, and give a zero reading. In practice this is not a serious limitation, but the software needs to be written with this time overflow problem in mind, which is not difficult.
This is the "software" solution, and it would work perfectly well with the four pulses per roller revolution that you already have. It would solve the rpm jumping problem, and give a very fast and accurate speed reading with high resolution. It just requires more software to do it this way.
The obvious intuitive way is to just count how many times the thing goes around over a full minute. That is slow, because it takes a full minute to get a complete reading. If the speed has changed at all in that minute, the result will not be accurate.
So instead, you decide to measure revolutions over say six seconds, and multiply the count by ten. That updates much faster, but the problem being the multiplication process. The readings will always change in steps of ten rpm.
But there is a completely different way to go about all this. Suppose you just measure the time period it takes for one complete revolution. You get a fresh reading every turn of the shaft, so it will follow speed changes extremely rapidly.
This is called reciprocal counting, because as the speed goes up, the time period actually measured goes down. The measurement works rather like a stop watch, very fast pulses are turned on and off every shaft revolution, and a counter counts upward in increments of time. The smaller the time increments being counted, the higher the speed resolution can be made.
So you might get a reading of something like 60 milliseconds per revolution, and that works out to 1,000 rpm.
60mS = 0.06 seconds = 60/1000 revs per second = 1/1000 revs per minute (exact time for one full revolution)
Or you could make the same measurement in microseconds (60,000uS) to give extremely fine speed resolution, and get it updated every turn of the shaft. The performance of reciprocal counting can be vastly better for measuring dyno roller speed than just counting pulses over a fixed time interval. But it requires a fast period counter and some software gymnastics to convert a time period back into roller rpm. But if you can do it, it is by far the better way.
The only real problem doing this, is that as rpm falls, the measurement period per revolution obviously lengthens. At zero speed, time stretches out to infinity, and your electronic stopwatch will overflow. So reciprocal counting always has a minimum roller rpm that can be measured. Software can take care to detect this minimum overflow speed, and give a zero reading. In practice this is not a serious limitation, but the software needs to be written with this time overflow problem in mind, which is not difficult.
This is the "software" solution, and it would work perfectly well with the four pulses per roller revolution that you already have. It would solve the rpm jumping problem, and give a very fast and accurate speed reading with high resolution. It just requires more software to do it this way.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
by bruce » Sat Sep 22, 2007 10:38 pm
I made mine out of a 30 tooth gear and used a 2 wire inductance coil sensor for my pickup. The teeth on the gear were machined off till the flat was the width the sensor required for a proper trigger. This was taken from the manufacturer's spec sheet. Here is a pic of my setup:
Edited By bruce on 1190515266
Edited By bruce on 1190515266
"There is no more formidable adversary than one who perceives he has nothing to lose." - Gen. George S. Patton
- bruce
- Site Admin
- Posts: 1638
- Joined: Sun May 09, 2004 12:17 pm
by Tony » Sat Sep 22, 2007 11:55 pm
An excellent solution there Bruce, that is how I would do it.
The engine dyno I mentioned earlier used 36 teeth. Around that number of sprocket teeth ends up being a nice convenient size for many things.
For something electronic with more pulses per revolution, some of the cam angle sensors may be worth looking at.
Nissan use an optical system with 360 pulses per revolution which would make an excellent dyno speed pickup.
The engine dyno I mentioned earlier used 36 teeth. Around that number of sprocket teeth ends up being a nice convenient size for many things.
For something electronic with more pulses per revolution, some of the cam angle sensors may be worth looking at.
Nissan use an optical system with 360 pulses per revolution which would make an excellent dyno speed pickup.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
- 99-1134301289
by Tony » Thu Oct 04, 2007 6:49 pm
cre,
That is really interesting. I was wondering how long it would be before someone brought out a commercial dyno controller. Dyno logging software is readily available from several commercal sources, but up until now, what controls the dyno speed and load has been left to the individual to design his own dyno control system.
Sandra,
How many teeth are best, depends on what you are going to use to measure the output frequency. Best talk to your software guy, and see what he suggests. Too many output pulses may overflow whatever is used to count them at high roller speeds. Too few output pulses reduce the amount of information at lower roller speeds. You need to look at the whole system to come up with an optimum design.
That is really interesting. I was wondering how long it would be before someone brought out a commercial dyno controller. Dyno logging software is readily available from several commercal sources, but up until now, what controls the dyno speed and load has been left to the individual to design his own dyno control system.
Sandra,
How many teeth are best, depends on what you are going to use to measure the output frequency. Best talk to your software guy, and see what he suggests. Too many output pulses may overflow whatever is used to count them at high roller speeds. Too few output pulses reduce the amount of information at lower roller speeds. You need to look at the whole system to come up with an optimum design.
Also known as the infamous "Warpspeed" on some other Forums.
- Tony
- Posts: 824
- Joined: Sat Dec 03, 2005 12:34 pm
- Location: Melbourne, Australia
15 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests