MichaelMcE

The normal way is to park the throttles at max or min. If you've calibrated with reliable dead zones both ends this will prevent any inputs from them. I usually leave them at max on climb, then bring them back to idle before descent. Hello Pete, Allow me to jump in here. What follows is a post to the Level D forum by Bob Scott regarding the conflict between the Level D autopilot and PFC h/w. In following his recommendation, I have been able to successfully fly so long as I keep the throttles full open or full close. Occassionally, the Level D autopilot will detect a discrepancy based on the PFC throttle setting - this usually occurs when my throttles are at idle and the Level D autopilot has set idle thrust (such as in a descent). The conflict will occur when the Level D autopilot adds power during level off at a lower altitude. Pete, in reading through Bob's post, you will note that he is suggesting a similar solution as the one your propose: have the PFC throttle inputs disabled when the Level D autothrottle is enabled. As I mentioned in the thread regarding autopilot disengage, I would be glad to do the research to get the information you need if in fact PFC.dll can be modified to provide inherent support to Level D. I hope this helps and as always - thanks. -michael ___________________________________________ Post by Bob Scott: ___________________________________________ Make sure that the "Suppress possible interference from GamePort throttle assignments" option on the main tab of the PFC driver page is ***NOT*** checked. That option was put there specifically for PIC767 in FS2000/2002, because the method by which the PIC (and presumably LDS as well) panel's A/T controls the power is via the same mechanism as the regular joystick input. Selecting that option kills the A/T inputs to FS. Second, I've found that if I firewall the throttle either full up or full idle, the A/T is less prone to jumping around. It appears that any time the PFC throttle input value changes, the throttle input to FS is set to the PFC throttle value until the LDS A/T resets it to where the A/T wants it. The net result is seeing the throttle target bouncing back and forth and jerky rapid changes in the power setting. If you leave some headroom in your throttle calibration, so that the last 1/2 inch or so of travel does not change the throttle input value, then it will prevent the PFC throttle values from drifting and causing these spurious power excursions. I believe that something still needs to be done to disable the PFC throttle input while the LDS autothrottle is active. When the power is advanced for takeoff, it ratchets its way up, giving the definite appearance that the A/T and the PFC control are fighting each other. That could be accomplished by either programming the appropriate FSUIPC calls into the panel to disconnect the PFC axes during A/T operation, or by PFC, FSUIPC, or a utility program if a means is provided to ascertain if the LDS A/T is engaged.

Level D 767 is a new product. As to the relationship to the 767PIC, the development team is the same (plus a few additions). However, I do not know how much - if any - of the old code base has been reused. I doubt that they developed it entirely from scratch. Ok, it is starting to make sense. Level D definitely does not have or use APS (there were explicit instructions to make sure that it was removed from any prior installation of 767PIC). I would suspect that PFC.dll is therefore sending keypresses not recognized by Level D. Ok! Level D does have keypresses that equate to PIC_AP_MASTER and PIC_AP_Left. I'll try that tonight and see how it goes. Pete, if there is the possibility of modifying PFC.dll for inherent support of Level D I would be glad to research the "signature" components that would allow PFC.dll to recognize the existence of Level D. Thanks. -michael

Oops my apologies. I had originally stated that I tried your suggestion and it did not work. What I actually tried was assigning the PFC button directly to a Level D custom control - and that did not work. I will try your suggestion later tonight - Pete has suggested that same approach. Thanks.

Hello Pete, I've acquired the Level D 767 package and unfortunately, the autopilot disengage button on my PFC Jet Yoke is having no effect on the autopilot CMD state. When depressed, there is an audible alarm that sounds, but the Level D 767 autopilot remains in whatever state it was in before the button was depressed. With PIC767, depressing the autopilot disengage would toggle the autopilot CMD state on/off. I suspect something has changed between the implementation of PIC767 and Level D 767 in this regard. My question is this: the PFC.dll user interface prevents the user from changing the key command sent when the autopilot disengage button is pressed. Would you please tell me what command is being sent when that button is pressed? This will allow me to follow-up with the folks at Level D. Also - is this something that you could unlock - allowing the user the option to specify the key command to be sent when the autopilot disengage button on the jet yoke is depressed? Thanks. -michael

Excellent! Thanks for the pointer and quick turn-around. -michael

Hello Peter, I use your FSUIPC hot-key feature to toggle AI on/off. I would like to have the opportunity to also modify the AI traffic % without having to stop the sim. I was unable to find anything in the programmers SDK about such a capability. Do you know if such a capability exists? Thanks. -michael

Yes, 767PIC. Also I'm flying it in FS9 so - who knows! ;-) I for one do appreciate all you've done to make this aircraft and h/w such as the PFC stuff work as well as it does! Tomorrow is my birthday and I've taken the day off to sit back and enjoy the things I enjoy doing! I will play around with it some more as I hope that I'm missing something in a setting somewhere. Have a great vacation! -michael

Peter, It seems that this is yet another PIC anomoly. With electric trim programmed in my yoke there is no response to trim adjustments when using the PIC panel. With default a/c it works just fine. If I assign the FS trim up/down to my yoke it works with the PIC panel. -michael

Hmmm, perhaps I did not pay sharp enough attention to the movement of the trim indicator on the panel. I will certainly try this again this evening. I have contacted PFC and am awaiting their response. Thanks for confirming that it is not a s/w issue. -michael

Peter, I am using the Pfc Jetliner Yoke with the digital throttle quad through the COM port interface. I checked FSUIPC and there are no keys or buttons programmed. I tried using the default configuration of the PFC driver for yoke buttons but the electric trim preset must only work with PFC console h/w - it does nothing in my setup. So - I reprogrammed the yoke so that the left:left rocker top is FS Trim Down; left:left rocker bottom is FS Trim Up. The left:right rocker top is FS Panel 4 and the left:right rocker bottom is FS Panel 5. I then went to the test screen and this is what happened ... D0 TrimDown = Pressed C0 TrimDown = Released D0 TrimDown = Pressed C0 TrimDown = Released D0 TrimDown = Pressed 9B 0A CHcontrl = 0A JetLiner Yoke: Left: right rocker top C0 TrimDown = Released 9B 0F CHcontrl = 0F JetLiner Yoke: Release D0 TrimDown = Pressed C0 TrimDown = Released D0 TrimDown = Pressed 9B 0C CHcontrl = 0C JetLiner Yoke: Left: right rocker bottom C0 TrimDown = Released 9B 0F CHcontrl = 0F JetLiner Yoke: Release D0 TrimDown = Pressed C0 TrimDown = Released D0 TrimDown = Pressed C0 TrimDown = Released D0 TrimDown = Pressed C0 TrimDown = Released Notice that I got both a 9B 0C 9B 0F and a 9B 0A 9B 0F sequence just from pressing and releasing the left:left top rocker. At no time during the test did I depress the left:right rocker top/bottom. Any ideas? -michael

Peter, I'm using the PFC Jetliner Yoke and have programmed the left outer rocker to adjust trim (top rocker is trim down, bottom rocker is trim up). I have programmed the left inner rocker to toggle the overhead panel and throttle quad (top rocker is overhead, bottom rocker is throttle). The trim rockers have a repeat of 20. The panel rockers are set to toggle - Press once to get the panel to display and press again to remove it. The problem I am experiencing is that when I press the trim rocker I get an uncommanded request for a panel to display. That is, if I apply trim up I get the throttle quad panel or if I apply trim down I get the overhead panel to display. It is not consistent in behavior but does occurs very frequently. I am using the pre-defined FS mappings for Trim Up, Trim Down, Panel 4 and Panel 5 (as opposed to explicitly setting keystrokes). Is there some reason why when pressing the left rocker I get both a trim response and occasionally also get a panel to display? Thanks. -michael

Well, two points there: (1) The option doing that in FS2002 was the Taxi Wind facility. You are not using the option you used in FS2002. You are limiting the surface wind layer's speed actually being set. (2) Because the wind being set IS limited to 1 knot, that IS the wind, there is no other, so that is what ATIS correctly reports. Regards, Pete Peter, Yes, you are correct. I confused the two very different capabilities. And I must admit - I switched from FS2k2 with AS1 to FS2004 and AS2004 overnight - never took the time to read up on the FSUIPC differences. Thanks for the clarification! -michael

Peter, I will post this to the RC Beta Group as I'm running with RC4 Beta. In regards to the 1 knot being reported as calm - yes that is correct. The question is why is ATIS affected? This did not happen in FS2K2 with the FSUIPC limit surface wind option enabled (I flew in that mode by default). ATIS always reported the actual wind conditions and through FSUIPC "magic" :-) the effects were gradually dialed in and out for takeoff and landing. Many of us enabled the FSUIPC max surface wind option to alleviate the extreme weather-vaning of aircraft in FS2k2. I had been flying with the option off and just recently enabled it - only to find that ATIS is then not reported accurately. -michael

I enabled the limit surface wind option in AS2004 and set the upper limit to 1 knot. This results in Radar Contact ATIS reporting winds as calm regardless of the actual wind conditions and gusts are not reported at all. If I enable max surface wind in FSUIPC with the wind limit set to 1 the Radar Contact ATIS reports winds as 0 knots and reports the gust as the difference in Actual Wind Gust and Steady Wind Speed. Setting the max surface wind option in FSUIPC w/AS1 and FS2k2 did not result in the wrong ATIS report - and of course, there was no such feature in AS1 as there is in AS2004. I am cross-posting this in the AS2004 forum. -michael