• @pankleks, you may face the issue that by the time you read the pin, it is a bounce... because you do not debounce. But even a solid debounce may not help you because you may run into the speed / frequency issue. There was another conversation about the encoder run with setWatch() (and using repeat:true and edge:"both" options) I elaborated on.

    If you do not use a mechanical contact / switch based decoder but rather an optical (bare bone) one, following comments apply only partially. If it is electronically - with lights - some kind of Schmitt trigger with appropriate hysteresis has to be applied. The frequency issue - overrun - you can detect by looking at the error flags with https://www.espruino.com/Reference#t_l_E­_getErrorFlags.

    Handling mechanical switches IS a challenge, because of the bounce and its even more so because of its unpredictability (heavily dependent on materials / quality / cleanliness / etc. of the switch) . For "slowly" changes in states you may get away with a simple approach. But to reliably detect you have to catch not only the good states, but also reject the bad states. I still believe that JS and in particular Espruino is fast enough to handle that. - *** Try your code with an original Espruino board... *** (or at least with an ESP-8266 where there is no - or much less of - layering of SW is involved between the actual pin and your watch callback function, HW event handling and reading the pin state. ESP-32 - though considered powerful in regard of computing power - is not that suitable for handling HW events and interfacing HW and JavaScript as @Gordon's implementation on STM32 and MDBT42).

    What I would do - and did in some of my applications where buttons are involved - was to create a state machine which is aware of all the good and bad states and all possible timings and let the setWatch() feed this state machine. The state machine then sends out valid / validated events to registered subscribers, such as an up or down counter, frequency meter, etc. (Think about a mouse that has multiple decoders... and sends only good signals to the computer).

    To reliably detect a motion on a rotary/linear decoder you need two events from different sensors / pins to confirm an actual movement. You cannot derive from an on or off of a single sensor / pin wether it is a clockwise / counter-clockwise / forward / backward movement: it could just be a jitter.

    With mechanical sensors (switches) you have to have the guarantee that when the second one shows on event, the first one has to have stabilized / debounced. Only then you can be sure about the state of the first one. In basic hardware implementation you use a pairs of interlocking negative and positive pulse triggered RS-flip-flops. Luckily, this you can emulate / simulate w/ software... and that is what I meant with building a state machine.

    (Btw, fat-arrow functions have limitations - see https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Functions/Arro­w_functions - but as I see nothing in your code that would hint that these contribute to the flaky results you experience.)

    ...for some info about encoders see https://www.researchgate.net/publication­/305649159_Re-gripping_analysis_based_on­_implementation_of_slip-detection_device­_for_robotic_hand_model - from where the attached pic is from - and https://www.analogictips.com/rotary-enco­ders-part-1-optical-encoders/ (interestingly - only optical and magnetic encoders are mentioned...)


    1 Attachment

    • movementDecoder.png
About

Avatar for allObjects @allObjects started