Jump to content

Sign in to follow this  
Guest LeoL

Decoding rotaries using a PIC

Recommended Posts

Guest LeoL

Hi all,I finally had some time to finish working on a rotary decoder using a $2 PIC that needs no other parts except for one resistor. It can read 3 Panasonic type phased rotaries (or any other compatible types). The outputs are compatible with practically any type of TTL circuitry including standard joystick button inputs.Come to think of it, might actually work with the KD

Share this post


Link to post
Share on other sites
Guest kdarling

Leo,First off, great work on the PIC boards!I do have a question about using your PAN16 Panasonic decoder for high turning rate applications, which is something I would definitely want some for.As you know, my Shift-key trick for using these rotaries with a keyboard decoder is not very useful for instruments that usually require a high spin rate (the OBS's, DG adjustment, and trim wheels) because keyboard decoders expect to see a switch down for some tens of milliseconds before recognizing it as valid. Plus add in the need for the Shift key to lead any key by even more ms.Thus spinning the switch quickly will cause the decoder to simply ignore the "keystrokes". This is good in a way, because you don't get false outputs, but is poor for high turn rate applications. I suspect even the Hagstrom will ignore high button transition rates for debounce reasons.Have you tried your decoder and input boards with such an app? Does your PAN code do like your POT code did (I think), and go for continuus output if the user spins faster? In other words, what's the fastest you can turn the rotary and get a (fairly) corresponding output stream? If I have to change the OBS heading by 180 degrees, I don't want to have to turn a knob for days .Many thanks!KevinDarling

Share this post


Link to post
Share on other sites
Guest LeoL

Kevin,You are correct in your assumptions regarding turning rate and output rates are inversely proportional. The faster you turn, the fewer pulses are recognized.This is due to the interface device in question and not the PAN16F. The PIC runs at 4MHz and outputs exactly what it sees!!! Trust me its bloody fast!The problem is introduced when interfacing this to a KB, Hagstrom, USB modules, etc. I've realized that the only solution is to go up to a full-speed USB device (in my case) which polls at 1 ms rate as opposed to my current device which polls at a 10 ms rate.The Panasonic rotary outputs 3 ms pulses. In theory, a full-speed USB device would trap all these pulses. In fact I would probably modify my PIC code to double the output rate from 20 to 40 pulses per turn for coarse and fine adjustment.I'm a solid month away from developing my first full-speed USB device, so until then, I'm stuck spinning my rotary for days to get up to 180 degs too. ;)-Leo

Share this post


Link to post
Share on other sites
Guest LeoL

After some thinking, I got an idea on how to possibly improve the tracking for better response on slower interface devices. I'll post the results here if they are positive.FYI - if anybody needs a really cheap PIC programmer, check these guys out. http://www.olimex.com/dev/index.htmlLook for the PIC-PG1. It sells for only 7 bucks. It

Share this post


Link to post
Share on other sites
Guest MikePowell

Leo, Kevin,I use a rotary encoder to change OBS on a home made VOR CDI and faced a similar spin rate issue. The solution was to have the PIC time the rate. Beyond a threshold rate the PIC automatically switches into an 8X step size. When you get close to the desired setting you turn more slowly and the PIC automatically "down shifts" to single step size.Perhaps this approach could be adapted through use of an additional PIC output for use on another letter that indicates large step size.Mikewww.mikesflightdeck.com

Share this post


Link to post
Share on other sites
Guest kdarling

> Perhaps this approach could be adapted through use of an additional PIC output for use on another letter that indicates large step size.Yah, that or simply count the spins on the fast PIC, and then dribble out that count of keypresses if the PC can keep up... which it should be able to, since we all have turned the OBS by holding down a key.If the low-speed USB devices are set to a 10ms "scan", then that's still 100 turn motions a second.So, for example, if I spin fast, couldn't the PIC queue up more keypresses? Or, perhaps, leave a key as "down" so auto-repeat kicks in (if that comes from the PC OS).Anyway, I have faith in Leo :) I'm betting he'll come up with something clever.Thanks, Mike!Kev

Share this post


Link to post
Share on other sites
Guest

I think that the solution used by Mike is the best one: it's the same that is used for standar autorepeat.It is also used by FSBUS.I am really thankfull for you sharing this nice peace of electronics.It keeps me from buying a whole lot of LSI encoder quadrature chips.Anyway where i live, 16f84 go for 6$ (6

Share this post


Link to post
Share on other sites

Here's one alternative way to interface the phase-shifted rotary with FSBUS key-card. I found it from the german home cockpit forum in www.flightxpress.de - my german is a bit rusty, so I use google translator when needed :-)http://hongkongfui.de/REDec/redec09b.pdfIt uses 3 logic circuit IC's that seem to cost about $0.6 each at ELFA, but if one gets 25 of them the price drops to 25 cents each, so those can probably be found cheaper than the PIC. One rotary encoder needs 2 of 4011 and one 4066 so it's not THAT many if you want to do a whole cockpit that has quite a few of those..Not that I have tried that, nor I know anything about electronics, but that might work. The circuit looks like it could be assembled into a "breadboard" with jumper wires as well if you work carefully, so one can skip the PCB making process.I bet someone could construct a layout from this that can do, say, 6 or so of these in parallel in one board..But like I said, I havent tried if this works. Fast rotaries used as switches might also trigger the chatter protection built in to the fsbus, this is apparently being addressed by Dirk in the upcoming, not yet finished dirk-said-do-not-ask-when FSBUS software v2.0. :-)Tuomas

Share this post


Link to post
Share on other sites
Guest LeoL

Wow, lots of questions...where to begin?First off, I will have updated code in a few days which is better suited for low speed devices (10-20ms polling rates). Current code is good for high-speed devices (1ms), but has no rate multipliers.Mike: thanks for the PIC rate idea. I don't have the need for this at the moment so I didn't even think about implementing such a system. It

Share this post


Link to post
Share on other sites

>Tuomas: I haven't noticed any chatter (I assume you mean>switch bouncing). The code inherently debounces and I get>absolutely no false readings. I was surprised myself that it>worked so cleanly. The only current problem is the missed>pulses due to the polling rate being too slow. My upcoming>code will address this problem.Yeah, the stuff I was talking about was regarding the german guys at the flightxpress forum who were talking about the other (on the PDF I linked to) circuit and its speed issues on the FSBUS system. The *fsbus router* software or the PIC code contains some anti-chatter stuff for switches, which could limit the max speed of rotaries as well. I dont know if it really does though, I found some old ALPS "knitter-type" rotaries cheap and they work pretty great. The only issue though, if you use keyboard emulation to interface with FS2002, is that FS itself tries to be smart about keystrokes and starts accelerating the input if you have fast "keystrokes", thinking you are desperately trying to adjust the heading with keys... I wonder if there is some option on the fs2002.cfg to force it to not accelerate keyboard inputs..?>Oh and if you really want to get down and dirty, one could>solder everything onto the PIC pins! No "breadboard" and no>PCB. :-wink2Yeah, and cover everything in a big blob of hotglue.. Yummy :-) Yep, can be done.Tuomas

Share this post


Link to post
Share on other sites
Guest MikePowell

Leo,I do the speed shifting locally in the PIC. The state counter is maintained in the PIC too. All that is communicated to the host PC is the end result. This makes the response on the instrument really fast and minimizes the load on the communication channel, which is limping along a 2400 bps. The PIC is a 16F628 with a serial port. Your comment on not needing debouncing is interesting. I implemented debouncing based on the specs for the rotary encoder, an inexpensive Bournes unit. Now it looks like I don't need it. I may drop the code out from the next version. Thanks!Mikewww.mikesflightdeck.comInfo for simpit builders.

Share this post


Link to post
Share on other sites
Guest LeoL

Ah, serial port. Unfortunately, the PIC16F676 doesn't have a serial i/o so I'm stuck with the 10ms USB polling cap at this point. I selected this one for my USB devs because it has the min amount of i/o support for my needs and is cheap. I'm learning about these drawbacks as I go along, but hey, I'm having fun! :DLatching onto the signal transition does the debouncing with a few additional verifications on signal validity. Thankfully, its silent in-between indents so no false pulses. Simply latch onto the first up or down pulse and ignore everything for a fixed period of time while monitoring the opposite pulse. That's all there is to it in a nutshell. The 676 triggers an interrupt on any transition on the input pins and does all the monitoring work for me. It must have a built in threshold on pulse duration before triggering the interrupt resulting in very good debouncing by default.Might not work with all PICs, so don

Share this post


Link to post
Share on other sites
Guest LeoL

Yeah, I worked on some devices where we had really crappy push buttons. I remember adding up to 50-100 ms of debounce time to really clean up the mess. But it was fine for our needs where speed wasn't a factor. By holding down the button for a second, the firmware would increment the LED display counter automatically at a faster rate.Oh yeah I forgot about the hotglue. Actually we're really big on duck tape here in Canada. Fans of Red Green will know what I'm talking about. :-lol-Leo

Share this post


Link to post
Share on other sites
Guest

>Erupter: I might look into a 4x/8x version in the future, once>I finish my full-speed USB device. Yes, port A = rotary>inputs, port C = output pairs (up/down). Sorry for the>confusing schem, but I used my pot decoder schem as the base>so that I could use the same PCB for both. With my newer code>(not the link above) the pulse lasts about 16ms ON and 16ms>OFF. With the old code, the pulse lasts for as long as the>rotary pulse does (i.e. Panasonic rotary is about 3ms ON and>3ms OFF).Actually as far as i know the pulse duration from the encoder is dependent from the turning speed...Why do you say that you have 3ms of pulse width?If i turn mine slow enough, i can even idle the shaft at half phase, haveing one channel on and the other off...Those tests i did to play with the encoders when they arrived, just wired 2 leds to the channels :(Anyway since you have 3 spare pins on portB (what you actually called PORTC), why don't you think at some config flags?You can make the three available pins, as configurations jumpers:on startup the mcu would check which one is closed, and configure itself.For example:jumper1 4x/8x selectionjumper2 debounce on/off (fixed pulse width, or rotary dependent pulse width)jumper3.... hum can't think at anything else, maybe you can ;)

Share this post


Link to post
Share on other sites
Guest LeoL

> Why do you say that you have 3ms of pulse width?The Panasonic specs indicate this clearly on their diagram. It could be meant as a general rule perhaps using an avg turn rate. I don't have a scope to check this out myself. I wish I did, it would have helped in debugging this thing.> Anyway since you have 3 spare pins on portB (what you actually called PORTC), why don't you think at some config flags?The PIC16F676 doesn't have a "Port B" as per the specs sheets. This wasn't a typo on my part. They have a Port A and a Port C! Who knows, someone must have been asleep on the job that day at Microchip. :-lolActually if you look carefully at my schem, you'll notice that all the pins are used. There are 6 for outputs (3 up/down pairs) and 6 for inputs (3 rotary A-B pairs). I would have to give up one rotary to have configuration pins free. Not worth it IMO, it's just as easy to re-program the PIC with new code and have that extra rotary. This way the code stays small and readable.-Leo

Share this post


Link to post
Share on other sites
Guest

>The PIC16F676 doesn't have a "Port B" as per the specs sheets.>This wasn't a typo on my part. They have a Port A and a Port>C! Who knows, someone must have been asleep on the job that>day at Microchip. :-lolSorry, didn't know the 676...:(

Share this post


Link to post
Share on other sites
Guest kdarling

Leo,I believe the 3ms is the maximum bounce for the Panasonic EVE (which is really good).I haven't looked at the PIC specs yet, and I don't know how/what interrupts you're using/are available... but can't you just hook all the rotary B outputs together at the PIC? If first change was B transition == watch for which A changes to determine CCW switch. Or if first was A transition then look at commmon B (or just figure it was CW). That way, you can hook up five rotaries. This may be difficult to program; have to think about it.When I said that you should be able to send 100 chars/sec, I was reading into things perhaps. Low-speed USB = 10ms scan, yes? Does the driver send a polling signal to your PIC, is that how it works? If so, then my idea was that if you see the rotary spin fast, then "lie" and give back more pulses to the PC over the next X scans than there really were. Sort of a warped translation of Mike's method... since you can't actually send a x8 value, just send x8 pulses. The user would visually see things move fast and he would subconsciously slow down to compensate near his destination. Does that make sense?Best regards,KevinDarling

Share this post


Link to post
Share on other sites
Guest LeoL

> I believe the 3ms is the maximum bounce for the Panasonic EVE (which is really good).No No No...why won't anybody believe me? :-hahTake a look for yourself:http://forums.avsim.com/user_files/2927.jpgHmmm, I see what you mean, but it would get really messy on the firmware side of things if it

Share this post


Link to post
Share on other sites
Guest kdarling

Re: 3ms and 3.5ms. Right, if the max bounce per A/B side is <=3ms, then the total detent to detent time would have to be slightly greater than that to give a readable output. I believe that's what they're trying to say in the diagram.Re: B common. I wasn't thinking well before (baby on my lap ). Yes, make all B's common. Then wait for any A to go ON via interrupt or poll. This tells you which rotary it is. At that point simply check the common B. OFF=CW, ON=CCW. Dirt simple. Should work, as long as the user isn't an alien turning multiple rotaries at once. The point is, no one needs to turn more than one at a time. Getting 5 rotaries vs 3 is well worth that simple rule. Umm. Well okay if they were using rotaries for multiple throttles, I could see it, but...Re: USB poll. I was thinking that if a person spun the rotary quickly (you see X transitions within a single poll interval), then you queue up X or perhaps X/2 button pulses to send for the next X or X/2 polls. Or something along those lines. Kind of like a button repeat. The faster the spin, the more repeats. (If the user reverses the spin, of course, null the old repeat queue.)Kevin

Share this post


Link to post
Share on other sites
Guest LeoL

Actually, I remembered 3ms instead of 3.5ms. I meant 3.5ms the whole time...ooops. I only looked at the spec once...my bad!As for "alien turning multiple rotaries at once", In my career I've seen people do the strangest things to software / systems. You don't need aliens to find holes in code and then complain loudly and sometimes rudely about it. I instinctively do not like leaving firmware holes like that. I guess it come from years of abuse at the hands of military clients, some of which were nitpickers of the extreme kind (to put it politely). I guess they had a right to be...they were spending our taxpayer dollars, right? :-)-Leo

Share this post


Link to post
Share on other sites
Guest kdarling

* laughing *Yes, I do know what you mean. Currently I write code for the phone company. Before that, I spent 25 years writing drivers for embedded devices. So yes, I too usually lean towards writing software so that it cannot fail or be failed.However, people also complain about cost . Myself, I'd rather have the 5 rotaries to use with my radios, than just 3. I suppose there could be two versions? OTOH, I'd take the 3 if they could do the fast OBS trick.Thanks for all your time!Best,Kev

Share this post


Link to post
Share on other sites
Guest LeoL

I would really like to accommodate you and develop the 5 rot version, but I just don't believe that it would offer any major cost advantage to someone wiring them up themselves.There's really no cost advantage to having 5 per PIC vs 3. You don't need to buy my $15 PCB version. You can easily and cleanly solder the IC and the rotaries onto an inexpensive protoboard. You can even wire up the PIC to your parallel port to program it using the precompiled HEX file I provided with no extra parts. All it takes is a little extra time and some patience. So for the price of 1 of mine you could build 3 yourself! Sheesh, some salesman I make!! :-rollAs for the "fast OBS" version, its now in my todo list, but until I have a full-speed USB device to test it on, there's just no point in my working on itPerhaps Mike Powell would be persuaded to share his "fast" version if asked nicely. ;)-Leo

Share this post


Link to post
Share on other sites
Guest

My knowledge of analog electronics is still small.Since the pic produces a positive pulse out of portc, and FSBUS need to ground a pin in order to detect contact, i shall use a transistor, or at least i think so.Would a standard 2n2222 NPN do the work?the output pin of the pic connected to the gate, the two pins of the FSBUS connected to base and emitter?Or what else?Also:Leo the code you provide would compile for a 16f84?Or did you use some model-specific declarations or calls?Because at the moment my supplier don't have 676 and i would like to try your code with the 16f84 i have lying around.Thanks you very much

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...