"Indicator Colour" events not working on VIRPIL APLHA Grips LED when installed on the newer WarBRD-D base

[twinny21989]

• [ X] I have read Getting Help

  Sending Indicator Colour events through Helios to a VIRPIL ALPHA Grip on the newer WarBRD-D base has no effect.

---

Helios_status_report_133511268015041277.txt

Describe the Helios Issue

Am able to set up the event but when fired it has no effect on either of my sticks. Issue occurs on the following devices:

LEFT VIRPIL ALPHA Grip on WarBRD-D Base (appears as LEFT VPC Stick WasBRD in HELIOS) RIGHT VIRPIL ALPHA Grip on WarBRD-D Base (appears as RIGHT VPC Stick WasBRD in HELIOS)

I also have a VIRPIL CM3 Throttle and VIRPIL Control Panel#2 but these function as expected when sending Indicator Colour events.

All devices are plugged into their own individual ports on a powered USB 3.0 hub, no devices are slaved and apart from the Indicator colour commands not functioning on the ALPHA grips everything else works as expected.

I am able to send equivalent Indicator Colour events to all devices using different software with no issue (VIRPILS own VPC LED software and a Python script through Joystick Gremlin both work to change the ALPHA Grip LEDS)

Steps to Reproduce the problem

Steps to reproduce the behaviour:

1. Interfaces added and a button created to fire the event
2. Add event: Bindings/Output/Actions/Interfaces/RIGHT VPC Stick WarBRD/ADDONGRIPS Indicators/Click and drag "Set indicator colour 1" on to "Output/Bindings/Pushed"
3. Input Action Value in correct format (colour value in hex format) as noted
4. Save profile
5. Run Helios Control Center and push button to test

Expected behavior

Expect LED on the ALPHA grip to change colour or turn off depending on what Colour Indicator event has been selected

Please complete the following information:

• Helios Version [1.6.6060.0003]

The problem happened while using

(place an 'x' between the square brackets for all that apply)

• [ x] Profile Editor
• [ x] Control Center
• [ ] Keypress Receiver
• [ ] Something else (remember to tell us what it is)

Additional context

Went through both the left and right grips and tried every indicator event under ADDONGRIPS, ONBOARDLEDS, SLAVELEDS AND EXTRALEDS Indicators. No event whether it be to change the colour or turn off the LED works when sent to the ALPHA Grips.

Control Center Problem Logs show a USB Vendor ID error for both the LEFT and RIGHT VPC Stick WarBRD devices:

LEFT: 2024-01-30 20:56:09.0526|INFO|GadrocsWorkshop.Helios.Interfaces.Vendor.Functions.VirpilHotasIndicators|Unable to find USB device with VendorID: 13124 and ProductID: 203.|

RIGHT: 2024-01-30 20:56:26.5002|INFO|GadrocsWorkshop.Helios.Interfaces.Vendor.Functions.VirpilHotasIndicators|Unable to find USB device with VendorID: 13124 and ProductID: 32971.|

These Product ID's do not appear in "DirectXControllerInterface.cs"

ProductID: 203 in HEX: CB or 00CB ProductID: 32971 in HEX: 80CB

Left VPC WarBRD Stick Error Control Center.20240130.7 - Copy.log Right VPC WarBRD Stick Error Control Center.20240130.8 - Copy.log

[BlueFinBima]

@ryanwoodcox Are you able to reproduce this?

[BlueFinBima]

@twinny21989 Thanks for the detailed description of the issue. I don't have any Virpil products to test, however there is a Development build of Helios here which can be installed in parallel to released versions of Helios. This development release of Helios is 1.6.1000.0 and assets for this release live in the "HeliosDev" directory %userprofile%\documents\heliosdev. The development release of Helios has the product codes you identified defined.

Please let me know if this resolves the problem.

[twinny21989]

@BlueFinBima Tried the dev release as requested and no joy unfortunately. The logs show the same error even though the product codes from the error logs have been added. The LEDS on the other two VIRPIL devices (CM3 Throttle and CP#2) still function as expected.

DEV BUILD Control Center - Copy.log

[ryanwoodcox]

@BlueFinBima I unfortunately do not have the new WarBRD-D base to test with.

I have not messed around with my Virpil devices in Helios for a while now, but would be happy to poke around and see if my devices are still working.

This message is in the log concerning: 2024-01-31 20:29:35.9068|INFO|GadrocsWorkshop.Helios.Interfaces.Vendor.Functions.VirpilHotasIndicators|Unable to find USB device with VendorID: 13124 and ProductID: 203. What are the possible causes of the logging of this message?

@twinny21989 We set the Virpil logic up in the section of code you found in DirectXControllerInterface.cs to support any ProductID. The references to the ProductIDs you see in your screenshot are just notable products that are used to set the testStatus string and have no impact on the logic. You'd only have to be concerned if you flashed your Vipil device and changed the VendorID from what we have hardcoded (0x3344).

Are you using Alpha or Alpha Prime grips on your WarBRD-D bases?

What are the Hex color values you are testing with?

Given you've had success with setting the LEDs of your other devices, you've probably seen this, but just in case: my walkthrough video https://www.youtube.com/watch?v=dNW1BXG8TrY&t=429s. There is a simple test of me configuring my WarBRD (legacy) base and ALPHA Prime Left Grip at 7:09.

[ryanwoodcox]

@BlueFinBima Your dev patch doesn't actually affect the logic, right? https://github.com/HeliosVirtualCockpit/Helios/commit/56fc98bc13aa66da2c4fd7f3bfad43ec082d5700

[twinny21989]

@ryanwoodcox Funny enough your walkthrough video is exactly what I was following when I discovered the issue.

Firmware is stock, I've attached a screenshot of my VPC Config Tool to show the VendorID etc, all appear to be as they should.

I'm using a standard ALPHA grip on both WarBRD-D bases so it only has one addressable LED which does the rim around the top of the stick. I have tried every option in the output tab, Addons, Onboard, Extras and Slave (even though none of my VIRPIL devices are slaved) just to make sure but nothing seems to effect the ALPHA LED, not even the SetDefault, Refresh or Reset commands work, the state of the ALPHA LED doesn't change whether I have it on or off before trying to change it with Helios.

Tried multiple HEX colour values, including all of the ones in your video but mainly #FFFF0000.

Examples of HEX values I have tried:

1.Tried changing just the alpha values (#44FF0000, #CCFF0000)

2. Tried only alphabetical (#FFFFFFFF)
3. Tried only numerical (#99999999)
4. Also tried putting in these values on the throttle and CP#2 to confirm they work first, copied and pasted those exact values onto the ALPHA sticks but still no joy.

This is the case in both the latest release build and the dev build @BlueFinBima asked me to try.

I don't think it matters but one thing I did notice in your video is that while you do demonstrate being able to change the LEDs on the side on your ALPHA Prime, unless I missed it you don't actually change the LED zone on the top of the stick that is present on both the Prime and the standard ALPHA grips.

[BlueFinBima]

@BlueFinBima Your dev patch doesn't actually affect the logic, right? 56fc98b

Correct, the change I made was a quick punt without me checking the logic. All products from Virpil's VID are treated the same with only the messages differing in the testing status.

The message is issues when we get null back from _hotasDevice = DeviceList.Local.GetHidDevices().Where(d => d.VendorID == device.Properties.VendorId && d.ProductID == device.Properties.ProductId && d.GetProductName() == device.Properties.ProductName).FirstOrDefault(d => d.GetMaxFeatureReportLength() > 0);

Given that we have a reasonable looking ProductName (from the message) then I guess the focus is on there being no devices with d.GetMaxFeatureReportLength() > 0. Why this might be the case, I have no idea.

[BlueFinBima]

@twinny21989 Here is a new development build with a few more messages to home in on the problem. You'll need to manually uninstall the previous development build using "add / remove programs" before you will be able to install the new one. Please start Control Center with: "%ProgramFiles%\Helios Virtual Cockpit\HeliosDev\Control Center.exe" -l Debug

Link to Development Build with extra messages

If this does not throw some light onto the matter, the next step is probably WireShark.

[twinny21989]

Hi @BlueFinBima

Debug log attached DEV BUILD WITH DEBUG Control Center.log

[BlueFinBima]

@twinny21989 Thanks for that log. I didn't see the debug message I was expecting which probably indicates that I was wrong in my assumption about the reason for the HID Device not matching the test criteria. It suggests that it is the product name which was not matching.

Here is a new development build with a few more messages to home in on the problem. You'll need to manually uninstall the previous development build using "add / remove programs" before you will be able to install the new one. Please start Control Center with: "%ProgramFiles%\Helios Virtual Cockpit\HeliosDev\Control Center.exe" -l Debug

Link to Development Build with extra messages

It is remotely possible that this development build may make it appear as if your devices work. I'm interested to know if this is the case, however it is the log file that I am really interested to see.

[twinny21989]

@BlueFinBima Latest debug logs. Interestingly the ALPHA stick LEDs did work with this build. All commands I tried worked as expected (different hex colour codes and the set default/reset options all functioning) when addressing ADDONGRIPS Indicators.

Another Dev build EVEN MORE messages Control Center.log

[ryanwoodcox]

I believe the log is still missing the info we'd like to see. I left two comments on this commit: https://github.com/HeliosVirtualCockpit/Helios/commit/9cbce5b7e4f29f36956cb587cd1a43a73adbd08c

[BlueFinBima]

@ryanwoodcox Thanks for the comments. The code which was just tested was commit 34f199c. This included a re-attempt to get _hotasDevice without the ProductName test, and the positive results suggest that for some reason this test for ProductName is failing for the Alpha sticks. As you spotted, the additional information is not coming out in the debug message which is annoying because I did remove the ProgramName test from the foreach but I guess I must have done a Ctrl-Z because it managed to still be in the build. I'm not comfortable about permanently removing this test without understanding why it is failing, so I think we'll need one more attempt to get that information.

[ryanwoodcox]

Damn Undo... heh. Yeah, I'd love to see at least one more attempt as well. Very curious why the Product Name mismatch. Thrilled to see things working but its important we understand why.

[BlueFinBima]

@twinny21989 Sorry to ask you to perform another test. There is another build underway (it is likely to take about 20mins). Once it completes, there will be a new HeliosDev zip file at the bottom of this page https://github.com/HeliosVirtualCockpit/Helios/actions/runs/7762445415 Hopefully the log from this will have the information about why there is a mismatch in the ProductNames. Same process as before. Thanks

[twinny21989]

Here you go.

One more Control Center.log

[BlueFinBima]

@twinny21989 Thanks for the quick turn around on the test.

Finally, we have the info... Apologies that it took several iterations. The comparisons which fail are L-VPC Stick WarBRD against LEFT VPC Stick WarBRD and R-VPC Stick WarBRD against RIGHT VPC Stick WarBRD which raises a few more questions than I have answers to unfortunately.

1. Are all four of these names defined by Virpil? (@ryanwoodcox / @twinny21989 )
2. Does the Virpil tooling allow for the names of the devices to be changed? (I know that the Thrustmaster tooling does because I have four MFDs (they usually come in pairs) and I had to change the names on two of them) (@ryanwoodcox / @twinny21989 )
3. Were any of these names changed in the Virpil tooling? (@twinny21989)

More generally

1. Do Vid&Pid pairs on a particular system need to be unique? (The belief that they did not need to be unique was what led to the inclusion of the ProductName test) (@ryanwoodcox / @BlueFinBima )
2. Is there a better test for something akin to ProductName which when combined with Vid and Pid result in a unique combination? I'm fairly certain we can't use the GUID for this (@ryanwoodcox / @BlueFinBima )

Ultimately what Helios is trying to protect against is a system where a user has plugged in two identical hardware devices (eg two LEFT VPC Stick WarBRD).

Does anyone have answers to any of these questions?

[BlueFinBima]

A 2. Looks like you can change the "USB Name" in the Profile section of VPC Tool. Looks like it will also let you change the Vid and Pid.

A 4. Vid and Pid do not need to be unique on a system so an additional test is needed.

[ryanwoodcox]

A 1.) I'm not sure what the difference is between hD.GetProductName() and device.Properties.ProductName. Does a device have two separate name properties? If so, perhaps Virpil sets one name internally that the user cannot change based on the profile configuration and the user can manually change the second name property. @twinny21989 can you send a screenshot of the VPC configuration tool with your Left Stick device selected and another screenshot with your Right Stick selected please?

A 2.) Yes, you found the spot @BlueFinBima . If devices have two name properties, I'm not sure which name property is editable until we see the screenshots requested above.

B 1.) This is a great question. @twinny21989 if you're willing to temporarily try this - this would be very helpful. Can you try setting the PID of your Left Stick to the same PID of your Right Stick and see if the VPC Configuration tool allows this? If it does, can you confirm both Sticks are recognized by Windows and function normally (don't worry about LED functionality)

@BlueFinBima I'm worried B 1. will be possible, and if that is possible then I have serious doubts about Device Name properties having to be unique.

B 2.) @BlueFinBima Where are your doubts about potentially using GUID coming from? Do you know if the device GUID is generated and assigned by Windows or embedded into the firmware of the device? I believe DCS uses the GUID for saving key bindings associated with hardware devices. I've had to manually edit my key binding files when my device GUIDs had changed (flashing device firmware, reinstalling windows, etc)

[ryanwoodcox]

Update: I'm still very curious about @twinny21989 's findings for B1, but it does appear at least from the user's perspective that Virpil expects users to have a different PID for all of their Virpil devices. I say this due to this LED control tool that Virpil offers:

[twinny21989]

@ryanwoodcox @BlueFinBima I've no problem running those tests, I won't be able to get near my Sim gear until tomorrow night so won't be as quick this time unfortunately

[BlueFinBima]

@ryanwoodcox What I am shooting for is a test which will work with any "legal" combination of Vid / Pid / Product Name etc which VPC Tool can create. I think to do this, we need to ditch the test for ProductName and replace it with something else.
Initially, I thought the GUID would not be available because the actual device only has a class UUID, and does not know about the Windows GUID, however I think what gets presented as the device has been endowed by the operating system with a path, and part of this path is what I believe to be the GUID. Current plan is to test the relevant part of the path.

Unfortunately, I only have a Virpil base which works with this new design, however if it holds up in testing by twinny21989, then it would be great for it to be regression tested using your extensive inventory of Virpil products ;-)

[BlueFinBima]

BTW the device has a ProductName and an InstanceName. On my base, both are the same. I'm guessing that these are different on twinny21989's Alpha Grips. It might very well be that if we test against the InstanceName, this might work, however I'm not convinced that this would be better / more robust solution than using the part of the path that I'm contemplating using.

[BlueFinBima]

Builds are happening much faster on Saturday nights!

@twinny21989 Can you please test this build and let me know if you're able to make the LEDs twinkle.

I don't need a log unless this does not work.

Thanks!

[BlueFinBima]

PS, the UUID I'm now testing definitely isn't the GUID, or any of the devices' inbuilt UUID's so TBH, I'm not sure how reliable this is going to be. This said, the GUID is not available from the DeviceList we're checking so we can't test this.

[ryanwoodcox]

Interesting. I did see this - so I think you may be onto something promising, @BlueFinBima 1.5 (May 18, 2013): Added the DevicePath property to HidDevice. This is useful for differentiating devices with the same VID, PID, etc.

https://github.com/treehopper-electronics/HIDSharp

You may even want to just use the devicePath as-is without splitting on #

[BlueFinBima]

Thanks for the pointer. There are differences between the devicePath and interfacePath so a direct comparison would fail hence only using the last part. If they were the same, I could have dropped the vid and pid checks because both are in the devicePath.

[ryanwoodcox]

Of course! The property's description comment is here: https://github.com/treehopper-electronics/HIDSharp/blob/6fa83aaa3c82547451f4c2ae3666e45afd04b431/HidSharp/HidDevice.cs#L67

[BlueFinBima]

Flagging as bug because the product name is not the correct test to be using.

[BlueFinBima]

Flagging as More Info Needed - Specifically test feedback.

[ryanwoodcox]

@BlueFinBima The build artifact has expired. I'm willing to test this if I can get that dev build.

[twinny21989]

@BlueFinBima @ryanwoodcox Sorry for going dark for a few days, life got in the way. I'm back at my rig this weekend so can do some more testing.

[ryanwoodcox]

I haven't opened my old profiles in a while and it seems the newer version of Helios is puking on me when trying to load the profile. I'll have to start one from scratch to test this issue 800.

Update: I believe the issue is related to my profiles using a custom Helios.AH54D.hif.json Interface File from before Helios had it built into it. <Interface TypeIdentifier="Helios.DCSInterfaceFile" Name="DCS AH-64D" /> Perhaps Helios is not finding that custom Interface file and puking.

I will try doing a bulk find and replace on my profiles to update them to use the built in version of the AH64 Interface.

[BlueFinBima]

Update: I believe the issue is related to my profiles using a custom Helios.AH54D.hif.json Interface File from before Helios had it built into it. <Interface TypeIdentifier="Helios.DCSInterfaceFile" Name="DCS AH-64D" /> Perhaps Helios is not finding that custom Interface file and puking.

Helios.AH64D.hif.json still exists, but if your own copy had arguments which don't exist (or are different controls) then the deserialization can get a tad upset.

[BlueFinBima]

@ryanwoodcox @twinny21989 https://github.com/HeliosVirtualCockpit/Helios/actions/runs/7769290428 is in the final stages of re-building the artefacts.

[ryanwoodcox]

Helios.AH64D.hif.json still exists, but if your own copy had arguments which don't exist (or are different controls) then the deserialization can get a tad upset.

I actually realized I'm using an older (years) DCS.AH-64D.hif.json/lua interface from Bunny on the DCS forums that I've been modifying. I looked into porting over to the newer AH64 interface but every binding name is different. It does not sound like a fun time.

To get my old profiles working again, I:

1. I noticed the custom interface was also in C:\Users\{user}\Documents\Helios\Interfaces\HeliosInterfaces. Is this a valid location for additional/custom interface files? I was confused by the final HeliosInterfaces directory.
2. I added the custom interface to C:\Program Files\Helios Virtual Cockpit\Helios\Interfaces.
3. The profile loaded in Helios Profile Editor without crashing.
4. I was able to delete the interface file from C:\Program Files\Helios Virtual Cockpit\Helios\Interfaces while leaving the interface file in C:\Users\{user}\Documents\Helios\Interfaces\HeliosInterfaces and my profile still loaded in Helios Profile Editor without crashing.

[BlueFinBima]

4. C:\Program Files\Helios Virtual Cockpit\Helios\Interfaces

You shouldn't have needed to delete the interface in this directory, the one in C:\Users\{user}\Documents\Helios\Interfaces\HeliosInterfaces should have been loaded in preference.

[BlueFinBima]

@ryanwoodcox @twinny21989 The rebuilt artefact is Here

[twinny21989]

@BlueFinBima That latest test build works fine. I've added the log anyway. latest Control Center.log

[ryanwoodcox]

@BlueFinBima I confirmed all of my Virpil devices are working fine on the new dev build. Nice work! :shipit:

[BlueFinBima]

@twinny21989 & @ryanwoodcox many thanks on feeding back on the latest code. I plan to deliver this in 1.6.607.

[BlueFinBima]

Delivered in 1.6.6070.2 @ryanwoodcox & @twinny21989 Thanks for your assistance to get this diagnosed and tested.