Most of the commonly reported issues and questions are answered in the Frequently Asked Questions (FAQ) option under the Support menu of this website.
*** PLEASE NOTE ***
Your forum account is not the same as the account used in the shop. They are completely separate accounts.
Your forum account is not the same as the account used in the shop. They are completely separate accounts.
1st December: A new version of the GoFlight Interface Tool for MSFS is now available.
12th November: A new version of the GoFlight Interface Tool for X-Plane is now available.
6th June: A new version of Virtual Flight Sim Hardware is now available (huge update)
21st November: A new version of the GoFlight Interface Tool for FSX/FSXSE/P3D is now available.
Inconsistent Behavior with GF Modules
While this post doesn't have anything to do with the GIT, I'm choosing to post here because there isn't much activity in the GoFlight forums and figure if anyone knows, it'll be in this group.
I've been running GoFlight equipment for a long time. I'd estimate my first purchases were back 15 years ago when they were painted black. Over the years I've added modules as money and interest permitted. In terms of Windows OS, this has spanned from Windows 2000, Windows XP, Windows 7 and now Windows 10. Before Windows 10, my modules worked 99.9999 % of the time without a lot of messing about with them. In addition to the OS history, my FS platform history across the span of time has been FSX, P3D v2.x, v3.x and now 4.x. With Windows 10 (and P3D v4.x) the consistency and reliability of the modules working when I want them to work has dropped below the 50% mark.
I recently built a new gaming and flight sim rig. It's my dream build and along with P3D v4.2, I can finally fly without the fear of OOM, CTD's or other hassles. I just completed a long-haul in the PMDG 747-400 from KDEN to EGLL (with add-on scenery on both ends) and this was something I never would have been able to do without a OOM or some other failure.
Anyway, ever since moving to Windows 10, I've had to spend just about as much time messing about getting my GF modules working and functioning with whatever aircraft I am wanting to fly. The major bugbear appears to be with the GF-166's. I have three. Two are the newer grey painted versions and one old black one.
For full disclosure, I'm running the latest GF software (as posted on their website) v2.28.0 and I'm running version 2.747.3.0 of the GIT. I believe this is an older version of the GIT that initially came out just after P3D v4 was released. I've never been successful at getting the newer versions to work correctly. But I really don't think this is the issue. Anyway....
On the new PC, I did select a Motherboard which offered me a few USB 2.0 connections and am running two powered USB 2.0 hubs which are connected to the USB 2.0 ports on the motherboard.
The issue I experience with the GF-166's and also the GF-45 is they'll almost always show up in the GF-Config software. I have a two profiles created. One profile is for my PMDG aircraft which allows for the GF-MCP Pro and the EFIS to be in Compatible Add-on Mode and a second profile for just about everything else. But as I said, the GF-166's and GF-45 will show up in the GF config all. But when I launch P3D, they may or may not function.
Generally I can unplug them, plug them back in and sometimes can make them appear and function. But sometimes despite what I do, they just won't work in the sim. Yet, they'll still show up in the GF Config.
Sorry for the long post, but I wanted to provide enough background. I have a feeling all this boils down to Windows 10. Or perhaps part of it is P3D. But these are the future and I'm not planning on going backwards.
Is anyone else experiencing similar issues? What have you done to try to resolve it?
Thanks for your time.
Jerry
I've been running GoFlight equipment for a long time. I'd estimate my first purchases were back 15 years ago when they were painted black. Over the years I've added modules as money and interest permitted. In terms of Windows OS, this has spanned from Windows 2000, Windows XP, Windows 7 and now Windows 10. Before Windows 10, my modules worked 99.9999 % of the time without a lot of messing about with them. In addition to the OS history, my FS platform history across the span of time has been FSX, P3D v2.x, v3.x and now 4.x. With Windows 10 (and P3D v4.x) the consistency and reliability of the modules working when I want them to work has dropped below the 50% mark.
I recently built a new gaming and flight sim rig. It's my dream build and along with P3D v4.2, I can finally fly without the fear of OOM, CTD's or other hassles. I just completed a long-haul in the PMDG 747-400 from KDEN to EGLL (with add-on scenery on both ends) and this was something I never would have been able to do without a OOM or some other failure.
Anyway, ever since moving to Windows 10, I've had to spend just about as much time messing about getting my GF modules working and functioning with whatever aircraft I am wanting to fly. The major bugbear appears to be with the GF-166's. I have three. Two are the newer grey painted versions and one old black one.
For full disclosure, I'm running the latest GF software (as posted on their website) v2.28.0 and I'm running version 2.747.3.0 of the GIT. I believe this is an older version of the GIT that initially came out just after P3D v4 was released. I've never been successful at getting the newer versions to work correctly. But I really don't think this is the issue. Anyway....
On the new PC, I did select a Motherboard which offered me a few USB 2.0 connections and am running two powered USB 2.0 hubs which are connected to the USB 2.0 ports on the motherboard.
The issue I experience with the GF-166's and also the GF-45 is they'll almost always show up in the GF-Config software. I have a two profiles created. One profile is for my PMDG aircraft which allows for the GF-MCP Pro and the EFIS to be in Compatible Add-on Mode and a second profile for just about everything else. But as I said, the GF-166's and GF-45 will show up in the GF config all. But when I launch P3D, they may or may not function.
Generally I can unplug them, plug them back in and sometimes can make them appear and function. But sometimes despite what I do, they just won't work in the sim. Yet, they'll still show up in the GF Config.
Sorry for the long post, but I wanted to provide enough background. I have a feeling all this boils down to Windows 10. Or perhaps part of it is P3D. But these are the future and I'm not planning on going backwards.
Is anyone else experiencing similar issues? What have you done to try to resolve it?
Thanks for your time.
Jerry
Comments
Those devices and the GF-46 are always problematic. Its nothing to do with Windows 10 as I had the same issues on Vista back in 2008 when I first bought GoFlight gear. They have a habit of locking up (before use, during use or after use)
See https://www.pollypotsoftware.org.uk/vanillaforums/discussion/715/problem-with-duel-gf166s#latest plus lots of other forum posts on the subject.
Some BIOS settings may help:
XHCI Handoff to be Disabled
Legacy Support Enabled
EFI/BIOS support (disable CSM if you have UEFI and/or visa-versa)
But the best results have always come from buying different powered hubs and spreading them around.
I suspect that the devices need a firmware update as I remember the MCP PRO used to be as problematic before the A25 firmware. In fact GoFlights readme implies this fact as it talks about a program for firmware updates which I wonder if it actually got finished (see Motherboard Chipset USB Host Controllers in readme.txt in the GoFlight directory)
Best wishes
Steve
I actually prefer the older GF-166s (have two of the black ones) but like you suggested they can be problematic. I've since updated to the newer GF-166. Which BTW you can now buy via NewEgg for about 20% lower price all the time.
IMHO the issues are the GF drivers ... they haven't been updated for Win10 and they aren't coded to deal with USB 2.0 specification or USB 3.0 specification and ... having to run the Windows8Fixer to get the displays to work in older GF-166s and other older modules shouldn't be necessary if the drivers were coded to take this into account.
To add more complexity to the issue, USB Kernel-Mode ... as you know there has been significant changes/patches at OS core and EFI/BIOS and even CPU microcode to deal with Meltdown and Spectre vulnerabilities which is very much a kernel mode issues ... this has not helped with stability.
Start here for MS docs on writing USB device drivers, it's not trivial and reading thru this document will provide an understanding of the complexity.
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/tutorial--write-your-first-usb-client-driver--kmdf-
and specifically power management states
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-power-management
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/comparing-usb-device-states-to-wdm-device-states
Beagle USB 480 is a very good quality USB 2.0 protocol analyzer, but a little pricey at over $1000 US ... it's probably the best tool to determine why the GF-46's lockup.
In theory USB spec's are supposed to be backwards compatible, but in reality there is always something on the driver side that will need to be updated to deal with new/update USB specifications along with BIOS/EFI modes of operation.
I'm usings USB 3.0 hubs (because they provide more power) and two additional PCIe USB 2.0 cards and have my BIOS/EFI set to force USB 2.0 spec on all motherboard USB ports. I'm at the max for my setup (to avoid power cycling) ... around 47 USB devices (not all GF).
Cheers, Rob.
Same thing with a GF-46 older type. I have a new one that is working fine.
Any suggestion?
Thanks
Best wishes
Steve
Best wishes
Steve
By the way, i think my second 46 is faulty one... will test it on FSX install