MichaelMcE
-
Posts
39 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by MichaelMcE
-
-
Are the two developments related? I thought this "Level D" 767 was a new product. Are you saying it is just an FS2004 update an the old FS2000/FS2002 767PIC?
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.
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?It depends what it thinks is running. With Project Magenta it does one thing, with the (original) 767PIC it does another, with default FS another still. For the old 767PIC it sends the keypresses listed as PIC_AP_MASTER and PIC_AP_LEFT (ids 1000, 1001). Currently PFC.DLL recognises the 767PIC by modules "APS", "B767W" and the gauge "B767WAFDS.GAU". I don't know if this new one looks anything like the old one.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.
You can program any of the PFC buttons, knobs and switches in FSUIPC. If you do so it overrides the PFC.DLL default action.
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
-
Hi Michael,
I think you can assign a key press or an FS control to that button using the FSUIPC button page. What you program there will override the settings in PFC.dll. I have programmed all the GPS buttons on the Digital Avionics to operate the FS internal GPS.
HTH
Frank
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
-
Oh, you want to program it? Best to use offset 3110 and send the FSUIPC Traffic Density Control. Recent releases of FSUIPC support FSUIPC controls via this offset as well as FS controls. See the Advanced User's guide for control numbers.
Regards,
Pete
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
-
Is this the Wilco 767 PIC? If so it certainly used to work -- I programmed quite a lot into the PFC DLL for that aircraft. But that was way back, version 1.2/1.3 I think. Perhaps it's changed. I don't touch it any more. The programmers were very uncooperative, even hostile, so I uninstalled it all and stopped developing for it.
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
-
But that's not right. The trim is pre-programmed for all the yokes with the pairs of rockers on each side. When you say "it does nothing" perhaps you aren't noticing the subtle trim adjustments? By default it starts off with very slow adjustment, designed for very good accurate trimmimg. If you hold it down for more than a second (or whatever, adjustable) it speeds up. You can adjust the sensitivity in the Console options page. You can also change things in the INI file to reduce or eliminate the delay if you want it faster straight away.
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.
Ahthat is wrong, indeed. The incorrect codes are doing the damage. It looks like there is some wiring problem, maybe a dry joint, maybe a problem in the little CH decoder board in the base. I'm afraid I can't fix that in software, you'll need to check with PFC.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
-
Ah, NOW I understand! You are confusing the setting to limit the surface wind with the FS2000/FS2002 "Taxi Wind" facility, which was entirely different. That operated by directly changing the wind experienced at the aircraft, without changing the weather, as such. The surface wind you are limiting is the lowest wind layer, i.e. the whole layer.
There is no taxi wind facility in FSUIPC for FS2004 because I couldn't find any way to get to the wind actually imposed. If I could, I would be able to smooth it too! I'd love to do this, but in many many hours or hacking through FS code I haven't managed, and there are other things needing doing.
Please check through the FSUIPC User Guide some time. It does actually mention all these things. You certainly were NOT using the same option in FS2002.
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.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
-
Post it in the Radar Contact forum too. Are you using the latest Beta, or only the current released version of Radar Contact 3? I think there's been quite a few changes.
BTW I thought generally as far as ATIS and METARs are concerned, a 1 knot wind is likely to be regarded as calm.
Pete
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
Major problem with LDS 767 A/T and PFC hardware.
in FSUIPC Support Pete Dowson Modules
Posted
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.