HIDdemo testing

[kamarad]

Hi,

 

I’m trying to build a lua routine to scan my 3 Saitek panels (Multi, Switch, Radio) and I use as a template the example HIDDemo.lua. While reviewing the code, there is a point needing clarification.

 

I was able to access the panels and took note of each button value. The next step for me was to assign different virtual joystick to each of the 3 panels and that is where I have some problems.

 

On the writing button loop of HIDDemo, I don’t understand why in the ipc.write line the increment is 8. I was expecting that writing a double world 4 bytes x 8 bit = 32 buttons will requires a 4 bytes increment between each button write. The last loop when I=8 here will give an increment of 64 bytes over the base address of 0x3340 which seems larger than the block of offset associated with virtual buttons. I’m missing something?

 

                i = 1

                while i <= 8 do

                    if buttons ~= prevbuttons then

                        fbutton = true -- flag change for logging

                        prevbuttons = buttons

                        -- Send to FSUIPC as a set of 32 virtual buttons

                        -- i.e. DWORD offsets 3340 onwards

                        ipc.writeUD(0x3340 + ((i-1) * 8), buttons)

                    end

                    i = i + 1

                end

 

Also, I was wandering why in this example, the decision was to read 8 buttons x 32 bit each instead of less? How can we know what is the quantity of button that will be returned by a HID device? Is it the “wr” parameters in the com.openhid command? For instance, I know from testing that the Saitek radio panel  use 17 bits and the Multi panel 19 bit of information. So I expect to be able to assign the 3 first block of 4 bytes in the 0x3340 offset to my 3 panels. Does it makes sense?

 

 

 

[Pete Dowson]

On the writing button loop of HIDDemo, I don’t understand why in the ipc.write line the increment is 8. I was expecting that writing a double world 4 bytes x 8 bit = 32 buttons will requires a 4 bytes increment between each button write. The last loop when I=8 here will give an increment of 64 bytes over the base address of 0x3340 which seems larger than the block of offset associated with virtual buttons. I’m missing something?

 

Your comment had me puzzled for a while, but then I realised you didn't mean an increment f 8 but a omultiplier of 8.

 

And, yes, it is a bug. It should be 4. Thank you for pointing this out. I never had a HID device with more than 32 buttons so it never resulted in any errors!

 

I'll fix it ready for the next update.

 

Also, I was wandering why in this example, the decision was to read 8 buttons x 32 bit each instead of less? How can we know what is the quantity of button that will be returned by a HID device? Is it the “wr” parameters in the com.openhid command? For instance, I know from testing that the Saitek radio panel  use 17 bits and the Multi panel 19 bit of information. So I expect to be able to assign the 3 first block of 4 bytes in the 0x3340 offset to my 3 panels. Does it makes sense?

 

You mean 32 buttons x 8, not 8 buttons x 32. Each value returned by com.GetHidButtons is a 32-bit word. So if a device has say, 48 buttons, you'd get 32 in the first and 16 in the second 32 bit word. It allows up to 8 of these 32 bt words. Why would I want to split the returned values down in to smaller pieces when I can so efficient;y merely store them into the offsets 32 bits at a time?

 

If you want to use some of the virtual buttons offsets for other devices then you need to alter the program, obviously. You need to limit how many words or bytes you store and adjust the starting offset appropriately. If you only want to handle 8 bits or less, then you'd use a Byte write, and so on.

 

At present there's no way to get the number of buttons actually provided. That's a fair point. It is something I could might be able add if needed.It could be returned by com.gethidcount with the axis name omitted. I'd need to check first.

 

[LATER]

Actually, just getting the number of buttons for the device is a lot more complex than I thought -- a lot more code. I know how to do it (it is done, for instance, in my HidScanner program), but at this stage I'd really rather not mess with the current Lua library code in this area. Sorry.

 

Pete

[kamarad]

Thanks Pete for the fast return and the clarification of the multiplier. Now it makes perfect sense.

 

As for reading 32 bit at the time, I'm fine with that approach. I was not suggesting to make more read operation with smaller quantity of byte each.

 

As for the quantity of information returned, if my Saitek multi panel for instance fit in 2 x 32 bits, I will have to modify the GehidButtons line of code as follow risk of causing errors because I just have two destination variables button[1] and [2] instead of 8 in the initial code?

 

buttons[1], buttons[2] = com.GetHidButtons(dev, CurrentData)

 

If it is as simple as that, no need for a function that return the quantity of information from the Panel as I can test this already using the Hiddemo and adjust the code accordingly.

 

I will try to give a go to my first trial in lua programming....  I will need indeed to modify the program and destination offset for each of my 3 panels but that should not be too complex.

[Pete Dowson]

As for the quantity of information returned, if my Saitek multi panel for instance fit in 2 x 32 bits, I will have to modify the GehidButtons line of code as follow risk of causing errors because I just have two destination variables button[1] and [2] instead of 8 in the initial code?

 

buttons[1], buttons[2] = com.GetHidButtons(dev, CurrentData)

 

If it is as simple as that, no need for a function that return the quantity of information from the Panel as I can test this already using the Hiddemo and adjust the code accordingly.

 

Yes, the GetHidButtons line you show is okay, but you also want to shorten the loop. Change while i <= 8 do to while i <= 2 do. And if you are keeping the logging, change the logging line a bit later to:

 

       ipc.log(string.format("Buttons= %X %X",  buttons[1], buttons[2])

 

On the matter of getting a count of buttons, I'm having second thoughts about that and may implement a new function, com.GetHidButtonCount. But maybe not this week. It's on a list.

 

Pete

[kamarad]

It works fine for the Saitek Radio, Saitek Multi and Saitek Switch panel. I create 3 different versions of HIDDemo, one for each panel that write at different offset as you mention.

 

Thanks for the fast and very informative support..

Edited April 3, 2014 by kamarad

[kamarad]

And if it may help others people to get access to their Saitek panel, here is the mapping of the value returned by each switches and button. they fit in 17 or 19 bytes so reading a single double world is sufficient to get the complete status of the panel.

 

Note: The value returned is the sum of the value associated with all switch position and button that are pushed.

 

Saitek Radio Panel

 

Button 1 (top left)

1= com1

2= com2              

4= nav1

8= nav2

16= adf

32= dme

64= xpdr

Button 2 (bottom left)

128= com1

256= com2

512= nav1

1024= nav2

2048= adf

4096= dme

8192= xpdr

16384 = ACT/STB button 1 (top right)

32768 = ACT/STB button 2 (bottom right)

65534 = Turn right (top dial button)

131072 (2E17)= Turn left (top dial button)

 

Saitek Multi Panel

 

Selector button

1= Alt

2= VS

4= IAS

8=HDG

16=CRS

32= Dial turn right

64= Dial turn left

128= AP button

256= HDG button

512= NAV button

1024= IAS button

2048= ALT button

4096= VS button

8192= APR button

16384= REV button

32768= Auto Throttle switch

65536= Flaps up (2e16)

131072= Flaps down (2e17)

262144= Pitch up (elevator trim)

524288 (2E19)= Pitch down (elevator trim)

 

Saitek Switch panel

Note: The minimum value for saitek value correspond to the position of the landing gear handle. 262144 is returned in the UP gear position and 524288 for down Gear.

1= Battery

2= Alternator

4= Avionic

8= pump

16= DeIce

32= Pitot heat

64= Cowl

128= Panel

256= Beacon

512= Nav

1024= Strobe

2048= Taxi

4096= Landing

8192= OFF magneto

16384= Left Magneto

32768= Right Magneto

65536= Both Magneto

131072= Start Magneto

262144= Landing gear Up

524288 (2E19)= Landing Gear Down

[Pete Dowson]

And if it may help others people to get access to their Saitek panel, here is the mapping of the value returned by each switches and button. they fit in 17 or 19 bytes so reading a single double world is sufficient to get the complete status of the panel.

 

Do you think you could post these details, maybe with our working plug-in, as a User Contributions subforum? That way it will remain a useful reference.

 

Thanks!

 

Pete

[kamarad]

Hi Pete, 

 

Was abroad for a couple of week so didn't had time to post the information in the user contribution. I will do it eventually but I have now problem to have a consistent access to the Saitek modules. At the beginning of this week, I made a fresh install of Prepar3dV2.2 on a new SSD drive and tried my 3 modules again just to find that their behavior was now erratic. I get access to the Radio panel most of the time (but not always), Multi is so so.. .about 50% success and I'm not able anymore to access the Switch panel. I took a couple of hours on the last two evening to investigate but still puzzled as the changes made to HidDemo are minimal (in the last try I made yesterday, I just changed the vendor and product number, the loop to 1 iteration as all information fit in one 32 bit button and the destination offset address). And I did restart P3D about 50 times yesterday evening and the success of connecting is random....  I finally gave up yesterday after the last 5 tries didn't succeed to access the 3 panels. I will see if I can investigate further this week-end.

 

Pierre