Encoder rotation velocity questions

[fmichea]

Hello, not sure it's at the stage of "reporting a bug" yet but I thought I'd open a task to discuss. I'm having some trouble with encoder rotation velocity behavior (as in, faster one rotates the encoder => how fast does the value change).

I've noticed two opposite issues and taking a look at the code I cannot explain them quite yet, but here are two different behaviors to discuss.

Possibly related code: https://github.com/maartentamboer/X-Touch-Mini-FS2020/blob/main/rotaryencoder.py#L101 and maybe #69 (although it should be fixed)

1/ CRJ heading/altitude changes going way too fast if encoder rotated too fast.

In the CRJ when the heading/altitude encoder is being rotated, at low rotation speed it will simply increment by one, but if the rotation is a bit faster then it will get in a mode where it increases the value by a lot (eg. altitude by 1400ft for each "notch" or heading between 15+ degrees). Stopping rotation for a bit might help but it often doesn't. It makes it quite difficult to be precise if getting into this situation.

2/ Default config on G1000 NXi and altitude

Opposite of that for G1000 NXi using the default config, if rotated too fast the value change actually slows down. Here is an extreme example with the logs from the program, doing a quick rotation:

on_cc_data: 3: 65
on_cc_data: 3: 68
on_cc_data: 3: 70
on_cc_data: 3: 71
on_cc_data: 3: 71
on_cc_data: 3: 71
on_cc_data: 3: 70
on_cc_data: 3: 71
on_cc_data: 3: 71
on_cc_data: 3: 70
on_cc_data: 3: 70
on_cc_data: 3: 70
on_cc_data: 3: 69

  => exp. number of altitude increment: Sum - 64 * Count = 75 => 7500 feet.
  => actual change in altitude on NXi G1000: 200 feet.

This is kinda visible but not as difficult to deal with with the first example.

Are you able to reproduce this? Do you think this could be coming from the velocity implementation sending multiple events depending on how fast the controller is reporting?