Lua: com.openhid() with vendor ID 0x0

[TorstenP]

Hi,

I have two USB cards from OpenCockpits (https://www.opencockpits.com), both have a vendor ID of 0000. Fortunately, the firmware of the UBSKeys card has strings for vendor and product, so opening it with com.openhid() works.
The second card is installed in an Airbus A320 RMP and has no strings for the two IDs. Opening with com.openhid() does not work, although my tests in C and Lua with the hidapi library  recognized and opened the device. Is it possible that FSUIPC does not accept a zero as vendor ID? If so, can this be corrected please?

Best regards,

Torsten

[John Dowson]

7 hours ago, TorstenP said:

both have a vendor ID of 0000. Fortunately, the firmware of the UBSKeys card has strings for vendor and product, so opening it with com.openhid() works.

This sounds contradictory - does the firmware for UBSKeys (USBkeys?) have a vendor if or not (is it 0000)?

7 hours ago, TorstenP said:

The second card is installed in an Airbus A320 RMP and has no strings for the two IDs.

Then I think you should contact the vendor to see if they can add a correct VID/PID for this card....

7 hours ago, TorstenP said:

Is it possible that FSUIPC does not accept a zero as vendor ID?

Yes, that is entirely possible and probably...

7 hours ago, TorstenP said:

If so, can this be corrected please?

I am not happy with this change, but I could provide you with a version where the null check on VID/PID is removed. I cannot test this though, but if it works for you then I could allow this on a new ini parameter. I'm pretty busy at the moment, but I'll provide you with an updated FSUIPC7.exe to try within the next few days. If I haven't posted by Monday, ping me a reminder....

John

[TorstenP]

1 hour ago, John Dowson said:

This sounds contradictory - does the firmware for UBSKeys (USBkeys?) have a vendor if or not (is it 0000)?

Then I think you should contact the vendor to see if they can add a correct VID/PID for this card....

Yes, that is entirely possible and probably...

I am not happy with this change, but I could provide you with a version where the null check on VID/PID is removed. I cannot test this though, but if it works for you then I could allow this on a new ini parameter. I'm pretty busy at the moment, but I'll provide you with an updated FSUIPC7.exe to try within the next few days. If I haven't posted by Monday, ping me a reminder....

John

Hi John, both have really 0000 as vendor ID:

Here is the output of HidScanner for USBkeys:

Device at "\\?\hid#vid_0000&pid_0002#6&11466537&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
  Vendor=0000, Product=0002 (Version 0.0)
  Manufacturer= Opencockpits   
  Product= IOCardKEYS V2   
  Serial Number= IOCardKEYS V2   
  Usage Page: FF00
  Input Report Byte Length: 9
  Output Report Byte Length: 9
  Feature Report Byte Length: 0
  Number of Link Collection Nodes: 1
  Number of Input Button Caps: 0
  Number of InputValue Caps: 1
  Number of InputData Indices: 8
  Number of Output Button Caps: 0
  Number of Output Value Caps: 1
  Number of Output Data Indices: 8
  Number of Feature Button Caps: 0
  Number of Feature Value Caps: 0
  Number of Feature Data Indices: 0
  Value 0x01 at index 0, range 0 -> 255, using 8 bits
  Value 0x02 at index 0, range 0 -> 255, using 8 bits
  Value 0x03 at index 0, range 0 -> 255, using 8 bits
  Value 0x04 at index 0, range 0 -> 255, using 8 bits
  Value 0x05 at index 0, range 0 -> 255, using 8 bits
  Value 0x06 at index 0, range 0 -> 255, using 8 bits
  Value 0x07 at index 0, range 0 -> 255, using 8 bits
  Value 0x08 at index 0, range 0 -> 255, using 8 bits
  **************************************************************************

and here from the RMP module:

Device at "\\?\hid#vid_0000&pid_0011#6&1566ae5b&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
  Vendor=0000, Product=0011 (Version 0.0)
  Manufacturer= 
  Product= 
  Serial Number= 
  Usage Page: FFA0
  Input Report Byte Length: 9
  Output Report Byte Length: 9
  Feature Report Byte Length: 0
  Number of Link Collection Nodes: 2
  Number of Input Button Caps: 0
  Number of InputValue Caps: 2
  Number of InputData Indices: 2
  Number of Output Button Caps: 0
  Number of Output Value Caps: 2
  Number of Output Data Indices: 2
  Number of Feature Button Caps: 0
  Number of Feature Value Caps: 0
  Number of Feature Data Indices: 0
  Value 0x04 at index 0, range -128 -> 127, using 8 bits
  Value 0x03 at index 1, range -128 -> 127, using 8 bits
  **************************************************************************

Your idea with a "special" version sound good to me, mayn thanks for your support!

Torsten

[John Dowson]

Hi Torsten,

please try the attached version.  Let me know how it goes, and check your FSUIPC7.log file for a message starting '*** Calling OpenHid with ...' and post that if you have issues.

BUT, looking at your HIDScanner output, it seems as of the issue is with the Manufacturer, Product or Serial number (and/or GUID, which seems to be the same for both cards), which are all null/empty. Even though the VID is 0000 (which IS ok, as your USBKeys card IS recognised),  there is still a unique product ID for both cards. Given that, I don't hold out much hope.
Have you tried OpenCockpits support to see why these fields are not being populated?

John

 

Edited December 6, 2021 by John Dowson
Attachment removed

[John Dowson]

Could you also attach your FSUIPC7.JoyScan.csv file please...

[TorstenP]

Today I tested your new exe file - unfortunately it dosen't work. But... I'm a little embarrassed, but the original application DOES run with both USB devices. It may be that I had included a few errors in the Lua code (sorry, but I can no longer trace it - I changed the code again and again).
Here is the FSUIPC7.JoyScan.csv file no your request:

Good?, flags, VID, PID, Name, INIid, REGid, RegEntry, INIguid, REGguid, HIDguid, ValsOK?, ReadsOk?

,,, HIDscanning completed


,,, REGscanning completed


,,, User settings imported


,,, Values matched and decided

Your new program also wrote the same csv file. And, it gave an error on

com.openhid(0x0, 0x11, 0, 0)

8687 LUA.3: Crash C0000005 at 7FFC143F6CBC: "D:\FSUIPC7\A320Rmp.lua"

So the code change seems to be unsuccessful. However, the same line works with v7.2.13 and I cand send and receive data from the A320 RMP.

The only remaining problem is that the device starts sending it status messages (with 20 Hz) right after the Lua script sends an message. And, it seems to not stop after FSUIPC is closed. At the next start of FSUIPC, the device is opened successfully, but sending a message fails. Restarting the device before the next FSUIPC start helps to establish a working connection again. I need to investigate that further.

Many thanks again!

Torsten

[John Dowson]

On 12/4/2021 at 5:28 PM, TorstenP said:

Today I tested your new exe file - unfortunately it dosen't work.

No, I didn't think it would make much difference...

On 12/4/2021 at 5:28 PM, TorstenP said:

But... I'm a little embarrassed, but the original application DOES run with both USB devices

Ah, ok....I should have asked to see your logs first....

On 12/4/2021 at 5:28 PM, TorstenP said:

So the code change seems to be unsuccessful. However, the same line works with v7.2.13 and I cand send and receive data from the A320 RMP.

Yes, forget that version I posted - I will remove.

On 12/4/2021 at 5:28 PM, TorstenP said:

The only remaining problem is that the device starts sending it status messages (with 20 Hz) right after the Lua script sends an message. And, it seems to not stop after FSUIPC is closed. At the next start of FSUIPC, the device is opened successfully, but sending a message fails. Restarting the device before the next FSUIPC start helps to establish a working connection again. I need to investigate that further.

Ok. Did you try closing the com object before FSUIPC exited? You can do this in an event.terminate function. 

John