Velocity Tracker - String Potentiometer

I have a question.....

I am trying to design an electronic tool that uses a homemade string potentiometer to calculate the velocity (peak/average) of a barbell and also uses an IR emitter/receiver to track bar path in a 2D plane.

Materials:
-Arduino Uno R3
-IR emitter/receiver
-Rotary Encoder 200 p/r (quadrature)
-3d printed spool
-3d printed casing
-steel spring
-ball bearings
-breadboard
-10 ohm resistors
-LED output

My first question will a UNO R3 handle this or do i need a shield of some sort?

What is the difference between a quadrature and basic rotary encoder?

Thanks!
Brad

A quadrature encoded has 2 outputs 90 degrees apart so direction of rotation can be realized as well as position.

groundfungus:
A quadrature encoded has 2 outputs 90 degrees apart so direction of rotation can be realized as well as position.

great thank you!

groundfungus:
A quadrature encoded has 2 outputs 90 degrees apart so direction of rotation can be realized as well as position.

do you think an uno will be compatible?

Yes. There are even libraries to facilitate their use.

quadrature library

Here is one I found. I have never use it but it looks like a good tutorial.

Ok. So a couple questions:

Design will be a spool with a direct connection to the encoder to minimize backlash. The spool will have a 2-3" diameter that the string will lay on and that will yield up to 20-15 revolutions of the encoder.

Encoder axle diameter is ~.24"

Will a 1024 pulse/rev quadrature overload the arduino? My guess is yes considering roughly 5-6+ rev/s being plausible

My other question is an external interrupt to eliminate the coding hassle:

http://www.robotoid.com/appnotes/circuits-quad-encoding.html

by using this:

Thoughts??

Some of the libraries use interrupts. How fast is the linear motion that you want to record? Over what distance do you measure? That information will allow one to calculate the minimum time between pulses and determine if that rate is reliably measureble given the arduino specs.

groundfungus:
Some of the libraries use interrupts. How fast is the linear motion that you want to record? Over what distance do you measure? That information will allow one to calculate the minimum time between pulses and determine if that rate is reliably measureble given the arduino specs.

Linear motion will be 0-1.5 m/s over a distance of 0-3.05 m (0-10ft).

So lets say:

1.5 m/s over 1 m of distance

Spool circumference - .319 m ---> 3.135 revolutions per meter

@ velocity of 1.5 m/s equates to .6667 s to cover the 1 meter distance and complete 3.135 revolutions

Pulse/revolution of encoder - 200 p/rev

.667 s/3.135 rev = .212 sec/rev

.212 s/rev * 1 rev/200 p = .00106 s/pulse = 1.06 milliseconds/pulse

I am unsure on how to compare that to the 16 Mhz of the arduino uno?

Thanks for all your help!

The Uno executes 16,000,000 instructions per second, 16,000 instructions per millisecond. No problem to do this function. You only need one input as the direction of motion is known (I am assuming correct me if wrong). Pulses easily measured with or without interrupts. I would use one interrupt, if available. Is displacement all that you measure or do you want velocity, acceleration? You have resolution at 200, now and had the resolution of the encoder at 1024 before, which is it for sure?

Well if i can get away with the 1024 and not overload that would be great which would come out to .207 ms/pulse.

I would like velocity so direction and magnitude. this is to determine what the speed is when the bar is being lifted up.

Dude, thank you so much for all your help!

groundfungus:
The Uno executes 16,000,000 instructions per second, 16,000 instructions per millisecond. No problem to do this function. You only need one input as the direction of motion is known (I am assuming correct me if wrong). Pulses easily measured with or without interrupts. I would use one interrupt, if available. Is displacement all that you measure or do you want velocity, acceleration? You have resolution at 200, now and had the resolution of the encoder at 1024 before, which is it for sure?

The direction of the bar will be up and down. For example, the bench press, the bar will come down and this will retract the string and cause the encoder to turn CCW and when it is lifted the string will pull the encoder will be pulled CW.

When you reference one interrupt is that just for displacement? two interrupts for disp and direction?

I think (because I haven't use encoders) when using one interrupt the interrupt senses a pulse and then you can read the other encoder output to determine direction. See the site that I linked to, it explains how to get direction.

groundfungus:
A quadrature encoded has 2 outputs 90 degrees apart so direction of rotation can be realized as well as position.

Partially correct - you cannot get the position of a quadrature encoder, only one or more pulses in time (indicating a movement of the encoder), and a direction of travel (clockwise or counter-clockwise). In order to get a position, you need what is called an "absolute encoder" - a potentiometer is one example, but a true digital absolute encoder returns values as a binary number (and once you get beyond 8 bits or so, the cost of such encoders goes thru the roof).

I guess that I meant relative position. If, at some point , you "zero" the count, then you can count pulses and know displacement referenced to your "zero".

So i have some follow up questions about data logging:

My options are

  1. Bluetooth - to - android app

  2. Wifi w/SD Shield to Blynk or similar database website so i can CSV the data.

Ultimate goal is get into excel for graphing/logging. Eventually want all devices I create to log to Access database.

Which option would be easier/optimal? Mind you some users may not have Wifi and also I dont know how to do an android app (working on it tho).

Thanks

You might want to start a new thread as the subject line no longer matches your question. People that are knowledgeable about wireless may not look at this thread.

groundfungus:
You might want to start a new thread as the subject line no longer matches your question. People that are knowledgeable about wireless may not look at this thread.

Ok thanks!