Issue with Encoder feedback - timing question

[BDRas]

Hi, I have a question on the timing of the Phidget Endoder (ENC1001_0).

It is connected to a Raspberry Pi 5, using a USB VINT HUB, on one of the high speed ports on the VINT. The dataRate is set to 50Hz, 20ms between samples.

When looking at the time reported when the onPositionCallback is called, I once in a while get a callback with a timestamp way below 1ms (which often is seen together with a single change in position - leading to an invalid speed calculation (the encoder is not moving visibly))

Here's the data form the last 50 samples of the onPositionChange callback:
positionChange: [-16, -25, -37, -54, -60, -70, -81, -91, -85, -81, -74, -69, -56, -42, -40, -30, -28, -7, -4, 0, 0, -1, 0, 0, 5, 11, 41, 37, 50, 55, 72, 89, 97, 82, 76, 69, 65, 56, 51, 39, 30, 15, 16, 0, 0, 1, 0, 0, 0, -4]
timeChange: [22.096062, 20.667734, 19.920125, 19.854203, 20.100671, 20.103703, 20.051671, 19.752468, 20.111781, 20.062046, 19.733015, 20.27464, 20.068921, 19.677515, 20.251875, 19.329093, 17.433312, 21.63275, 21.27114, 20.404796, 19.992625, 3.874515, 36.125031, 20.007421, 19.360109, 19.664656, 20.898765, 19.968812, 19.843796, 20.240453, 19.794328, 20.188921, 19.993265, 19.839062, 20.173687, 19.786828, 19.877734, 20.155531, 20.065578, 19.806015, 19.904718, 19.565828, 17.62189, 23.243296, 20.005078, 0.021203, 39.972765, 20.006828, 19.998359, 19.525734])

The issue is the fifth last one: 0.021203ms (and the following 39.97ms).

Any ideas why this happens, and how to configure the Phidget so it doesn't?

Btw: Where is the timing (sample rate) controlled? In the VINT hub or in the Phidget22 Python library?

Best regards
Brian

[jdecoux]

It looks like a textbook case of the issue outlined this article on encoder velocity calculation, which outlines how best to accommodate low speed movement.

https://www.phidgets.com/?view=articles ... erVelocity

[BDRas]

Thanks for the link!

Our other thoughts was to implement a "Speed limit" e.g. if the reported interval was less than 1ms, but this seems like a better approach.

Another thought was to set the encoder to give feedback e.g. when it has turned e.g. 4 counts - but it might overflow the host compared to the solution above.

/Brian