Major problem with LDS 767 A/T and PFC hardware.

[B777ER]

Pete,

The LDS 767 was just released. Many of us that use the PFC throttle quad's cannot get the A/T to work on the plane. Please see this thread over at the 767 forum with particular attention to Bob Scott's post. Any help from you would be great as none of us can use the autothrottle!

http://www.leveldsim.com/forums/forum_pD=311&PN=1

[Pete Dowson]

The LDS 767 was just released. Many of us that use the PFC throttle quad's cannot get the A/T to work on the plane. Please see this thread over at the 767 forum with particular attention to Bob Scott's post. Any help from you would be great as none of us can use the autothrottle!

Sorry, I am really very very busy at present and cannot go chasing threads. If folks want help with anything they'll need to provide details here.

Regards,

Pete

[Rich@KMIA]

Hi Pete,

The problem us PFC users are having with this plane is that the A/T always disconnects even when the levers are not being touched. I figured this problem was coming from the quadrant when I noticed that I had to bring the levers to a dead zone in order for the A/T to work properly... Like let’s say if I move my levers half way the input values should read 50/50 in the PFC menu. What happens is that they don’t stay at 50/50 even when I'm not touching them. They constantly move up and down by -/+ 2 digits causing the A/T to think I'm trying to manually apply throttle.

To any PFC quadrant/LDS 767 owners having this same problem you must find a sweet spot for each throttle where your input values don’t constantly change. A slight change in the throttle input value will not allow the A/T to fully work on this plane. I personally have to bring my levers all the way down before the A/T can actually work properly because this is where my input values constantly stay put.

The creators at Level-D included a feature for A/T to inhibit any manual throttle input but it doesn't seem to work with PFC quadrants. Your help would be greatly appreciated Pete.

Regards,

Rich Rodriguez

[Pete Dowson]

To any PFC quadrant/LDS 767 owners having this same problem you must find a sweet spot for each throttle where your input values don’t constantly change.

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.

A slight change in the throttle input value will not allow the A/T to fully work on this plane. I personally have to bring my levers all the way down before the A/T can actually work properly because this is where my input values constantly stay put.

You really should not be getting so much jitter in the hardware. PFC.DLL is only obeying the signals it is receiving. There are some filters available in the PFC DLL which you can enable and maybe adjust to help. Check "Apply digital filtering" in the Main options page, and take a look at the "AxisSmoothTime" parameter, described near the end of the documentation.

Are you enabling the A/T via PFC controls too? Or, alternatively, does this aircraft's auto-throttle operate the FS default auto-throttle switch? If either of these are true I could provide an option to disconnect the PFC throttles when A/T is enabled and re-connect them afterwards.

If I cannot even detect when the A/T is enabled then I wouldn't be able to do anything automatically. I could instead maybe provide an FSUIPC-programmable button to disconnect them.

Please monitor these locations (FSUIPC's Logging page, right-hand side):

310A type U8

07DC type U32

07E4 type U32

0810 type U32

If you check the "AdvDisplay" option, below, the 4 values will show in real time on the FS screen. Let me know what happens when you engage autothrottle and disengage it. Try both Airspeed and Mach hold.

Regards,

Pete

[MichaelMcE]

To any PFC quadrant/LDS 767 owners having this same problem you must find a sweet spot for each throttle where your input values don’t constantly change.

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.

A slight change in the throttle input value will not allow the A/T to fully work on this plane. I personally have to bring my levers all the way down before the A/T can actually work properly because this is where my input values constantly stay put.

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.

[Pete Dowson]

The critical part is:

... if a means is provided to ascertain if the LDS A/T is engaged.

You tell me how I can detect that, and the throttle disconnection is easy.

Check that monitored locations for me first. Then I'm stuck. If the modes are entirely contained in the aircraft's own code then the only thing I can think of is to have another programmable button to specifically disconnect or reconnect the throttles.

Regards,

Pete

[MichaelMcE]

The critical part is:

... if a means is provided to ascertain if the LDS A/T is engaged.

You tell me how I can detect that, and the throttle disconnection is easy.

Check that monitored locations for me first. Then I'm stuck. If the modes are entirely contained in the aircraft's own code then the only thing I can think of is to have another programmable button to specifically disconnect or reconnect the throttles.

Regards,

Pete

I'll check into it and get back to you - thanks.

-michael

[MichaelMcE]

Please monitor these locations (FSUIPC's Logging page, right-hand side):

310A type U8

07DC type U32

07E4 type U32

0810 type U32

If you check the "AdvDisplay" option, below, the 4 values will show in real time on the FS screen. Let me know what happens when you engage autothrottle and disengage it. Try both Airspeed and Mach hold.

Regards,

Pete

Pete,

Unfortunately, there were no change in any of the monitored locations. It seems LVLD is manipulating values internally. They have provided an SDK to access such variables - sounds like a project for one of us to tackle.

Thanks for your help!

-michael

[Pete Dowson]

Unfortunately, there were no change in any of the monitored locations. It seems LVLD is manipulating values internally. They have provided an SDK to access such variables - sounds like a project for one of us to tackle.

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically.

Regards

Pete

[MichaelMcE]

Unfortunately, there were no change in any of the monitored locations. It seems LVLD is manipulating values internally. They have provided an SDK to access such variables - sounds like a project for one of us to tackle.

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically.

Regards

Pete

Thanks Pete - your assistance is very much appreciated. I'll get on with it and see what materializes.

-michael

[airforce2]

Hi Pete;

The LDS team released an SDK with the 767 add-on which gives access to a variety of extern variables, including one with the A/T state (via an IPC DLL they provide for their panel). If you don't have it already, hopefully a member of their team will provide it to you shortly.

Cheers

[Pete Dowson]

The LDS team released an SDK with the 767 add-on which gives access to a variety of extern variables, including one with the A/T state (via an IPC DLL they provide for their panel). If you don't have it already, hopefully a member of their team will provide it to you shortly.

That is doubtful given our past history.

Pete

[MichaelMcE]

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically.

Regards

Pete

Pete,

FYI: Good news and not so good news. Using the LDS 767 SDK I developed a routine to determine the autothrottle state and then ENABLE/DISABLE manual throttle input as appropriate using the THROTTLES_ON and THROTTLES_OFF custom controls in FSUIPC 3.47.

Unfortunately, those custom controls are also disabling the LDS 767 autothrottle inputs! I would not have suspected such to occur.

Will continue to investigate ...

-michael

[Pete Dowson]

Using the LDS 767 SDK I developed a routine to determine the autothrottle state and then ENABLE/DISABLE manual throttle input as appropriate using the THROTTLES_ON and THROTTLES_OFF custom controls in FSUIPC 3.47.

Unfortunately, those custom controls are also disabling the LDS 767 autothrottle inputs! I would not have suspected such to occur.

Ouch. I seem to recall that this was a problem with the earlier Wilco 767PIC. Isn't that why we can't use the "suppress possible interference from Game Port throttle assignments" option on these aircraft?

In that case, instead of using the FSUIPC throttle disconnection option, you might try disconnecting the PFC throttles only. If you check the PFC DLL User Guide, you'll find a section entitled

Application program axis handling

You'll see that you can disconnect selected PFC axes by setting bits in FSUIPC offset 3BC8. You can either set and clear these bits direct from a program, or do it by programming a button in FSUIPC and using the Offset Word controls to set, clear or toggle bits.

Let me know if you can't figure this out and I'll go through it in more detail. You'd need to be clear which PFC axes you have throttle inputs on.

If you can give me information on how to detect A/T engaged state in the LDS 767 I can look into doing this automatically in the PFC driver, but it will now have to await my return from holiday, first week in April.

Maybe you still need to retain the action of A/T disconnection on significant throttle movement? Isn't that what they are really trying to emulate? It seems that they really have a bit of a bug in allowing minor fluttering to disengage the speed modes. I could do that.

Let me know please.

Regards,

Pete

[MichaelMcE]

In that case, instead of using the FSUIPC throttle disconnection option, you might try disconnecting the PFC throttles only. If you check the PFC DLL User Guide, you'll find a section entitled

Application program axis handling

You'll see that you can disconnect selected PFC axes by setting bits in FSUIPC offset 3BC8. You can either set and clear these bits direct from a program, or do it by programming a button in FSUIPC and using the Offset Word controls to set, clear or toggle bits.

Once again, I never thought to look! Ok - will take a look.

If you can give me information on how to detect A/T engaged state in the LDS 767 I can look into doing this automatically in the PFC driver, but it will now have to await my return from holiday, first week in April.

Basically, via the dll provided by LVLD, you provide a pointer to a STRUCT that is populated with all internal state information.

Perhaps I should just request permission from LDS to allow me to provide you with the SDK??? (I'm aware of the past issues ...)

Maybe you still need to retain the action of A/T disconnection on significant throttle movement? Isn't that what they are really trying to emulate? It seems that they really have a bit of a bug in allowing minor fluttering to disengage the speed modes. I could do that.

Honestly, in my experience to-date with the LDS767 I have no problems with minor throttle movements/control jitter and the a/t.

The significant problem occurs on takeoff after manually positioning the throttles at ~70%N1 and then engaging THR/N1 on the MCP. There is a short period during which the two seem to fit each other, and then it settles out.

I actually complicate this because I routinely practice manually advancing the throttles to the full open position while the a/t takes over (which I believe is also the case for real world ops: although the throttles are motorized the pilot does keep his hands on them while they are automatically positioned!)

I would say this boils down to having a solution that is more eloquent than the current work-around.

Perhaps others do have jitter issues.

-michael

[Pete Dowson]

Basically, via the dll provided by LVLD, you provide a pointer to a STRUCT that is populated with all internal state information.

Aha. Similar to their (eventual) solution for the 767PIC, then. I by-passed that because it would have meant packaging the DLL with my programs, and I don't want to get into any of that. In the 767PIC the DLL only sent messages to the FS-installed parts to get the data.

In this new case, is the DLL a standard part of the aircraft install, or do applications using it have to supply it or get the user to obtain the SDK also?

Perhaps I should just request permission from LDS to allow me to provide you with the SDK???

Well, there would be problems testing without the aircraft in any case. If you have code that does the job already I can plug it in and let you test it? :lol:

But I don't want to supply their DLL.

Honestly, in my experience to-date with the LDS767 I have no problems with minor throttle movements/control jitter and the a/t.

Seems that some must have more jitter than is tolerated, then, as I thought that was the problem originally reported.

The significant problem occurs on takeoff after manually positioning the throttles at ~70%N1 and then engaging THR/N1 on the MCP. There is a short period during which the two seem to fit each other, and then it settles out.

Getting your input values matching what their code wants would be a problem. I don't think that's going to be solvable even with an SDK, except maybe by disconnecting throttles altogether, which removes the possibility of auto-disconnect again.

I actually complicate this because I routinely practice manually advancing the throttles to the full open position while the a/t takes over (which I believe is also the case for real world ops: although the throttles are motorized the pilot does keep his hands on them while they are automatically positioned!)

Yes, of course. I do the same. But Project Magenta doesn't seem to mind. :wink:

Regards,

Pete