Honeycomb Alpha - Error state in device manager after reboot

User Support Hub Hardware & Peripherals
1

Hi everyone,

since a while ago i noticed my Honeycomb Alpha being not properly initialized on system startup / reboot.

The symptom is: During boot the yoke obviously gets Power (its red backlight is on) - but shotly after the “windows boot circle” the light gets switched off. After login i could see in device Manager a yellow warning sign next to one of the USB input devices. Disabling/Re-enabling that device always made the yoke come back to life.

My yoke is connected via a USB-Hub - no idea if the problem would persist without that Hub.

I could solve the issue with a powershell script, that checks the state of the device and if its “Error” automatically Disables/Re-enables it. That script is now triggered via Task Planner on every logon event, which solved the annoying need to do that manually.

If anyone suffers from this issue too and is interested in an automated solution, i could describe the powershell script / its execution in detail here - just let me know there is interest.

Edited: as two people asked me fo the details in a PM i post it here - even if it serves someone only as a temporary solution while waiting for the replacement of a defective hub / yoke or the arrival of a long enough cable (see posts below)

Step 1)
I created a file called “RestartHoneycombAlpha.Ps1” in my “C:\Windows” Folder (use a place, that you like) with the following content:

Get-PnpDevice |
	Where-Object { $_.HardwareID -match 'USB\\VID_294B&PID_1900' } |
	Where-Object { $_.Status -eq 'Error' } |
	ForEach-Object {
		$_ | Disable-PnpDevice -Confirm:$false
		$_ | Enable-PnpDevice -Confirm:$false
	}

Step 2) Opened task planer and created a new task “RestartHoneycombAlpha” with the following Properties:

  • On the “general” tab:
    • select a user account with admin rights to run the task
    • configure Task to run independent of the login of that user
    • check the “don’t save password” box
  • On the “trigger” tab
    • select “at /after login” option from the dropdown list
    • configure trigger to fire “for every user”
  • On the “action” tab
    • select a “run a program” action
    • specify powershell.exe in the program/script field
    • specify optional arguments: -ExecutionPolicy Bypass C:\Windows\RestartHoneycombAlpha.ps1

Those two steps helped me out with the issue. Note that i had no stability issues during the rest of the windows session … if you have, your problem might be more on the hardware defect / powersaving side of things (see comments below)

Fly safe …

2

Honestly, you might have a defective usb hub. I have had one in the past and it was impossible to troubleshoot because it looked okay to Windows. I would take devices off the hub, plug them in somewhere else, and they would work fine. I decided to try a new hub from a different manufacturer and I have had any problems since.

I personally try to use the motherboard USB ports (3.0 if possible) for devices that need to have a very fast response and no lag such as joysticks, yokes, and mice.

3

I’d reach out to Honeycomb for support.

You might try unchecking USB power saving on in the Device Manager settings while it is in a working state, just to see if that helps.

5

thanks for the hint … thats what i tried first. Windows 10s “enhanced power management” is indeed a little tricky for cockpit builders.

So i already disabled this “feature” for all my Saitek and now even both Honeycomb ones - no success for the yoke.

Otherwise … if that was an issue with power saving, the device should go “offline” just after some waiting on the windows desktop. But thats not the case - i just had to disable/enable one time after boot and the device would stay perfectly fine for the whole session.

6

you might be totally right about that USB Hub, but as mine doesn’t look totally ok to Windows (device manager marks it as ‘could not start’) - and my solution works just fine for me with no further “hicups” for the rest of the session … i thought i might share it, just in case someone else has that problem.

i totally agree, that motherboard USB Plugs are the best choice in most cases … but unfortunately sometimes thats either nor practical for various reasons or impossible, because of the lack of enough of them.

thanks for your suggestions anyway - they are much appreciated. And of cause thats, what people should try first, before automating a workaround with powershell/task planner. :smile:

Fly safe …

1 Like
7

Old post but exactly the same thing with mine.

8

And did you try my workaround?

9

Disabled/enabled, yep, worked fine. May make use of your script, could run it from the ms exe.xml perhaps.