Encoder accuracy (bourns) MB-6582?

MIDIbox SID
1

Hi Guys,

I’ve now completed my MB-6582 build and everything is working fine except for a minor issue with the encoders.

I’m getting skipping/jumping of values in a repeatable fashion, but not at every detent (hard to explain).

The encoders are the bourns type (mouser part PEC16-4220F-N0024).

For example. If I turn the still detented menu encoder slowly, one detent at a time, I am able to select patch by patch in single increments for say the first 8 patches, but then it’s like the encoder reaches some threshold and any minor movement at this point can send the values off wildly in either direction. Almost like a short in the encoder. It might jump 10 forward, could be several back. Whilst the encoder is in this position putting forward or backward pressure on it (without moving beyond the present detent), can result in the value continually changing, usually all the way back to 0, but where this occurs around the 360 degrees of a full rotation seems to be random (so it doesn’t appear to be a set point in the encoder for instance).

I could understand if it was a bad encoder. But this appears to be evident on all of the encoders (though all detents have been removed on the others), but they still jump in a similar fashion on slow turning). So I believe that the encoders are working as I can select individual increments to a point, up or down, but when trying to set a specific value (say 500 on the cutoff freq), it’s near impossible without getting as close as possible with the encoder, then using buttons to inc/dec the value.

I’ve searched and can’t find anything that would still be relevant (I think). Mios 1.9g (which I have), supports the bourns encoder from what I’ve read. Other than that I’ve seen some mention of a variable in code (detended_3), but am unsure if I should need to resort to the code to try and fix this.

I also have the latest MB-6582 v2.041 firwmare loaded.

Is there a hex or an app that lets you test the encoders and what is coming back from them for accuracy?

If I need to adjust something in the code I’m happy to do so. But given that SmashTV also sell these encoders I’d imagine that they should just work perfectly out of the box?

Any help much appreciated.

Thanks.

Cheers,

Arkay.

P.S. The machine is perfectly usable as is as I can adjust everything well enough, but something just isn’t right and I’d like to get it perfect :wink: I can take a video of the effect if it would help.

2

I’m sure somebody more experienced with encoder problems will have something to say, but I’m thinking of two possible problems:

  1. There is a “debounce” parameter in the app config for the encoders. Did you experiment with that?

  2. For some reason there is electrical noise interfering with your ground, or with your DIN chain. Your solder joints around the 595s, the encoders, the ribbon flexes are all good? ICs firmly in their sockets? Are you using a fan? What are you using for a power supply? Are any of the buttons acting weird (like double-triggering) as well?

I hope you sort it out, but perhaps more importantly, congratulations on your build!

3

Hi Nebula,

Thanks for the post :slight_smile:

I’m sure somebody more experienced with encoder problems will have something to say, but I’m thinking of two possible problems:

  1. There is a “debounce” parameter in the app config for the encoders. Did you experiment with that?

I haven’t experimented at all with the software yet. Trying to ascertain what I could look at before I get to that point.

  1. For some reason there is electrical noise interfering with your ground, or with your DIN chain. Your solder joints around the 595s, the encoders, the ribbon flexes are all good? ICs firmly in their sockets? Are you using a fan? What are you using for a power supply? Are any of the buttons acting weird (like double-triggering) as well?

Will need to check everything but I’m pretty certain it’s all ok. Everything works as it should, except the encoders. Shorts or ground issues I would think would show up at all times, not when only turning encoders. I’d also expect to see some problems with the LED’s if the 595’s were involved. All buttons work as expected. No double presses or bounce. I do have a fan connected at 5v, still looking for the right sized heat sinks here in Aus.

Hopefully there’s some test code to read the encoders and output what is going on.

I’m using a C64 supply at the moment. Seemed more appropriate than messing with anything else during the initial build.

I hope you sort it out, but perhaps more importantly, congratulations on your build!

Thanks! It was a great project. Highly enjoyable. Been a while since I’d done something like this, and I don’t think I’ve ever done one that resulted in such a fun and awesome end product :smiley:

Cheers,

Arkay.

4

Other than that I’ve seen some mention of a variable in code (detended_3), but am unsure if I should need to resort to the code to try and fix this.

Yes, this is the place where you want to start experimenting. See what encoder mode is most suitable for your model of encoder.

5

Cool, thanks. :slight_smile: Bout time I looked at the code anyway.

Now I have to work out how to get a dev environment working. Hope it compiles under linux :slight_smile:

Cheers,

Arkay.

6

Love this midibox stuff. It’s all so well put together.

Grabbed the code, read for a few mins, grabbed the required compiler, set 2 ENV VARS (love Linux!), found where the DETENT setup is in the mb-6582 setup assembly and just made myself 5 firmwares (1 for each encoder type), to try out when I get home.

Looks like the default is type 2 and I’m sure I read type 3 was correct for the bourns encoders.

Can’t wait to get home and try it out now! Been so long since I looked at assembly and I actually miss it… LOL.

Stay tuned.

Cheers,

Arkay.

7

Ok. Scratch my earlier excitement. Tried all possible encoder types now. 3 was better for the menu encoder that still has the detents, but all the others are lousy, jumping up to 10 points at a time seemingly at random. Going 1 step forwards, 2 steps back at times even though I’m moving it in the upward direction. Then at times it’ll go 1,2,3,4,5,6,7,8,9,6,11,8,9,10 etc etc… It’s odd.

1, 4 and 5 were no good at all, giving me two increments per click of the encoder, still with the randomness.

I have to checkout the code at home and read it some more, just to make sure there’s no other adjustments I can play with.

I’m still open to suggestions though.

Maybe people with mb6582’s can confirm that they are able to accurately and repeatedly go up or down, 1 increment at a time, right the way through the range of whatever is selected? Maybe I’m expecting more accuracy than there can be?

Cheers,

Arkay.

8

Hi Arkay,

I’m sorry if I’m banal but I experimented a similar crap on my second MBSid.

I just forget to stuff the pullup resistor of the HC165 on the DIN.

So I would ask you:

do you have right stuffed the resistor arrays in the DIN zone?

Best regards

Antonio

9

Hi Antix,

I’ll check it all over. The arrays are definitely there, but I guess I could have put one in backwards or something (though I doubt it), it is worth checking.

Cheers,

Arkay.

10

Ok. I’ve checked and the resistor arrays are all in place, all the right way around as far as I understand. Can’t see the squares anymore but the dot on each of the arrays is directly below the resistor number which if I remember correctly from the schematics is the way it should be.

I’m not sure what else I can check. Everything is ok until I turn the encoder, there’s no jumping or randomness indicative of a short until I turn the encoder. Then they jump all over the place by up to 10 points in either direction, sometimes more. The ones with the removed detents are far worse than the menu encoder.

Is there anything I can measure with a multimeter, anything I can trace to see what’s going on. Sadly I don’t have an oscilloscope.

I have a bunch of new bourns encoders for my MBSEQv4, perhaps it’s worth trying one of those to see if it acts the same way, if I can work out how to temporarily connect it to the base board without the CS plugged in.

Cheers,

Arkay.

11

Hiya,

I experienced the same kind of thing with my mbfm build,it turned out I had loaded the wrong type of firmware (I needed to use tks’ setting as oposed to the normal firmware).

It does sound like exactly the same kind of thing .

cheers

Paul

12

Thanks taximan. I’ll keep looking through the code. Maybe for some bizarre reason I might have to set the menu encoder to type 3 and everything else to a different type. That’s what it’s felling like. Though I’m yet to find a type that works perfectly for the non detented encoders. That shouldn’t make sense either as they are all the same type.

Hope I can sort it as buying another 15 ALPS encoders is something I’d rather avoid. Not due to the cost, more to the disassembly and desoldering required… I really dislike desoldering! :slight_smile:

Cheers,

Arkay.

13

Ok. Little more research and while I feel I’m getting closer I’m still confused.

I found a page on the wiki that describes the various types of encoders.

the page is here: http://www.midibox.org/dokuwiki/doku.php?id=encoders&s=encoder&s=types

On that page the bourns encoder mentioned is the PEC11 (which is no longer used).

The original Wilba MB-6582 control surface parts list wiki page found here: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_6582_control_surface_parts_list

suggests to use Mouser part #: 652-PEC16-4220FN0024 (PEC16), which is what I purchased : http://au.mouser.com/ProductDetail/Bourns/PEC16-4220F-N0024/?qs=%2fha2pyFaduidMAYXvh4P%252bOmugSqGmJEMvgB8DnSDzKia7TN8Tt6xRCYrHqKqgnwK

from the data sheet on that encoder:

The PEC16 is a 24 detent, no switch, flat shaft 24 detent per 360 degree encoder.

The data sheet can be seen here: http://www.bourns.com/pdfs/pec16.pdf

This page: [http://midibox.org/forums/index.php?app=core&module=attach&section=attach&attach\_rel\_module=post&attach\_id=5566](< base_url >/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=5566)

Shows the various quadrature possibilities, and also suggests how you can specify in the code any combination of encoder based on its data sheet information. (It gives an example how to replicate DETENDED_2 for instance.)

I’m trying to figure out from the data sheet if the switching method of this encoder matches any of the predefined ones in the code, or alternately, what values I can try to tell mios about the intricacies of this encoder. But I haven’t quite got my head around it yet. Perhaps someone could look at the data sheet and the last link and suggest how they match up. Note that the diagram from Thorsten shows counter clockwise at the top where the datasheet shows counter clockwise at the bottom.

I can’t see that this should be necessary as this encoder is the type Wilba recommended in the control surface parts wiki so perhaps there is something else amiss but I’ve looked over the board and by the way it’s acting I can only assume that it’s a firmware (software), related issue with these encoders and their jitter.

I’ve just about researched this to the limits of possibility. If I can work out what these diagrams mean I can try different values but ultimately there are only 8 hex values according to the last link above (0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80), so I can always create firmware for every possible combination of switching and test which gives the best result and possibly fix it that way.

If I’m reading the code in mios.h correctly along with the data sheet then this encoder should trigger on 1/5 (A=1,B=5) which gives 0x022 same as DETENDED_2 which I’ve tried and had poor results with.

Maybe I should buy some ALPS encoders and de/resolder. But I could have the same problem with them too… Arrrrgggghhhhhh.

14

Sorry to keep posting in this thread people but I just read something interesting about bourns data sheets.

I just checked the schematics and the CS board layout has the pins set as A C B for the inner holes and A B C for the outter ones, depending on the type of encoder and size of the encoder used I’d guess. Where A/B are the 2 channels in the encoder and C is the common.

The datasheet here: http://www.bourns.com/pdfs/pec16.pdf

Suggests the pin ordering is A B C!, but from everything I’ve seen the board is wired for A C B, where C is common and A/B give you the directional information on a 4 bit turn. Have to check this but if the bourns encoder uses the smaller pins and the data sheet is correct then everything would be all messed up… Or perhaps I’ve gone insane. Occam’s razor suggests the later.

Here’s the thread that raises the issue with these bourns data sheets : http://www.eevblog.com/forum/projects-designs-and-technical-stuff/bourns-rotary-encoder-with-detents-no-gray-code/

I’m going to plug one of these into my raspberry pi via a breadboard to see what the hell it’s really configured for but could it be possible that the MB6582 is reacting with the jitter I’m seeing because of this, or am I barking up the wrong tree?

It would sort of explain why the values can go up or down while only turning in one direction. However the value will always go fully up or down eventually when turning it in the correct direction continually. Slow turning results in more jitter though and it seems at times like the encoder shorts (or rather), A and B pins are grounding at the same time more often than they should), perhaps that is a side effect of this…

Cheers,

Arkay.

P.S. I’ve ordered 15 alpha encoders anyway as I’ve lost all confidence in these bourns ones but I’m still not keen on desoldering 15 encoders…

15

You could pry one open and have a closer look at the quadrature. Maybe you bought a weird special edition, or b-stock, without knowing.

Also you could bend the contacts, while open, to have more contact force. That could help with the bouncing, if that’s the problem.

16

Thanks for the ideas :slight_smile:

I actually plugged one in on a breadboard with a couple of resistors/leds and a 5v source. Realised I didn’t need the Pi as well.

Turns out the quadrature and the encoder works fine. It is ABC wired, but so is the board, so that is all ok.

Testing revealed:

for one direction (I can’t remember which):

00

01

10

11

and the other:

00

10

01

11

So things are as they should be. This happens per detent (I also tested an unused detented one), everything sits at 0 when the encoder stops at a detent.

Once I can find my aligator clips I’m going to try the same test on my breadboard with the encoders that are on the CS with the MB6582 powered off. I can test at the encoder and also at the board connectors that go to the base board. That will tell me if there’s any fault with the encoders. I do notice some are better than others.

Once I’ve done that and I’m expecting they will be ok, so I’ll be pretty sure then that it’s some sort of earth issue with the commons being dirty somehow.. Some noise in the power somewhere perhaps. How I isolate that I don’t know.

I have noticed that the piece of electrical tape I put on my LCD to stop it touching the board on the non wired side is fine, but on the side where the cable is connected the tape doesn’t go all the way across. I’m going to have to pull the CS apart again to check if the LCD could be shorting on the board somehow. Bit frustrating. But I’ll get there.

Cheers,

Arkay.

17

for one direction (I can’t remember which):

00

01

10

11

and the other:

00

10

01

11

Umm… that is not how it should look. It should go like this:

00

01

11

10

and

00

10

11

01

(think about the nature of the contacts in the encoder)

18

Sorry. You’re correct. I just wrote it incorrectly late last night when I posted that post. I am getting 4 different bit patterns that are opposite based on direction so at least that one I tested was working as expected.

Cheers,

Arkay.

19

Really, go through the setup file and try modifying the debounce parameter. Your LED test tells you nothing about how “dirty” the switching action is.

20

True. I had a look at the debounce code and there didn’t seem to be much to modify. I’ll have a better look though.

Interestingly, I replaced all my connections between the base board and the CS the other day as the way it was soldered wire connections could break too easily with the amount of moving about I need to do at the moment. It’s much better now but after I did this I was messing about, had all 4 SID engines screaming and the LCD packed it in on me. Lost everything but the top left quadrant of the LCD, then eventually it died completely. This leads me to believe (hope), that it was shorting on the board at one point where it may have been possible if a single pin had gotten through the solder mask on the LCD.

I’ve ordered another display which I’ll have in about a week. So I can re-test then. I’ll make a new LCD cable as well and mask the LCD better. With any luck the encoders will be fine testing the machine with the LCD not mounted etc and I’ll have found the issue. I didn’t pick it up during assembly as turning the encoders changed values up/down without issue, it’s only the fine control and trying to set a specific value where the problem is obvious.

These encoders are not weird in any way, they are the bourns encoders Smashtv sells and the ones Wilba recommends in the Wiki so they should be fine.

I’ll be back with an update in a week or so :slight_smile:

Cheers,

Arkay.