John Dowson

Try the same test with the following build - make sure you move each of the 3 axes through their full range (from min to max and back) with the assignments panel open. And let me know the order in which you tried them Thanks, John FSUIPC7.exe

I am not sure what you mean by this... There is no path to MSFS in FSUIPC, and the log is just that - a log file, There is no point in changing that. Note that the log file you posted is from 25th April 2022 and is for version 7.3.2, and the ini file you posted from version 7.3.11. Are they from different folders? Did you change the location of the MSFS Community folder? If so, maybe the WASM needs re-installing? Although the WASM isn't needed to access PMDG offsets. I really think you need to check things again at your end. Are you even sure you have enabled data broadcasts for the PMDG 737? As far as FSUIPC7 is concerned, I suggest that you uninstall it by running the uninstallFSUIPC7.exe that you will find in your FSUIPC7 installation folder. Once it has uninstalled, re-run the installer to re-install - you can choose the same/default folder (C:\FSUIPC7) and your settings (and registration, if registered) will be maintained. John

Hi Ed, I didn't think the registry cleaning would do much but it was worth a try. It is difficult to see what is happening in that log file - I am going to provide a special build for you with additional logging as well as restricting the current logging to the device which has this issue (with joyId 2 and letter D in your original ini). Once I have supplied this build, please perform the same test - and let me know the order in which you are trying the trim controls, and make sure that you just move each control through its full range just the once, i.e. from min axis value to max and then back to min. However, although I don't understand what has occurred at the moment, I can't see how this can be an issue with FSUIPC5 or FSUIPC6. As this was previously working, do you have any idea what could have changed? Were there any windows updates just before it stopped working? John

Also, the offset I would like to see logged (initially) is the following: 3102 as U8 - ELECTRICAL MASTER BATTERY Maybe @Fragtality can check this? The avionics won't turn on unless this is set. I presume 0x3364 is set (otherwise FSUIPC wouldn't be working), and Daniel has already told us that offset 0x3103 (AVIONICS MASTER SWITCH) is always 1. If the ELECTRICAL MASTER BATTERY simvar isn't being used, is there an lvar that can be used instead? Thanks, John

@PSantosYou are using an old version of FSUIPC7, 7.3.6 - the latest and only supported version is 7.3.11. Please update. Also, I have said (and probably several times): Can you please do this when generating log files for support. There is also no monitoring of the requested offsets in your log file extracts. Did you check the button Display to Normal log file? If not, please do that - you must select a destination for the offset logging otherwise nothing will be logged. Do you see the PFC Control Connection Check dialog box? And do you have access to the PFC driver window? If so, please activate logging in the PFC driver for Log all decoded received data (under the Test tab), and also attach your PFCcom64.log and PFCcom64.ini files. I would also like to see a PFCcom64.log file and FSUIPC7.log file generated when using another aircraft where the avionics panel turns on as expected - just start the sim and load the aircraft and when the avionics stack has turned on, exit FSUIPC7 and show me the same files for this test, John

It looks like the PMDG SDK documentation for the 737-700 is wrong, and the Rotor Brake control is still being used. Please see John

I have checked this now with the latest/current PMDG 737-700 release (3.0.42) and the Rotor Brake control is still being used - I therefore suspect the documentation is wrong. You can see the various Rotor Brake events if you activate logging (in FSUIPC) for Events, open the logging console and activate some switches or rotaries in the VC. I have also tried assigning to several controls and everything I have tried is working as expected. The only issue I see is with the documentation. I will check the PMDG support forums and report this if it has not already been reported. For those getting the TransmitClientEvent event error with this aircraft, I need to see your assignments and log file (with appropriate logging activated) to look into this - no point in just posting the error (I need to see the context). Thanks, John

There is no point in just posting the error - please attach your FSUIPC7.ini file and a full FSUIPC7.log file containing that error, and generated with logging for Buttons & Keys as well as Events activated. John

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