A few days ago, another flight instrument panel (FIP) of mine suddenly stopped working. Didn’t have any symptom similar to the other faulty one I reported in my Post 561, this one just ceased to work — no display, no response — during a flight session.
After trying many possible solutions to revive it but of no avil, I had no choice but to unplug it from the hub and put it aside waiting for another teardown.
Nothing lasts forever in reality, I know. This one has also served me for more than 10 years.
I was planning to tear it down this morning. But out of “a shot in the dark” mentality, I re-plugged it into a USB hub one last time.
Unbelievable! The device really came back to life and worked normally again!
Not sure what had happened to the device in the last few days — perhaps it needed a respite from an accidental choke?
Anyway, it lives again and it gives me a second chance as well.
Although I am not a Christian, I tend to believe it’s a kinda miracle during these Easter days.
Like the old saying goes: every cloud has a silver lining. Our tough time should be gone soon.
Stay Safe, My Friends
FS Times 
For me, it was a July 4th miracle…. one of my 10+ year old FIP, went MIA. The long weekend gave me the time, and the post 561 as well as this one was giving me some guidance. However, before taking it apart, I moved it over from it’s usual home on my Win 7 “P3D support PC” with SPAD.next, etc. to my “main” P3D Win 10 machine. I tried doing troubleshooting including loading the Saitek driver so Win 10 could recognize the FIP. . The FIP was recognized, but not much more. Further troubleshooting noted that the FIP had been disabled (explaining that sometimes a device disables itself [as you say, “accidental choke.”). I clicked on the “enable” option, it’s been fine ever since. II did move it back to the Win 7 “P3D support” PC, and removed the Saitek drivers from the Win 10 machine. Tom, with your “Easter miracle” FIP, did you somehow do something that caused it to re-enable itself?
Somehow I feel it’s time to indeed “question such good fortune” since FIPs are not cheap, there isn’t a newer model,
We all have experienced FIP lock-ups/disconnects, but what is this “disabling itself” all about? …and is there a way to re-enable a FIP without going through all the Win 10 device advanced troubleshooting steps? Is the disable-check/forced “enable” logic part of the Saitek [Win10] driver’s troubleshooting?
LikeLike
Hi Jim,
Not quite sure what you meant by the FIP was disabled. Was it just the one you were testing or all of them? How did you re-enable it ?
Tom
LikeLike
It was just the one that went dark and unresponsive. When I put it on a Win 10 PC, I had to load the Saitek drivers for it to be recognized by the device manager. After being recognized, I selected it in device manager and did the troubleshooting steps. It was the troubleshooter that detected it had been disabled, and allowed me to enable it.
And it’s been fine since, and even continued to work after moving back to it’s former Win 7 PC. So that means “disable” it’s not related to the PC’s registry, it’s not related to a USB hub, it’s not related to SPAD.next (eventhough SPAD.next is on both the main Win 10 and the auxiliary Win 7 PC. It is therefore in the FIP’s internal firmware. I don’t know if the Win 10 device manager’s troubleshooting steps are from the driver. Obviously, the disable state detection as well as the enabling logic is in the driver. This looks like a job for SPAD.next’s Ulrich Strauss to possibly add it to his FIP driver if he’s not already doing so. [Kudos to Ulrich for doing a great job in continuing to tame FIP hiccups.]
—
In trying to understand the “miracle” mystery, I’m trying to piece together some of the clues…
I can understand if FIPs have a self-defense “shut down” or disabling mechanism. Think of hardware abnormalities [e.g. overheating, power spikes, etc.] or if the firmware abnormalities [e.g. a memory glitch, bug in the firmware, etc.] Apparently this “disabling” aka “accidental choke” is very very rare [else the forums would be “lit up” with complaints]. Also there’s the fact that in the early days sending the FIP back for repair was very do-able. (Come to think of it, I did have to send one of mine back almost 10 years ago, for the same unresponsive condition. [It was replaced at no charge.])
Consider that device drivers have also advanced and been updated, not only to handle Windows changes (think the 64-bit Windows, as well as Windows 10 requirements), but also to correct logic and timing issues in the driver itself. [Windows needing more and more memory which also give the drivers more room to add fixes and features.]
The better driver support also allowed FIP gauge developers to keep adding features that add processing demands on the FIP. [Thank you Tom, for your part in making the gauges look and feel realistic, as well as doing “combo” functionality so we don’t need as many FIPs.]
After understanding more about the “re-enabling” process, the next task is trying to avoid the disabling. [Like flying, itself, it seems building a better flight simulator is also a journey with many lessons to be learned.]
LikeLike
I see. I never encounter such “disable” issue before. All I got was an unrecognized USB device message from Windows.
It is still a good thing as least you can enable it again.
Probably you can install the Logitech driver on you Win 7 PC to enable the device. Then uninstall the driver to allow it to run with spadnext.
Or you may use my FIP_Driver_Toggler to turn off the Logitech driver, just in case you’ll need it to reenable the device again in the future.
Tom
LikeLike
It might also need Win10’s device troubleshooter in conjunction with the driver. I don’t know. [And remember, Win 7 is no longer supported.]
I still don’t know how to “reproduce” the disable, as It happened during a “normal” flight (although I use Active Sky’s live weather).
Time to pass this issue off to the experts. I’m hoping SPAD.next’s next version will incorporate the “reset disable” command. [I’ve passed on my findings to SPAD,next.]
LikeLike
Right. Let us know if any news from spad.next.
Best
LikeLike
Piecing together the issue…. Here’s Ulrich’s reply and my reply to it.
Bottom line: we may just need an initialization tweak to force a FIP out of “high current mode.”
=======
Re: FYI: windows 10 device manager troubleshooting steps on an “unresponsive FIP” did show “device is disabled” and allowed me to enable. [#158172]
Mon, Jul 13, 2020 8:44 am
SPAD.neXt Support (support@spadnext.com)To:you Details
Hi Jim,
Thanks for letting me know.
This is not a Satiek Feature. it’s a windows feature. If a devices draw too much power (read: it draws more than specifed, which fip often do, since the satiek specs are wrong), windows might disable the device.
If a fip crashes (becomes unresponsive) usually it’s enough to unplug it, wait 10 seconds and replug it to have it coldstarted.
However i’ll check with saitek if they recently updated the firmware, but well, i doubt they did. they did not the last 10 years ;)
Regards,
Ulrich
SPAD.neXt – Simulation Panel Advanced Driver: neXt Generation – http://www.spadnext.com
———————————————————–
— To which I replied:
Thanks. Ulrich. Still something doesn’t make sense….. Most of us are well aware of the “unplug, wait, replug” and indeed SPAD.next over the years has helped in tweaks to minimize / help hasten the restart. But this is was an unresponsive to the device manager for days, and over a week. And what “resusicated” it was the installing of the Saitek driver in Windows 10, so device manager could recognize it. But SPAD.next still didn’t. [Remember, different computer, different USB port, different version of Windows. The SPAD.next was a different license but I think the same version.] Only when I did the Win 10 device manager troubleshooting and did the “enable” did SPAD.next recognize the FIP. It’s been fine after that… even back on the Windows 7 PC, with it’s usual powered USB hub, and SPAD.next loading the same gauge into it. [Thanks Tom Tsui.]
—
Note before going to Windows 10, the FIP had been plugged in and out of the Windows 7 PC several times. Note this wasn’t a FIP “freeze”, it was loss of video as well, and loss of device manager recognition. [This no video/no recognition/etc. has only happened to me once before in 10 years, and I have 12 FIPs. ]
—
Your clue of Windows doing the power-related “shutdown” would make sense, except it didn’t go away when the FIP was moved to the Windows 10 PC. (The USB cable was different, the USB port was different, and it was plugged into a different powered USB hub, and I even tried plugging it into a USB 2.0 port on the PC itself.) ….but what if it was the FIP that internally was in a “draw the extra current” mode. That would explain the problem moving with the FIP. Then it is understandable that installing the Saitek driver did something to initialize it [which reset what was causing the high current draw], and allowed the FIP to be recognized by the Windows 10 device manager (but not SPAD.next). The device troubleshooting step that did the re-enabling in the USB driver for this FIP, now allowed SPAD.next access to the FIP. And because the FIP was out of “high current draw” mode, it was welcomed back to Windows 7 as well.
Now the question becomes “what did the Saitek driver [TBD if it was unique to the Windows 10 64-bit driver], to reset the FIP so it didn’t draw as much current ? …maybe that’s something Saitek/Logitech support can help us with.
Thanks for all your support keeping these FIPs going!
–Jim
LikeLike
Thanks for the update, Jim.
LikeLike
Hi! Maybe you could check your usb hub… I got a lot of problems with an old usb hub. Since I changed the hub the problems disappeared. Have a nice day!
LikeLike
Hi Andre.
Actually I did. The hub is fine.
But will keep an eye on it if same thing happens.
Thanks a lot.
LikeLike
since you’ve opened-up the patient, did you notice any electrolytic capacitors? time and temperature can dry them out, and may temporarily “short”
[my FIPs are “senior citizens” now like yours, so your continued observations welcomed]
Keep up the great work!
LikeLike