Thank you @wyleu! I got no where with my efforts last night, but this sounds like the info I need. Gonna give it a try now 
Hello friends!
Fresh new hell 
. If y’all help me fix it, I’ll upload some sick audio 
. I’m seeing info all over the place, but it’s not terribly organized. Has anything changed about what pin numbering the wiring in webconf uses?
The link I put above on connecting encoders directly to the gpio, seems to answer the question. Yet I’m getting no response from the zynthian system. I see people have gone round and round explaining the encoder breakout boards you can get on amazon and aliexpress. I opted to use unboarded encoders. To the best of my knowledge the use the standard encoder pinout.
If they don’t use some uncommon pinout then looking at the bottom of the encoder, with three prongs on right and two on left, going clockwise starting at roughly 1’oclock on a clock face, they would be: pin A, cnt grnd, pin b, switch ground, and switch.
But using wpi pin numbers in webconf is giving me nothing. I haven’t tried to make a debouncing circuit, just hooking them directly to gpio. I’ve tried putting them wherever feels convenient, and I’ve tried putting them where I can see others have put them in their webconf screenshots. But I’m getting nothing. That’s what makes me wonder if maybe the pin numbering convention was changed in a release between the forum posts I’m seeing(mostly late last year) and now.
Or is it possible I’ve got a whole set of 10 bad encoders? It was amazon, and no one can really speak for their merchants quality control. I saw some where that you can only daisy chain about 4 encoders to a ground. Is that a thing? I haven’t actually hooked all 4 encoders up at the same time(experimenting with different connection types left me with less socket to plug jumpers). Have some good wire and a terminal breakout arriving today that will let me rig them all up at once, waaaaaayyyyyy easier than I was doing it.
Do all the encoders need to be connected simultaneously for any of them to work? That could be another reason that mine isn’t working. Do to having only 6 socket to plug jumpers I could only try one at a time on breadboard. When I did this I used x,none,none,none in the pin a, pin b, and switch fields, where x is the wpi pin number that I’ve connected the encoder pin to. tried running switch gnd thru center gnd, and running it to it’s own ground pin, with no luck. As I understand, the gpio pins supply 3v so there’s no need to hook the encoder to a 3v3 or 5v powerline(heard 5v can fry the pi) So if for some reason the encoders only function in zynthian when all 4 are connected, then that would explain why I can’t get anything to come up for the encoders I’m programming. Wouldn’t make sense to me, but most things don’t until they do.
Also, for any future zynthisists out there: Webconf does not ask to reboot when new wiring is saved, it just reboots. Don’t hit save again in webconf, before it reboots. Expecting the prompt to reboot, I hit save again thinking webconf didn’t hear my mouse click. If zynthian is rebooting and you hit save on wiring in webconf, it will corrupt the zynthian image and you’ll need to flash a new sd card.
Any help with this wiring nightmare would be greatly appreciated. It seems preposterous, but not impossible that all 10 encoders I ordered are bonk, and I tried so many ways of hooking them up(breadboarded, fully soldered, soldered encoder to breadboard to pi). So unless all the various solder joints and breadboard connections are failing, it seems like there has to have been a change in how the zynthian wiring in webconf works between now and the last slurry of this question being answered.
You’re all bad asses, and I really appreciate your work. I know it’s got to be frustrating to reteach every new generation, and that’s probably where some of the “your answer is somewhere on the forum, go look for it” responses come from. But a lot of the people finding answers sort of drop off posting once they figure it out, leaving weird info gaps all over the place. If any of you actually geniuses could provide clarity, or clarifying links, then maybe we can compile these fixes here, and then maybe transfer them to official documentation. Plus, again, I will reward you with some tasty bass riffs my fingers and zynth keep coming up with 
Thank you again
Hi
I don’t think anything has changed.
The three pins are the encoder with common in the centre. The two pins are switch which can be wired either way.
There is sometimes a capacitor on encoder PCBs to act as a filter but this is not necessarily required and generally reduces risk of false triggers, i.e. is not required to get the thing working (or at least partially working).
Pretty unlikely. I have never had any completely broken encoders and I have bought a lot of cheap units.
That is more of someone’s rule of thumb. It depends on the wires used, the quality of the ground, the routing of the wires, etc. At these currents and these speeds I would expect you to be able to use a single common ground pin for all connections.
No, they do not but you do need to configure them all in webconf.
I think this is most likely your issue. Assign valid and free GPI for all four switches and all four encoders. I seem to remember (not checked the code today) that there is a constraint that partial configuration is not acceptable.
Indeed! The encoders and switches act as switches between the GPI pin and ground reference. The GPI is held high by internal resistors and when the switch closes it pulls the GPI low which is detected by code running on the Raspberry Pi. (Encoders are just two switches that open and close in a particular pattern.)
Please report this as an issue.
This is more of hacker info. The official kit should just work and should be properly documented in the official documentation. The forum is a good place to ask, answer and search for info on non-standard builds like this. It can be a haystack with you not knowing if that precious needle of info is in there so it is good if questions and answers are clear, unambiguous, fully descriptive and ideally, edited for accuracy.
I would suggest you configure the hardware in webconf for all the GPIs for the 4 switches and encoders then try just one switch first, e.g. BACK switch. This should allow you to see that the simplest action is working. If not you can diagnose that simple issue. If it is then you can start to add more switches and encoders, diagnosing issues as they arise without trying to boil the ocean!
Good luck.
Thank you. I think that confirms what I was wondering. That if the encoders aren’t set in webconf it could cause a problem. Several of the attempts were done with the wiring from others screenshots, and pre-existing wiring profiles in webconf( emulator I think was the only one that starts out with values all under 100). By which I mean I left the other wpi pin numbers in webconf, and just edited the 1st one in each field to match the gpio pins the encoder was connected to. So, in theory, my switches or encoder turns should have worked on one of those tests. But still nothing. I’ll be trying again this afternoon tho, so fingers crossed.
Thank you again
Maybe a picture of the wiring might help and a screenshot of the configuration. One can sometimes identify something that has not been mentioned by looking over someone’s shoulder.
I think @wyleu has (recently?) configured a Zynthian using just GPI so may be able to give you a screenshot of a working configuration.
Remember there should be 4 integer numbers separated by a comma in each of the “Encoders A-pins”, “Encoders B-pins” and “Switches Pins” fields. There can be more integers in the switch pins which enables extra switches like the 4 at the bottom of the screen on the official V4 kit.
1 Like
AAh yes the glorious world of zynthian encoder config…
I have to relearn it everytime I REALLY muck around!
A bit of history helps.
The Zynthian started out on the standard GPIO pins and, indeed you can build the original 4 encoder zynth with nothing more than a gpio connector and … 4 encoders.
But which pin on which encoder goes to which pin on the GPIO pins…? Do they all work …? how do I work out what goes where.
Well A Build with Variations variation: HiFiBerry Amp+ goes some of the way to describe the process, and
Encoder mapping for Direct I/O connection - #9 by wyleu shows the mapping in a nice chart . . . .
!!! THE ZYNTHIAN WEBCONF NUMBERING IS WPi !!!
The Wpi pins match the numbers that go in the Zynthian webconf, so you can use this chart to allocate appropriately. The SPI errors listed are something hat just seems to have magically occured so avoid those pins and ignore the rgb encoders that was a fanciful bit of playing around, that never made it to zynthian code.
Basically you specify the GPIO pins connected to the encoders on the top two rows and the switch on the bottom row…
The encoders are ordered anti clock wise from the top Left…
So the
- first column are the Layer ( TL)
- second column Back (BL)
- third column Select ( BR)
- fourth column Learn (TR)
This is all very much he open source way of doing things. To properly support a zynhian infrastructure you can use a zynthian all in one board which does this over 12c bus, and then you will load up the settings in the webconf for that configuration which include numbers in the 100’s
IT may not seen particularly user friendly but it allows us to provide the same interface from similar devices delivered and presented in a zynthian like way.
The Offical kit does this all on the screen board so doesn’t need to support the flexibilities of a homebuild.
Looking forward to the The pictures of the installation often helps!
1 Like
Well last night was crazy, and I only had time to check a couple pin configurations on the new terminal hat before I conked out. Tried with my soldered encoders, and just in case I bonked the soldering, I plugged a few into jst connectors and ran their open wires into the terminal hat. Then I fell asleep. Pics will have to wait till tomorrow, but I’m kind of wondering if my pi’s gpio is shot. I don’t know how common that is, but everything else seems to work fine. Then here at work it occurred to me an easy trouble shooting question for that possibility.
I know people have used gpio for encoders, and that it was the go to on old versions of the zynth. But, does anyone, maybe @wyleu, have a zynthian running the current stable image with gpio connected encoders? If so, then I’ll at least know that it isn’t an os problem, and I can put gpio trouble shooting on the list. Luckily I have a spare pi 4 I can try once I’m off.
I’ve no idea where I’d begin to fuss with or troubleshoot the actual code. But I’ve got some mpc23017s, so I suppose I could also try to mock together an allinone circuit. Logic being if my 2nd pi4’s gpio also doesn’t work, and it gets confirmed that people’s gpio encoder zynths are running an old image, then an allinone circuit does work, it would help confirm that something is happening in code.
Please let me know if that’s a crazy theory. Not knowing fully how the code translates to the digital/physical functions, maybe the fact that allinones and zynscreens work negates the possibility that the current stable of zynthian is fighting direct gpio. If so then that can be added to the tapestry of my logics and help me make better diagnoses in the future.
Thank you!
It’s not an os problem.
Encoder/GPIO Works with stable. I have two machines running this way.
Zynthian-amp.local A hifiberry 60W Amp Pi3 combi …
as detailed here.
The other is zynthian-alm.local which is audio injector card based machine. IT’s wired slightly differently, ( one pin is on a different i/o pin. )
It’s really down to the internal layout of your encoder and Pi combination. That’s how I chose the pins to minimize the crossing over and general wiring mess. With stable avoid the SPI allocated pins.
It’s perfectly possible to run just encoders or switches by appropriate settings in webconf. IT makes for a good test to just see the response from the switches because a miswire produces a very confused encoder response as the button gets pressed by an encoder twist by mistake.
Perfect thank you @wyleu. Wasn’t sure if any of the direct gpio instances out there were running the current stable. Most of those threads are pretty old.
Is gpio readall live, or just a snapshot? If it’s live, and a miswired encoder would cause it to look “confused”, then that’s unfortunately another indicator that my pi may simply not be able to use it’s gpio. When using gpio readall the last couple times it appears static, and the values don’t change regardless of whether I run it again with the encoder unplugged, and/or am twisting/pressing the encoders
I am aware of PI’s with dead GPIO pins, but I haven’t encountered it directly myself. It seems to be people putting 5v’s into the pins rather than 3.3v and its’ irreversible as far as I’m aware.
It’s just a snapshot. You need to be methodical in these situations. if you have connectors then you can swap known working encoders with others and narrow down where the fault or indeed faults exist.
A picture would help even if it’s just a ratsnest on a desktop at the moment.
Having known working encoders would be very helpful in troubleshooting
Unfortunately this is the first synth design I’ve taken to this stage. Just wait though. If I can get these encoders working, and in as much be confident to mount them, then the finished synth will be something to see. She’s gonna be kinda beautiful
A good test of an encoder, if you have a multimeter is to connect it in continuity mode (makes a buzz) across the outer encoder pins, it will click as you turn the encoder but won’t buzz continually.
Do you see any response from the zynth at all when you press and twist encoders?
No I get nothing from the encoders. Haven’t hooked the gpio up to 5v either(already read the horror stories). I’m a bit less careful about wearing my strap or touching metal before picking the pi up, but I’m usually pretty careful about where I touch.
I really need to find my multimeter
Checking current status…
Are you are able to power the Zynthian and boot into the display with a menu showing: New Synth layer, etc.
If so then the basic system is working. To test switches, remove all the switch and encoder GPI wiring and just connect a dupont cable to a ground pin, e.g. Pin 6 of the Pi. Now you can touch the other end of this briefly to the pins that you have allocated to the switches, e.g. if you have assigned SELECT SWITCH to pin 27 (like in @wyleu’s previous example) then touching the free end of this cable to physical pin 36 of the 40-way header should trigger the SELECT function, selecting the currently highlighted entry in the menu.
Thank you @riban! That led to some fascinating new info. Rigged up the 2nd pi 4 I have and tried to get switch functions like you suggested. just a wire from gnd momentarily touching the pin. Nothing on any of the pins set for switch. But, when I touch the pin cable from gnd to rxd0(gpio15, pin 10, wpi16) the little blue midi m appears! So the pi definitely has functioning GPIO, but for some reason the wiring settings I’m using don’t seem to be doing anything
Anyone have any ideas why gpio would work, but none of the pins would respond to the wiring configuration?
This does make me feel less crazy, but I’m stumped. With the above wiring settings I tried jumping every pin to gnd except the power pins and other gnds. Did this inside the fluidsynth engine and it’s expressive acoustic guitar, because I figured from those screens any of the encoder functions should do a visible thing. But got nothing on any, except again rxd0(gpio15, pin 10, wpi 16) which produced the little blue midi m. I’m gonna try to rig together an mpc23017 expander to see if the pi can access user programmed pins over 100.
So it’s probably not all my encoders(still haven’t verified on any other testbed). It’s not incorrectly inputted wpi numbers, as we’ve covered that, and I tried all pins(except powers and gnds). It’s not the pi gpio, as we have two pi’s in play and a verified action on rxd0. And people are saying they have currently function gpio encoders on the most recent stable release, so it’s not an issue caused as the Zynthian os has evolved Any guesses?
Oh and @riban, you sort of asked about my zynths current functionality. I can’t test the 5 pin midi in/out on the behringer, because I don’t have a reliable device with 5 pin midi in or out. But otherwise it’s fully functional outside of the encoders and momentary switches I’m trying to add. Screen works, both display and touch, and is properly scaled. Sound comes out beautifully from the umc204hd. Only other thing is there’s an error -22 that pops up on start up before going to the functioning system
You seem to be using some unavailable or reserved pins. Try this:
Configuration
Encoders A-pins: 10,21,23,28
Encoders B-pins: 11,22,24,29
Switches Pins: 14,26,27,25
Physical 40 pin header
Layer encoder to pins 24 & 26
Back encoder to pins 29 & 31
Snapshot encoder to pins 33 & 35
Select encoder to pins 38 & 40
Layer switch to pin 23
Back switch to pin 32
Snapshot switch to pin 36
Select switch to pin 37
Try connecting just the switches first.
Thank you @riban! I will try that configuration when I get home. How can one know which pins are reserved or unavailable? Thought I was avoiding that
