Rotary Encoder Goes Crazy

[GoogleCodeExporter]

Which board (stock / gruvin9x / sky9x) are you using?

Stock board with Atmega128

trying to change from -100 to 100, if I spin the wheel a bit faster the encoder 
goes crazy and starts going backwards. sometimes just goes in the other 
direction, then turns to the right direction, then goes back in the other.. 
drunk obviously :D the encoder, not me ;)

Original issue reported on code.google.com by joaoalve...@googlemail.com on 20 Feb 2013 at 1:11

[GoogleCodeExporter]

Are you able to compile yourself the trunk now? If yes I will tell you what to 
change and test.

Original comment by bson...@gmail.com on 20 Feb 2013 at 10:07

[GoogleCodeExporter]

In open9x.h would you try to change the line 1066:

typedef int8_t rotenc_t;

By:

typedef int16_t rotenc_t;

Original comment by bson...@gmail.com on 20 Feb 2013 at 1:24

• Changed state: Started

[GoogleCodeExporter]

Never diod that before but will do and then report back.

Original comment by joaoalve...@googlemail.com on 20 Feb 2013 at 1:43

[GoogleCodeExporter]

Sorry that i take too long..

I changed the line as you said, compiled, burned.

The same, if i spin the wheel faster, it will go in the oposite direction 
sometimes.. if I spin it slower I get to the desired values fraster :D
I'm not sure but it could be even worse than it was before.

Original comment by joaoalve...@googlemail.com on 20 Feb 2013 at 1:59

[GoogleCodeExporter]

This may be limited by hardware rise/fall time of the encoder lines. This 
behavior is typical of spinning the encoder faster than what can be read. 

Original comment by bernet.a...@gmail.com on 20 Feb 2013 at 6:07

[GoogleCodeExporter]

So, we might have to just spin that encoder nice and slowly??  ;)

Original comment by joaoalve...@googlemail.com on 20 Feb 2013 at 6:09

[GoogleCodeExporter]

Perhaps I could add some check to avoid that the value moves too fast?

Original comment by bson...@gmail.com on 20 Feb 2013 at 6:12

[GoogleCodeExporter]

I think everything worth trying..

Original comment by joaoalve...@googlemail.com on 20 Feb 2013 at 6:36

[GoogleCodeExporter]

IT's not the value moving too fast, it's the encoder moving too fast, at which 
point the sw will receive wrong info anyway... so limiting the speed wouldn't 
change a thing.

What could is sampling the pins more often.

Original comment by bernet.a...@gmail.com on 20 Feb 2013 at 7:03

[GoogleCodeExporter]

Understood. It's true that open9x runs the perMain() (where is the rotary 
encoder code) only every 20ms, when er9x runs it continously. 

In an interrupt, we would have a concurrency problem with the LCD

Perhaps I should try to run the rotary encoder twice in each loop, I cc Mike in 
case he has a better idea

Original comment by bson...@gmail.com on 22 Feb 2013 at 1:00

[GoogleCodeExporter]

Would you try with the latest revision:
http://code.google.com/p/open9x/source/detail?r=2003

Original comment by bson...@gmail.com on 23 Feb 2013 at 3:18

[GoogleCodeExporter]

I think you nailed it this time.. it seems to be working correctly.. fast and 
without jumping.
I tested by creating a new mix and change the weight.
I goes from -125 to 0 and then 125 quite fast. faster than holding the right or 
left key. it seems to be working good. will keep an eye on it though.. But for 
now I would say, case closed

Will ask "Kaos" in the forum to test it with the m64 as well..

Thanks. Super...

Original comment by joaoalve...@googlemail.com on 23 Feb 2013 at 3:31

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 23 Feb 2013 at 3:37

• Changed state: Fixed

[GoogleCodeExporter]

Just got a report from Kaos. it's also good on stock board with m64. 

Thanks

Original comment by joaoalve...@googlemail.com on 23 Feb 2013 at 5:48