Encoder accuracy (bourns) MB-6582?

You’re right! I just looked at the MB-SID setup files and I couldn’t find a debounce setting. But when I developed my MB-808 sequencer I remember looking at that … from the Midibox 808 setup file we have this:

;

; debounce counter (see the function description of MIOS_SRIO_DebounceSet)

; Use 0 for high-quality buttons, use higher values for low-quality buttons

#define DEFAULT_SRIO_DEBOUNCE_CTR 32

… Since this is a MIOS function, I was wondering if you could (or should) add it to the MB-6582 setup.asm , but then I did some searching and found this:

http://discourse.midibox.org/t/topic/6798

As of MIOS 1.9c there is no encoder debounce parameter.

Sorry 'bout that!

No worries :slight_smile: It was a good line of thought. I’ve found a few threads that looked promising only to find that Mios (vx.y) fixed the issue and the information is no longer relevant.

I appreciate the help!

Hopefully when I get the new display everything will be fine and it was just a short caused by the lcd.

Cheers,

Arkay.

ok. Got and wired up the new display tonight. Display works fine, just like the last one. Encoders are still shite though.

Don’t know what to do now. It’s so bloody frustrating…

Maybe I can write some code for the raspberry pi so I can plug in each of the encoders on the control surface and see what they output running from the pi’s 5v power with the base board removed. If the encoders don’t jitter then that will prove the interference is coming from the base board and that the encoders are ok. That will stop be desoldering them all.

If it does prove the CS is fine I dunno what I’ll do then though.

Grrrrrrrrrmumble mumble…

Anyone live in Melbourne Australia and would like to try out their CS on my baseboard or my CS on their baseboard?

I have the same problem with my encoders on the mb6582. Never realy tried to trouble shoot it though as i thought it was just the way it worked. But i agree it is anoying. I have the encoders from voti.nl so i doubt it has anything to do with specific encoder types except for configuration.

Hi,

while these may not be the cheapest encoders, they are rock solid and working without problems in my MB6582, since more than two years now :slight_smile:

http://de.mouser.com…muFqx9z8g%3d%3d

I had some problems in the beginning after manually removing the “dent” where I accidentally bent the upper sliding contact too much upwards… which led to a bad contact between upper and the lower inner part of the encoder. But it was easily fixed by bending the sliding contact a bit down. . I´d also recommend that you “glue” the encoder case afterwards on the opening brackets with JB-Weld, this gives maximum strength - my unglued encoders were “wiggling” a bit after a year of heavy use :slight_smile:

So, if you are about to give up, I´d recommend you order one of these for testing, desolder your worst encoder and test with this Alpha encoder instead…

Many greets,

Peter

1 Like

I still haven’t sorted this. Very luckily for me though I live about 10 mins from Wilba’s place and he kindly offered to take a look at it for me.

I already ordered 14 replacement encoders (the same as Hawkeye mentions above), to put them in my MB6582. Wilba has these too and I imagine when it comes time to troubleshoot my machine that he’ll end up having to remove and replace each encoder with these new ones. But until he’s looked at it it’s all conjecture. There might be some other issues. I don’t know.

When he has had time I’ll be sure to post the solution onto the thread as I know what it’s like to finally find a thread that completely explains your issue but never says what the resolution was.

Stay tuned.

Cheers,

Arkay

P.S. For Hawkeye: I was following your guide when I assembled the CS (great guide!), and I remember testing each of my encoders to make sure they worked. Both with a multimeter, after removing the detents, and then in the machine, after installation. They did of course function in that I can move any value from fully off, through it’s range to fully on, whatever it is (it appears to work as designed on every encoder). The problem here is only on fine movement when trying to set specific values. I thought everything checked out and moved on because I was testing for function, not control, having no real idea of what the synth is like to use at that time. I ended up soldering them in, and glueing them down, BEFORE I realised I had this problem.

Both those actions make this problem challenging to fix now. Can I maybe suggest a line item in your build guide to suggest that fine control of each encoder (setting specific values), should be checked before soldering the side tabs (the large ones) in place, and before glueing the encoders shut. As Wilba has since suggested he never solders the large tabs, only the 3 active pins on the encoders (which is already strong enough to keep them in place), as it makes them difficult to remove later should you need to.

Just a suggestion but it could save some people some grief :wink:

As Wilba has since suggested he never solders the large tabs, only the 3 active pins on the encoders, as it makes them difficult to remove later should you need to.

All respect to Wilba, but I don’t agree with this statement - not soldering the large tabs allows the encoders to wiggle around on the PCB when turned (unless they are fixed to the frontpanel). This is not good for the active pins and their solder joints. The tabs are there for a reason.

Yeah. I know what you’re saying. I may have misunderstood and/or quoted Wilba out of context. I think he was referring to the single encoder on the Sammich when he said that and it could have meant not soldering the larger tabs in place until proven that the encoders work correctly. So don’t take what I said above as gospel.

Perhaps in Hawkeyes guide he could suggest only soldering the 3 pins in place at first until they are all proven to work correctly when the larger tabs can then be soldered and the glue applied to lock the encoders up… If any encoders are proven to malfunction you could then either pull them apart (while on the board), and try to bend the contacts into a better position before glueing), or cut the three pins to desolder and replace the encoder before soldering the larger tabs. It sounds like common sense to me now but inexperience is what guides are there to aid I guess.

Given the number of people that haven’t had this issue it’s clearly not common anyway. But all guides can always use more information from problem installs… :slight_smile:

Cheers,

Arkay.

I use the same type of encoders in my mb seq with no trouble at all. Of couse they are still detended.

Good ideas! I have added a subsection to the guide, where it is recommended

a) to solder the three connection pins of each encoder first and check with the baseboard, that the encoders work fine.

b) afterwards solder the big tabs - stability matters in my opinion, too. Fully agreed with ilmenator.

Arkay, when you´re at Wilba´s place - say him a big hello from me and ask him, if he has managed to get the OLED up and running yet, i´d be interested :wink:

Many greets to downunder!

Peter

Thanks Peter. Will do when I see him next :wink:

Cheers,

Arkay.

I have the same issue with my encoders on my midibox seq.

Is there any firmware setting that helps ?

Hey guys.

Finally got this resolved so thought I’d better post the results for anyone else that goes through this.

Was speaking to Wilba last week (he’s been flat out), and didn’t have time to look at my 6582 as yet, but he did loan me his SMD desoldering tool so I could have a go at desoldering the encoders myself.

Hawkeye (sorry man), forgot to ask Wilba about the OLEDs but I have to drop the tool back so will try to remember then.

Anyhow. Took the machine home and ended up not using the desoldering tool anyway. I desoldered a couple of encoders the old fashioned way, solder sucker, braid, and replaced some of the bourns encoders with the new ALPs ones.

The difference was like night and day. I left all the new ones detented too. But on the old bourns I could barely see a difference between different firmware setups (encoder3 vs encoder4) etc. With these, and the detents in place, it was very simple to detect the correct firmware setting to select the right encoder type.

I then proceeded to do the rest of the encoders. Some proved a little hard to get off but I had a technique and stuck with it and got there in the end.

Sadly though in my exuberance after I’d re-soldered all 15 new encoders I had 6 not working and 1 led that had taken a hit. Turns out I had put a little too much pressure under the encoders to get some of them out and must have broken some tracks on the board.

So it took me a little while to trace the circuit. I never found the actual breaks, but I did manage to solder 3 bypasses to fix all 6 encoders and the led.

So at the end I had a fully finished control surface that works perfectly. I was wrapped!!

Also managed to get the feedback pots installed. On the first 3 sids at least. I busted the 4th going for that extra half turn to line them all up! Grrr. Then I figured I’d never need feedback on all 4 anyway. Pots are an awesome mod though now I want some extra SSM2044s or something else too!

I also noticed 1 small problem in that if I switch the filter to ext on sid 4L I lose output. I haven’t tracked that one down yet, and aren’t that worried as it works fine for everything else and that engine doesn’t have the feedback pot anyway now. So I’ll use it for a “Standard Instrument” channel and it makes no difference.

I’m trying not to be anal and go for that “perfect, no problem build”, that always results in causing more and bigger issues. So all things are sweet as they are.

In the end this entire thread was the result of some bitch crap encoders, purchased from Mouser. Either I damaged them during removing the detents which is unlikely as I was very careful, or they were just crap to begin with. I favour the later.

Moral of the story. There isn’t really one. Bourns are used everywhere. I was just plain unlucky I think. One thing I did learn though is that there is no wierd stuff happening, no shorts or power oddities etc. It’s very easy to convince yourself of inexplicable wierdness when in reality with electronics there’s only so few things it really can be. I should’ve tried replacing an encoder much sooner.

I’m in the middle of assembling my MBSEQv4 now, it also uses bourns encoders, but I expect they will be fine. I’ve decided though that I prefer them with detents anyway and if you don’t pull them apart then if they really are rubbish you can send them back for replacement.

Herein endeth the saga of the dodgy detent removed bourns encoders.

Cheers,

Arkay.

1 Like

Thanks for documenting this. I was somehow lucky that Mouser messed up my order with the Bourns encoders, so I can place a new one without them :slight_smile:

Hi Arkay, glad to see that you solved the problem!

I can actually see a pattern here with the Bourns encoders - they were used in E-MU samplers, e.g. the E-IV/64/6400 and Ultra series, and these have a reputation for the datawheel to break down rather soonish. It seems like those encoders were just not up to the task. Interesting to see that your built confirms this.

Hi Arkay

great to hear! If there is really a quality issue, that is an important warning, was about to buy a few for the new LED ring boards… :open_mouth:

Many greets,

Peter

Hi Arkay, Hawkeye,

A lack of a few other components at Mouser saved me from buying lots of the Bourns encoders with switch, sans detents. There’s 200 on order that will arrive later next year so any of us LED ring board owners will likely need more, lots more. The Alphas used by the 6582 are twice the price sans switch - I have to locate a good alternative with switches that doesn’t break the bank

Best,

Johan

Fully agreed, switch is mandatory, the alphas sans switch were very nice to me.

I’m having exactly the same issue with my sammichSID I bought from somebody in Australia already built.

If I turn the encoder REALLY carefully, it proceeds 1 at a time to either direction, but the faster I move it, the more it just jumps randomly to diferent directions, sometimes in increments of several dozens or even hundreds.

So any idea for a replacement encoder for a sammichSID? And what about the firmware? Now I have the latest (just downloaded it a few days ago) sammichSID firmware uploaded.

Taika-Kim - are you also using the Bourns encoders? If you tried all available different encoder types in the firmware and the problems still persist, you could try the alphas, they work very nicely for the MB6582.

http://de.mouser.com/ProductDetail/Alpha-Taiwan/RE160F-40E3-20A-24P/?qs=yA6kp8fx8Y7zlmuFqx9z8g%3d%3d

Many greets,

Peter