John Dowson

I am not sure what you are referring to here.... I do not see any drop-down menus. Topics are always created in the forum you are looking at when you click the 'Start new topic' button. You just need to be in the correct forum (one without the text NOT for support request) which is either the main top-level forum (this one) or the specific FSUIPC7 sub-forum. Ok, glad its sorted. Cheers, John

Sorry, I think I misunderstood your question...you are asking if event.offset calls for the same offset will be queued? I don't think they will be, but it should be easy enough to test for this. John

Did you check your FSUIPC7.log file to see what it was logging for those offsets? Please do not post screenshots (unless requested) - I need to see your FSUIPC7.log and FSUIPC7.ini files, the former generated with the requested logging activated. This logging will tell you/me if there is a problem with FSUIPC receiving the PMDG data, or if it is a problem with your MobiFlight configuration. John

Hi Paul, ok, thanks for the info. I saw the SDK had been published (with some changed to the .h file but nothing that requires an FSUIPC update) but hadn't checked/noticed this. This is not only going to screw up peoples existing assignments to the Rotor Brake control, but also to any presets (MF or otherwise) that are also using the Rotor Brake control. Not sure why high custom event numbers no longer work either, unless higher than 4194304 (0x00400000) as that is the internal flag/value I use to mark preset controls, but that shouldn't be an issue as they start from THIRD_PARTY_EVENT_ID_MIN which is 0x11000 (69632). I will take a look at this tomorrow, or when I get the OPs log and ini files, as requested. John

No - you can have multiple event.offset calls on different offsets. if its on the same offset, I'm not sure of that is added or replaced without checking, but a simple test should reveal the answer to this. John

Hi Al, Any change in the offset value will trigger the event. However, there is a delta specified on request of the simvars for each offset, and so only changed values that differ by more than this delta value will be received. This delta value for offset 0x6050 (GPS WP BEARING) is 0.009. John

oh - can you also calibrate the trim rotaries in windows calibration, after you have removed the reg entries and reconnected - this will ensure FSUIPC is getting the full value range.

Nothing in those logs - did you check the Display to - Normal log file checkbox in the offset monitoring panel? Forgot to mention that (thought this would be obvious...) - please do that and try again. Also, PLEASE do NOT EVER use the Log->New Log menu option when generating log files for support, and always exit FSUIPC before attaching log files. I need to see one complete log file. Yes, sorry - you don't need to specify the Ox in that window, the values are assumed to be hex. John

No, sorry - you have to run P3D to use FSUIPC5/6. I mainly get support requests for FSUIPC7/MSFS these days and had switched to FSUIPC7 support mode - sorry about that. John

Yes, please disable LINDA when generating logs for me. Lets try cleaning the registry before the next test. First, take a backup of your current registry. Tun the windows Registry Editor application and take a registry backup (File -> Export...), remembering to select the All checkbox. Next, disconnect your two DTA Rotary Encoder devices, and then download and run (i.e. double-click it in windows explorer) the attached file: removeDTARotaryEncoders.reg Then reboot and re-connect your devices. Then start FSUIPC7 and see if the trim rotaries are recognised, i.e. the axis assignment box sees them or not (you don't need MSFS running to do this, or anything else) - you won't see the trim assignments, but this is not important at the moment, just want to see if the those axes are recognised. You can also attach the updated FSUIPC6.ini and FSUIPC6.log files after doing this and I will check them again. John

Yes, sorry about that. Yes, that is all correct - I was just clarifying that the aircraft/FS updates the simvars, not offsets, and it is FSUIPC that maintains the offsets based on these simvar changes. I believe it is just the ready-to-fly flag, but I will check this again. This is also my approach, which is why I have requested monitoring of those offsets. @PSantosSorry, UB should be U8, UW should be U16. I will correct my post. John

👍

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