pic: Encoder Graph

[JohnFogarty]

No not yet that seems to be the popular suggestion to fix this problem.
how would I go about sampling?
I know I would need to pull the raw value.
Do I store an initial value and then just add to it then divide it by my time?

[Ether]

Originally Posted by John_1102

No not yet that seems to be the popular suggestion to fix this problem.
how would I go about sampling?
I know I would need to pull the raw value.
Do I store an initial value and then just add to it then divide it by my time?

1. Get new_value (of counts)
   
2. delta_counts = new_value - previous_value
   
3. speed = delta_counts / cycle_time* (scaled to whatever units you want to use for speed*)
   
4. previous_value = new_value

*See posts 23, 24, & 26 of this thread.

[flameout]

I ran a quick test as well (not graphing the data or anything, just dumping it to the standard output) and found a similar amount of variation. I was using whatever WPILibJ defaults to for encoder decoding (1X? 2X? 4X?).

For what I'm writing, however, manual differentiation (to those who don't know what this means, it's the method Ether wrote in the last post) is easier to implement and completely effective.

[JohnFogarty]

Awesome, thanks this should really help out thanks for anyone who has been testing this along with me.

[Nikhil Bajaj]

Just so everyone knows, from the US Digital website, the length of the on pulse for each channel in phase degrees is 180 +/- 16, and the quadrature delay between channels can be 90 +/- 12 degrees for the E4P encoder. If you're in 4x mode and timing the gaps between transitions to get the rate, the data that you got is what I'd expect it to look like based on the specifications!

[Ether]

Originally Posted by Nikhil Bajaj

If you're in 4x mode and timing the gaps between transitions to get the rate

Is that what the FPGA does? Times the edge-to-edge transitions, and then GetRate() returns a calculation based on only the 2 most recent edges (not averaged over several samples?)

[Joe Ross]

Originally Posted by Ether

Is that what the FPGA does? Times the edge-to-edge transitions, and then GetRate() returns a calculation based on only the 2 most recent edges (not averaged over several samples?)

That is my understanding, although I haven't seen it documented. If it's 4x, it divides by the the time for the next edge on the opposite input. In 1x, it divides by the time for the same edge on the same input.

[Ether]

Originally Posted by Joe Ross

That is my understanding, although I haven't seen it documented. If it's 4x, it divides by the the time for the next edge on the opposite input. In 1x, it divides by the time for the same edge on the same input.

I guess that would explain why you get a cleaner signal reading raw counts and averaging over the sample time, like you said.

[DonRotolo]

Originally Posted by John_1102

1440 per revolution

Is it me, or does that seem like an awful lot of pulses per revolution for just controlling its speed. I'd imagine 1/1000 of that data would be more than enough. Or?

[Ether]

Originally Posted by DonRotolo

Is it me, or does that seem like an awful lot of pulses per revolution for just controlling its speed.

Agreed, for the speeds associated with a ball-shooting spinning wheel.

1440/4 = 360 so it seems like he's running a 360 encoder at 4x.

Even at 60rpm that's 29 pulses every 20ms.

[JohnFogarty]

This code gave me a VERY constant RATE on my graph.

    public void getSpeed(){  
        samples[counter] = Shooter_En.getRaw();
        counter++;
        Shooter_En.reset();
        if(samples[9] > 0){
            counter = 0;
            for(int i = 0; i <= 9; i++){
                sum = sum + samples[i];
               }     
            AVG = sum / 10;
            Rate =  AVG / 0.48;
            sum = 0;
        }
    }

[Ether]

Originally Posted by John_1102

This code gave me a VERY constant RATE on my graph.

    public void getSpeed(){  
        samples[counter] = Shooter_En.getRaw();
        counter++;
        Shooter_En.reset();
        if(samples[9] > 0){
            counter = 0;
            for(int i = 0; i <= 9; i++){
                sum = sum + samples[i];
               }     
            AVG = sum / 10;
            Rate =  AVG / 0.48;
            sum = 0;
        }
    }

Rather than putting the exact same post in two different threads, it's probably better to post a link:

http://www.chiefdelphi.com/forums/sh...9&postcount=27

http://www.chiefdelphi.com/forums/sh...6&postcount=29

[wireties]

Originally Posted by Ether

Agreed, for the speeds associated with a ball-shooting spinning wheel.

1440/4 = 360 so it seems like he's running a 360 encoder at 4x.

Even at 60rpm that's 29 pulses every 20ms.

What difference does it make? Isn't is just a counter in the FPGA incrementing? For a circuit like that, this rate is nothing. Am I missing something?

[Ether]

Originally Posted by wireties

What difference does it make? Isn't is just a counter in the FPGA incrementing? For a circuit like that, this rate is nothing. Am I missing something?

Depends on where he's going to put the encoder and whether the signal is going to the cRIO or the Jag.

If it's on a wheel spinning at 5000rpm (like to shooter wheel), then that's 120,000 pulses/sec.

cRIO:
https://decibel.ni.com/content/message/12523

[wireties]

Originally Posted by Ether

Depends on where he's going to put the encoder and whether the signal is going to the cRIO or the Jag.

If it's on a wheel spinning at 5000rpm (like to shooter wheel), then that's 120,000 pulses/sec.

cRIO:
https://decibel.ni.com/content/message/12523

Personally, I would not throw away dynamic range for zero benefit but still - it surprises me that the FPGA does not count that fast. This is good data to have - thanks again Ether!