256-button HID as joystick

[ckovoor]

Hi Pete,

 

I am experimenting with using an Arduino Mega as a 256-button USB HID joystick under FSX-FSUIPC.

 

HiDScanner duly recognises the device as such:

 

 

********* HidScanner, Version 2.00 by Pete Dowson *********
 
  Device at "\\?\hid#vid_03eb&pid_2043&mi_00#8&392dae83&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
  Vendor=03EB, Product=2043 (Version 0.3)
  Manufacturer= Arduino
  Product= 001
  Serial Number= C2
  Usage Page: 1
  Input Report Byte Length: 49
  Output Report Byte Length: 0
  Feature Report Byte Length: 0
  Number of Link Collection Nodes: 2
  Number of Input Button Caps: 1
  Number of InputValue Caps: 8
  Number of InputData Indices: 264
  Number of Output Button Caps: 0
  Number of Output Value Caps: 0
  Number of Output Data Indices: 0
  Number of Feature Button Caps: 0
  Number of Feature Value Caps: 0
  Number of Feature Data Indices: 0
  Buttons range 1 -> 256 at indices 8 -> 263
  Value Dial at index 0, range 0 -> 65535, using 16 bits
  Value Sldr at index 1, range 0 -> 65535, using 16 bits
  Value R/RZ at index 2, range 0 -> 65535, using 16 bits
  Value V/RY at index 3, range 0 -> 65535, using 16 bits
  Value U/RX at index 4, range 0 -> 65535, using 16 bits
  Value Z at index 5, range 0 -> 65535, using 16 bits
  Value Y at index 6, range 0 -> 65535, using 16 bits
  Value X at index 7, range 0 -> 65535, using 16 bits
  **************************************************************************

 

I use a 16 x 16 matrix to 'create' the various encoders and buttons, and have tested the arrangement partially with SV Mapper (a joystick testing software), so know it works.

 

I run a shortened version of your HidDemo.lua:

Vendor=0x03EB
Product=0x2043
Device=0 
Report=0
Pollrate=25


dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report)

if dev == 0 then
   ipc.log("Could not open HID")
   ipc.exit()
end

buttons = {}
-- Up to 256 buttons = 8 x 32 bit words
prevbuttons = { 0, 0, 0, 0, 0, 0, 0, 0 }

function Poll(time)
-- We use "readlast" so the values we use are the most up-to-date
  CurrentData, n, discards = com.readlast(dev, rd)

-- Now handle the buttons : up to 256 of them!
  	  buttons[1], buttons[2], buttons[3], buttons[4],
  	  buttons[5], buttons[6], buttons[7], buttons[8] = 
  	  	com.GetHidButtons(dev, CurrentData)
  	  	
  	  -- check for changes   
    	i = 1
    	while i <= 8 do
    	    if buttons[i] ~= prevbuttons[i] then
    	        prevbuttons[i] = buttons[i]
    	        -- Send to FSUIPC as a set of 32 virtual buttons
    	        -- i.e. DWORD offsets 3340 onwards
    	        ipc.writeUD(0x3340 + ((i-1) * 4), buttons[i])
    	    end
    	    i = i + 1
	end
end

event.timer(1000/Pollrate, "Poll")  -- poll values 'Pollrate' times per second

and then test for the encoders and buttons in the FSUIPC window.

 

The trouble is that irrespective of the actual button or encoder that I press/turn, FSUIPC always registers the action as (virtual) Joy# 71:Btn# 1 or Joy# 70:Btn# 1 or Joy# 69:Btn# 24. I have tried all possible buttons and encoders and always get the same result.

 

(I don't know if this is relevant to the issue, but at this stage I have not connected the entire 16 x 16 matrix to the Arduino, but test for a particular button or encoder in the matrix by connecting only the relevant pair of pins. This is not a problem when testing under SV Mapper.)

 

Would you be able to tell me what I am doing wrong?

 

Thanks and Regards,

 

Chakko.

 

(using registered FSUIPC 4947d, FSX-SP2)

[overpro]

Hi Chakko,

 

I have registered this account and let's see if Pete has any feedback, we can change our firmware if needed.

 

Regards

[Pete Dowson]

Would you be able to tell me what I am doing wrong?

 

No, sorry. I can't see any useful data from here.

 

In your position I would be using a USB monitoring program to log the actual data being received at the PC, and trying ot work out what that looks like to the Lua HID functions, and compare the results to those logged by the Trace/Debug facility in Lua.

 

Haven't you tried debugging the Lua using the facilities available to you? That would be the first step.

 

If you add:

 

Debug=Please

LogExtras=x200

 

to the [General] section of the FSUIPC4.INI file before running FS you will get a lot more logging regarding what the HID code for Lua is doing.

 

On the hardware/firmware side, for USB devices I use the "Device Monitoring Studio" USB package by HHD. There is a free (limited) version

 

If you do find anything which you think may be due to something wrong in FSUIPC do let me know. I've never had any opportunity to test with anything more than PFC, GoFlight, Saitek, and Leo Bodnar boards. Never anything with 256 button capabilities!

 

Pete

[ckovoor]

Hi Pete,

 

Thank you for your response.

 

I have found the problem lay in the code I had used earlier. I had omitted a condition n ~= 0, and I had omitted the init section.....one of these omissions was the culprit. When I inserted both and re-ran the lua, all 256 encoders/buttons were recognised as virtual buttons in the range you have specified in the manual.

 

For reference, here is the working code:

Vendor = 0x03EB
Product = 0x2043
Device = 0 
Report = 0
Pollrate = 25


dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report)

if dev == 0 then
   ipc.log("Could not open HID")
   ipc.exit()
end

buttons = {}
-- Up to 256 buttons = 8 x 32 bit words
prevbuttons = { 0, 0, 0, 0, 0, 0, 0, 0 }


function Poll(time)
-- We use "readlast" so the values we use are the most up-to-date
  CurrentData, n, discards = com.readlast(dev, rd)
-- Extract values we need
  if n ~= 0 then
-- Now handle the buttons : up to 256 of them!
  	  buttons[1], buttons[2], buttons[3], buttons[4],
  	  buttons[5], buttons[6], buttons[7], buttons[8] = 
  	  	com.GetHidButtons(dev, CurrentData)
  	  	
  	  -- check for changes   
    	i = 1
    	while i <= 8 do
    	    if buttons[i] ~= prevbuttons[i] then
    	        prevbuttons[i] = buttons[i]
    	        -- Send to FSUIPC as a set of 32 virtual buttons
    	        -- i.e. DWORD offsets 3340 onwards
    	        ipc.writeUD(0x3340 + ((i-1) * 4), buttons[i])
    	    end
    	    i = i + 1
		end
	end
end

------------------------------------------------------------------------

if init then
   -- Deal with initial values, if supplied (some joysticks don't)
   ipc.log("init seen!")
   Poll(0)
end

if Pollrate == 0 then
   -- Ouch. Mustn't divide by zero!
   Pollrate = 25 
end


event.timer(1000/Pollrate, "Poll")  -- poll values 'Pollrate' times per second

Thank you once again for FSUIPC-LUA, whose seemingly limitless possibilities never cease to amaze me, and thank you for your patience!

 

Warm Regards,

 

Chakko.

[Pete Dowson]

I have found the problem lay in the code I had used earlier. I had omitted a condition n ~= 0, and I had omitted the init section.....one of these omissions was the culprit. When I inserted both and re-ran the lua, all 256 encoders/buttons were recognised as virtual buttons in the range you have specified in the manual.

 

Excellent! That was easy, then! ;-)

 

Thanks for reporting back.

 

Pete

[ckovoor]

Hi Pete,

 

While testing the arrangement I found that the first 32 buttons seemed to be recognised by FSUIPC as belonging to two separate joysticks. Here is the relevant extract from the FSUIPC.ini file:

 

[JoyNames]
AutoAssignLetters=Yes
1=CH PRO PEDALS USB
1.GUID={DBCB2B40-097E-11E1-8002-444553540000}
:

:
11=C.V.P Joystick
11.GUID={6EDD62E0-6079-11E5-8001-444553540000}
T=C.V.P Joystick

 

 

So my Arduino Mega is being recognized simultaneously as 11=C.V.P Joystick and T=C.V.P Joystick. I am guessing that the former is a reference to a virtual joystick and the latter is a Windows Game Controller (not sure of the terminology).

 

The consequence of this is that in the FSUIPC window, for the first 32 assignable buttons, I am getting (flashing) dual references (for instance Joy#T:Btn# 0 and Joy#64:Btn#0). There is no problem after the 32nd button.....only the virtual joystick buttons appear after that (Joy#65:Btn#0 onwards).

 

My short term solution is to avoid the first 32 buttons, since I still have the remaining 224. But is there a better solution......to get FSUIPC to recognise the first 32 only one way? Preferably to see those as only belonging to the virtual joystick, for the sake of consistency.

 

Thanks and Regards,

 

Chakko.

[Pete Dowson]

While testing the arrangement I found that the first 32 buttons seemed to be recognised by FSUIPC as belonging to two separate joysticks. Here is the relevant extract from the FSUIPC.ini file:

 

[JoyNames]

AutoAssignLetters=Yes

1=CH PRO PEDALS USB

1.GUID={DBCB2B40-097E-11E1-8002-444553540000}

:

:

11=C.V.P Joystick

11.GUID={6EDD62E0-6079-11E5-8001-444553540000}

T=C.V.P Joystick

 

 

So my Arduino Mega is being recognized simultaneously as 11=C.V.P Joystick and T=C.V.P Joystick. I am guessing that the former is a reference to a virtual joystick and the latter is a Windows Game Controller (not sure of the terminology).

 

The virtual button range can only be set by software designed to set the bits in those offsets. Any regularly recognised joystick device will be seen by FSUIPC and is assignable, but can only have the joystick numbers 0-15. These are the IDs assigned normally by Windows and found in the Registry.

 

There's no way such a device can also appear in the virtual joystick range unless there's some driver or other software (like your Lua plug-in) actually writing to the offsets for those virtual buttons.

 

In the case you are citing, the C.V.P. Joydtick had the ID 11. That's why you have "11=C.V.P Joystick". Because it has been assigned the letter T it will appear in the FSUIPC option tabs as Joystick T.

 

The consequence of this is that in the FSUIPC window, for the first 32 assignable buttons, I am getting (flashing) dual references (for instance Joy#T:Btn# 0 and Joy#64:Btn#0)

 

 

 

T and 64 are absolutely distinct as far as FSUIPC are concerned. One is a DirectInput device, the other merely a set of bits in an offset. You have something else going on. There's no way anything in FSUIPC can invent an input on a regular joystick which it is reading in the usual way via DirectInput.  So the CVT joystick button inputs to the PC itself are being triggered by your other device. I can't really speculate further than that. All I can say that this is all happening outside of FSUIPC, and probably outside of Windows too. It would be a driver or a hardware or a hub problem.

 

Pete

[ckovoor]

There's no way such a device can also appear in the virtual joystick range unless there's some driver or other software (like your Lua plug-in) actually writing to the offsets for those virtual buttons.

Pete

Hi Pete,

Well, before I run the lua plugin, FSUIPC sees only joystick T with 32 buttons, and there is no conflict. The virtual joystick buttons (starting at Joy#64:Btn#0) appear only after I start the lua plugin. So the lua plugin is creating all these virtual buttons. And the first 32 of these buttons are mapped to the same hardware as the first 32 on joystick T. The conflict would end there since T cannot show more than 32. Is my understanding correct?

So then my question would be whether there is any way (perhaps a programmatic way?) of preventing the lua plugin from generating virtual buttons which would be in conflict (or dually assigned) with those from joystick T?

Thanks for your patience,

Chakko.

[Pete Dowson]

Well, before I run the lua plugin, FSUIPC sees only joystick T with 32 buttons, and there is no conflict. The virtual joystick buttons (starting at Joy#64:Btn#0) appear only after I start the lua plugin. So the lua plugin is creating all these virtual buttons. And the first 32 of these buttons are mapped to the same hardware as the first 32 on joystick T. The conflict would end there since T cannot show more than 32. Is my understanding correct?

 

I don't know how what you are describing could happen. if you unplug your joystick "T", does your other USB connection still provide input? If so it is being recognised in Windows as a normal joystick device and it seems to have been assigned the same joystick ID.

 

Please look at the FSUIP4.LOG file. If you are using FSUIPC version 4.947c or later (i.e the current release) it will log the devices it scans initially. Also download the "JoyIDs" utility (see the additional useful programs thread in the Download Links subforum). When you run that it should show the IDs assigned to each device, and allow you to change them. You could try changing the ID of one or the other.

 

I'm actually rather mystified by the ID your 'T' device seems to respond to in any case -- 11 is higher than any such assignment I've ever seen. They tend to be assigned in order, so it implies that at some time you had 10 other installed joystick devices. Or did you omit all the others in your earlier post?

 

So then my question would be whether there is any way (perhaps a programmatic way?) of preventing the lua plugin from generating virtual buttons which would be in conflict (or dually assigned) with those from joystick T?

 

 

Of course. You'd simply use offset 0x3344 as the base instead of 0x3340. The only thing determining the virtual button number is its offset and bit position! However, I think you should resolve the problem first, if possible. 

 

Luckily there is room in the FSUIPC implementation for 9 x 32 buttons, not just the 8 x 32 you need. However, I think going this way and ignoring the strange thing which is happening is not correct.

 

Pete

[ckovoor]

Hi Pete,

 

Let me review this, to make sure you have understood the scenario, as I may not have been very clear.

 

There is only one physical USB joystick suffering the conflict in this case: the Arduino Mega configured as a USB-HID rather than as a USB-COM device.

 

Here is the full FSUIPC.ini JoyNames section......I had omitted the irrelevant parts earlier

[JoyNames]
AutoAssignLetters=Yes
1=CH PRO PEDALS USB
1.GUID={DBCB2B40-097E-11E1-8002-444553540000}
2=Saitek Pro Flight Yoke
2.GUID={DBCB2B40-097E-11E1-8003-444553540000}
4=Saitek Pro Flight Quadrant
4.GUID={DBCB2B40-097E-11E1-8005-444553540000}
A=CH PRO PEDALS USB
A.GUID={DBCB2B40-097E-11E1-8002-444553540000}
B=Saitek Pro Flight Yoke
B.GUID={DBCB2B40-097E-11E1-8003-444553540000}
C=Saitek Pro Flight Quadrant
C.GUID={DBCB2B40-097E-11E1-8005-444553540000}
D=BU0836X Interface
E=One-Shot Pulse Gen Model 2160
F=BU0836X Interface
F.GUID={05EBBDE0-5281-11E1-8001-444553540000}
G=CH PRO PEDALS USB
H=Saitek Pro Flight Yoke
3=SideWinder Force Feedback 2 Joystick
3.GUID={B2C832F0-261C-11E1-8001-444553540000}
J=SideWinder Force Feedback 2 Joystick
J.GUID={B2C832F0-261C-11E1-8001-444553540000}
K=Pro Flight Cessna Trim Wheel
K.GUID={DBCB2B40-097E-11E1-8004-444553540000}
L=SideWinder Force Feedback 2 Joystick
D.GUID={247DEDD0-2127-11E2-8001-444553540000}
G.GUID={52390D80-C921-11E1-8001-444553540000}
M=Virtual Joystick
M.GUID={5C04E460-3A2D-11E2-8001-444553540000}
10=SideWinder Force Feedback 2 Joystick
10.GUID={FC327BD0-CC5C-11E1-8001-444553540000}
8=CH PRO PEDALS USB
8.GUID={52390D80-C921-11E1-8001-444553540000}
9=Saitek Pro Flight Yoke
9.GUID={5287F0D0-C921-11E1-8002-444553540000}
N=BU0836X Interface
N.GUID={B964AF70-7EA3-11E4-8001-444553540000}
5=DTA Rotary Encoder
5.GUID={DBCB2B40-097E-11E1-8008-444553540000}
6=One-Shot Pulse Gen Model 2160
6.GUID={DBCB2B40-097E-11E1-8009-444553540000}
7=BU0836X Interface
7.GUID={05EBBDE0-5281-11E1-8001-444553540000}
X=<< MISSING JOYSTICK >>
0=Pro Flight Cessna Trim Wheel
0.GUID={DBCB2B40-097E-11E1-8004-444553540000}
P=BU0836X Interface
P.GUID={5CF9E380-06C6-11E5-8001-444553540000}
13=BU0836X Interface
13.GUID={247DEDD0-2127-11E2-8001-444553540000}
Q=DTA Rotary Encoder
Q.GUID={DBCB2B40-097E-11E1-8008-444553540000}
14=BU0836X Interface
14.GUID={B964AF70-7EA3-11E4-8001-444553540000}
R=One-Shot Pulse Gen Model 2160
R.GUID={EB0D3BD0-1C07-11E5-8001-444553540000}
S=Virtual Joystick
S.GUID={5C04E460-3A2D-11E2-8002-444553540000}
11=C.V.P Joystick
11.GUID={6EDD62E0-6079-11E5-8001-444553540000}
T=C.V.P Joystick

Yes, I do have all those devices connected! :oops:

 

Okay, so if I start FSX with the Arduino connected (but without the lua plugin running), and open the FSUIPC dialog window to the Buttons + Switches tab, and operate any of the first 32 buttons on the Arduino, I will see FSUIPC responses ranging from Joy#T:Btn#0 to Joy#T:Btn#31. There is no conflict at this stage. If I operate physical buttons beyond the first 32 , say # 56, I do not see any response in the FSUIPC window.

 

Now, I go back into FSX and start the lua plugin. Then I return to the FSUIPC dialog box - Button + Switches tab. This time when I operate any of the first 32 buttons on the Arduino, I see either Joy#T or Joy#64 flash alternately in the Joy# window (but the same number in the Btn# window). So now the Arduino hardware seems to have a dual mapping to both Joy#T and Joy#64 (which was of course a virtual joystick created by the lua plugin). These conflicts occur for the first 32 buttons only, but not thereafter. From the 33rd Arduino button onwards, Joy#T does not appear anymore in the Joy window, only the appropriate virtual Joy#(65 to 71).

 

I tried changing the offset base to 0x3344 in the lua plugin, but all that did was to make the virtual Joy#'s start from 65 rather than 64. Conflicts still occur with Joy#T for the first 32 buttons.

 

If by the JoyID's utility you mean HiDScanner, then I have already run that to discover the Arduino data which needed to be inserted into the lua.

 

Thank you again for your patience and encouragement. :razz:

 

Regards,

 

Chakko.

[ckovoor]

Hi Pete,

Here is the FSUIPC log, in case that helps:

********* FSUIPC4, Version 4.947d by Pete Dowson *********
Reading options from "E:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini"
Running inside FSX on Windows 7
Module base=5C3F0000
User Name="Chakko Kovoor"
User Addr="xxxxx@xxx.xxx.xxx"
FSUIPC4 Key is provided
WideFS7 Key is provided
       31 System time = 21/10/2015 00:48:48
       31 FLT UNC path = "\\SERVER\Flight Simulator X Files\"
      842 Trying to connect to SimConnect Acc/SP2 Oct07 ...
      858 FS UNC path = "\\SERVER\Microsoft Flight Simulator X\"
     1170 ---------------------- Joystick Device Scan -----------------------
     1170 Product= 001
     1170    Manufacturer= Arduino
     1170    Vendor=03EB, Product=2043 (Version 0.3)
     1170    Serial Number= C2
     1170 Product= SideWinder Force Feedback 2 Joystick
     1170    Manufacturer= Microsoft
     1170    Vendor=045E, Product=001B (Version 10.0)
     1170    Serial Number= 
     1170 Product= SideWinder Force Feedback 2 Joystick
     1170    Manufacturer= Microsoft
     1170    Vendor=045E, Product=001B (Version 10.0)
     1170    Serial Number= 
     1186 Product= CH PRO PEDALS USB 
     1186    Manufacturer= CH PRODUCTS
     1186    Vendor=068E, Product=00F2 (Version 0.0)
     1186    Serial Number= 
     1186 Product= CH PRO PEDALS USB 
     1201    Manufacturer= CH PRODUCTS
     1201    Vendor=068E, Product=00F2 (Version 0.0)
     1201    Serial Number= 
     1201 Product= Saitek Pro Flight Yoke
     1201    Manufacturer= Saitek
     1201    Vendor=06A3, Product=0BAC (Version 3.3)
     1201    Serial Number= 
     1201 Product= Saitek Pro Flight Yoke
     1201    Manufacturer= Saitek
     1201    Vendor=06A3, Product=0BAC (Version 3.2)
     1201    Serial Number= 
     1201 Product= Pro Flight Cessna Trim Wheel
     1201    Manufacturer= Saitek
     1201    Vendor=06A3, Product=0BD4 (Version 1.6)
     1201    Serial Number= RD001180
     1201 Product= Saitek Pro Flight Quadrant
     1201    Manufacturer= Saitek
     1201    Vendor=06A3, Product=0C2D (Version 2.0)
     1201    Serial Number= 
     1201 Product= DTA Rotary Encoder
     1201    Manufacturer= Desktop Aviator
     1201    Vendor=16C0, Product=27CB (Version 1.33)
     1201    Serial Number= A12057
     1201 Product= One-Shot Pulse Gen Model 2160
     1201    Manufacturer= Desktop Aviator
     1201    Vendor=16D0, Product=0484 (Version 0.1)
     1201    Serial Number= DTA00271
     1201 Product= BU0836X Interface
     1201    Manufacturer= Leo Bodnar
     1201    Vendor=1DD2, Product=1001 (Version 1.35)
     1217    Serial Number= B14857
     1217 Product= BU0836X Interface
     1217    Manufacturer= Leo Bodnar
     1217    Vendor=1DD2, Product=1001 (Version 1.35)
     1217    Serial Number= B20455
     1217 Product= BU0836X Interface
     1217    Manufacturer= Leo Bodnar
     1217    Vendor=1DD2, Product=1001 (Version 1.35)
     1217    Serial Number= B20453
     1217 -------------------------------------------------------------------
     2044 Run: "C:\Program Files (x86)\IObit\Game Booster 3\GameBooster.exe -game"
     2449 Run: "C:\Program Files (x86)\SPAD\Spad.exe"
     2699 Run: "C:\Program Files (x86)\CH Products\CMStart.exe"
     2792 Run: "C:\Program Files (x86)\WinLayoutManager\WinLayoutManager.exe"
     3416 Run: "E:\Microsoft Flight Simulator X\FsRaas20\FsRaas20.exe"
     3526 Run: "E:\ToggleIDMacros.exe"
     3760 Run: "C:\Program Files (x86)\AivlaSoft\EFB\AivlaSoft.Efb.DataProvider.exe"
     4196 Run: "E:\PILOTS_FSGRW_NETWORKBRIDGE\FS Global Real Weather Network Bridge.exe"
     4633 Run: "C:\Windows\System32\cmd.exe /c "net stop "audiosrv" & net start "audiosrv""
     4633 LogOptions=00000000 00000001
     4649 -------------------------------------------------------------------
     4649 ------ Setting the hooks and direct calls into the simulator ------
     4649 --- CONTROLS timer memory location obtained ok
     4649 --- SIM1 Frictions access gained
     4649 --- FS Controls Table located ok
     4649 --- Installed Mouse Macro hooks ok.
     4649 --- Wind smoothing fix is fully installed
     4649 --- G3D.DLL fix attempt installed ok
     4649 --- All links checked okay
     4649 -------------------------------------------------------------------
     4649 SimConnect_Open succeeded: waiting to check version okay
     4649 Trying to use SimConnect Acc/SP2 Oct07
     8284 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0)
     8284 Initialising SimConnect data requests now
     8284 FSUIPC Menu entry added
     8315 \\SERVER\Flight Simulator X Files\FSX Startup for Complex Aircraft.FLT
     8315 \\SERVER\Microsoft Flight Simulator X\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR
    27753 System time = 21/10/2015 00:49:15, Simulator time = 13:30:30 (20:30Z)
    28533 Aircraft="Aircreation582SL red"
    30171 Starting everything now ...
    31512 Advanced Weather Interface Enabled
   694080 Sim stopped: average frame rate for last 500 secs = 22.7 fps
   725919 Sim stopped: average frame rate for last 21 secs = 75.9 fps

Thanks,

 

Chakko.

[Pete Dowson]

There is only one physical USB joystick suffering the conflict in this case: the Arduino Mega configured as a USB-HID rather than as a USB-COM device.

 

Yes, Joystick 11, assigned as T.

 

Here is the full FSUIPC.ini JoyNames section......I had omitted the irrelevant parts earlier

Yes, I do have all those devices connected!  :oops:

 

Phew! That's almost completely full! One more device and you've reached the FSUIPC/joyGetPosEx limit of 16 distinct joysticks! (There is no such limit in DirectInput, but FSUIPC was written long before that).

 

I tried changing the offset base to 0x3344 in the lua plugin, but all that did was to make the virtual Joy#'s start from 65 rather than 64. Conflicts still occur with Joy#T for the first 32 buttons.

 

So it MUST be something to do with the Arduino connection -- somehow it is activating and sending some copy data when the DirectInput polling request is sent to the #11 device. It's only picked up for the virtual button offsets when the Lua program is running to actually pick up that "echoed" data.

 

It has to be either the Arduino itself, or possibly the hub.  What's the physical arrangement like between the two device? Are they sharing a pair on the PCs' motherboard, or on the same hub? I think this is the area you need to investigate. It has to be in that area. There's no other way for what you describe to happen. You could try swapping some USB connections around. I wouldn't be surprised is the association then changed to one of the others.

 

If by the JoyID's utility you mean HiDScanner, then I have already run that to discover the Arduino data which needed to be inserted into the lua.

 

No. HIDScanner does not get the Joystick IDs, only the HID device details. The ID is in another part of the registry. JoyIDs shows all those and allows you to change them.  I thought I put a link to JoyIDs where I told you, but I was mistaken. It's actually in the FAQ subforum, in this thread:

 

Fixing joystick connections not seen by fsuipc

 

BTW, can you look at the HidScanner log. Are the Vendor and Product IDs definitely different between your Arduino and the PVT Joystick? I would hope so, but you never know. I've not heard of P V T before. Maybe it's Arduino based?

 

Pete

 

[ckovoor]

So it MUST be something to do with the Arduino connection -- somehow it is activating and sending some copy data when the DirectInput polling request is sent to the #11 device. It's only picked up for the virtual button offsets when the Lua program is running to actually pick up that "echoed" data.

 

It has to be either the Arduino itself, or possibly the hub.  What's the physical arrangement like between the two device? Are they sharing a pair on the PCs' motherboard, or on the same hub? I think this is the area you need to investigate. It has to be in that area. There's no other way for what you describe to happen. You could try swapping some USB connections around. I wouldn't be surprised is the association then changed to one of the others.

 

BTW, can you look at the HidScanner log. Are the Vendor and Product IDs definitely different between your Arduino and the PVT Joystick? I would hope so, but you never know. I've not heard of P V T before. Maybe it's Arduino based?

 

Hi Pete,

 

Thank you very much for taking so much time out to deal with this oddity ..... my own hunch is that you are right about some duplication of sent data at the firmware level. The firmware was written by overpro (who chipped in briefly earlier) and I will request him to tell us more about what is happening there.

 

As for the C.V.P Joystick, that is the Arduino itself! Once the firmware (various files created by overpro) is loaded onto the Arduino, that is the new name under which Arduino seems to announce itself to the various joystick testers available (including the Windows 7: Devices and Printers listing). I am sure overpro can tell us more about the origin of that name. :???:

 

Here is a screenshot of the JoyID scan:

 

 

in which you can see the Arduino as C.V.P Joystick (Id#12)

 

I have also attached the complete log from HiDScanner, but here the only reference to the Arduino is:

 

********* HidScanner, Version 2.00 by Pete Dowson *********

 

  Device at "\\?\hid#vid_03eb&pid_2043&mi_00#8&392dae83&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

  Vendor=03EB, Product=2043 (Version 0.3)

  Manufacturer= Arduino

  Product= 001

  Serial Number= C2

  Usage Page: 1

  Input Report Byte Length: 49

  Output Report Byte Length: 0

  Feature Report Byte Length: 0

  Number of Link Collection Nodes: 2

  Number of Input Button Caps: 1

  Number of InputValue Caps: 8

  Number of InputData Indices: 264

  Number of Output Button Caps: 0

  Number of Output Value Caps: 0

  Number of Output Data Indices: 0

  Number of Feature Button Caps: 0

  Number of Feature Value Caps: 0

  Number of Feature Data Indices: 0

  Buttons range 1 -> 256 at indices 8 -> 263

  Value Dial at index 0, range 0 -> 65535, using 16 bits

  Value Sldr at index 1, range 0 -> 65535, using 16 bits

  Value R/RZ at index 2, range 0 -> 65535, using 16 bits

  Value V/RY at index 3, range 0 -> 65535, using 16 bits

  Value U/RX at index 4, range 0 -> 65535, using 16 bits

  Value Z at index 5, range 0 -> 65535, using 16 bits

  Value Y at index 6, range 0 -> 65535, using 16 bits

  Value X at index 7, range 0 -> 65535, using 16 bits

  **************************************************************************

 

There does not appear to be a separate reference to its other avatar C.V.P Joystick here (unless I have missed it).

 

I have many many more USB devices, and they are almost all connected to the PC via powered USB hubs, as is the Arduino. The powered hubs have not so far given me any trouble in terms of dropped or swapped USB connections. However, I will try to play with those connections and get back to you.

 

Thank you again for your patience and encouragement!

 

Chakko.

HidScanner.txt

[overpro]

in device descriptor, the manufacture string is "Arduino", product string is "C.V.P Joystick". Serial number is "C2", HID interface string is "001"

 

I haven't tried using DirectInput to read the Input HID report from this joystick, I just used Microsoft Message Analyzer to intercept the RAW HID report and everything looks good for now.

Edited October 21, 2015 by overpro

[Pete Dowson]

As for the C.V.P Joystick, that is the Arduino itself!

 

 

Aha! That explains everything! In that case you don't really want it installed as a joystick as well as operating it via Lua. When the DirectInput polling function is being used the response is also recognised by the Lua plug-in. It cannot avoid it.

 

Actually, it might be cleaner to assign the first 32 buttons as the CVP Joystick, and discard the first 32 buttons in the Lua. i.e. still start at offset 0x3340 as before but start with i = 2 when using the results, so:

-- check for changes    i = 2

 in which you can see the Arduino as C.V.P Joystick (Id#12)

 

 

Yes, but to FSUIPC it is 11. FSUIPC and DirectInput and the Registry all count from 0. Windows and FS add 1.

 

There does not appear to be a separate reference to its other avatar C.V.P Joystick here (unless I have missed it).

 

No. it is only one device. And it wasn't listed in the FSUIPC4 log file you showed earlier either. Nevertheless it got identified as such and added to the FSUIPC4 INI file as #11. I think it's all down to Registry details vs DirectInput.

 

At least you answered the puzzle which had me Royally confused! :smile:

 

in device descriptor, the manufacture string is "Arduino", product string is "C.V.P Joystick". Serial number is "C2", HID interface string is "001"

 

I haven't tried using DirectInput to read the Input HID report from this joystick, I just used Microsoft Message Analyzer to intercept the RAW HID report and everything looks good for now.

 

The "Product" is read differently for the FSUIPC scanning log. Currently, as you could see earlier, it includes:

 

1170 Product= 001

1170 Manufacturer= Arduino

1170 Vendor=03EB, Product=2043 (Version 0.3)

1170 Serial Number= C2

 

This is the same as the HidScanner results (because it is basically dong the same thing). 

 

If you look at all the other devices in the scan in the log, the "correct" product name is shown.

 

The difference is that the [JoyNames] product description is obtained from the Registry, not via DirectInput. Until I recently added the scanning code (in 4.947), FSUIPC only used the Registry, and in fact it is only there you get the Windows ID number assigned.  I'm not quite sure what you'd read via DirectInput to get the same Product String ... it should be there, I would have thought ... UNLESS it is just an installation descriptor, from the .INF file which is normally needed to enter the Registry stuff. Yes, I bet that's it!

 

Pete

[ckovoor]

 

Aha! That explains everything! In that case you don't really want it installed as a joystick as well as operating it via Lua. When the DirectInput polling function is being used the response is also recognised by the Lua plug-in. It cannot avoid it.

 

Actually, it might be cleaner to assign the first 32 buttons as the CVP Joystick, and discard the first 32 buttons in the Lua. i.e. still start at offset 0x3340 as before but start with i = 2 when using the results, so:

-- check for changes    i = 2

 

Hi Pete,

 

Thanks for the explanation and the solution. I set i = 2 in the lua and of course it works cleanly.......Arduino physical buttons (1 to 32) are uniquely mapped to the range (Joy#T:Btn#0 to Joy#T:Btn#31), and physical buttons (33 to 256) are uniquely mapped to (Joy#65:Btn#0 to Joy#71:Btn#31). All very neat and predictable, and no dual mappings. Thank you!

 

You imply that it is also possible to prevent Arduino being installed as a joystick (and so have it operated solely via Lua). How would this be achieved? Some might prefer that solution as then we would have one device (with 256 buttons), rather than two (with 32  + 224).

 

Thank you so much for your help!

 

Chakko.

[Pete Dowson]

You imply that it is also possible to prevent Arduino being installed as a joystick (and so have it operated solely via Lua). How would this be achieved?

 

I'm not sure if it would be permanent, but it's removing the joystick stuff for it from the Registry. You could try uninstalling it via the Windows Device Manager.

 

However, I think you'd also have to find the INF file for it too, and remove that, otherwise Windows ight simply install it again next time you boot.

 

I assume when you connected the Arduino in the first place you ran some installation program?

 

[LATER]

 

Searching my Windows\inf folder I see Arduino mentioned in at least 3 inf files -- oem59, oen60 and oem61. Those cover a load of different devices so I wouldn't delete or fiddle with them.

 

I think it's a matter of trying things. I don't really know enough about this side of things I'm afraid. You might have to stick with what works after all.

 

Pete

[overpro]

I suspect there is no easy way to prevent a HID device to be installed automatically, the USB host (Windows) retrieve the interface descriptor and if it's a HID interface then a default driver will be used.

Edited October 21, 2015 by overpro

[Pete Dowson]

I suspect there is no easy way to prevent a HID device to be installed automatically, the USB host (Windows) retrieve the interface descriptor and if it's a HID interface then a default driver will be used.

 

Yes, but the problem here is that it doesn't just say its a HID device, but a Joystick type HID device, which surely Arduino's aren't by default? They can be used in all sorts of ways. I have one driving some indicator lights and that doesn't seem to appear as a joystick at all. I installed it's software so I could program it, of course, but it just isn't appearing as a joystick at all. Same with most GoFlight units other than yoke and throttle quadrants.

 

Pete

[ckovoor]

Hi Pete,

 

I have another question about all this......could (event.com + com.getHidButtons) be used instead of (event.timer + com.readlast) to read the button/encoder inputs? I tried running this:

Vendor = 0x03EB
Product = 0x2043
Device = 0 
Report = 0

dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report)

if dev == 0 then
   ipc.log("Could not open HID")
   ipc.exit()
end

buttons = {}
-- Up to 256 buttons = 8 x 32 bit words

function Poll(dev, CurrentData, rd)
-- Now handle the buttons : up to 256 of them!
  	  buttons[1], buttons[2], buttons[3], buttons[4],
  	  buttons[5], buttons[6], buttons[7], buttons[8] = 
  	  	com.GetHidButtons(dev, CurrentData)
  	  	
  	-- ignore first 32 buttons by setting i = 2   
    	i = 2
    	while i <= 8 do
    	        -- Send to FSUIPC as a set of 32 virtual buttons
    	        -- i.e. DWORD offsets 3340 onwards
    	        ipc.writeUD(0x3340 + ((i-1) * 4), buttons[i]) 
    	    i = i + 1
		end
end

event.com(dev, rd, rd, "Poll")

and while FSUIPC did not complain, it didn't work.......button presses in the virtual joystick range were not being recorded. Could you please tell me why.

 

Thanks again for your time and patience.......I absolutely appreciate it!

 

Regards,

 

Chakko.

[Pete Dowson]

I don't remember the exact explanation for this, but It's to do with the way USB devices work, relative to an ordinary serial port device.

 

The COM functions were designed for normal RS232 type connections (like my PFC equipment, and USB HID support added later. FSUIPC is effectively polling continuously for data, and most ordinary serial devices supply none unless there is some. But USB returns a packet every time, whether anything's changed or not.

 

The readlast function was added to make things more efficient, rather than processing every single frame in a loop. You'd use your changed code for normal serial port devices.otherwise you could miss stuff.

 

Why did you change a working program in any case?

 

Pete