#265

all of them. I’m using a 3b+ with this image disk (norns 190930)

#266

I think that is a hardware problem, the encoders are connected directly to the Raspberry GPIOs.
The encoders should be connected like the image.
Encoder%20Circuit
Without this circuit the encoder could be not readable at high speed turns (noises, parasitic voltages, etc.)

@okyeron consider to implement the circuit in futures versions of the Fates board.

1 Like
#267

so like how fast are we talking here? I’ve not run into this (or noticed it) since I started on this project more than a year ago. (Not to say it’s not a potential issue)

It could be the norns software doing something with the encoder readings or it could be due to the hardware not keeping up as @Oxbown made note

Would you pm me any links or references for that circuit? I’d like to read more about it. The various example circuits I looked at for pi or other modules (like MI Braids or Yarns) do not have this type of circuit.

#268

It’s a debouncing circuit. Switch debouncing can be done either in hardware or software. Both approaches are well explained in this series of articles https://hackaday.com/2015/12/09/embed-with-elliot-debounce-your-noisy-buttons-part-i/

6 Likes
#269

Braids and yarns debounce in software - see drivers/encoder.h and .cc

3 Likes
#270

Really fast :slight_smile: Anyway, I think it’s something on my side, I’ve noticed that the problem described shows up while using this power supply:

Everything works fine powering the rPI from my macbook with a usb cable :-/ I’ll double check everything…

#271

Good article!
I think that the problem on encoders is more the hysteresis than debouncing.

1 Like
#272

It could be the norns software doing something with the encoder readings

this was added to combat physical encoder issues that were popping up from the first batch of norns

#273

Hardware solutions are more robust, but the software fix could solve the problem.

#274

Not sure I understand everything that’s happening in the norns software, but here’s some of what is happening with regards to encoder sensitivity/acceleration, etc. which might be a factor here:
https://github.com/monome/norns/blob/master/lua/core/encoders.lua

This seems a bit strange. Please keep me posted.

#275

I haven’t gotten to play much with mine yet, but I did notice the occasional lag/unresponsive encoder turns (also same thing with my DIY Arc) - it was very prevalent when I tried to power the Pi from a powerbank. When using the official Pi power supply, it happens rarely and usually a reboot seems to get it back in order.

#276

with my limited electrical knowledge that debouncing circuit looks like a RC low pass filter to me.

why would that be better than doing a low pass filter in software?, which is what I believe the norns software is doing (in a fairly simple way iirc)

Im not saying not a good idea to do these things in hardware, but I dont think they are ‘neccesary’?!

( seems reasonable to me that an unstable power supply might give issues … I used to have all sorts of issues with rPIs when i was using a PSU that had didn’t supply quite enough power… ever since then, Ive always used a 2.5a one … though I dont think thats up to spec for a rPI4 :frowning: )

1 Like
#277

That’s all the software debouncers that I have seen are… (low pass, low order filters)

#278

Software debouncing is more like a time-oriented latch than a lowpass filter. I would want both hardware and software approaches for mechanical switches, personally. If you look at the garbage signals coming out of them, you’d see why.

2 Likes
#279

I’ve been using a 2.5A supply on my Pi4 without too many under voltage warnings. But… it really should have a 3A supply.

I bought a couple cheap “3A” supplies but they don’t seem any better than the 2.5A :frowning:

1 Like
#280

Yep, software debouncing is a time filter for signals, if a signal is true or false two times in less than X milliseconds the filter ignore the trigger. This method could ignore signals when a encoder is twisted too fast.

#281

I’m using the official 5.1V 3A supply from Raspberry Pi on my RPi4 Fates and it seems to run great. I haven’t noticed any encoder issues before, but now I’ll try to search for them specifically to see.

#282

To be fair, so can hardware debounce, and it cannot be tweaked after the fact.

1 Like
#283

debouncing is integral.

http://www.ganssle.com/debouncing.htm

be sure to read part 2.

FYI norns has time-based de-glitching on the encoders already. https://github.com/monome/norns/blob/master/matron/src/hardware/gpio.c#L106

1 Like
#284

just to clear up a few things:

yep.

nope. norns has a hardware (RC) lowpass and a software timed latch / hysteresis.

whether SW or HW, this setup is pretty normal for mechanical switches that exhibit chatter. if there are problems with supply voltage fluctuation i would try a comparator after the RC. at that point a debounce IC might be called for - save CPU and real estate. (but it’s far better to fix the supply fluctuations at the source, since other components will be affected!)

oddly, Encoder::Debounce just looks to me like a straight read to the quadrature decoder inputs.

but, this is a very different situation because on those modules the encoders are polled. (at ~1ms or something?) so it’s not really an issue. [ed: ok, tehn called me out below and he’s right: polling is not a silver bullet, just a different situation.] this is a great solution when you don’t mind having some latency and “downsampling” in encoder response. (e.g. when it’s scrolling a menu and never being used as a performance gesture.)

i very much doubt this is related.

4 Likes