John Dowson

I cannot see this, but it doesn't matter for now. The log is interesting...first it shows an error starting FSUIPC7: Windows error 0x000002E4 indicates that the requested operation requires elevated privileges. Have you set FSUIPC7 to run with Admin privileges, or are you running MSFS with admin privileges? Note that MSFS and all clients must be ran at the same privilege level. Please check that you are doing this - either running everything with admin privileges or everything without. Running with mixed privilege levels will cause connection issues. This is also interesting from your SimConnect log file: So 59 connections are being used by the Fenix bootstrapper, out of a maximum of 64. There are also many exceptions reported in the SimConnect log file, all from the FenixBootStrapper. Could you please temporarily remove the Fenix and try without this to see if that is causing your issue. Also check the privilege levels, as previously indicated. Thanks, John

That is in your P-51 CIV profile, not in your P-51 MIL profile, which your latest ini shows no assignment, although your previous ini did: 8=DS,256,D,21,0,0,0 -{ DIRECT: ElevatorTrim }- That is ok - you have additional assignments to flaps macros via a set of ranges (right-hand side of axes assignments panel) for that axis. Yes, you don't need to do this. Profiles are automatically loaded based on the aircraft name, its just that in the button and key assignment panels, you can assign a button/key in either the general section or in the profile, so you can check/uncheck the profile-specific box in those assignment panels. For axes it will automatically be checked and not possible to uncheck, and calibration will depend if you have profile-specific calibration or not. Ok, thanks - that confirms there is nothing strange in your ini preventing the trim axes being seen. Thanks - I will take a look and get back to you. However, you now seem to be using LINDA as well....your previous logs do not show LINDA being used - why have you suddenly added this into the mix?

Also, note that the custom controls for the PMDG 737 use the Rotor Brake event with the parameter indicating the button and mouse action - see You can also use custom controls via presets - see https://hubhop.mobiflight.com/presets/ for a list of available presets, and you can also create your own if a preset for that button does not exist. John

Could you please attach a full FSUIPC7.log file showing the issue, with logging for Buttons & Keys as well as Events activated, together with your FSUIPC7.ini file. Thanks, John

Hi Ramon. Offset 0x2834 holds the simvar ELECTRICAL BATTERY VOLTAGE, and from the MSFS documentation: ELECTRICAL BATTERY VOLTAGE The battery voltage. Use a battery index when referencing. Volts i.e. it should already be in volts so no conversion needed - just read it as a double. What are you looking for? Cheers, John

Yes, but the ready-to-fly offset at 0x3364 is the one that activates the PFC driver as far as I remember. It has been a while (3 months) since I last looked at this, so I really need to review the whole thread and the PFC driver code again if you want to resurrect this.... But if its always 1, then it is always on, so I don't think this is an issue. However, I could check the PGC driver code to see if it is waiting for this to change from 0 to 1 (but I don't think so). Yes, I do - and I have asked for a log with these offsets being monitored with the Fenix. I see no point in looking at this again until this is provided. Please see my last comment from 3 months ago, If you can provide those logs with the suggested logging/monitoring, then I will look at this again. Otherwise, I do not think it worth me spending the time to go through this again... And the Fenix will be updating simvars and lvars, not offsets. It is FSUIPC that picks up these changes and maintains the offset data. If the Fenix is not using the standard simvars for this. then we need to determine what it is using instead, add this to an offset and then spoof the original offsets for these values to the new offsets, so anything reading the original offsets will automatically get the spoofed value from the new offsets. What would be of personal Interest to me, for StreamDeck Plugin and the Fenix Integration: what would that Offset be? And is that a reliable working way to test that the Ready-to-Fly Button was pressed by the User? The ready-to-fly offset is at 0x3364, but this is not related to the Ready-To-Fly button being pressed. There is no event generated for this. You could try offset 0x026D - CAMERA STATE. This offset was added in 7.3.11 and will be < 11 (and non-zero) when ready, but not necessarily after the Fly Now button has been pressed. FSUIPC now also uses this to determine when to start threads for aircraft control. John

And one more test, with your original FSUIPC6.ini, could you add the following to the [General] section: Debug=Please LogExtras=x1000 and generate another log file where you move the axes assigned to the trim controls with the assignments window open, then exit. The log file could be quite large and so may need zipping before attaching. John

Hi, it maybe better if another blind pilot and FSUIPC user could assist you with this - maybe @Ron Kolesar or @Jason Fayre? The Set buttons define the minimum axes value, the null/dead range, and the maximum axis value. However, this can depend on the axis being calibrated, and with throttle calibration, it depends if you are calibrating with a reverse range or not - controlled by the checkbox No Reverse Zone (top left in the calibration tab, only available when calibrating separate throttles per engine). When calibrating with a reverse zone, the first set button calibrates maximum reverse (minimum axis value), the 2nd set button the idle range (click twice to set the range, first click will be the end of reverse/start of idle range, 2nd click the end of idle range), and the third the maximum axis/thrust value. When calibrating with No reverse Zone set/checked, you only calibrate the minimum and maximum axis/thrust values. By flying and checking the axis is working as expected. This depends on the aircraft you are flying, and if you have calibrated with a reverse zone or not. If calibrated with a reverse zone, then the idle range is calibrated using the second Set button. You can also post/attach your FSUIPC6.ini and FSUIPC6.log files here if you like, and I can take a look at your assignments/calibration and see if that is ok with the aircraft that you are using. Cheers, John

ok - good luck! Regards, John

You need to adjust the ButtonRepeat ini parameter - see the Advanced User guide, page 16. The default value for this is: ButtonRepeat=20,10 This will give a half-second delay between the initial button press and the first repeated button press (as explained in the documentation). If you want no such delay, change this to ButtonRepeat=20,0 Note that this will affect all button repeats, not just for trim. Cheers, John

No. Different versions of FSUIPC support different flight simulators, and each version requires its own license. For FSX, you used FSUIPC4. For MSFS2020, you will need FSUIPC7, which requires a new/different license. Before purchasing a license for FSUIPC7, you can try it using the trial license which is available in a sticky post at the top of this sub-forum. John

Hi Ed, Ok, thanks - this is want I wanted to confirm. In FSUIPC, the rudder trim was assigned to axis U, the aileron trim to axis V, and the elevator trim previously assigned to axis S. What are the corresponding axis letters for these axes in windows controllers and Spad.next? What do you mean by ' select the P-51 MIL profile'? You should not need to do this - profiles are automatically loaded based on the current aircraft name, and if you go to the axis assignment tab you should see the profile already loaded. It is only in the Button and key press assignment tabs where you have the ability to switch between profile and general assignments, as the general assignments for buttons and key presses are used when you have a profile, unless overridden in that profile. Do you see the same behavior when using another profile,, e.g. when using the aircraft A2A North American P-51D CIV? Could you also perform a test when you run with a default ini and see if these axes are recognised - just temporarily rename your FSUIPC6.ini file (e.g. to FSUIPC6.ini.unused) and run P3D/FSUIPC, and see if the axes you were using for the trim controls are recognised then. Can you also run a test without running Spad.next, just to confirm that is not causing this issue. John

Yes, I believe this is just a visualization issue that has been around since msfs was released. See this post about the issue on the MSFS/Asobo forums: https://forums.flightsimulator.com/t/movement-of-on-screen-yoke-does-not-match-real-controller/418391/18 Regards, John P.S. The same issue was also reported in FSX - see https://www.flightsim.com/vbfs/showthread.php?263439-The-movements-of-the-saitek-yoke-aren´t-truely-representated-in-fsx

What are those screenshots supposed to show? I can only see windows for the WASM test client and WideClient. Are you even running FSUIPC7? Have you installed it? Have you installed the WASM module? WideClient is usually ran in a client PC, not on the same PC as the FS. You run FSUIPC7 on the same PC as the FS, and WideClient on any client machines that you want to use with FSUIPC clients. So, please confirm that you have installed FSUIPC7 and that it is running. By default, once installed, it should start automatically with MSFS - you should see an FSUIPC7 splash-screen and then it will sit in your system tray. If you don't see the splash screen when MSFS is started, try starting FSUIPC7 manually (i.e. double-click the FSUIPC7.exe in windows explorer). If you problem is with FSUIPC7 not auto-starting with MSFS, please see the following: If there are issues running FSUIPC7 (e.g. you get an error when trying to run it) then your VC++ redistributables probably need updating - please see the README.txt file provided in the FSUIPC7 zip file you downloaded. Any further issues, please show me your InstallFSUIPC7.log file and your FSUIPC7.log file (if available) together with a detailed description of what you have tried and what the issue is - no screenshots please. John

Hi Daniel, As I previously indicated, the PFC driver is waiting for the ready-to-fly offset flag to change before the avionics are activated. The driver does not react to sim events, only offset changes. I don't think the polling frequency is an issue, it is the offset values themselves. This is why I need to see those offsets logged. If those offsets (or simvars associated to those offsets) are not being used by the Fenix, it is just a matter of determining what is being used (simvar or lvar) and then adding that to a spare/free FSUPC offset and then spoofing the value of the original offset (which is monitored by the PFC driver) to the value of the new offset. But I really don't think it is worth looking at this further if the OP is not prepared to supply the information required to resolve this for him. Thanks for your input, regards, John

I deleted one of your posts as you had just copied and pasted my previous comment. What is too complex? I gave simple instructions - what do you not understand? Have you even tried? You will be waiting for a long time... Controlling wither of these aircraft is a lot more complex than using standard/default aircraft. You will have to use lvars/hvars/custom controls and presets for almost everything, so you really need to familiarise yourself with how to use these if using such aircraft. Having said that, I don't think there is much difference between the control of these aircraft. I only have the 737-700, and there are only presets available for the 737-700 on the MF HubHop preset list (https://hubhop.mobiflight.com/presets/), but other users have said that most controls (custom controls and presets) are the same for both aircraft, although some differences have been reported. Not sure what you mean here, but the specific PMDG offsets are available for the 737-700, and I believe these also work for the 737-800. There is a document included in the FSUIPC7 documentation for the PMDG-specific offsets, so please see that. There are also some User Contributions on how to use the SDK, so check the User Contributions sub-forum (as well as maybe the FAQ sub-forum). John

I presume you are referring to @savery999's response - I would think he is using MobiFlight as he is referring to the 'More Options' checkbox for Substring from/to which you have checked in the image you posted. So, try unchecking that - and also try logging the FSUIPC offsets as I have advised, as this will confirm that the offsets are being populated correctly. John

Hi John, Ok. I know nothing about Delphi or Lazarus. This SDK was provided by Pelle F. S. Liljendal (pelle@liljendal.dk) over 20 years ago....you could try emailing him for support, but I think you would be better of using one of the more modern SDKs, Yes, I think that is a better choice, if you are familiar with C:# / .Net. Cheers, John

Hi Ed, I'm sorry but it is still not clear to me...could you re-read what I have said in my previous post and answer the specific questions and try what I have advised, i.e. you again say: Here you say 'elevator, rudder and aileron trim do not appear in the Type of action required' but what does show, if anything, in the joystick id/letter and axis letter boxes? Does anything register there, and if so, and it is not the correct axis, have you trued clicking the Ignore Axis button (not the Rescan button) and then trying again? Again, if a different axis is showing, click the Ignore Axis button and try again, not the Rescan button. Please do this and tell me what joystick id and axis letter you see, and it is not the expected one click the Ignore Axis button and try again. This indicates that the rudder trim and aileron trim ARE assigned, and you should see these (eventually) in the axis assignment tab. You will not see the Elevator trim as the latest ini you posted shows no assignments for this. You need to get this axis recognised again in the axis assignment panel (again, click Ignore Axis until you see this, NOT Rescan) and re-assign this. So, please take another look using the Ignore Axis button and not the Rescan button, and tell me what letters you see in the joystick and axis boxes. John

First, you posted in the User Contributions sub-forum where it explicitly states NOT for support requests. Did you not see this? This is happening a lot and I do not understand why - can you explain and let me know what I can do to stop this? As for your issue, you obviously have both FSUIPC5 and FSUIPC6 installed, which is very strange. Usually FSUIPC5 is detected and uninstalled when you install FSUIPC6, unless you previously converted your FSUIPC5 installation to use the add-on.xml method, in which case you need to manually remove it. Check your Documents\Prepar3D v4 Add-ons folder and see what is there - if there is an FSUIPC5 folder then remove it. Also check your Modules folder, if that exists then FSUIPC5 should be installed there. Otherwise, please show me your InstallFSUIPC6.log file together with any FSUIPC5.log and/or FSUIPC6.log files that are generated. John

But this doesn't make sense...if you have DirectAxesToCalibs set, then values written to the offsets will go through FSUIPC calibration, and so you must calibrate. From the FSUIPC Advance User guide: If you don't want calibration, maybe try removing that ini parameter. Otherwise, has this always been an issue, or is this a new issue since the SU10 release? I ask as there are various issues with calibration since SU10. If the issue persists, could you add logging for offsets 0x0BB2 and 0x0BB6 (using FSUIPC's offset logging facilities), activate logging for Axes Controls and Extras and produce a log file showing your issue and attach that (zip if large) as well as your FSUIPC7.ini file. Thanks and regards, John

Can you please post a full log. Also, what version of FSUIPC are you currently running? A full log would tell me this....if not using the latest version, 7.3.11, please update and try again... From the log extract you posted, FSUIPC can get a simconnect connection but the WAPI interface cannot, which is strange. Multiple WASM clients shouldn't be an issue, but I will check this again in SU10 and get back to you. I also see LINDA running (or being killed) and LRM as well as vPilot. Could you also try running the WASM test client when you get this issue, both when it occurs with FSUIPC and other programs, and see if that can connect or not when you get this issue with your other programs, I have attached this for your convenience. John WASMClient.exe

Hmm...even stranger.... But what is registered, if anything? If nothing is registered, why click the Rescan button? If anything IS registered, what? And if another axes IS registered, have you tried clicking the Ignore Axis button and trying again? And repeat until the axis is recognised...or not, as the case may be...please try this until the axis is recognised or you see no joystick letter or axis letter recognised. That would confirm that the axis/axes are not being seen. It is difficult for me to know this without you doing this and reporting back. And you say there 'is no recognition of the controller at all' - but I thought the other axes assigned to that controller were functioning ok: 'You had asked if the other axes (i.e. PropPitch and Throttle) on the DTA device are recognized and they are' . So, if hey are recognised and working, so is the device. Sorry to be so pedantic but your issue is very strange and you need to be very clear otherwise it gets confusing.... Maybe you could take a short video of what you see, which may help clarify things... Possibly - there are various APIs to access HID devices. You say that these are also not recognised by P3D. and FSUIPC recognises the device, and was previously ok (for 5 years) but there are now problems with specific axes/pots on the device (the ones assigned to trim), not the device itself (other axes are working, no?), so the problem is not that straightforward as device recognition. Or at least this is what it seams... I will let you know how to do this if/when necessary - for now, please just clarify the above. Cheers, John

I have moved your post to the main support forum so Pete has visibility, as he still supports this utility.

John, not Peter. Pete retired several years ago. Sorry, but I have no idea what this means. What is Lazarus? What are 'FPC Files'? What SDK/programming language are you using? FYI, the most used and supported client library would be Paul Henty's ,Net client API (see https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/).