Pete Dowson

I've been analysing the Registry exports you sent and trying to relate them to the last FSUIPC log I got from you, the only with the Extra logging. They don't match. There is no way that log is from the same machine, or in the same situation (i.e. no removals or reinstalls of the X-55 between) as the registry exports. Background If you refer to the top (pinned) thread in this Forum, you will see that I now have this sort of information from Paul Henty, one of the many successfully running an X-55 system with FSUIPC 4.966c. Comparing his registry with yours I was hoping to find the problem, assuming it it registry rather than hardware or connections. First off, oddly, for both Throttle and Stick, there are two entries each. On Paul's system the Stick pair both have the same GUIDs -- which should be impossible! However, only one has a Joystick ID, and that, the first, is the one FSUIPC chooses. For the Throttle the two have different GUIDs, and again onl the first has a Joystick ID. FSUIPC chooses that. When FSUIPC knows that there are 2 devices it will be looking for the details for the second. but in these cases there's only one, and FSUIPC therefore assumes there's only one entry and chooses the first. I suspect that through some error during installation the Throttle using on your system is actually using the second. However, without further analysis on your setup I can't progress that further and work out what to do. Action Please So, please can you do this: 1. Make sure you still have Debug=Please LogExtras=x200000 in the [General] section of the FSUIPC4.INI 2. Run the Sim till ready to fly, then close it. 3. Repeat the Registry export process to get two .reg files and rename them to .txt. 4. ZIP the 3 files together and send to me again. This will make sure everything tallies. Thanks, Pete

Sorry, that is well out of date. The supported version is 4.966c. Please update. Use the right-hand side of the Axis assignments tab as explained in the user manual. Don't assigned to keypresses though unless they are unique to the add-on. Use the FS controls to which those key presses are assigned -- Elev Trim Up and Elev Trim Dn. Pete

Thanks. Unfortunately the Lua did nothing because it couldn't even open the devices: 128968 LUA.2: Could not open HID Vendor 0738 Product 2215 I'll make another small modification to it to try again. If it still doesn't work, I'm stumped. Please replace it and try again. Same method. HidX55.lua

I have a Lua plug-in to try. this is just to give me some information. I'm considering offering an alternative more for reading such devices, but if the alternative gives the same then I'm likely to point to faulty harware, or firmware unsuited to use with Win10. I read some of the reviews of the X56, the new one replacing the X-55, and that was apparently released with old firmware. Maybe X-55 users need to see if they are up to date? Anyway, here's the Lua plug-in. I have no idea if it will do exactly what I want it to do, but I'll be able to tell from the FSUIPC log. Please remove those extra logging lines in the INI and turn off Axis and Button logging because that will cloud the issue. Then place this Lua in the Modules folder, run the sim, then in the Keypress tab, assign an otherwise un-needed keypress (or combo) to "Lua Hidx55". Back in flight mode, press the assigned key or combo, and just move the sticks, press the buttons, operate the hats, on both devices. close the sim and sohw me the log. Thanks. Pete HidX55.lua

The log shows some axis activity, though by the look of it from "zero2 being received from the units. Was that with the X55 units, and they are returning just zeroes, as in the case of Kegs1953? 22360 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 0 (0x00000000) AXIS_AILERONS_SET 22360 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 0 (0x00000000) AXIS_ELEVATOR_SET 22360 *** AXIS: Cntrl= 66387 (0x00010353), Param= -8736 (0xffffdde0) AXIS_LEFT_BRAKE_SET 22360 *** AXIS: Cntrl= 66388 (0x00010354), Param= -8840 (0xffffdd78) AXIS_RIGHT_BRAKE_SET 22360 *** AXIS: Cntrl= 65764 (0x000100e4), Param= 0 (0x00000000) AXIS_RUDDER_SET 22547 C:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\VRS_FA-18E\FA-18E-6.8_SE.air 22547 Weather Mode now = Global 22547 c:\users\kurt\documents\flight simulator x files\FA-18E at Miramar.FLT 24485 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 0 (0x00000000) AXIS_AILERONS_SET 24485 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 0 (0x00000000) AXIS_ELEVATOR_SET 24485 *** AXIS: Cntrl= 65764 (0x000100e4), Param= 0 (0x00000000) AXIS_RUDDER_SET 26125 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 26203 User Aircraft ID 1 supplied, now being used 26266 Aircraft loaded: running normally now ... 26344 *** AXIS: Cntrl= 66420 (0x00010374), Param= -16384 (0xffffc000) AXIS_THROTTLE1_SET 26344 *** AXIS: Cntrl= 66423 (0x00010377), Param= -16384 (0xffffc000) AXIS_THROTTLE2_SET

Have you got any further? Have you made any axis and button assignments yet to your X-55 devices (stick and throttle?). If you have things working in FSUIPC, could you do me a favour, please? Provide some logs. Add these lines to the FSUIPC4.INI file's [General] section: Debug=Please LogExtras=x200000 then just run the sim for a short time, using the X55 a bit 9axes, buttons). Close down and show me the log -- or send it, ZIPped to petedowson@btconnect.com. Thanks. Pete

Sorry, what are they? Are you referring to some action documented in case of problem, relating to Joystick IDs, which actually isn't needed now and involved a program called JoyIDs? Or do you mean the resistry fixes to the bad install Saitek does? Have they not even fixed that yet? That is extremely strange, because both axis values and buttons are read at the same time, in the same actual operation. They are indivisible. You are now the third person here with outstanding X-55 problems, and all three of you have different problems but ALL with the X-55 (and all on Win10 which may also be relevant). One has neither stick nor throttle seen, another has stick but no throttle inputs, and now you with axes okay but no buttons. The X-55 is a nightmare. Can you please refer to the other two threads and supply the same data, so I can compare it? They are by "OldPop" and 2Kegs1953". Best go to the last few exchanges or you'll get very confused. it even confuses me. I'm going to try to get someone with a working X-55 set to supply similar data for a comparison with what it should look like. Pete

MakeRunways cannot possibly change the files it creates to different types. They are still csv files. You are being befuddled by Windows' habit of defaulting the Windows Explorer option for showing the full filename to off. It then classifies them according to what Application it thinks might read them. Excel can read csv files. This stupid and annoying setting also classifies .log, files as text files and .ini as configuration files. The FSUIPC user guide advises you to change that option. Left to default, it doesn't do any harm except mislead you and confuse you. Why are you worried about it in any case? Programs which use the MakeRunways files won't be bothered. Pete

Did you plug in to the same USB port? Here I can unplug and replug devices at any time, whether FS/P3D is running or not. The assignments stay. They are dictated by the Registry, not by FSUIPC. But then though I've got, for instance, two apparently identical Bodnar boards, Windows and therefore FSUIPC distinguishes them by their Serial numbers, which, unfortunately, many devices don't supply on the USB interface. Are you sure when you say "FSUIPC did not recognize any of the controllers" that the two Pokeys were not simply swapped? Apart from two Pokeys, what others are there? How did you decide FSUIPC didn't recognize them? Deleting JoyNames won't magically make FSUIPC "recognize" joystick devices! the entries there only tell it how to assign them when it has recognised them. so I think you are not describing this properly. What probably happened was that, since the Pokeys devices are probably indistinguishable to FSUIPC, it saw them in a different order and so cross-assigned them. the fix is simply to change the numbers or letters or both over in the JoyNames section. Pete

Ah, sorry. I misread. So you have two sets of identical controls, like me, and simply want to assign both sides to the same controls? And are both sets identical devices? Are they connected differently -- different USB hub perhaps? Or one via a hub the other not? As well as the INI and LOG files as requested by Thomas: Could you run my HidScanner utility please and send me the log file it makes? It’d in the “useful additional programs” thread of “Download Links” subforum. Also export the relevant registry parts: HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties Do this by running RegEdit from the Windows start menu, going down the Explorer style layers to those and with that layer selected do File-Export give them each a name (it’ll save as a .reg file). Then rename them from .reg to .txt so the mail system or my anti-virus doesn’t reject them (.reg files, when run, change the registry), and send those to me at petedowson@btconnect.com. Just going back to your first post (added rather misleadingly to a thread mainly about X-55's, which seem to be the main source of problem), you said Any reason you are not assigning directly in ProSim? I think that's the more usual way for ProSim users. Does that not see both sets? (I'm a ProSim user, but cannot assign that way because my controls are PFC serial port devices, handled by my own drivers). Also, can you say what might have changed 'recently' when they stopped responding in FSUIPC? Thanks Pete

That means the full left deflection is giving a HIGHER value than the others. You have to have the LOWEST in the "minumum" column. You are mixing up "minimum" with left. It is the NUMERIC minimum, not necesarily the way the stick moves matching the screen orientation. If you want to start with the left deflection giving a maximum value, click thethe Maximum" side instead first, or just start with full right deflection. FSUIPC calibrates the NUMBERS used in the sim. In the calibration phase it is NOT reading the joystick but the values in the simulator! I see Thomas answered you as well. But I'm afraid reacted to your accusation. It s NOT "aberrant" behaviour. You are mixing up the meanings of the words minimum and maximum as meaning left and right deflection, which they can be but might not be. And such a mix up wouldn't make sense anyway for an elevator control, or throttles which don't have a left and right action. Please note also that negative values (those preceded by a '-' sign) are lower (less than) positive numbers. Pete

I don't see any axis assignments at all. Are they only assigned in the sim? You also have no axes calibrated. I don't think ANY mappings work without any calibrations. As far as I can see, this is a completely default settings except for the mapping lines. I didn't think you could set those (at least not in the calibration tab) without at least calibrating. The mapping maps the post calibration values! Pete

The "ping" only happens when numbers don't increase from left boxe to right. Just keep them in order -- left box (minimum) not higher than either centres (order of top and bottom centres don't matter) and all those not higher than the right value (maximum). If you need the order reversed, select REV first, before calibrating. The it is still low to high but applied the other way around. Press "RESET" to start again. The numbers will reset to defaults to start with which can then be set, maintaining the correct order. I'm sure it says this sort of stuff in the User Guide. Pete

Only those enabled. Pete

Sorry, what do you mean by the "Left" and "Right" sides? I don't understand. The axis assignments tab only has one place where it shows the values received from the axis,and that's top centre. Pete

I'll have a look, before the next release. Not sure when, but they are more or less monthly at least. No promises till I've checked the code. It's pretty old now. Pete

Sorry, I need to see your FSUIPC4.INI file too, for the assignments, calibrations and options. Just post its contents in a message here -- use the <> button above the edit area to enclose it. Did you try Throttle 3 lever on its own? Does that work? There's no Throttle3 or Throttle4 controls in the log. Do they both work independently? Did you try a 1,2,3,4 mapping, or a 1,2 + 3,4 one, in this session? Did you try Throttle Sync as I suggested? Pete

Using the FSUIPC TCAS tables (which are designed really purely for TCAS display use, the range limit applying to airborne traffic is 40nm by default, but can be set in the options or via the INI file parameter. The ground traffic range when the user aircraft is airborne is 6nm, but only 3nm when the user aircraft is also on the ground. Normally ground traffic is not a feature of TCAS. FSUIPC does in fact get ALL the traffic from SimConnect (it doesn't really have an option), and uses this for its own Traffic Limiter options, but the TCAS tables are purpose designed and very limited in size, using offsets as they do. Most programs doing the sort of things you are doing get the traffic data from SimConnect directly, even if they have to use FSUIPC to delete them (SimConnect only lets the object creating program to delete said objects. FSUIPC's method is actually a hack into the code). I suppose I could make the Ground traffic range for an Airborne user configurable to more than 6 nm, perhaps following the Airborne setting. Pete

Do the other add-ins load ok -- PMDG Options? The one for ActiveSky? Show me the FSUIPC4 Install log please. Pete

You've made a mess of the DLL.XML file. Delete it and re-run the FSUIPC installer. It will make a new correct one. Use the latest FSUIPC4 installer (4.966c) available on the Schiratti site (ignore the text there, it's out of date) or in my own Download Links subforum above. You then might need to re-run a PMDG installer, or just add the following to the DLL.XML BEFORE the first <Launch.Addon> line: <Launch.Addon> <Name>PMDG Options</Name> <Disabled>False</Disabled> <Path>PMDG\DLLs\PMDGOptions.dll</Path> </Launch.Addon> Pete

Just enable "Mouse Look", in the Miscellaneous tab in FSUIPC Options. Pete

Okay. In that case, here's what your log clearly shows: Your stick is working, and as you have two button assignments to that it is being scanned all of the time, even when you are not in the FSUIPC Options for Axes or Buttons. That fills up most of the log. The rudder isn't assigned so that doesn't appear except when you enter the options. After you entered the Buttons assignment dialogue, all possible joystick numbers were scanned (I must fix that -- it should only scan those detected before hand -- i.e. in your case 0, 1, and 2, the Stick, Throttle and Rudder. Oddly, 3 gave a valid response too, but I think that must be a fluke. it gave an error later. Here's an extract showing valid responses for 0-3: 153218 *** Entered Buttons option page *** 153218 Read joy 0, Buttons=x00000000, POV=-1 153218 Axes: X=33444,Y=32524,Z=0,R=0,U=0,V=32751 153218 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 153218 Read joy 1, Buttons=x00000000, POV=-1 153218 Axes: X=0,Y=0,Z=0,R=0,U=0,V=0 153218 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 153218 Read joy 2, Buttons=x00000000, POV=-1 153218 Axes: X=0,Y=0,Z=0,R=0,U=0,V=32383 153218 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 153218 Read joy 3, Buttons=x00000000, POV=-1 153218 Axes: X=0,Y=0,Z=0,R=0,U=0,V=0 153218 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 You see the X, Y values for the Stick (Joy 0), near max. Those values wobble a bit, typical jitter probably ignored by FSUIPC with the default Delta value left set. The readout for Joy 1 is basically a default. But it is most certainly coming from the device (or rather from DirectInput and the device's driver). Here, Joy 2, the rudder, has an interesting non-default value for the V axis (probably not used), but otherwise the input from that seems stable at zero. Oddly, though you were supposed to be checking the buttons on the Throttle, you pressed buttons on the Stick instead: 159640 FirstButtonChange res=00000008 (0.0, 8) 159656 Read joy 0, Buttons=x00000100, POV=-1 159656 Axes: X=31852,Y=32206,Z=0,R=0,U=0,V=32751 159656 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 Later the same again for buttons 8, 6, 7, 8, 12, 10, 13, 11, 4, 12, in that order. Surely you saw these coming up in the dialogue, for your stick? Did you actually press any buttons on the throttle? Then, at about 235 seconds (3m 55s) into the session, something wierd started happening. Your X-55 devices were disconnecting themselves (unless you did it), or losing power. This happened with both Stick and Throttle. maybe this is when you pressed buttons on the Throttle, precipitating the problems? 235156 *** JOY ERROR: GetDeviceState for Joy #0 returned 'Input Lost' 235156 *** JOY ERROR: GetDeviceState for Joy #1 returned 'Input Lost' 235156 Read joy 2, Buttons=x00000000, POV=-1 235156 Axes: X=0,Y=0,Z=0,R=0,U=0,V=32383 235156 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 235156 Read joy 3, Buttons=x00000000, POV=-1 235156 Axes: X=0,Y=0,Z=0,R=0,U=0,V=0 235156 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 235156 *** JOY ERROR: Poll for Joy #0 returned 'Input Lost' 235156 *** JOY ERROR: GetDeviceState for Joy #0 returned 'Input Lost' 235156 *** JOY ERROR: Poll for Joy #1 returned 'Input Lost' 235156 *** JOY ERROR: GetDeviceState for Joy #1 returned 'Input Lost' Interestingly the Rudder and the mysterious Joy 3 continued okay. This went on for a great portion of the log until 238 seconds (only 3 seconds, but a lot of log!) when another USB device was added! 238093 ***** A device has been attached! 238093 ***** HID USB device reconnected: re-initialising FSUIPC connections 238093 #### Initialising Dlrectinput Axis Scanning ... 238093 EnumDevices: 0.GUID={B15E4040-937C-11E5-8002-444553540000} 238093 EnumDevices: 1.GUID={B160B140-937C-11E5-8006-444553540000} 238109 EnumDevices: 2.GUID={B15E4040-937C-11E5-8001-444553540000} 238109 EnumDevices: 3.GUID={3C3B5D00-9DAB-11E5-8001-444553540000} A "real" device 3 after all! Not the ghost scanned earlier. And see what this turned out to be: 238125 Joy#3: Finding name in "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_068E&PID_C010\" 238125 Joy#3: OEMName = "CH Control Manager Device 1" 238125 Joy#3: GUID = {3C3B5D00-9DAB-11E5-8001-444553540000} Now what is that for? Why are you running the CH control Manager at all? Maybe this is the cause of all the problems? It not only did this, but appeared to reconnect the device many more times (over 6, I lost count), and in the process also got the Stick moved to device 4! Not only that, but subsequently Joy 3 stopped returning any values, even though as a "ghost" device it did! So, conclusions: 1. Uninstall CH Control manager and re-test. 2. It looks possible that the USB port for your X-55's, and especially the Throttle, is playing up. Try moving them. If using a hub try plugging them direct into the PC. As far as I can see, apart from the excessive scanning (all 16 initially), FSUIPC is doing everything right. Pete

Did you send me a log by email, from someone called "Ron" (you NEVER seem to sign your posts here so I've no idea who you are or where the email is from)? Pete

Yes, but only in the assignments dialog. Sorry, yes, I see what you were trying to do. but it didn't look like the sim was ready to fly (I was looking for the "Starting Everything Now" message in the log -- that's when FSUIPC is fully ready for normal use. It might be a few seconds after the sim appears ready. I'm looking at shortening anydelay there -- I'm trying to detect the end of the sim's loading progress bar. Ready to fly should be when you can do things in the menus, as you are. but I think, especially with P3D, this can occur later -- maybe 10-12 seconds or so. The reason for this delay is that I was trying to avoid doing things when the scenery/traffic etc progress bar is still running. I didn't find a way to detect that, so estimated a time. On my system the progress bar isc still going for quite some time after my delay, so FS starts everything too early. Yors may load stuff a lot faster (less scenery, AI traffic, lower settings, etc). That's why at present I'm trying to find a way to detect the progress bar. Pete

I've checked, and in fact the logging I need is already in place. It logs the results from the actual polling of the joysticks, at first and then whenever they change. It will make a BIG log, especially with your working device in place, so please, not only keep the session short (though not so short you don't get to operate buttons or move levers when the sim is ready to fly), then ZIP it up and send it to me at petedowson@btconnect.com. To get this logging as well as the earlier stuff, change the LogExtras line n the INI to LogExtras=x201000 Please don't forget to remove the extra copies of the two added lines. Oh, and to keep the log size down, it might be best to temporarily disconnect the working devices. Otherwise I'll have to add an INI parameter to select which devices to log. [LATER] Another thing I now realise: you have no assignments to the axes or buttons in question. I sort of assumed you were carrying over an INI file from an earlier install. FSUIPC does NOT scan devices where there's no need because no assignments, so the new logging I'm asking for will ONLY occur whilst in the Axis or Button assignments dialog. So you can keep the session and log shorter by keeping those visits short. Thanks, Pete