Hardware or software problem for FMC programming

[Jean-Claude]

I wonder if I could get some help with the following problem:

When I programme my GoFlight FMC with PMDG keys on FSUIPC (latest version), immediately after this process, my keyboard does not work anymore except for the "esc" key which immediately sends me to the desktop and loses my FS9.cfg file in the process. I could replicate that problem over and over again making my hardware programming impossible.

I suspect that this could be caused by a hardware problem with my USB setup. I am using three USB multi-port cards, each of them individually powered, one with seven ports and two with four ports each. These three USB cards are plugged at the back of my PC on three of the USB ports.

Would it be better or worse to have one USB card with 10 or 12 ports, or to the contrary more of smaller cards? If this is not the likely problem then what could be the next probable culprit?

I use a Dell 8300 3.02, 2Gb RAM, ATI Radeon 9800 128DDR Pro.

Could anyone offer some advice on this item please?

Many thanks for any help.

[Pete Dowson]

When I programme my GoFlight FMC with PMDG keys on FSUIPC (latest version), immediately after this process, my keyboard does not work anymore except for the "esc" key which immediately sends me to the desktop and loses my FS9.cfg file in the process.

Please state what you mean by "FSUIPC (latest version)". I always need actual version numbers. The "latest version" just means the latest one that the user has seen and downloaded -- in some cases this has proven to be many weeks old!

Can you also explain what a GoFlight FMC actually is, please? As far as I'm aware there is no such beast, and FSUIPC will not recognise buttons on it in any case. The GoFlight devices FSUIPC currently recognises are:

GF-45, GF-P8, GF-T8, GF-LGT, GF-166, GF-MCP, GF-RP48, GF-46 and GF-TQ6.

FSUIPC accesses these devices through the Go-Flight module GFDEV.DLL, which handles the USB connections as far as I know. If your keyboard is USB connected too, then possibly you have a corrupted version of that DLL? When you program your GF devices with GF's software do you have similar problems? (They don't use GFdev.dll).

The only other thing I can think of is that you are trying to program a rotary knob on a GF device to produce keystrokes, and your have enabled the "Repeat whilst held" option in FSUIPC. Do NOT do this with rotaries -- half of the time, when you turn a rotary, it will be left with the "button" it is emulating looking "pressed" -- FSUIPC will then generate a continuous stream of results, and this may flood the keyboard input buffer.

The same would apply to latching switches (toggles) -- you never want to program the "repeat" action on any switches which can stay "pressed" or the equivalent.

In version 3.22 of FSUIPC this repeat option is actually too fast -- I am working on a revision now which will regulate the repeat rate to a default of 20 per second, but adjustable in the INI file. However, even then you would not use "repeat whilst pressed" on anything but normal press buttons or spring-centred toggles.

I'll add some notes to the documentation about this too.

Regards,

Pete

[Jean-Claude]

My apologies for the mistatement, last night was extremely short (3 hours) hence my confused mind, there is no GoFlight FMC, but an MCP, my mistake.

. I use FSUIPC version 3.22 downloaded last Friday.

. I do not click on "repeat whilst held" option

. My keyboard is not USB connected

. There is no such problem when using my GF hardware on the GF cfg

I checked this morning with a hardware specialist about my USB setup and he found it adequate. I posted the same message on GoFlight forum hoping to get a reply this afternoon.

Thanks for the help anyway.

Regards.

[Pete Dowson]

. I use FSUIPC version 3.22 downloaded last Friday.

. I do not click on "repeat whilst held" option

. My keyboard is not USB connected

. There is no such problem when using my GF hardware on the GF cfg

Hmmm. Very strange then. I don't know how any USB device can intterfere with another, non-USB device.

I am emailing you my latest interim version of FSUIPC, still under development, as 3.224. Please try this just in case it is related to the over-speed operation of "repeat", which I have now fixed. Let me know.

[LATER]

I just thoughtthe GF MCP also has its own DLL in the FS Modules folder, doesn't it? Can you try the FSUIPC programming method with that DLL removed? Maybe there is some conflict.

Regards,

Pete

[Jean-Claude]

Pete, I could use 30 minutes to quickly check your test version. Here is a status report with PMDG 737-700:

A) With the GF MCP.dll:

1/ No more keyboard problem as soon as I move one knob on my GF MCP, that's good news, this was not the case before

2/ All knobs work fine but do "jump" from time to time

3/ For info, if my memory serves me well, CRS and HDG selectors work without FSUIPC, I would need to double check that, but I believe it is correct

4/ The altitude knob does not seem to accept the fast rotation even though it is correctly programmed and checked thoroughly

5/ The speed knob IS the problem, it can be used for a while normally and suddenly goes full speed and cannot be stopped. When this happens, then all other knobs (HDG, CRS, ALT) become inoperative and the keyboard is stuck for a long while, but this time I could exit FS9 with the task bar without jumping to the desktop and did not lose my cfg file.

B) Without the GF.MCP.dll

1/ Of course there is no more dials visible, but there is no significant change for any knob, same general behaviour as mentioned above, a tendancy to jump or miss numbers even when turning the knobs very slowly

2/ There is also a strange interference between the HDG bug influenced by the speed selector or the CRS knob (not seen above)

3/ The altitude knob remains unchanged, no fast rotation (incidentally, I had to "reactivate" it by going to FSUIPC, the programming had been kept in memory but the selector was not moving the numbers at all). After a while, I could decrease altitude but not increase my selection

4/ The speed knob behaves strangely, this time if you select 250 knots for example, it will slowly decrease, and come back, and decrease again, sometimes interfering with CRS or HDG

5/ The keyboard was also stuck at one time, but more briefly than before and I could again exit normally not losing my FS9.cfg.

It looks like you have your nail on the problem Pete, I hope this helps. Let me know if you need more testing, I had no time to try the buttons yet.

Kind regards

[Pete Dowson]

4/ The altitude knob does not seem to accept the fast rotation even though it is correctly programmed and checked thoroughly

5/ The speed knob IS the problem, it can be used for a while normally and suddenly goes full speed and cannot be stopped. When this happens, then all other knobs (HDG, CRS, ALT) become inoperative and the keyboard is stuck for a long while, but this time I could exit FS9 with the task bar without jumping to the desktop and did not lose my cfg file.

Since FSUIPC cannot tell any difference between one knob and another, all this must be differences in the way the keys are implemented in the aircraft panel code -- unless, that is, there are hardware problems. To eliminate the latter, just try programming the altitude and speed on two other knobs.

As far as FSUIPC programming is concerned, the knob looks like a set of 4 buttons. When you program each of those to send a keystroke, that is exactly what FSUIPC does. It has no idea what the knob is for, nor what the keystroke does. So differences in function, between altitude, speed or whatever, are completely irrelevant to it.

a tendancy to jump or miss numbers even when turning the knobs very slowly

Jumping and missing is a function of the way keyboard queues work I'm afraid. A bit like jams on busy roads. Direct controls, as available for the FS default MCP, are far better and not liable to such problems. All third party panels designed for use only by mouse and keyboard (only) have been prone to this for many years. It is hoped that in future panel designers would realise that folks want to be able to use external hardware and will cater for it (like, for instance Project Magenta).

I do know that PMDG have produced or are producing an SDK to allow this to be done properly, and all I think you can do is press GoFlight to go for this and implement PMDG aircraft support into their drivers.

2/ There is also a strange interference between the HDG bug influenced by the speed selector or the CRS knob (not seen above)

That sounds either like a hardware problem or a problem with the GFDev.DLL. Please report the details to Goflight support.

It looks like you have your nail on the problem Pete

Well, the only problem I've fixed is one where FSUIPC would scan the buttons too often and send too many controls or keypresses to FS. Now it is regulated. Possibly, in view of your queueing problems, it isn't regulated enough -- you can adjust the rate by adding "ButtonRepeat=n" to the main [buttons] section, where n is 1-100 for that number of 'repeats' per second. The default is 20, and I doubt if much faster would be wise, but you could experiment in both directions. If you set it to 0 then the regulator will be disabled and it will be as before.

I'm afraid I don't think FSUIPC can be held responsible for any of the other irregularities. Some look like the typical bad results of relying on keyboard inputs to alter things at any speed. The cross-interference and Windows hangs, and weird wrong direction changes, sound more likely due to the panel software itself.

Maybe you can try programming them for FS's normal A/P, though I know it isn't necessary as GF does that in any case. Try programming using FS Controls first, just to see how smooth and good that is (especially if you use the new "Fast" variants I've added too), then try the same with FS's normal keyboard shortcuts. See the difference? Like chalk and cheese. But, still, though there be jumps and stalls, there should be no odd reversals nor cross-interference.

Regards,

Pete