About RPM's ?

[maniman]

Hi guys these days I make a rpm counter based on arduino. As many people say that type of pic's havent accurate timing ? in my experience with that i can say no turntable have the same spin time never .. whats the tolerance of that ? maybe im going mad and the system runs relatively well .... someone with a buyed tachometer can post the exact spin time of some turns ? there something like "average" spin time or tolerance spin time that i'm missing ? will post a vid next days to make more clear the question.


Thanks.

[opcode66]

Don't use Arduino. Use real pic chips from microchip.com. Get a 20mhz crystal and some caps for timing. That will be highly accurate.

[markrob]

Don't use Arduino. Use real pic chips from microchip.com. Get a 20mhz crystal and some caps for timing. That will be highly accurate.

Why in the world would you say that???? Do you think the Arduino boards do not have crystal oscillators, counter/timer hardware or decent CPU's? I don't use these boards in my day work, but I see no reason why they would not be ideal for one off DIY projects. I would certainly consider usign them in a case like this. There plenty of great development tools availble too. The availablity of a crystal oscillator is only a part of what would be required to implement this. I'm not sure what he is trying to accomplish here.

A simple readout of the platter speed to say 1% accuracy? .1%?

or

Highly accurate timing data used to reveal small timbase jitter.

If its the first project its not a very dificult thing to implement and should be no problem for an Arduino based design.

Mark

[maniman]

Thanks for the quick response mr . Opcode , I have some programming skills but about electronics and pics I'm totally ignorant ,The arduino was totally easy as entry level ( easy connection , in/out and programming ) , where to start ? its possible be pointed to a "how-to" of similar example or something in that way please ?

which would you do ? if wanna make a simple device for that ?

I'm restoring a old French LD Lathe plus a Grampian , and plan to make a little front panel with a LCD ( rpm , stylus pressure ) , probably a Carusso PCB , definetly a smart panel of basic lathe controls.

Thanks in advance , its a very very interesting subject , deep , but very interesting.

[maniman]

Aha , yes , really my question about accuracy isnt in that way , as Mark suggest isnt a pretentious project , must be simple and easy , and for fun , and taking in care the case , its and old Lathe , the original motor is dead , i replaced with a Bodine that works @ 60hz , and here in Spain the mains its 50 hz , I'm using a shaft that corrects the Hz deviation , taking in care all that inexact things , the lathe probably runs better than never was run in the past.

The real question is the next , as you can see in the vid every turn the spin time its slighty different , that problem its about the motor and / or transmission ? occurs in other turntables ? WHEN CAN AFIRM RUNS 33 1/3 ? average ? tolerance ? or really the arduino are introducing delay that are causing that type of things .

http://www.youtube.com/watch?v=iVPngK1lSac&feature=youtu.be

[opcode66]

Don't use Arduino. Use real pic chips from microchip.com. Get a 20mhz crystal and some caps for timing. That will be highly accurate.

Why in the world would you say that???? Do you think the Arduino boards do not have crystal oscillators, counter/timer hardware or decent CPU's?

Arduino is a handled environment. It is like a BASIC Stamp. If you want very inefficient code then great. If you want efficient code for timing critical devices then Arduino is a poor choice.

[markrob]

Don't use Arduino. Use real pic chips from microchip.com. Get a 20mhz crystal and some caps for timing. That will be highly accurate.

Why in the world would you say that???? Do you think the Arduino boards do not have crystal oscillators, counter/timer hardware or decent CPU's?

Arduino is a handled environment. It is like a BASIC Stamp. If you want very inefficient code then great. If you want efficient code for timing critical devices then Arduino is a poor choice.

Nonsense! The resulting code is c/c++ compiled code. There is a set of supplied libraries to make it easier to get up and running without the need to program at the chip hardware register level. If you really want to get down to the nuts and bolts, you can program directly in c/c++ or assembler using the GNU toolset.

http://arduino.cc/en/Main/FAQ

Mark

[opcode66]

I write in Assembly...

[markrob]

Aha , yes , really my question about accuracy isnt in that way , as Mark suggest isnt a pretentious project , must be simple and easy , and for fun , and taking in care the case , its and old Lathe , the original motor is dead , i replaced with a Bodine that works @ 60hz , and here in Spain the mains its 50 hz , I'm using a shaft that corrects the Hz deviation , taking in care all that inexact things , the lathe probably runs better than never was run in the past.

The real question is the next , as you can see in the vid every turn the spin time its slighty different , that problem its about the motor and / or transmission ? occurs in other turntables ? WHEN CAN AFIRM RUNS 33 1/3 ? average ? tolerance ? or really the arduino are introducing delay that are causing that type of things .

http://www.youtube.com/watch?v=iVPngK1lSac&feature=youtu.be

Hi,

Its hard to tell from your video, but I think I can see the jitter you are talking about. Can you tell us:

1. What model board are you using for your project?

2. How are you sensing the rotation? Looks like you might be using an reflective optical sensor. If you can post the source code, I can take a look at it for you.

3. How are you doing the timing in software? Are you taking advantage of any on-chip counter timers?

Mark

[Steve E.]

Can you double-check your results by using a stroboscope? I would think if your rpms are that slow, you'd see something indicating such a thing by using a stroboscope and disc. I may be missing the basic question.

[maniman]

Wow response avalanche when sleep (really happy friends ,was very bad days for me , Im recovering from herniated disc on the back (how ironic not ?) , and all good things its aligned in the precise days , yesterday and today , thanks for your energy ).

Really its very very simple.

The chip its an Arduino w ATmega 328.

The sensor its a magnetic reel , every turn the magnet pass in front of the coil produces continuity , first attemp was tested with a button.

simplified code (from head , havent the code here)

Code: Select all

bla bla bla lcd library etc etc

bla bla bla setup pins

Declare Array[60];
Declare counter;
Declare ms;

(all are floats except counter its integer)

counter = 0;

the loop{
              if(reel_continuity){
                                              Array[counter] = millis();
                                              if(counter>1){
                                                            ms = 60000 / (Array[counter] - Array [counter-1]);
                                                            print on screen (ms); 
                                                                     }
                                              counter++;
                                             }
if counter = 60{
                          counter = 0; (and start again filling the array)
                         }
}

basically use the millis function to return miliseconds between pulses and get it in array positions , resulted miliseconds between pulses , when divide 60000 / milisecond during a turn get the rpms (NOT?)

now thats is the way , I know its very dumb way but is the one now.

What you think guys ?

Yes , try a strobe disc today , thanks to all .

Best Regards

[markrob]

Hi,

I believe the problem is your method of detecting the sensor pulse. You are not trying to capture the edge. Because you are simply polling for a TRUE condition on the reel_continuity input, there is no sync to the edge state change. To fix tightly poll the sensor input to detect the edge.

for example:

char edge_flag = FALSE;
char last_input_state = FALSE;
char current_input_state = 0;
float current_time = 0;
float last_time = 0;
float rpm;

while (ALWAYS)
{
edge_flag = FALSE;
while(!edge_flag)
{
current_input_state = reel_continuity;
if ((current_input_state == 1) && (last_input_state == 0))
edge_flg = TRUE;
last_input_state = current_input_state;
}
current_time = millis();
rpm = 600000.0 / (last_time - current_time);
printf(%f,rpm);
last_time = current_time;
}

I couldn't this to format correctly, so hopefully, you can make sense of this. If you PM me with your email, I can send a better formatted version with some comments.

Basically, you first tightly poll for a rising edge of the sensor input. Then capture the current time in ms and calculate the rpm based on the difference from previous time reading. The first rotation value will be garbage as there is no edge or time history. Depending on how you sensor is setup, you may need to poll for the falling edge.

Just change

if ((current_input_state == 1) && (last_input_state == 0))

to

if ((current_input_state == 0) && (last_input_state == 1))

Also note that I read the state of the input at one place in the loop (this is important).

The remaing source of errors are:

The accuracy and resolution of the millis() function. I assume it has at least ms resolution. The accuracy is hopefully controlled by the system clock. Check the documentation or source code to see how this is implemented. Youmay need impelent your own timer function.

Finally, the polling rate in the edge detection loop adds a potential source of timing jitter. For example, if the polling rate is 1Khz, you would have up to 1ms of timing jitter. If there are any backgroud interupts running, you may need to disable them during the detection loop or larger errors will result.

Hope this makes sense.

Mark

[Radardoug]

In addition, if you are just using a mechanical switch, then you have contact bounce to contend with, which could add up to 10 mS of uncertainty. You need a better method of sensing rotation. An opto interuptor might be better.
Also if you average the speed over a number of rotations you will get a more stable result.

[markrob]

In addition, if you are just using a mechanical switch, then you have contact bounce to contend with, which could add up to 10 mS of uncertainty. You need a better method of sensing rotation. An opto interuptor might be better.
Also if you average the speed over a number of rotations you will get a more stable result.

A valid point to consider. However, you won't have to deal with a 10ms or more bounce time as timebase jitter here. As the code sample stands, once you are in the loop looking for the edge detection, you will respond to the first sampled edge. At this point, you calculate the rpm and display. Simply add a delay before looping back to the the next edge detection loop. This allows time for any bounce to damp out before you arm for the next edge. You might even be able to eliminate this delay if the total calc and display time is longer than the bounce time. Since we have 1.8 secs to the next edge, you have a ton of time to do nothing. I would avoid a mechanical switch just because of life and repeatabilty issues. A reflective optical sensor should work fine. A slotted opto switch, magnetic Hall or reed switch would also be good choices as well. Averaging is a good idea, but the resolution improvement is a square root function samples taken. So 16 sample average increases your precision by a factor of 4. To get one extra decimal place of accuracy, you need to take a 100 sample average. This has the downside of a long settling time constant. If you use a moving averange, you will have the same slower time constant, but a 1.8 (at 33.33 rpm) second update rate. In the past, I've implemented a simple 1st order IIR digital lowpass filter which does away with the need for a large buffer and gives better results.

Mark

[dubcutter89]

To average might be the right way for absolut measurement, but you cannot measure differintial speed issues (wow&flutter). So I guess a higher resolution sensing system would be better...

just my opinion...

Lukas