Let's Design and Build a (mostly) Digital Theremin!

"D-LEV is the king of my electric jungle. Other device will have to adapt !"  - Mr_Dham

tVox: The voice of Tarzan, king of the electric jungle!

A Tale Of Two Encoders

Received a shipment of 200 inexpensive generic encoders from eBay yesterday:

Having been burned by Bourns (apt name!) & Mouser, I now feel compelled to laboriously test all encoders before any return window closes, and definitely before they go into any D-Lev.  Here is my simple test jig, which consists of IC sockets for the encoder pins and three 10k pull-up resistors.  It is connected to a 3.3V bench supply and my oscilloscope:

And now for some scope data captured with the jig. 

This first image is one of the new generic encoders plucked at random out of the Styrofoam above - it's very clean:

This next image is of a new and unused Bourns PEC11L-4120K-S0020 that Mouser sold to me - it's extremely noisy:

Night and day!

I fully understand how encoder inputs have to tolerate a certain amount of noise, that isn't the issue here.  Neither are soldering practices, as the data above was obtained with the jig.  The Bourns encoders are clearly defective right out of the shipping box, and I wish I hadn't installed them in the D-Levs.  Any kit owner experiencing encoder skips can contact me and I'll send along a replacement set of encoder boards.

The thing is, Bourns won't reply to my emails, and Mouser says Bourns hasn't had any reports of defects, and the Mouser 30 day return window has closed anyway.  Bourns / Mouser didn't even ask for bad samples from me to test on their own, which doesn't make any sense.  I mean, sure, in retrospect I guess I should have at least spot checked some as soon as Mouser shipped them, but getting a whole tray of bad parts fresh from a large reputable manufacturer via a large reputable supplier shouldn't be happening in the first place, statistical spot checks should catch anything egregious before it gets to me.  And them not dealing with it in a professional manner after the fact is quite strange.

Not sure what my recourse is here, but I've never encountered anything quite like it.  I paid with a credit card, maybe I should enlist their help?  Email the CEO of Bourns?  At this point I'd be satisfied with someone just saying they're sorry for making me cranky.

For what it's worth dewster, I'm sorry that Bourns aren't bigging up for their sloppy QC.
Mouser too don't come out of this in a good light: maybe you are a customer whose demand doesn't warrant a second thought.

Aye, I know that every customer should be treated with equal respect and all that...

I was speaking with a friend today who had been printing photos over the past few days and found the chemistry was all wrong: was giving a cyan cast where none should have existed.
As far as he knew, he was buying from a good supplier. Thing is though, there was no usual 'use by' date on the chemicals but he only saw this after the problem arose.

Almost like the company supplying the goods knows they have bought a bummer but don't want any losses.

Hey ho, we may never know.

Pretty naff that the burden lands on the honest broker

Worser And Worser

And it actually gets worse!  In June of 2021, before I bought a hundred of those noisy Bourns PEC11L-4120K-S0020 from Mouser, I bought ten Bourns PEC11L-4115F-S0020 (also from Mouser) which have a flatted D shaft and a higher turning torque than normal, but are also "high endurance" and rated for 100,000 cycles - these two encoders in fact share the same data sheet.  I mainly wanted to see if the turning torque felt too high, and it did to me at the time, so I decided against using them or buying more.  Then the PEC11L-4120K-S0020 suddenly showed up as in-stock at Mouser, for $1 a pop no less, so I ordered 100 thinking it was a dream come true (little did I suspect it would turn out to be the stuff of nightmares).

Out of curiosity, this morning I dug the ten PEC11L-4115F-S0020 encoders out of my storage cabinet and stuck several in the test fixture:

Above: Ludicrously, absurdly, etc. noisy Bourns PEC11L-4115F-S0020.

I don't know of any logic, analog or digital, that could properly decode that bottom trace.  It spends way too much time in the wrong state so simple averaging won't work.  Stability debouncing might be the best, but I don't want to go there as that's vulnerable to other error conditions and can confound relative phase timing.  I've modified the FPGA code to weight the average 3x towards ground, but even that's entering rather tricky non-linear territory.

It could be my imagination, but it seemed like these PEC11L-4115F-S0020 encoders fresh out of the Mouser shipping bag got progressively and significantly noisier the more I turned them in the very short time they were in the test fixture.  Like they were wearing out right before my eyes after only a few turns.  Some looked fine during the first rotation, then started showing some noise, then got all hairy.  So much for "high endurance"! 

Though this is actually consistent with my testing of the PEC11L-4120K-S0020 in the D-Lev kits.  After final assembly, I turned each encoder slowly through one complete revolution in both directions while watching the LCD value, then several fast revolutions in both directions.  None failed this initial test so I naively thought, well, call me crazy but "high endurance" should mean they're good to go for years of use.  But when doing some rework on Jeff's unit #000000001 several were clearly skipping detents and perhaps even reversing after very little use on his part.

For some sanity, I spot checked 5 generic eBay encoders from each tray and they were all clean as a whistle, even after spinning them for a while.

"Almost like the company supplying the goods knows they have bought a bummer but don't want any losses."  - RoyP

It does seem that way from the way they (aren't) handling this.  I feel like they're gaslighting me (insult to injury).

I remenber now that I had same noise problem with some Bourns potentiometer.
I don't know if their reputation comes from that self attributed logo "Bourns Pro Audio" representing a guitar and letting customers imagine that their components are good for audio application thus flooding a significant part of the market.
It feels strange to my eyes because an encoder is an encoder whatever the application you are targetting.

"I remenber now that I had same noise problem with some Bourns potentiometer. "  - Mr_Dham

Hmm. 

I looked around for other folks having Bourns encoder problems and found this (ended up replacing them all with Alps):
http://midibox.org/forums/topic/17233-encoder-accuracy-bourns-mb-6582/

Here's a guy who rolled his own encoder:
https://hackaday.com/2018/02/19/roll-your-own-rotary-encoders/

Here's a guy who rolled his own encoder:

No quadrature, much less bounce problem. A more attractive version of the classical increment/decrement switch solution (usualy enhanced with long push handling for fast increment/decrement and simultaneous push for the 0/min/max toggle function).

Anyway, I wonder if endurance is so high (constanly oscillating swithes...)

"Anyway, I wonder if endurance is so high (constanly oscillating swithes...)"  - Mr_Dham

The endurance has gotta be higher than the Bourns, which are broken straight from the factory!  ;-)

Encoder Multiplexing

The D-Lev currently runs every encoder pin to an FPGA pin.  There are 3 pins (CW, CCW, and PB) on each encoder which ground when active, and internal programmable FPGA resistors are used to pull them to VCC when not active.  There are 8 encoders, so these take 8 x 3 = 24 FPGA pins.

Internally, the pins are each sampled and debounced, and the CW and CCW are sent to individual gray code state machines which present inc / dec values to the clear-on-read processor register.

Those 24 wires turn into 32 IDC ribbon cable wires (+8 grounds) each of which must be soldered to the encoder PWB, which is a lot of work.  All this parallelism to support the turning of more than one knob at a time, which I never really do.  Could the interconnect and FPGA pin count be reduced without significantly impacting performance?  The Bourns fiasco has got me thinking...

Above is what I'm thinking.  Wire all the encoders in parallel, and use the normally grounded side of each to signal which one is active.  This way only one analog debounce network is needed for all 8 encoders, and signal wiring is also reduced to 3 + 8 = 11.

One thing I like about the current arrangement is there are 4 encoders per PWB, so they can be positioned / spaced / arranged in different ways.  I also like the fact that the boards are entirely bare, with no active or even passive components on them, just the encoders.

So the above may be the best way to implement a multiplexed scheme.  Make each PWB as shown, which requires 3 + 4 wires back to the main board, +1 for an ESD bleed ground = 8, which we can do with a 2x4 IDC ribbon cable and PWB connector at both ends.  Combine CW, CCW, and PB from both boards and run these to 3 analog debounce and FPGA pins.  Run ENC0 etc. to transistor inverters and then to 8 FPGA pins.

I like the way the encoders are more electrically isolated from the FPGA pins, and I like the lack of soldering a million wires.  The transistors and other additional components would require more soldering though.  One off-detent encoder would impede the input of all, so you couldn't use those detent-less types.  In the code one could steer the input to the proper state machine and leave it there until a different one is selected, thus debouncing the selection itself.  One could also ignore the case of multiple selections.  For flexibility, I'd love to get more of this sort of logic out of the FPGA firmware and into the processor software.

I'll have to give this the old breadboard try when it comes time for a redesign.

Those 24 wires turn into 32 IDC ribbon cable wires (+8 grounds) each of which must be soldered to the encoder PWB, which is a lot of work.  All this parallelism to support the turning of more than one knob at a time, which I never really do.  Could the interconnect and FPGA pin count be reduced without significantly impacting performance?  The Bourns fiasco has got me thinking...
-- Dewster

Eric,
I believe this would not work.
When on some encoder both phase lines are shortened, or button is pressed and any phase is shortened, CW, CCW, PB lines become connected together.

Actually, it's similar to commonly used keyboard matrix. Just treat phase and pushbutton pins as switches in keyboard matrix.
It should work if diodes were added, like below:

Alternative solution, with only 3 signal pins:
PIN1: input CLK
PIN2: input LOAD
PIN3: output OUT
You would need shift register with parallel load and serial IN.
Encoder pins (with pullup resistors, and optional caps) connected to parallel inputs of shift registers.
When LOAD is active, on CLK edge registers catch pins state snapshot,
when LOAD is inactive, one each CLK edge shift register outputs stored pin state serially.
Usually, register IC has 8 bits, but N register can be cascaded using serial input.
Scan rate is CLK/N_pins
By increasing of number of signal wires, you can increase scan rate - e.g. connect each 8-bit shift reg output to FPGA separately (in this case, scan rate is CLK/8).