So close! Usb interface help please?


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 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

  1. first column are the Layer ( TL)
  2. second column Back (BL)
  3. third column Select ( BR)
  4. 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 :face_with_monocle: 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 :sweat_smile:

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 :grin:

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 :sweat_smile:

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:

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 :sweat_smile:


Tried to upload a video of me touching the jumper to pin 37, 36, 33, and 32. But it’s too large, and sending a video to my computer to shrink it and uploading from there (since iPhones are insanely hobbled for “ease of use “) is more steps than I can focus on now. Suffice it to say that I’m still getting zero activity on the zynthian. Again there are two pi 4’s in play and I still get the blue midi m when I touch the jumper to rxd0. Multiple instances of the current stable zynthian image have been used (since I’ve accidentally corrupted some hitting save more than once on the wiring config page of webconf.

My partner is moving at the end of the week, and I’m still praying for a miracle insight from this wonderful community. I’m giving him the synth as his birthday present tomorrow. Probably without knobs It’s my own fault for exploring too many options, and not committing to zynthian at the beginning of this process. But it’s disappointing.

I’m not done with this platform, and I’ll post some pics when I can, and I’ll get some audio uploaded when I build the second one. Need to make a box based around not having knobs tonight, so there won’t be time to get audio from this current iteration.

Thank you all for your help

Tried to cobble together an all in one circuit, but when it’s plugged in, the zynthian’s screen won’t turn on and I can’t access webconfig. Went over the circuit a few times before turning anything on. If you can see what I’m doing wrong I’d love to know

Can’t wait to get past this knowledge hump, and understand the pi and the zynthian platform better. Perhaps some resource the screen is leveraging is interfering with gpio. Idk

New plan is that this Leviathan doesn’t have knobs. Anyone know what the lead time is on the zynscreen and all in one circuit. The gift was always meant to be an upgradable synth, who’s features can grow and change with my partners needs. So once I’ve completed a more functional version, I’ll probably just swap boxes with him