Preserving HID ids when devices added or removed?

[MarkDH 234]

I'm sure others have discovered this but adding or removing joystick devices can break some or all of the programming you have done for your buttons and switches, for some or all of your aircraft. This is disastrous, especially if you have a large number of panels and a fly a large number of aircraft!

 

It appears that when LINDA starts it enumerates the HIDs connected to the PC and for each it creates a unique identifier from the vendor id (VID), product id (PID) and a sequence number (UID). The VID and PID are read from the device but the UID is not, it is assigned in sequence - presumably the order in which Windows reports it to LINDA. The problem is, this order may (or may not) change if you plug in a new device.

 

The VID/PID/UID for a Leo Bodnar BBI-32 board will be 1DD2/114/0, which LINDA uses in its config files as the string "1DD211400". When I program all my buttons for, say, the 'FSX Default' profile I discover a file fsx/modules/linda-cfg/aircrafts/FSX Default/config.hid with all the button mappings in it. For example,

JSTK["1DD211400"][11]="RXP_530_NAVFLIP"
JSTK["1DD211400"][12]="RXP_530_LKNOBPUSH"
JSTK["1DD211400"][13]="RXP_530_ENT"

...and so on. BUT if I add a new Bodnar board, LINDA may identify the new board as "1DD211400" and the original one as "1DD211401". If this happens, all those previous mappings are bound to the wrong controller. The effect is that pressing buttons on the new device will cause unexpected things to happen, while pressing buttons on the old device will not do anything. This can happen to some, none or all of your devices, depending on where in the sequence the new one appears. To put this in perspective, I currently have twelve devices connected (eight Leo Bodnar boards, two Saitek throttle quadrants, A VR Insight Multi Panel and a Saitek radio panel).

 

I wonder if this could be fixed so that prior programming was not affected by adding or removing joysticks. I note that the Bodnar boards have a unique serial number that is readable from a program, since the BBI-32 config program displays it, and I am wondering if this applies to other HIDs too. If so the present programming system could be left untouched but LINDA could remember the VID/PID/UID for any device it encounters and associate it with its unique serial number. This would ensure that once LINDA has encountered a particular joystick device it would never change the UID and all previous programming would be preserved.

[ScotFlieger 280]

I understand exactly what you are describing.  The problem arises from the fact that it is impossible to distinguish between devices with identical PID/VIDs. The UID is assigned (PID/VID plus sequential single digit number) purely on the order Windows presents the devices of the same type when the enumeration code is called.  In your example (1DD211400), the PID is 1DD2 and the VIS is 1140.  The last digit is added in numerical order.

 

Ideally, if all devices are left connected, they should be read in the same order.  It is the increasing use of identical USB interface boards, like Leo Bodnar, that has created this problem.  I wonder if there is a further unique ident that can be 'read' from these devices?  Could one of the board inputs be used to provide such an ident?

[hs118 707]

My experience with FSUIPC (and previously with LINDA) in Windows 7, 8, 10 is: if the devices are connected thru a USB hub, they will almost always be detected in the same sequential order. BUT (and a pretty big BUT), on a computer reboot, they can be detected as new sequentially numbered USB devices.

 

What I have done to workaround this operating system issue is to delete all the HD devices detected in FSUIPC/LINDA then run the software again. This has always re-assigned the joy letters and numbers correctly.

 

I have also seen (but not completely tested), where some USB hubs make this problem worse because of their power management behavior. Generally the more feature rich a USB hub is advertised, the more likely the hub will not detect the devices in exactly the same order.

 

I would definitely recommend you get all of your devices organized into inexpensive hubs, this should maintain the order they are detected in Windows. There is not much that can be done about the way Windows will re-detect the devices as far as I can tell.

 

It does seem possible that software such as LINDA and FSUIPC could compare the GUIDs of newly detected HIDs and discard the new detections if the GUID are the same. However, there may be implications of this logic that would have unintended undesirable side effects.

 

Hope some of my experience helps you.

[MarkDH 234]

I wonder if there is a further unique ident that can be 'read' from these devices?  Could one of the board inputs be used to provide such an ident?

 

Well there's what looks like a serial number, although I don't know how you can read it. The BBI-32 config program uses it to distinguish between boards - check out the screenshot below. I can't imagine how using one of the inputs can easily be used to distinguish the boards as they're one-bit inputs. (Although perhaps some kind routine where the user presses the 'id' button of each board in sequence might do it?)

 

 

For me this isn't about plugging and unplugging devices, it's about when I add a new board to my existing setup, as I have just done this weekend. The new board inserted itself about third in line (of eight), so I was left with five messed-up boards. The way I have gotten around this is to figure out which ones have been affected and then go into the config.hid file for the affected aircraft and do a global replace of the ids. Once you understand what's happened it is fairly straightforward, although obviously error-prone! What seems to have happened is all the five affected boards stayed in the same sequence but just moved one UID further up.

 

It strikes me that a small program to do the re-mapping I have done by hand would be useful in the absence of a better solution. I can imagine a program that does something like this:

 

(1) Scans fsx/modules/linda-cfg/aircrafts and presents a list of aircraft.

(2) Asks the user 'select an aircraft to re-map'. This gives it a particular config.hid file to fix.

(3) Opens the selected config.hid and scans all the HIDs that have functions mapped.

(4) For each HID it finds in the file, choose (say) the first button and display the name of the function that is mapped to it.

(5) Ask the user to 'press the button that calls this function'. (*)

(6) Wait for a button press and figure out which HID it is on. [i am assuming this is easy/possible!]

(7) Note the old and new HID ids so we can swap them over (later).

(8) Repeat (5), (6) and (7) until all the HIDs have been identified.

(9) Now use the info gathered to do a global replace of the HID ids in the config.hid file. (It may be possible/sensible to do this for all config.hid files in the fsx/modules/linda-cfg/aircrafts/xxx folders.)

 

(* I can see a problem here if you have the same function mapped to more than one button, particularly if the buttons are on diffreent HIDs. It may be necessary to have an option to 'skip to next function' during this step.)

[ScotFlieger 280]

My experience with FSUIPC (and previously with LINDA) in Windows 7, 8, 10 is: if the devices are connected thru a USB hub, they will almost always be detected in the same sequential order. BUT (and a pretty big BUT), on a computer reboot, they can be detected as new sequentially numbered USB devices.

 

What I have done to workaround this operating system issue is to delete all the HD devices detected in FSUIPC/LINDA then run the software again. This has always re-assigned the joy letters and numbers correctly.

 

I have also seen (but not completely tested), where some USB hubs make this problem worse because of their power management behavior. Generally the more feature rich a USB hub is advertised, the more likely the hub will not detect the devices in exactly the same order.

 

I would definitely recommend you get all of your devices organized into inexpensive hubs, this should maintain the order they are detected in Windows. There is not much that can be done about the way Windows will re-detect the devices as far as I can tell.

 

It does seem possible that software such as LINDA and FSUIPC could compare the GUIDs of newly detected HIDs and discard the new detections if the GUID are the same. However, there may be implications of this logic that would have unintended undesirable side effects.

 

Hope some of my experience helps you.

Thank you for your input. That is very useful. You mention GUIDs but my understanding that this is a means for Windows to identify a device and may not be consistent between system reboots. However, it is a idea that I need to investigate.

Well there's what looks like a serial number, although I don't know how you can read it. The BBI-32 config program uses it to distinguish between boards

The serial number would be ideal. The question is how can it be read by LINDA. I will need some time to study the rest of your post. As a user of these would you be prepared to approach the company to get the interface spec and details of how to read the Serial Number?

[MarkDH 234]

As a user of these would you be prepared to approach the company to get the interface spec and details of how to read the Serial Number?

 

Yes, I'll email them and see what I can come up with.

[hs118 707]

Below is an example of a duplicate detection on my system. Your are correct that the GUID is a Windows assigned number but it is uniquely assigned per computer. This is so that if a device is moved around the various USB ports, the system can "remember" it.

 

Not sure how this could be used by LINDA but in FSUIPC, the duplicate detections show up as additional joy letters but with the same assigned GUID. So if joy "A" is detected and is assigned GUIDxyz by FSUIPC, and the operating system re-detects it, the joy will show in FSUIPC as joy "K" (for example) but have the same GUIDxyz.

 

Unfortunately, my knowledge of how USB plug and play works is a result of troubleshooting detection/driver problems while working on a support helpdesk. I've never written device drivers or studied the formal material.

[MarkDH 234]

would you be prepared to approach the company to get the interface spec and details of how to read the Serial Number?

 

This is what I got. It looks like a useful site and I guess the answer's in there somewhere, but I don't know where to start.

 

 

Hello Mark,

Thank you for your enquiry.

 

You can find this information and much more about generic HID devices from here: http://janaxelson.com/usb.htm

 

Best Regards

John Beeson

 

[MarkDH 234]

Thanks to Andrew for tackling this in 2.6.8!

[ScotFlieger 280]

Thanks to Andrew for tackling this in 2.6.8!

You are very welcome. I was greatly helped by the loan of cards by Leo Bodnar to whom we are indebted.