Decoding rotaries using a PIC

[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

[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

[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

[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

[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

[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

[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

[tigert]

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

[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

[tigert]

>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

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

[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

[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

[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 ;)

[Guest]

Ooops, double post :(