ForumLearjet 45 Discussion: Learjet 45 DiscussionEncoder Solutions and Discussion

Please or Register to create posts and topics.

Encoder Solutions and Discussion

#1 · December 14, 2017, 7:03 am

Quote from Hangar45 Admin on December 14, 2017, 7:03 am
(Original thread started on 09-27-13 by Alan Norris)

I thought I would start a new thread for this as the FGC will be with us soon. As you know programming a rotary encoder that is attached to the PoKeys card is done in FSUIPC Buttons + Switches section. Right and left turns of the encoder are seen as button presses and you can program them for heading, course, altitude, speed etc. The issue is that using say the standard Course Increment and Decrement makes tuning a slow process. You can select Course Increment fast and Course Decrement fast but then the rate of change is so great for each click of the encoder that you cannot fine tune the number. Some have tried using Course Increment fast for right turns of the encoder and Course Increment for left turns. This means that to get to a setting you use the fast turn and go past the setting and then use the regular or slow turn to fine tune. Some have had issues with this.

Here is a link to a thread on Pete Dowson's forum about a LUA plug in that emulates the proper method of using the FGC encoders -- turn the knob slow and the values change slowly, turn the knob fast and the values change quickly. I have only just started using Lua plug ins but only for simple stuff like playing a sound when the Test knob is turned.

Please chime in with any comments and suggestions that may help us get this working. I don't have an encoder right now to test so may have to rely on those who do or wait to get my FGC and then try it out:

http://forum.simflight.com/topic/68260-rotary-encoder-input-speed/

(Posted by Eric Tomlin on 09-27-13)

I guess I'm having a hard time understanding why this is even an issue. Have I flown my simulator for so long that I do not even realize that turning a knob one way or the other is a pain in the rear? I admit that it doesn't zip by like greased lightening, but it is responsive and works generally fine, as long as you're not trying to set a new speed record on dialing in a new HDG, CRS, ALT.

Since I will be at Ron's tomorrow, I guess I will see what the fuss is about regarding this.

(Posted by Eric Williams on 09-27-13)

I'll have to give it a try and compare to my existing driver setup. In all the videos I've seen of the real aircraft, doing a drastic change does seem to take the pilot some time to accomplish.

Here is a video that illustrates the turning of a encoder on the FGC but I don't think it tells us much other than this is more rotating than my setup would take to adjust for any normal change. Check out at 5:33

https://youtu.be/1H_awWil8pA

That's a whole lotta crankin' I would say my setup is very unrealistic (too easy/user friendly) as for that amount of (estimated) turns I could go from ground level to beyond the Lear ceiling.

My guess? The change rate you guys are seeing is likely fairly normal/reasonable. I'll know better once I set up the new FGC.

(Posted by Will Sasse on 09-27-13)

Although I don't fly a jet, the Cessna I fly has electronic HSI with encoders for CDI & HDG. It has only one speed, so a 180 degree turn requires a bit of rotating the knob. Takes a few seconds, but in my opinion is easier to use. You don't overshoot significantly your selected bearing, no thinking on the rotation as to fast or slow. As I suggested in Ron's build thread, this action should not require thought which could distract from more important tasks. I haven't found fast encoders on anything I've flown. Perhaps others have found different?

(Posted by Ron Rollo on 09-27-13)

Eric W., your video shows the pilot give a good eleven turns of the knob. Depending on how far he was going is the question. It may be that what I have is fine. Tomorrow I have Mike Badger and Eric Tomlin stopping in to check things out. We will see what they say. The more I think about it, the more I think it is fine and just one of those things that is gonna take a few seconds.

(Posted by Eric Williams on 09-29-13)

I agree with Will's comment. The thought about increasing "focus" if we have dual speeds I think is bang on. I can only speak for my setup but it does require a bit more attention (minimal but noticeable). Your insight is definitely valuable.

Any aircraft I have flown in "up front" has had no autopilot to speak of but the bugs definitely take a few rounds to move a large distance. Interesting topic for sure.

Should be interesting to get the impressions from the crew at Ron's place. I really like that we are finally at the stage to begin poking at these items!

(Posted by Ron Rollo on 09-30-13)

Eric T. and Mike B. were down a few days ago and they both thought that it took a little longer than it should to get the bug where it needs to be. The impression I got from both of them is that it was satisfactory at best.

Eric did point out one thing, I do not have my sync button working yet. That will go a long way. If I am 180 degrees out from where I want to be, I can hit the sync button, (the push button built into the encoder) and that will swing the heading around to the direction I am flying. From there I can add a few twist to get to the exact heading. I will let them chime in.

(Posted by Mike Badger on 09-30-13)

It was pretty slow and I am not sure if this can be solved in the software. Usually the software will jump by 10's if it detects rapid turning and then goes down to one deg/100ft when the turn is slows.

(Posted by Alan Norris on 10-02-13)

Has anyone had chance to try that Lua script that is supposed to allow slow and fast turning? I don't have an FGC so I can't try it out.

(Posted by Ron Rollo on 10-26-14)

About a month ago I was at a point in my build that I needed to finally address what I called, "These darn Encoders" in my Lear45 sim. The encoders that I was mainly concerned with were the five on the FGC, especially the heading, CRS1 and CRS2. The issue that I was having is that they were running slow, choppy and sometimes would skip backwards. Several of you who have had the opportunity to fly my sim have commented on it. (Trust me, I have never been happy with them either.) As many of you know I am using the Pokeys56U cards for the interfacing of the encoders, DUs and RMUs. To say the least I wanted to finally get to the bottom of my poor performance also known as E.D., "Encoder Dis function."

I sent out an email to a few key guys including DonnyRay, Eric, Shane, and Jason to kick around the encoders to see if we could come up with a solution or even a better way to address the encoders all together. DonnyRay took the lead with his vast knowledge and wisdom on electrical engineering and let me tell you, he never ceases to amaze! We wanted to work behind the scenes until we figured out at least some of the fundamental problems that we were having. I think we have reached that point.

A very long story made short is that several factors came up as possible issues with the performance that myself and others were experiencing relating to encoders:

1. Is there a "Debounce Filter Circuit" built into the card or is there an external midware circuit?

2. The PoKeys cards may not be the first choice to run encoders, especially more than three.

3. The encoders that I have chosen to use on the FGC may not be the highest of quality.

4. The configuration of the encoders within the PoKeys interface cards may not be correct.

5. The network between the computers may not be up to par.

6. Running only two computers may be causing lag on the network.

These were some of the main possible issues or combinations of issues that are causing the poor performance. When I first started I gave my encoders a grade of D-. This grade represents that the encoders are connected and show signs of life and even turn in the same direction as your asking them to turn. After 4 weeks, my encoder grade has improved to a B-, possibly even a B. This is an acceptable grade and it represents that the encoders are not stuttering, turn at a reasonable rate and do not take micro steps the wrong direction.

But what would it take to achieve an encoder grade of an A+ you might ask? For me it would need two be two additional things:

1. The elimination of all stutters which I believe can be addressed by adding the third computer.

2. Making the encoders work like they do in the real Lear45. That is the heading, CRS1 and CRS2 are all dual speed encoders. What this means is that if you turn the encoder slow, the heading bug moves at one degree at a time. If you turn or spin the encoder fast, the heading bugs moves fast, up to four times as fast!

What we have learned is that DonnyRay is more than capable of making a circuit that can make this happen, but the issue is we are not sure if the PoKeys card can support it.

Another issue that we have is that most of us are using or are planning on using the Pokeys56U card. What we are looking for is anyone who is using another type of interface card that they are running encoders on. There may be something out there that we are not even aware of and all this research is for nothing although a learning experience.

So at this point we are looking to expand our quest for better encoder performance with all hangar members! If you have any general encoder knowledge, comments or questions please post here.

In my next post, I will cover how I am now currently running my encoders with the PoKeys to achieve the satisfactory performance that I am now getting.

(Posted by Ron Rollo on 10-26-14)

This post is to cover what I am doing to achieve the satisfactory level of performance that I am currently getting with my PoKeys56U interface card and the encoders that were originally chosen for the Project45 FGC.

What I have found is that some encoders/functions are more important than others. The most important encoders as far as noticeable performance are the Heading, CRS1 and CRS2 on the FGC. These three have to work to the best of their ability because for each detent of the encoder should equal one degree of turn. After that the Altitude encoder followed by the Speed encoder are in the next tier of importance.

There are as many as 22 encoders in the Lear45, but there are a few taken care of by other programs (CDR software takes care of two and Mark's software application takes care of four more on the RMUs as examples.) The vast majority of the encoders just need to work, meaning that they need to turn the direction they are suppose to turn, not stutter, and not take micro steps backwards.

To get started, you need to have a basic understanding of how the PoKeys56u card works which I will assume you have. It also helps if you have this printed out:

You can find the Pokeys illustration HERE under FAQ.

The first thing that we need to do is make sure that you have your hardware plugged into the proper pins on the PoKeys card. The Pokeys has several pins that are specifically designed for FAST encoding operation. This is good but not for all encoding functions. What I have found is that only the Heading, CRS1 and CRS2 should be hooked up to FAST encoder pins. Leave all the other Fast and Ultra Fast pins empty, unless you need them for basic on/off switch function.

Heading is hooked into pins 1 and 2 (Fast enc A1 and B1)

CRS1 is hooked into pins 5 and 6 (Fast enc A2 and B2)

CRS2 is hooked into pins 15 and 16 (Fast enc A3 and B3)

Notice that these are all Fast Encoder pins and in addition to that, they are encoder sets 1AB, 2AB and 3AB. I left all the other variations of Fast encoder pins open, they are not needed, AND, they are not as straight forward as the first three sets that I am using.

My ALT is on pins 3 and 4. My SPD is on pins 17 and 18. (notice that they are just standard pins) I have all four of my display units hooked in starting at pin 23 through 53. (pin 35 was skipped for no reason other than I ran out of things to plug into the Pokeys)

So at this point you should have the hardware part of the problem squared away with your encoders plugged into the correct pins. The next step is within the PoKeys Configuration software. But first, make sure you are using the latest version of the PoKeys software, currently 3.1.35. If not update your Pokeys cards.

I have also noticed while looking at screen shots from Eric that his PoKeys configuration screen looks a little different. I think he is using the PoKeys55. If your using something other than the PoKeys56u, expect that some of these settings and selections will be in other places in the software.

Using the Heading encoder as an example which is hooked to pin 1 and 2. In the PoKeys configuration, click on pin 1 and select "Digital Input" This will open up two tabs below called "Key Mapping" and "Encoders/Counters". You will need to do a few things in both tabs.

Within "Key Mapping" select "Direct Key Mapping". This will allow you to select something in the "Key Down" box and also to select the "CTRL" box. (You have the option to select two other boxes, the up arrow and the windows logo) I used the letter A in the "Key Down" box followed by CTRL. This is an important time to point out that you want to make sure that there are no key assignments in FSX or any other program that could get confused with these new key assignments that your going to be making. I actually went into FSX and erased 98% of them leaving only the ones that I know I will still use as key strokes, P for pause as a quick example.

All five of my encoders on the FGC use "Key Down" assignments from A CTRL to J CTRL, (10 total). This is important because from the testing that I have done, I have noticed a significant difference in performance using the "Key Down" option. compared to the Joystick assignment configuration option.

Now click on pin #2 and repeat by programming the "Key Down" tab to B CTRL. This way you will have both pin 1 and 2 ready to go when you let the PoKeys Configuration know that you want an encoder assigned to pins 1 and 2.

Going back to pin 1, click on the "Encoders/Counters tab, scroll up to encoder 1 in the box, select channel A and 2X sampling. Then select "Encoder". This should set pin 1 to be encoder 1 channel A. Now select pin 2 and click on the "Encoders/Counters tab. This time you will scroll to encoder 1 in the box, select channel B and 2X sampling. Then select "Encoder". This should set pin 2 to be encoder 1 channel B. (If your like me, you will screw this up and also see that the PoKeys has a mind of it's own. But you will get it.)

The last thing that you need to do is "Enable Counter" and if the pin is increasing, select "Rising". If it is decreasing, select "Falling" Once you have the encoders assigned in FSUIPC, insure that you have them going the right direction, If not reverse them. Do the same with pins 5 and 6 which is CRS1 and pins 15 and 16, CRS2.

And that's it withing PoKeys. Like I said, the three main ones that have to be done right are the Heading, CRS1 and CRS2. If you get these three done correctly, all the others will follow with ease. The next step will be to have FSX running and go into FSUIPC and program the key strokes. Let me know if anyone needs further assistance on that part.

NOTE: We use 2X sampling because for every full detent of the encoder, (there are 24 on the encoders on the FGC), the heading will change 2 degrees. To fine tune the heading and CRS bugs, the encoders will sit on the hump of the detent, not in the valley. I tried 4X sampling and it is counterproductive to keep it simple.

One thing to look out for:

If while programming the PoKeys you start running into issues where something sounds like it is stuck, (constant dinging), go back into the PoKeys and deactivate the last one or two things that you did. If it gets really bad, you will need to unplug the USB fro the PoKeys so that it can not see that key stroke. This happened to me to the point that I could not even log into the computer because the PoKeys card was corrupt. I discovered that once I unplugged the PoKeys USB, I was able to log on and get into the Pokeys Configuration to undo the last few things that I did. Growing pains.....

Next I will be designing a six pack Debounce Filter Circuit based off of DonnyRay's engineering. It will insure that the FGC encoders are sending nice clean signals to the PoKeys card in addition to help with wire management. Keep an eye out for that in the next few days!

UPDATE:

When I first brought this problem to DonnyRay, the first question he ask me is if I was using a debounce filter circuit with my encoders. I had no idea what that was and what it was for. All these years playing around with sim stuff and never heard of the term "debounce".

Anyway, what a debounce circuit does in Layman's terms is cleans up the signal from the encoder before it goes to the interface card. DonnyRay engineered four different variations of a test filter until we found one that worked well with the PoKeys card. From that, I designed what I call the Debounce Filter Circuit 6 pack:

It is designed to handle six encoders. I plan on only using this filter for the five on the FGC and the single encoder on the standby altimeter. It would also fit nicely with the six on the four display units.

UPDATE:

Here is the 6 pack Debounce Filter Circuit hooked in and tested. It works! Actually I expected it to work but what I was really looking for is if there were any adverse effects. I have not seen any yet, although all my testing has occurred on the simulated ground.

Here is a photo of the 6 pack DFC wired in:

On a related note, today I have also finished wiring in the RMUs. I had to design and make a converter card so that the ribbon cable from the RMUs can be converted into wires that the PoKeys can handle:

A close up look at the RMU converter PCB:

Last but not least, spaghetti junction over the PoKeys. There is no neat way to make nearly 100 wires look squared away but this is my best attempt:

In the next 24 hours I will have the RMUs programmed and tested. At this point, I am satisfied with the performance of the encoders, although they are still kinda jumpy but I believe that will be resolved with the addition of the third computer here in a few weeks. That will be my next big change for the better and testing to follow.

UPDATE:

After testing the Debounce Filter Circuit, I found that it works but does not add any value to the performance of the encoders. I tested with it and without it and found that there was no difference one way or the other. With that said, it does not hurt to have it but I found now value in having it if that makes sense.

If you have any encoder information, comments or questions, please post here. The encoder solution is still a work in progress and there is not a definite path set in stone.

(Posted by Will Sasse on 11-04-14)

Nice, and very useful information Ron! Some of the engineers at my work would be jealous of your cable routing skills!

(Posted by Ron Rollo on 11-05-14)

The wiring and being able to make it neat is a hobby in it self. It might not be so difficult if we knew what we were doing from the beginning but when you couple the facts all together, it is amazing it looks as good as it does.

1. A ten year project.

2. Not knowing nothing to begin with and learning as we go.

3. Guys with great ideas coming and then going, sometimes leaving us hanging.

4. Technology changing on the fly.

5. Countless modifications.

6. My sim is more like one big beta test!

(Posted by Alan Norris on 11-10-14)

Ron, I was playing around with the PoKeys console today and was trying to follow your instructions on programming the encoder. I should mention that I do need to rewire my card as the CRS 2 encoder is on Pins 2 & 3. I went ahead anyway and clicked on Pin 2 selected the keyboard option and clicked on A and CTRL and for Pin 3 I used B and CTRL. I checked the Enable Counter box for Pin 2 and checked Rising however I could not select this option for Pin 3 as the Enable Counter box was grayed out. Is this because this option is only available for the fast encoder pins and as Pin 3 is not one it would not allow me to select that option?

Also in FSUIPC if I turn the encoder and then check the Keyboard box and enter the CRTL A there is no drop down box to select OBI 2 INCR or DECR -- that is only available if I use button presses not key strokes. Am I doing something wrong here?

(Posted by Ron Rollo on 11-10-14)

Hey Alan, your right, the "enable counter" is only associated with the fast encoders. Print out a map of the PoKeys if you have not yet done that yet. It makes things easier.

As far as the OBI 2 INCR DECR, it has to be there. I will look at this tomorrow when I get a free minute.

(Posted by Alan Norris on 11-13-14)

Got all the fast pin encoders working just fine. I used the joystick buttons option in PoKeys console as opposed to keystrokes. I don't think it makes any difference.

(Posted by Ron Rollo on 08-09-15)

Anyone ever experience a couple PoKeys pins seemingly going bad? I just spent a few hours tracing a couple "bad" buttons on RMU #2 back to the PoKeys pins #15, #17 and #19. I swapped the pins for ones that are not in use like the TST and 1/2 buttons. So I was wondering if anyone else has seen this before, PoKeys pins going bad and becoming dead?

UPDATE:

I found the issue. I could not initially get Mark's RMU Utility "No Gear" version to work so I was using his version with the gear pins. His "Gear" version uses pins #14 thru #19. This explains a lot because I was having other issues when I would raise the gear, RMU 2 would go a little nuts and freeze up. When I lowered the gear it would clear up. In addition to that, the encoders for my VSPD and CRS2 were also using those same pins numbers on my second PoKeys card. Guess what, they were also going haywire. In a perfect world you would think that what happens on one PoKeys card stays on that PoKeys card and the same for the other. Apparently not in our sim world.

SOLUTION:

Option #1 Do not use pins #14 thru #19 with Mark's "Gear" version. DO NOT plug any wires into these six pins on the PoKeys card using the RMU Utility unless those wires are for the gear indicator LEDs.

Option #2 Use Mark's "No Gear" version of the software. If you use the "No Gear" version, you can use pins #14 thru #19 for any function on either of your RMUs. Initially I was having a hard time running the "No Gear" version and I had to overt back to his "Gear" version. Now I am back to using his "No Gear Version.

For more information on Mark's RMU Utilities click HERE

One last tip! In case your not aware, your two RMUs will take up almost every pin on one single PoKeys56U card. Do not attempt to plug anything else into that one PoKeys card except the wires coming from your two RMUs (unless you are going to use the Gear version for the LEDs) or you will have a whole new set of issues that you can write about here in the hangar!

One last point for the new guys! If your planning to use a FDS SYS card to handle all your LED lighting in your AML switches, (HIGHLY RECOMMENDED) you will want to also have your gear annunciation lighting plugged into the FDS SYS card. If for no other reason so that when you do a lights test, your gear annunciation lighting will also be part of that test. In case your wondering, Mark added this small piece of software to the RMU Utility because he was not planning on having a FDS SYS card which handles the gear annunciation logic. And what that means is in both his software and in the FDS SYS InterfaceIT software, the gear annunciation lighting has delays as the gear is coming up and the lights even stagger replicating lag between each of the gear doors closing independently of each other. A really neat feature! And now you know. Thanks Mark L. for the RMU Utility software!

If you have any encoder information, comments or questions, please post here. The encoder solution is still a work in progress and there is not a definite path set in stone.

(Original thread started on 09-27-13 by Alan Norris)

I thought I would start a new thread for this as the FGC will be with us soon. As you know programming a rotary encoder that is attached to the PoKeys card is done in FSUIPC Buttons + Switches section. Right and left turns of the encoder are seen as button presses and you can program them for heading, course, altitude, speed etc. The issue is that using say the standard Course Increment and Decrement makes tuning a slow process. You can select Course Increment fast and Course Decrement fast but then the rate of change is so great for each click of the encoder that you cannot fine tune the number. Some have tried using Course Increment fast for right turns of the encoder and Course Increment for left turns. This means that to get to a setting you use the fast turn and go past the setting and then use the regular or slow turn to fine tune. Some have had issues with this.

Here is a link to a thread on Pete Dowson's forum about a LUA plug in that emulates the proper method of using the FGC encoders -- turn the knob slow and the values change slowly, turn the knob fast and the values change quickly. I have only just started using Lua plug ins but only for simple stuff like playing a sound when the Test knob is turned.

Please chime in with any comments and suggestions that may help us get this working. I don't have an encoder right now to test so may have to rely on those who do or wait to get my FGC and then try it out:

http://forum.simflight.com/topic/68260-rotary-encoder-input-speed/

(Posted by Eric Tomlin on 09-27-13)

I guess I'm having a hard time understanding why this is even an issue. Have I flown my simulator for so long that I do not even realize that turning a knob one way or the other is a pain in the rear? I admit that it doesn't zip by like greased lightening, but it is responsive and works generally fine, as long as you're not trying to set a new speed record on dialing in a new HDG, CRS, ALT.

Since I will be at Ron's tomorrow, I guess I will see what the fuss is about regarding this.

(Posted by Eric Williams on 09-27-13)

I'll have to give it a try and compare to my existing driver setup. In all the videos I've seen of the real aircraft, doing a drastic change does seem to take the pilot some time to accomplish.

Here is a video that illustrates the turning of a encoder on the FGC but I don't think it tells us much other than this is more rotating than my setup would take to adjust for any normal change. Check out at 5:33

That's a whole lotta crankin' I would say my setup is very unrealistic (too easy/user friendly) as for that amount of (estimated) turns I could go from ground level to beyond the Lear ceiling.

My guess? The change rate you guys are seeing is likely fairly normal/reasonable. I'll know better once I set up the new FGC.

(Posted by Will Sasse on 09-27-13)

Although I don't fly a jet, the Cessna I fly has electronic HSI with encoders for CDI & HDG. It has only one speed, so a 180 degree turn requires a bit of rotating the knob. Takes a few seconds, but in my opinion is easier to use. You don't overshoot significantly your selected bearing, no thinking on the rotation as to fast or slow. As I suggested in Ron's build thread, this action should not require thought which could distract from more important tasks. I haven't found fast encoders on anything I've flown. Perhaps others have found different?

(Posted by Ron Rollo on 09-27-13)

Eric W., your video shows the pilot give a good eleven turns of the knob. Depending on how far he was going is the question. It may be that what I have is fine. Tomorrow I have Mike Badger and Eric Tomlin stopping in to check things out. We will see what they say. The more I think about it, the more I think it is fine and just one of those things that is gonna take a few seconds.

(Posted by Eric Williams on 09-29-13)

I agree with Will's comment. The thought about increasing "focus" if we have dual speeds I think is bang on. I can only speak for my setup but it does require a bit more attention (minimal but noticeable). Your insight is definitely valuable.

Any aircraft I have flown in "up front" has had no autopilot to speak of but the bugs definitely take a few rounds to move a large distance. Interesting topic for sure.

Should be interesting to get the impressions from the crew at Ron's place. I really like that we are finally at the stage to begin poking at these items!

(Posted by Ron Rollo on 09-30-13)

Eric T. and Mike B. were down a few days ago and they both thought that it took a little longer than it should to get the bug where it needs to be. The impression I got from both of them is that it was satisfactory at best.

Eric did point out one thing, I do not have my sync button working yet. That will go a long way. If I am 180 degrees out from where I want to be, I can hit the sync button, (the push button built into the encoder) and that will swing the heading around to the direction I am flying. From there I can add a few twist to get to the exact heading. I will let them chime in.

(Posted by Mike Badger on 09-30-13)

It was pretty slow and I am not sure if this can be solved in the software. Usually the software will jump by 10's if it detects rapid turning and then goes down to one deg/100ft when the turn is slows.

(Posted by Alan Norris on 10-02-13)

Has anyone had chance to try that Lua script that is supposed to allow slow and fast turning? I don't have an FGC so I can't try it out.

(Posted by Ron Rollo on 10-26-14)

About a month ago I was at a point in my build that I needed to finally address what I called, "These darn Encoders" in my Lear45 sim. The encoders that I was mainly concerned with were the five on the FGC, especially the heading, CRS1 and CRS2. The issue that I was having is that they were running slow, choppy and sometimes would skip backwards. Several of you who have had the opportunity to fly my sim have commented on it. (Trust me, I have never been happy with them either.) As many of you know I am using the Pokeys56U cards for the interfacing of the encoders, DUs and RMUs. To say the least I wanted to finally get to the bottom of my poor performance also known as E.D., "Encoder Dis function."

I sent out an email to a few key guys including DonnyRay, Eric, Shane, and Jason to kick around the encoders to see if we could come up with a solution or even a better way to address the encoders all together. DonnyRay took the lead with his vast knowledge and wisdom on electrical engineering and let me tell you, he never ceases to amaze! We wanted to work behind the scenes until we figured out at least some of the fundamental problems that we were having. I think we have reached that point.

A very long story made short is that several factors came up as possible issues with the performance that myself and others were experiencing relating to encoders:

1. Is there a "Debounce Filter Circuit" built into the card or is there an external midware circuit?

2. The PoKeys cards may not be the first choice to run encoders, especially more than three.

3. The encoders that I have chosen to use on the FGC may not be the highest of quality.

4. The configuration of the encoders within the PoKeys interface cards may not be correct.

5. The network between the computers may not be up to par.

6. Running only two computers may be causing lag on the network.

These were some of the main possible issues or combinations of issues that are causing the poor performance. When I first started I gave my encoders a grade of D-. This grade represents that the encoders are connected and show signs of life and even turn in the same direction as your asking them to turn. After 4 weeks, my encoder grade has improved to a B-, possibly even a B. This is an acceptable grade and it represents that the encoders are not stuttering, turn at a reasonable rate and do not take micro steps the wrong direction.

But what would it take to achieve an encoder grade of an A+ you might ask? For me it would need two be two additional things:

1. The elimination of all stutters which I believe can be addressed by adding the third computer.

2. Making the encoders work like they do in the real Lear45. That is the heading, CRS1 and CRS2 are all dual speed encoders. What this means is that if you turn the encoder slow, the heading bug moves at one degree at a time. If you turn or spin the encoder fast, the heading bugs moves fast, up to four times as fast!

What we have learned is that DonnyRay is more than capable of making a circuit that can make this happen, but the issue is we are not sure if the PoKeys card can support it.

Another issue that we have is that most of us are using or are planning on using the Pokeys56U card. What we are looking for is anyone who is using another type of interface card that they are running encoders on. There may be something out there that we are not even aware of and all this research is for nothing although a learning experience.

So at this point we are looking to expand our quest for better encoder performance with all hangar members! If you have any general encoder knowledge, comments or questions please post here.

In my next post, I will cover how I am now currently running my encoders with the PoKeys to achieve the satisfactory performance that I am now getting.

(Posted by Ron Rollo on 10-26-14)

This post is to cover what I am doing to achieve the satisfactory level of performance that I am currently getting with my PoKeys56U interface card and the encoders that were originally chosen for the Project45 FGC.

What I have found is that some encoders/functions are more important than others. The most important encoders as far as noticeable performance are the Heading, CRS1 and CRS2 on the FGC. These three have to work to the best of their ability because for each detent of the encoder should equal one degree of turn. After that the Altitude encoder followed by the Speed encoder are in the next tier of importance.

There are as many as 22 encoders in the Lear45, but there are a few taken care of by other programs (CDR software takes care of two and Mark's software application takes care of four more on the RMUs as examples.) The vast majority of the encoders just need to work, meaning that they need to turn the direction they are suppose to turn, not stutter, and not take micro steps backwards.

To get started, you need to have a basic understanding of how the PoKeys56u card works which I will assume you have. It also helps if you have this printed out:

You can find the Pokeys illustration HERE under FAQ.

The first thing that we need to do is make sure that you have your hardware plugged into the proper pins on the PoKeys card. The Pokeys has several pins that are specifically designed for FAST encoding operation. This is good but not for all encoding functions. What I have found is that only the Heading, CRS1 and CRS2 should be hooked up to FAST encoder pins. Leave all the other Fast and Ultra Fast pins empty, unless you need them for basic on/off switch function.

Heading is hooked into pins 1 and 2 (Fast enc A1 and B1)

CRS1 is hooked into pins 5 and 6 (Fast enc A2 and B2)

CRS2 is hooked into pins 15 and 16 (Fast enc A3 and B3)

Notice that these are all Fast Encoder pins and in addition to that, they are encoder sets 1AB, 2AB and 3AB. I left all the other variations of Fast encoder pins open, they are not needed, AND, they are not as straight forward as the first three sets that I am using.

My ALT is on pins 3 and 4. My SPD is on pins 17 and 18. (notice that they are just standard pins) I have all four of my display units hooked in starting at pin 23 through 53. (pin 35 was skipped for no reason other than I ran out of things to plug into the Pokeys)

So at this point you should have the hardware part of the problem squared away with your encoders plugged into the correct pins. The next step is within the PoKeys Configuration software. But first, make sure you are using the latest version of the PoKeys software, currently 3.1.35. If not update your Pokeys cards.

I have also noticed while looking at screen shots from Eric that his PoKeys configuration screen looks a little different. I think he is using the PoKeys55. If your using something other than the PoKeys56u, expect that some of these settings and selections will be in other places in the software.

Using the Heading encoder as an example which is hooked to pin 1 and 2. In the PoKeys configuration, click on pin 1 and select "Digital Input" This will open up two tabs below called "Key Mapping" and "Encoders/Counters". You will need to do a few things in both tabs.

Within "Key Mapping" select "Direct Key Mapping". This will allow you to select something in the "Key Down" box and also to select the "CTRL" box. (You have the option to select two other boxes, the up arrow and the windows logo) I used the letter A in the "Key Down" box followed by CTRL. This is an important time to point out that you want to make sure that there are no key assignments in FSX or any other program that could get confused with these new key assignments that your going to be making. I actually went into FSX and erased 98% of them leaving only the ones that I know I will still use as key strokes, P for pause as a quick example.

All five of my encoders on the FGC use "Key Down" assignments from A CTRL to J CTRL, (10 total). This is important because from the testing that I have done, I have noticed a significant difference in performance using the "Key Down" option. compared to the Joystick assignment configuration option.

Now click on pin #2 and repeat by programming the "Key Down" tab to B CTRL. This way you will have both pin 1 and 2 ready to go when you let the PoKeys Configuration know that you want an encoder assigned to pins 1 and 2.

Going back to pin 1, click on the "Encoders/Counters tab, scroll up to encoder 1 in the box, select channel A and 2X sampling. Then select "Encoder". This should set pin 1 to be encoder 1 channel A. Now select pin 2 and click on the "Encoders/Counters tab. This time you will scroll to encoder 1 in the box, select channel B and 2X sampling. Then select "Encoder". This should set pin 2 to be encoder 1 channel B. (If your like me, you will screw this up and also see that the PoKeys has a mind of it's own. But you will get it.)

The last thing that you need to do is "Enable Counter" and if the pin is increasing, select "Rising". If it is decreasing, select "Falling" Once you have the encoders assigned in FSUIPC, insure that you have them going the right direction, If not reverse them. Do the same with pins 5 and 6 which is CRS1 and pins 15 and 16, CRS2.

And that's it withing PoKeys. Like I said, the three main ones that have to be done right are the Heading, CRS1 and CRS2. If you get these three done correctly, all the others will follow with ease. The next step will be to have FSX running and go into FSUIPC and program the key strokes. Let me know if anyone needs further assistance on that part.

NOTE: We use 2X sampling because for every full detent of the encoder, (there are 24 on the encoders on the FGC), the heading will change 2 degrees. To fine tune the heading and CRS bugs, the encoders will sit on the hump of the detent, not in the valley. I tried 4X sampling and it is counterproductive to keep it simple.

One thing to look out for:

If while programming the PoKeys you start running into issues where something sounds like it is stuck, (constant dinging), go back into the PoKeys and deactivate the last one or two things that you did. If it gets really bad, you will need to unplug the USB fro the PoKeys so that it can not see that key stroke. This happened to me to the point that I could not even log into the computer because the PoKeys card was corrupt. I discovered that once I unplugged the PoKeys USB, I was able to log on and get into the Pokeys Configuration to undo the last few things that I did. Growing pains.....

Next I will be designing a six pack Debounce Filter Circuit based off of DonnyRay's engineering. It will insure that the FGC encoders are sending nice clean signals to the PoKeys card in addition to help with wire management. Keep an eye out for that in the next few days!

UPDATE:

When I first brought this problem to DonnyRay, the first question he ask me is if I was using a debounce filter circuit with my encoders. I had no idea what that was and what it was for. All these years playing around with sim stuff and never heard of the term "debounce".

Anyway, what a debounce circuit does in Layman's terms is cleans up the signal from the encoder before it goes to the interface card. DonnyRay engineered four different variations of a test filter until we found one that worked well with the PoKeys card. From that, I designed what I call the Debounce Filter Circuit 6 pack:

It is designed to handle six encoders. I plan on only using this filter for the five on the FGC and the single encoder on the standby altimeter. It would also fit nicely with the six on the four display units.

UPDATE:

Here is the 6 pack Debounce Filter Circuit hooked in and tested. It works! Actually I expected it to work but what I was really looking for is if there were any adverse effects. I have not seen any yet, although all my testing has occurred on the simulated ground.

Here is a photo of the 6 pack DFC wired in:

On a related note, today I have also finished wiring in the RMUs. I had to design and make a converter card so that the ribbon cable from the RMUs can be converted into wires that the PoKeys can handle:

A close up look at the RMU converter PCB:

Last but not least, spaghetti junction over the PoKeys. There is no neat way to make nearly 100 wires look squared away but this is my best attempt:

In the next 24 hours I will have the RMUs programmed and tested. At this point, I am satisfied with the performance of the encoders, although they are still kinda jumpy but I believe that will be resolved with the addition of the third computer here in a few weeks. That will be my next big change for the better and testing to follow.

UPDATE:

After testing the Debounce Filter Circuit, I found that it works but does not add any value to the performance of the encoders. I tested with it and without it and found that there was no difference one way or the other. With that said, it does not hurt to have it but I found now value in having it if that makes sense.

If you have any encoder information, comments or questions, please post here. The encoder solution is still a work in progress and there is not a definite path set in stone.

(Posted by Will Sasse on 11-04-14)

Nice, and very useful information Ron! Some of the engineers at my work would be jealous of your cable routing skills!

(Posted by Ron Rollo on 11-05-14)

The wiring and being able to make it neat is a hobby in it self. It might not be so difficult if we knew what we were doing from the beginning but when you couple the facts all together, it is amazing it looks as good as it does.

1. A ten year project.

2. Not knowing nothing to begin with and learning as we go.

3. Guys with great ideas coming and then going, sometimes leaving us hanging.

4. Technology changing on the fly.

5. Countless modifications.

6. My sim is more like one big beta test!

(Posted by Alan Norris on 11-10-14)

Ron, I was playing around with the PoKeys console today and was trying to follow your instructions on programming the encoder. I should mention that I do need to rewire my card as the CRS 2 encoder is on Pins 2 & 3. I went ahead anyway and clicked on Pin 2 selected the keyboard option and clicked on A and CTRL and for Pin 3 I used B and CTRL. I checked the Enable Counter box for Pin 2 and checked Rising however I could not select this option for Pin 3 as the Enable Counter box was grayed out. Is this because this option is only available for the fast encoder pins and as Pin 3 is not one it would not allow me to select that option?

Also in FSUIPC if I turn the encoder and then check the Keyboard box and enter the CRTL A there is no drop down box to select OBI 2 INCR or DECR -- that is only available if I use button presses not key strokes. Am I doing something wrong here?

(Posted by Ron Rollo on 11-10-14)

Hey Alan, your right, the "enable counter" is only associated with the fast encoders. Print out a map of the PoKeys if you have not yet done that yet. It makes things easier.

As far as the OBI 2 INCR DECR, it has to be there. I will look at this tomorrow when I get a free minute.

(Posted by Alan Norris on 11-13-14)

Got all the fast pin encoders working just fine. I used the joystick buttons option in PoKeys console as opposed to keystrokes. I don't think it makes any difference.

(Posted by Ron Rollo on 08-09-15)

Anyone ever experience a couple PoKeys pins seemingly going bad? I just spent a few hours tracing a couple "bad" buttons on RMU #2 back to the PoKeys pins #15, #17 and #19. I swapped the pins for ones that are not in use like the TST and 1/2 buttons. So I was wondering if anyone else has seen this before, PoKeys pins going bad and becoming dead?

UPDATE:

I found the issue. I could not initially get Mark's RMU Utility "No Gear" version to work so I was using his version with the gear pins. His "Gear" version uses pins #14 thru #19. This explains a lot because I was having other issues when I would raise the gear, RMU 2 would go a little nuts and freeze up. When I lowered the gear it would clear up. In addition to that, the encoders for my VSPD and CRS2 were also using those same pins numbers on my second PoKeys card. Guess what, they were also going haywire. In a perfect world you would think that what happens on one PoKeys card stays on that PoKeys card and the same for the other. Apparently not in our sim world.

SOLUTION:

Option #1 Do not use pins #14 thru #19 with Mark's "Gear" version. DO NOT plug any wires into these six pins on the PoKeys card using the RMU Utility unless those wires are for the gear indicator LEDs.

Option #2 Use Mark's "No Gear" version of the software. If you use the "No Gear" version, you can use pins #14 thru #19 for any function on either of your RMUs. Initially I was having a hard time running the "No Gear" version and I had to overt back to his "Gear" version. Now I am back to using his "No Gear Version.

For more information on Mark's RMU Utilities click HERE

One last tip! In case your not aware, your two RMUs will take up almost every pin on one single PoKeys56U card. Do not attempt to plug anything else into that one PoKeys card except the wires coming from your two RMUs (unless you are going to use the Gear version for the LEDs) or you will have a whole new set of issues that you can write about here in the hangar!

One last point for the new guys! If your planning to use a FDS SYS card to handle all your LED lighting in your AML switches, (HIGHLY RECOMMENDED) you will want to also have your gear annunciation lighting plugged into the FDS SYS card. If for no other reason so that when you do a lights test, your gear annunciation lighting will also be part of that test. In case your wondering, Mark added this small piece of software to the RMU Utility because he was not planning on having a FDS SYS card which handles the gear annunciation logic. And what that means is in both his software and in the FDS SYS InterfaceIT software, the gear annunciation lighting has delays as the gear is coming up and the lights even stagger replicating lag between each of the gear doors closing independently of each other. A really neat feature! And now you know. Thanks Mark L. for the RMU Utility software!

If you have any encoder information, comments or questions, please post here. The encoder solution is still a work in progress and there is not a definite path set in stone.

Meta

HANGAR 45 FORUM

Encoder Solutions and Discussion