FSUIPC button -> keypress problem, please Help!

[teropa]

Hi,

Please check this thread I posted at Avsim about the problem.

http://forums.avsim.com/dcboard.php?az=6524&page=

Thanks for the help!

regards

Tero

[Pete Dowson]

Please check this thread I posted at Avsim about the problem.

If this is addressed to me, please state your problem here. I do not have time to go chasing threads is other fora.

Thank you.

Pete Dowson

[teropa]

Well Pete,

It's a problem that might be related to FSUIPC, so I guess it is related to you.

"Hi,

Recently I've discovered a problem that I didn't have before.

I have programmed four buttons in my CH yoke to send keypresses in FS through FSUIPC: a/t disconnect, a/p disconnect (PIC767), RW push to talk key (scroll lock) and a "throttle cut" parameter to enable reverser functionality in PIC767.

The problem. The keypresses experience a serious LAG for some reason. Many times when I press the buttons, nothing happens. Sometimes after a delay, and very rarely immediately as it's supposed to work. This is so weird because I never had this problem before. Some people over at PIC forum have complained about the same thing, and no one knows what to do ? It's seriously annoying when the button -> keypress thing "misses" all the time, especially when using the PTT to talk on RW and when disconnecting the automatics on approach in PIC.

Also, I run FS in windowed mode, since I have 3 monitors (and have PIC's different panels undocked in them), that I need to access with the mouse. (could this have effect?)

Any help much appreciated!"

Tero

[Guest MB327]

Same problem as defined by Tero. Sometimes they work, sometimes they don't.

Mike Bevington

[Pete Dowson]

The problem. The keypresses experience a serious LAG for some reason. Many times when I press the buttons, nothing happens. Sometimes after a delay, and very rarely immediately as it's supposed to work. This is so weird because I never had this problem before. Some people over at PIC forum have complained about the same thing, and no one knows what to do ?

This is only with the PIC767? If so then I think the most likely cause is the PIC 767 software clobbering the message queue -- it has a nasty habit of getting into some weird state where is is sending many Windows messages continuously, every second. This fills up message queues and causes other problems. I don't know *why* it does this, and it doesn't do it all the time. It's very inefficient in this way.

All FSUIPC is doing with your pre-programmed buttons is sending the related keypress, as a message (or a sequence of messages -- keydowns and keyups, as needed). It does this as soon as it sees the button press.

Alternatively, or, indeed, as well, given this statement:

Also, I run FS in windowed mode, since I have 3 monitors (and have PIC's different panels undocked in them), that I need to access with the mouse. (could this have effect?)

It is possible that the system is rather overloaded and the detection of the buttons being pressed is lagging, or even being missed. The button actually has to be held down during one of the scans for the change up-down or down-up to be noticed. The joystick drivers don't actually queue these things.

I can only think of a couple of things you could try:

1. Limit the FS frame rate at something below your normally observed rate, so that FS itself spares more time for other things. For instance, on a 2GHz PC I would suggest something like 25fps or 20fps. Lower on lesser PCs, not much higher on faster ones. Experiment with that. It's in the FS Options-Settings-Display-Hardware dialogue.

2. Try making FSUIPC poll the buttons more frequently. This is done by a parameter "PollInterval" in the [buttons] section of FSUIPC.INI. the default is 55 mSecs which gives about 18 tests per second. Read the section "Button Programming" in the Advanced Users Guide.

I'm not saying either of these will "fix" the problem, but they're the only things I can think of which stand a chance, short of getting the 767PIC software problems fixed.

Regards,

Pete

[Guest]

Hello Pete,

I have the same problem. It looks to me that it mainly/only? occurs when still on the ground waiting at the gate. When airborne the PTT switch on my CH Yoke is working fine again...

I run my PIC 767 panel instruments at the highest update rate, and the sim windowed at max 25fps (2.4Ghz machine with 512 Mb RDRAM, windows XP Home)

Regards,

Nico

http://www.nicokaan.nl/

[Pete Dowson]

I have the same problem. It looks to me that it mainly/only? occurs when still on the ground waiting at the gate. When airborne the PTT switch on my CH Yoke is working fine again...

I run my PIC 767 panel instruments at the highest update rate, and the sim windowed at max 25fps (2.4Ghz machine with 512 Mb RDRAM, windows XP Home)

Hmmm .. weird. But it still must be down to the way the 767 software works. If my suggestions above have no effect then I've really no idea. I don't suppose the 767PIC authors are fixing things any more.

Regards,

Pete

[Guest MB327]

Pete,

Thanks for the responses. I will experiment with your suggestions and also check the button performance in a couple of different aircraft in the same situation.

Mike Bevington

[teropa]

Pete,

Changing the PollInterval to a lower value (in my case 30) worked!!

Perfect.

There was no such entry in the ini by default, so I guess the default value is somewhere hard coded ? Or should there have been the "PollInterval=55" there anyway ?

Anyhow.. thanks for the help, all systems are go once again!

regards

Tero

[Pete Dowson]

Changing the PollInterval to a lower value (in my case 30) worked!!

Perfect.

Good.

There was no such entry in the ini by default, so I guess the default value is somewhere hard coded ? Or should there have been the "PollInterval=55" there anyway ?

None of the entries in the Joystick Button programming section are generated by default. Anyway, the PollInterval thing is a bit technical and has the potential for wrecking FS performance if taken to extremes -- I didn't really want folks playing with it without good reason.

To be honest, I never thought that some bug in some panel programming would make a change in this parameter necessary. It was really aimed at EPIC users who have to be pretty technically minded in any case!

Regards,

Pete

[Guest]

Changing the PollInterval to a 30 has a positive effect. There is still about a 1 in 5 failure rate when in dense scenery airport areas, a touch better when on the ground at default airports. That is much better than I had before.

Thanks for the tip Pete,

Mike Bevington

[wahltho]

Thx a lot Pete,

the reduction of the PollIntervall value solved the problem that the A/P disconnect button of my PFC Jetliner Yoke was not being recognized by the PIC767.

Nevertheless I have another problem with 3rd party hardware and the PIC767.

I own the Flighboard 2000 USB from ITRA. This is a device which has a lot of soft-buttons and emulates keystrokes once you press one of the buttons.

I can assign all of the PIC767 A/P controls to these buttions (lik VS+/VS-), meaning the push of the buttons on the FB2000 is being recognized correctlya within the PIC767 control assignent menu.

But afterwards, when flying the PIC these buttons do not work. I guess it is the same problem, the PIC767 flooding the Windows message queue.

Would it be possible to have something like the PollIntervall for buttons also for keys or do you have any other ideas whow to solve this problem.

[Pete Dowson]

Would it be possible to have something like the PollIntervall for buttons also for keys or do you have any other ideas whow to solve this problem.

FSUIPC isn't "polling" keys so it cannot implement a shorter interval to do it in. Keyboard events are dealt with by the Windows keyboard system which generates Windows messages like WM_KEYDOWN, WM_KEYUP and WM_CHAR. These are processed by FS directly, unless intercepted by FSUIPC when set as Hot Keys or programmed in the Keys page. But even if FSUIPC is converting keystrokes to FS controls (which isn't applicable here in any case) it cannot do this "faster" than the keystrokes are arriving!

So, sorry, there's no way at all to do it with that cockpit. The 767PIC programmers did produce a direct programming DLL for use with their gauges, licensed to folks such as Aerosoft (for their MCP). I don't know if they'd be willing to let you have that, or sell it to you, but that is the only way you'd get to beat its crazy continuous control sending. It would mean you programming your own interface, as Aerosoft did.

You might consider moving on to PMDG cockpits. I understand they will be producing an SDK for those who want to interface equipment to them, though I have no details nor timescale yet. And, again, it probably won't be free.

Regards,

Pete