John Dowson

FSUIPC populates these offsets with the data received from the PMDG SDK. If the value is not correct, you need to raise a support request with PMDG. However, before you do this, best to verify what these offsets actually hold via FSUIPC (not MobiFlight). To do this, use the offset logging facility for offsets 6430 and 6431, both as U8, and check what is logged for the different button positions. Also maybe log offsets 6436 and 6437.

To list the lvars, make sure you have the FSUIPC WASM module enabled, then just use the Add-ons -> WASM -> List Lvars... menu option to see all lvars and their values. Note that more lvars are available the longer the aircraft is loaded - you can issue a Reload command (again, from the WASM menu) to rescan and reload all lvars. [NB. There is also an ini parameter to the WASM called LvarScanDelay which you can increase to delay the lvar scanning - see the Advanced user manual for details on this). For the description of the lvars, you need to check the documentation for the a/c you are using.... However, there doesn't seem to be much of this available, especially for the stock aircraft. However, its usually pretty obvious what they are from the name. Note also that not all lvars are writeable - some are read-only. There is no way (that I know of) to determine if an lvar is updatable - you just have to try. I will also be releasing FSUIPC7 v7.2.0 later today (this has been available as a beta release for a while now). This has an additional facility to populate free user offsets with lvars for both read and write (where applicable). You may want to download and use this, once I've released. John

You could disconnect your device and just remove the registry entries for that device anyway, reboot and re-connect to get them added again. Take a backup of your registry first, and then save the following text in a .reg file (e.g. removeVPCStick.reg) and then execute by double-clicking: Windows Registry Editor Version 5.00 [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_3344&PID_4130] As I said, I'm not sure if this is the issue or will help, but worth a try. Otherwise, just continue to use device 1, thats not really an issue.

Not unless provided by the aircraft, i.e. this data is available for the PMDG airliners via the PMDG SDK (for FSX and P3D). There is no provision in the SimConnect API for such data, so I don't think this info is currently available for any MSFS a/c.

No problem, updated again!

Ah, ok. I don't know why this is and cannot really look into it as I don't have such a device. Could it be that it has multiple registry entries (just a thought)? Anyway, if it works with device 1, just use that.

I think the second argument to the com.readfeature call should be the report number, so try gt, n = com.readfeature(dev, Report) Maybe also try setting Report to 1 (which is the default), rather than 0, in your init section (of 0 does not work). I'm not sure why this should be if you only have one of those devices....

If you are using the FBW mod, you can use the lvars: A32NX_RMP_L_SELECTED_MODE A32NX_RMP_R_SELECTED_MODE which hold 1,2 or 3 for the left/right RPM, where 1 indicates VHF1, etc. For the stock A320Neo, you can use the following lvars: XMLVAR_RMP_L_CURRENT_BUTTON_IN_GROUP_FREQ XMLVAR_RMP_R_CURRENT_BUTTON_IN_GROUP_FREQ which also hold 1,2 or 3 for the left/right RPM, where 1 indicates VHF1, etc.

Updated!

Yes - you could restrict to just remove the rudder by using the Pid (Product Id) as well, but if you no longer have the yoke there is no problem removing that as well (i.e. just using the Vid to remove all products from that vendor). Make sure that the pedals are disconnected when you edit the registry, and best to reboot afterwards before reconnecting. Not at all!

Just make sure you back up your registry first - just in case....!

Yes, it should be the same. It only mentions windows up to 8 as that post was written in 2014, before windows 10 was released. I should update it....

No, it is not normal but has been reported before. When this occurs, the FSUIPC WASM module cannot be installed as the installer cannot determine the location of your MSFS Community folder. Did you run MSFS at least once before attempting to install FSUIPC7? If not, uninstall FSUIPC7, run MSFS, stop MSFS and then install again. If you get the same issue, check the location of the file to see if it is correct (can you see the UserCfg.opt file at that location?) and of so open the file in an editor to see if you can read it ok. If you get the same problem, please show me your InstallFSUIPC7.log file, and let me know what MSFS version you have (steam, MS Store or boxed).

Did you select to install the desktop icon, checked by default, at the end of the installation process? If so, I cannot see how it cannot be installed...could it have been quarantined by windows defender or some other anti-virus software? Is the MSFS.bat file created? There is no harm whatsoever in re-installing every time. And this needs to be done for various reasons (i.e. keeping documentation up-to-date, and now, more importantly, making sure the FSUIPC WASM module version is compatible with the FSUIPC7 version. As I said, I only provide stand-alone executables for beta releases for test purposes.

I will check this. I am planning on moving these gauge events to simconnect events at some point - been meaning to do this for a while but just not found the time yet. Thanks for your report.

You shouldn't have done that unless you are planning on using it! Can you reproduce the OP's problem? I've taken a quick look but it seems ok here. But I'm also running v7.2.0 with WASM 0.5.1. Thats why I would like to release these ASAP (tomorrow) to see if that makes a difference. Also the latest update to the CRJ implements throttle control via its own simconnect connection, so I'd like to investigate how throttle assignment works for this a/c. May be issues with priority levels if assigned and calibrated in FSUIPC (as with PMDG a/c), but not sure....

One thing you could also do is to change the following parameters in your FSUIPC7.ini, in the general section. Change: to Changing those stall times to a negative number will just log a message when data is stalled rather than reconnecting. As the CRJ seems to take a long time to load, it may be re-connecting to many times and then running out of SimConnect connections. However, I don't think this is your issue (from your log) but still worth doing. I will be releasing FSUIPC7 v7.2.0 sometime tomorrow, just got some documentation updates to do to complete the release. Once thats done, I'll take a look at the CRJ to see if I can duplicate your issues and investigate. Please update to 7.2.0 once released though. Thanks, John

This sort of issue is usually due to the axis being flagged as a digital axis (on/off) in your windows registry. To resolve, please see the following FAQ entry - although that mentions Saitek devices, it also applies to others:

I'll take a look tomorrow, but please check your ini. The last one you posted has this: Delete that bit in bold, and change to:

I don't think that is easily achievable. FSUIPC provides a mechanism for syncing flap detents, but not for throttle, sorry. I think the best you can do is to try to calibrate so that the throttle detents line-up as closely as possible., I guess things also depend on if using managed or manual mode, although I am not too familiar with the A320 to advise on this. You could try experimenting with the controls sent when with a range (i.e. the right-hand side of the assignments panel), by sending the axis control with the correct parameter value for the detent when within a range of that detent, but then you would not get a smooth axis movement.

They will probably be PMDG custom controls - you need to check your PMDG 737NGX header files to see what those are. You need to subtract THIRD_PARTY_EVENT_ID_MIN (which is, I think, 0x00011000 which equals 69632 - but check your header file to make sure), so for 85635, look for an event defined as (THIRD_PARTY_EVENT_ID_MIN + 16004) in the header on your PMDG documentation. John

That happens when you open the axes window directly from the system tray icon context menu. I'm not sure there is anything I can do - as its a modal sub-window of the main window, I certainly can't make it visible in the task bar as that is for main windows only. What you can do in this situation is: - press ALT-F - this is the hot key that displays the FSUIPC main window - then click the FSUIPC7 task bar icon. This will then bring both the FSUIPC main window and the Axes window to the foreground. John

As I have said several times, please just disable controllers in P3D for the time being. You still haven't done this: Also, please update to the latest version, v6.1.2, which was released 5 days ago. Only the latest version is supported. And also update your FSUIPC6.ini as suggested, i.e. (you don't seem to be following ANY of my suggestions....) Also, your ini shows that you have assigned your throttles as 'Send Direct to FSUIPC Calibration', but you have not calibrated your throttles. You MUST calibrate any axis that you assign via this method. Please read the documentation - the section I previously mentioned. As you only have assignments to the 4 throttle axis, anything else you are seeing MUST be coming from an assignment else where, either from P3D or the Honeycomb configurator, which is why I am asking you to disable controllers and stop (or uninstall for now) the honeycomb software. Enabling logging for Axes Controls will also show you the axes controls being sent, but best to remove the known culprits for this sort of behaviour (i.e. assigned in multiple places) before we look at this any further.

Sorry, but this is just confusing. For example, when you say moving lever 1 backwards, is that lever 1 on your Bravo? And if so, does that move your bravo lever 4 forwards? Or are you talking about in the UI, and mean thrust lever for engine 4? Anyway, I cannot help you if you do not show me your FSUIPC6.log and FSUIPC6.ini files. Please ALWAYS include these, especially after updating/changing. And did you follow the instructions I gave in my last post? Have you disabled controllers in P3D? Did you try calibrating as suggested?

Ok. That certainly is strange and sounds like an issue with FSUIPC. I will investigate. Thanks.