Encoder issue on first build

[manumx]

Got my kit. Built it. Had a really great time. I think this is a very sweet project!. Very happy with it.

I noticed my encoder was not so responsive. Saw in another post someone with a bad encoder.  Some other post suggested a software fix. My soldering is good and everything else works as expected. I found that without the knob  I can sort of pull the encoder's shaft gently upwards as I turn it and it works like a charm.

Until I try a different encoder I will just use the one provided without the knob because I get a better grip. I'd like to share this for anyone with similar issues.

[Randall (Admin)]

Well that kinda sucks.  Since you can make it work well by pulling the shaft, it sure sounds like a mechanical issue.

I can send you another.  Just send your address to: support@treefallsound.com

[benh]

Exact same problem here ... I don't think it's worth trying to ship one to Australia though, I'll grab one myself. Anything special to look for ? Will this do (available locally here in Canberra) https://www.jaycar.com.au/rotary-encoder-with-pushbutton/p/SR1230 ?
Otherwise can I have the mouser ref ?

[benh]

Is it a Bourns PEC11-4320K-S0012 ? The dimensions *seem* to match according to the datasheet I found there: https://cdn-shop.adafruit.com/datasheets/pec11.pdf

ie,  20mm shaft, 7mm of screw (not sure the right word in english), push button, 12 steps per rotation, body 3.5mm thick...

(Or another ref because this specific one or the PEC11R version are nowhere in stock, at least not anywhere near australia)

[Randall (Admin)]

If anyone has a defective encoder, let me know and I'll either send you one or compensate you for a new one.

It would be good to rule out that it's not caused by a bad solder joint or header not making a good connection though.  Unfortunately, the electrons thru the encoder contacts make a longer than ideal journey from the encoder through the pi-Stomp header, through the hat hacker to the RPi.  I would strongly suggest checking the resistance of that path using an ohm-meter.

Here's what I'd do...
- clip one ohm meter probe one of the 3 encoder pins (the side with the set of 3, not 2)
- touch the other probe to the corresponding pad on the back side of the RPi to make sure the resistance is just a handful of ohms (ideally less than 1 ohm, but definitely not more than 25)

The 3 pins all connect to 3 adjacent pins on the Pi:
Pin nearest board edge: 7
Middle pin: 9 (Ground)
Other pin: 11

The pin numbering starts with 1 being the square pad, then by 2's, so pin 7 is the 4th pin, 9 is the 5th, 11 is the 6th.  The attached photo shows probing pin 7.



If that all checks and the issue persists, then yeah, it could be a bad encoder.  I might like to hear more details though about how the problem manifests.

If the resistance is high or open, then there's either a problem with the encoder solder joint, the joint of the 2x20 header on the pi-stomp board, or in how the two 2x20 headers are making contact.  Might be worth restacking the boards and securing well with screws to make sure the headers are well seated.

It would also be good to rule out potential software issues.  Might be good to try this via ssh:
% ps-stop
% ps-run -l debug

If after it loads the pedalboards you seen a continuous stream of AnalogControl messages, then the polling loop is likely bogged down with spurious input likely from a analog_controller defined in default_config.yml but not actually connected.

Return to regular operation via:
% ps-restart

Regarding replacement encoders.  I would recommend encoders from the Bournes PEC11 series if possible.  Those are the ones I've used for years, and the pi-Stomp code (https://github.com/TreeFallSound/pi-stomp/blob/master/pistomp/encoder.py#L44) has been tweaked assuming that encoder.

The most important spec is that it be a "2-bit quadrature code" encoder.  I have always used 12 pulses per revolution, but you probably could use 18, etc.   The rest of the specs are mainly physical (shaft length, shaft style, etc.)  Those should behave the same electrically.

[benh]

It's a software problem I think. If I change the polling loop to sleep 0.001 it works prefectly fine. I think we just don't get enough samples per transition to accurately debouce. I'll play around with the algorithm, or maybe see if I can get a small kernel driver to do the job more efficiently than python :-)

[benh]

The attached patch fixes it for me. I'll let others verify it doesn't affect performance (I'm not the musician, this is a present for my son, so I am really not qualified to test the audio part :-)

[benh]

So it looks like interrupts shouldn't be a problem if we are a bit careful.

We have 4 cores in the Pi3. modep is single threaded. So it can be pinned to a core. In fact I want to play with using nohz_full and isolcpus to see if we can pin it to a completely isolated core (not even timer interrupts other than the ones requested by userspace). We can also ensure all interrupts (other maybe than the audio ones, see below) are routed to other cores.

That leaves 3 cores to handle buttons, GUI, web, network .. that's plenty and none of it needs to have real-time characteristics.

What I'm not sure is whether it's worth pinning jackd as well, and whether it should be on the same core as modep or can be on a different one. I'll do some experiments over the next few days see if I can come with a sane "default setup" that tries to avoid anything bothering the cpu doing audio processing.

Once we have that, we might want to generalize the use of interrupts for polling controls to see if we can reduce the speed of the main polling loop. I suppose we'll still need it for the ADC .. how often do we really need to poll this ? I'm thinking things like expression pedals might be a tad "sensitive". Reducing that speed would reduce CPU usage on the non-processing cores, thus reducing heat and power consumption.

[Randall (Admin)]

I appreciate your thoughts on this.  I did have the encoders (for v1) working on interrupts for a while.  It became problematic.  I forget exactly why, but found things were more stable having them work on a polling loop.  Not against the idea though as long as it offers a real benefit.

Might like the idea of pinning cores as long as audio (mod-host, jack, etc.) gets the lions share.  UI's don't mean anything if the audio is glitching.  pi-stomp processes (handling control events, LCD, etc.) are generally pretty low in CPU consumption - usually less than 4% and really only spiking to 50% or so just during load operations.  Meanwhile, mod-ui and jackd regularly idle in the 20% to 30%'s and mod-host from 20's to over 50%.

Feel free to fork, experiment and share your findings.  If your changes work out well, we could consider rolling them into the mainline.  May go without saying, but the real test is in how it handles CPU intensive pedalboards with numerous simulator plugins.

[benh]

Right, I will do some more testing but my time is limited at the moment... Also at some point I want to also play with moving it all to 64-bit, using a newer MOD etc.. :-) I might end up having to build a second  one just to toy with while I give this one to my son

That said, could your original interrupt problems relate to the old issues you had with the screen before numpy gave it a boost ?

One option could be to have both modes supported (polling and interrupts) via a config option, so users who have problems can tweak. I think the existing sample rate is just too slow for some encoders out there, they aren't broken per-se. That's actually why I moved the core debouncing code to a separate _process_gpios() so it can still be called from read_rotary() if we want to, easy change. I'm a bit sad about YAML though :-) JSON would have probably been a bit nicer and allowed maybe to avoid subclasses completely by having the entire HW def in a config files. I could look into it but ... time .. :-)

As for core pinning, it's a bit nastier than I originally thought because Broadcom was stupid enough not to provide a way to target interrupts. So all IRQs end up on core 0, always. That includes the audio DMA interrupts which are the critical ones.

That said I don't think the GPIO interrupts are enough to cause problem here, there isn't much done in a GPIO irq handler. It's more storate/SD that gets in the way. I suspect at this point the RT kernel will help more than any other game of CPU pinning. That said, I need to dig more at some point into the hardware, if we can make the audio IRQs FIQs (thus preempt other interrupts), we could have a fast path for them or even shoot an IPI to the core dedicated to audio processing and handle them there, with hopefully not much extra latency as a result.

[benh]

So I just randomly threw things at a board that idles at about 75% CPU.. (using the RT kernel). With my interrupt patch for the encoder, If I go crazy with the encoder, I see the CPU usage raise to about 83% but no XRUNs and everything is responsive.

[Venya]

I finished my initial build yesterday afternoon and am also having some weird encoder issues, so I'm grateful for the initial post and subsequent thread here. Mine seems hardware--I might have tweaked it somehow when mounting, but it is definitely more "click-y" in some positions than others, and only occasionally responsive to the click itself. I'll test before I rule anything out, though.

UPDATE: oh yeah, definitely user error. I had mounted the knob on the encoder hastily and I think it was too low and also off center, somewhat. When I pulled it off and just tested with the bare metal of the encoder, it worked just fine.