John Dowson

From the README.txt document (included in the zip file you downloaded) - I will update this as documentation is now available (and has been for a while): I have my hat assigned to send the default keys for view control that are assigned in MSFS. See the following article for a description of the view controls and default key assignments: https://flightsimulator.zendesk.com/hc/en-us/articles/360016003159-Camera-Overview John

When you assign to an axis, the axis value is sent to the control/event that it is assigned to. It doesn't really make much sense assigning an axis to a button, unless this is for a specific purpose (e.g. centering the axis). Such controls (up/down/left/right) are best assigned to a hat switch. If you have a spare hat switch, you can use that. Otherwise, it may be possible to overload your view control hat switch to send these controls when another button/switch is pressed, and to control the view when not. This is called a conditional assignment and is described in the Advanced User guide. But what makes you think these are axes controls? Up/Down/left/right are not axes controls, and if they are assigned to keys then they are certainly not axes controls.... If the controls are on a button, they are not axes controls. What controls do you see logged when you press these? You can just assign your buttons to the same controls. This also doesn't make much sense to me. How are you expecting to control two directions (left/right and up/down) on one axis? And this also sounds like you want to assign non-axis controls (up/down/left/right) to an axis, which is the opposite of the title of this post. Normally there are corresponding inc/dec controls for each axis control. If not using the axis controls, you would assign to two buttons, one to increment the axis value and another to decrement. What are the controls logged, if any, when you change the TDC cursor slew in the VC?

Ok. One other thing you can try to aid you in this is to keep the FSUIPC logging console window open, and monitor the events shown around the time your throttle 2 starts to fail. Some people also have issues with PMDG aircraft throttle assignments when calibrated in FSUIPC due to priority issues. I don't think this is your issue, as your problem only seems to be with throttle 2, which is strange. But you could try switching the assignments to Send to FS as normal axis, and making sure that no calibration is applied in FSUIPC. Regards, John

Have you tried without FSHUD running, and without pausing for decent? What other software/utilities/add-ons do you have running? Maybe try without anything running other than FSUIPC, and then add other utilities you may use back one by one. Also, check any throttle calibration utilities in the aircraft itself - does it have throttle calibration in the EFB? If so, check that. FSUIPC does not know or change anything in different flight stages.

You assign an axis to a preset on the left hand side of the assignments panel. not the right hand side, which is used for sending controls when entering and leaving specific axes ranges. You have assigned to send this preset once when the axis value goes to 0. Delete that assignment and assign the axis (left-hand side) not the axis range (right-hand side).

What do you mean by "Throttle 2"? For the 747, you have the following throttle assignment on axes: Looks like these are assigned to the quadrant attached to your yoke, and as you have an exes assigned to both throttle2 and throttle 3. Are you saying that this assignment continues to work for throttle 3 but not for throttle 2? When this occurs, if you go into the axes assignment tab. do you see these assignments when you move the throttle? You also have the following throttle decrement control assigned to buttons: Here you have a repeat throttle 2 decrement assignment on a button on your 2nd throttle quadrant. Also strange as nothing for engines 1 and 4. As you are controlling engines 1 and 4 on one axes, and 2 and 3 on another, I would have thought the decrement controls for 1 and 4 should also be on one button, and for 2 and 3 on another. You have also assigned with 'Direct to FSUIPC calibration' but have not calibrated your throttles. You should always calibrate an axes when assigned in this way. How are you doing this? I see no assignments to reversers. Then it does sound like an issue with your PMDG 747 configuration, I don't understand how this can just affect throttle 2... Try compressing / zipping it.

Just tried again - I clicked Select all then Read, and it seems to be showing data: John

Yes, just checked and its the same for me. No idea why, but I cannot do anything about this, sorry. This application was provided a long time ago by a user and is provided as-is and unsupported. What do you actually want to do? You can log up to 4 distinct offsets using FSUIPCs offset logging mechanism, in hex or otherwise. Alternatively, use the Interrogate panel of FS-Interrogate. John

Plenty of resources on boundary data alignment on the web, e.g. https://learn.microsoft.com/en-us/cpp/cpp/alignment-cpp-declarations?view=msvc-170 But I wouldn't worry about this two much. Just remember that the last digit of the offset address must be wholly divisible by the size of the data you are adding, as this will mean that the address is aligned to that data size.

I cannot explain it any other way. A 4-byyte value MUST start on a 4-byte boundary. So the hex address must end in 0, 4, 8 or C. Those are the 4-byte boundaries. If you add an int to an address ending with 0, e.g. xxx0, then the next address available is xxx4, and an int to that, and the next address available is xxx8, add an int to that, and the next address available is xxxC. 4-byte boundary addresses end in 0, 4, 8 or C. 8-byte boundary addresses end in 0 or 8.

What do you mean? You do not place data - the hex viewer just reads the data and displays the offset values in hex

As it says - the offset address needs to be bound to its size. So, for example if you add a 1 byte simvar to, say, offset A000, the next free offset in that area will be A001. But if you now want to add an int, which is 4-bytes, you cannot add to A001 as that is not on a 4-byte offset boundary. The next position it can be added in will be A004 (the last offset digit needs to be 0, 4, 8 or C, i.e. on a 4-byte boundary).

Check everything is working ok first and send me your files if any issues. I am not sure if the JoyScan file is re-written io joystick re-connection, so the last one you showed me might be out-of-date, and there could be another registry issue.

You should not do this when FSUIPC is running. It looks like this has caused some strange issues....can you delete this from the [JoyNames] section of your FSUIPC6.ini: The quadrant was recognised with the same GUID as your rudder pedals for some reason. Can you check that the power saving/allow sleep setting is disabled on all of your USB hub devices (in windows Device Manager). The most common cause of this issue is that windows has put the devices to sleep. Otherwise, I am not sure what could cause this. The next time it happens, pause the sim and open FSUIPC and see if your throttle assignments are recognised in the Axis assignment tab. Also, set logging for Axes Controls, Events (non-axes controls) and Buttons & Keys. Then un-pause the sim and move the throttles and rudder, and press a few buttons on each device. Then exit and show me the files. Do not unplug and re-connect your controllers. Thanks, John

Thanks, but I think you mean me and my father, Pete, who has now retired. Cheers, John

Looks a lot better... Only one throttle quadrant is recognised, but I think one is attached to the yoke and so the axis/buttons look like they are coming from the yoke. Can you replace your ini with the attached (I have just removed some unnecessary JoyName entries and assigned different letters) and then start P3D/FSUIPC and see if everything is recognised, and if your assignments are still valid. Any issues let me know and re-attach those 3 updated files. Thanks, John FSUIPC6.ini

Please see the documentation - the README.txt and the Installation and Registration guide. If you have re-installed windows, you will need to update to the latest VC++ redistibutables. John

Found this issue and should be fixed in the attached update. This is a long standing problem, I am surprised it hasn't been raised before... Note also that the interval is the minimum interval, and you should generally expect to see the data at a slightly slower frequency than that specified. This is strange and I cannot reproduce this here. If you still get this with this latest update, can you please add FSUIPC offset logging for offset 0x0580 as SA32 - this is the offset that the heading is calculated from. Also please keep the custom logging for the GPS out data that I showed you before. Ok - I took these values directly from the RPY sentence. I have reversed these values for PASHR in the attached update. Did you check on the comma before the checksum? As no other sentences have this, I would rather not include this. However, if you need this, you can add PashrComma=Yes to the [GPSout] and/or [GPSout2] section So can you please try the attached. Any issues, please attach your FSUIPC6.log file, with the GPSOut data logged, and also with offset 0x0580 logged if the heading is still an issue. Thanks, John FSUIPC6.dll

It won't be "recognized" by FSUIPC as a device, as it is a keyboard device. FSUIPC just receives the keyboard input from such devices from windows, and if it is sending keys then they should be picked-up in FSUIPC's keyboard assignment panel. Is this device actually sending any keys? Is there some configuration software that you use to determine what keys this is sending? If you open another app (e.g. notepad or notepad++) does that receive input/key strokes from this devices? Did you check the other button assignment (as I mentioned) on this device? If that has the same problem, it will be a problem with the device. If not, it will be an issue only with that button,

You did - it was the log file that was missing.

Yes - LINDA is a lua interface built on top of FSUIPC's lua facilities. Not necessarily - only if LINDA has a module/lua script that supports that hardware, otherwise you would have to write your own. You should ask about this on the LINDA support forum. The VRInsight MCP works with FSUIPC as we provide support for this device within FSUIPC (see appendix 3 in the Advanced User guide). Why do you want to send me that - it is of no use to me. I will not be adding any special support for this device. No. It is really up to the hardware provider to provide the software for this device. If this is not available, then you would have to see if it can be controlled using the lua com interface, and write your own lua script to handle this. Or maybe check if MobiFlight support this device. No, sorry. John

I will take a look and get back to you. John

Could you please also attach your FSUIPC6.ini file the next time you show me your files. Have you installed any saitek drivers? If so, please remove them and let windows install the default windows drivers. There is certainly something strange going on.... first, the joyscan file shows only 3 HID devices, and all showing the same GUID: And in your registry, there are multiple entries for the yoke with one using the same id as one of your throttle quadrants: And your ini file shows only one throttle quadrant and the yoke detected, missing your pedals and 2nd throttle quadrant: The first thing to do is to switch to using JoyLetters - this helps prevent issues and aids recovery when ids and guids change in the registry. To do this, change the AutoAssignLetters ini parameter in your [JoyNames] section (shown above) from No to Yes. Then run P3D/FSUIPC and exit. This will update your ini to use JoyLetters. After that, you need to clean the registry entries. To do this, first run regedit and take a back-up of your registry, then exit regedit. Disconnect your yoke and throttles, and download and run (i.e. double-click it in windows explorer) the attached regedit script: removeDevices.reg Then reboot your PC, and then reconnect your yoke and throttle. Run P3D with FSUIPC6 - just load an aircraft and then exit. Then show me/attach your updated 3 files - FSUIPC6.log, FSUIPC6.ini and FSUIPC6.JoyScan.csv, John

I don't think the version is the problem, and updating to v6 probably won't fix this, whatever the issue is. I could provide you with a trial/time-limited license if you would like to try it. No - you just need to rename your FSUIPC5.ini to FSUIPC6.ini and your settings will be preserved. John

I've also just tried the GFLeds-G58.lua with the Cessna 172 and it also works for this aircraft, so no need to resort to using lvars. The latest script should work for most aircraft, and for the ones it doesn't you will need to adjust and provide a separate script for that aircraft. For now, I suggest that you just install the script and add it to your general [Auto] section, i.e. [Auto] 1=Lua GFLeds-G58 It will than be started for all aircraft. If it doesn't work for a specific aircraft, you can then look at that on a case-by-case basis. Probably also better to change the name of that script to just GFLeds.lua, as it is not G58 specific (and change the name to match in your [Auto] section). John