Pete Dowson

We have many registered for third parties, yes. But we don't publish those details. It's left to them if they wish to (for example, Project Magenta publish their own lists). If you ask I expect you can be accommodated -- John is in charge of that now. Send him a PM. If you describe your application it would be best as it may be obviously one which would never clash with some other app which has a range of offsets, so making it more easily granted. Such an example would be SimAvionics v ProSim v Project Magenta -- no one would use any two of those at the same time as they do similar jobs. There are also a number of areas which have been reserved but were for applications never updated for use with today's sims, However, some of those we would just be guessing as we've lost contact with the authors. Pete

Run the FSUIPC4 Installer. If the FSX-SE installation is correct, the Installer will detect it and install itself correctly. Pete

As well as what John has told you, FSUIPC's inbuilt VRI facilities only deal with inputs -- switches etc which you can assign. It does not handle displays at all. You need to address whatever it is handling the displays. In the solution suggested by us, as described in the Lua Plugins for VRInsight Devices document, the Lua plug-ins needed for proper support depend on using SerialFP2 and the twin ports as described. That document also confirms that the correct COM port speed is 115200, but, anyway, yours must be correct for the device to be correctly identified and logged, as I explained before. Pete

Ah, I see. So without LINDA what are you using for the display? How are you expecting the display to work? I thought you needed to rely on SerialFP2 (or maybe that newer program). I think that is why I always used a pair of virtual ports to link SerialFP2 to the device with FSUIPC sitting in the com chain. SerialFP2->VPort1-linked to VPort2->FSUIPC->RealPort. If it works okay with LINDA why do you not want to use it? You need something to drive the displays. Pete

I've never seen or dealt with "VriSim". That must have come along a while after I ceased VRI development. In my days with VRI stuff I seem to remember that "SerialFP2" was needed. Is its function now superseded by LINDA on your system? I think perhaps that you need LINDA support? The COM port settings must be okay because the log shows the device recognised and named: 1735 VRI FMER ("MCP Combi") detected on port COM3 so it's either something to do with the way you are interpreting the inputs, or more than one program trying to adjust the same values. What interprets the encoder movement as button presses? Is that in LINDA or one of your own plug-ins? In our document "Lua plugins for VRInsight Devices" we provide an example "VRI_SetMach: An example for the MCP Combi Device", but this depends on setting it all up with the pair of COM ports. I can only assume that LINDA takes it all on by itself? Pete

Error 0xC0000022 is: ERROR_WRONG_DISK 34 (0x22) The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1. I think I've seen this spurious MSFS error reported in the MSFS Forums. Assuming you are not running the boxed version (which I've read needs Diskette #1 mounted) then it seems likely to be an MSFS installation problem. Pete

If you assign one button to FLAPS INCR and another to FLAPS DECR, then irrespective as to whether you do this in FSX or FSUIPC, that's the only thing which is sent. Just don't select "repeat" for the buttons in FSUIPC. And if assigning in FSUIPC do not also assign in FSX. There's really nothing else I can say, it is really that simple. In case something else is interfering in this very simple action, try using Event logging in the FSUIPC logging options. That logs events like those FLAPS ones as they reach FSX not matter how you have them assigned. Pete

For serial ports I can thoroughly recommend those by Brainboxes. They are more expensive that the majority, but all mine have been superb over many years. Pete

Any luck contacting PFC Technical Support? If you are getting spurious changes in the inputs it does really sound like a hardware problem, and maybe the console itself if the connections are good. Pete

I've not actually ever heard of, or seen, a Cirrus Console which wasn't using the USB (HID) system. That sounds like a very early model which I never knew about. You mention a DB9 to USB connector. Are you sure that's not delivering a true USB signal? Which PFC DLL are you actually using? The PFCcom64.DLL is for the COM/Serial port systems whilst PFChid64.dll is for the later USB/HID devices. I honestly can't think of anything in the PFC DLLs which would give the results you see, unless it is something silly like the wrong serial speed being set for the COM port. But then I wouldn't really expect the initial checks to pass. For my PFC gear I always first checked everything with the test and setup program supplied by PFC themselves. Haven't you got that? If not perhaps you could look at whether there's a download facility on the PFC site. If not please do contact PFC Tech support. Pete

The calibration facilities for the spoiler/speed brake axis allows for a region to be set for the "ARM" action. It is rather futile trying to use a button to Arm it, as the FS/P3D spoiler axis includes the Arm action part way through the axis movement, and that area is unavoidable when moving away from full down to any raising of the spoilers. Try to calibrate the Arm position in the calibration to the area so marked on your lever. Pete

But effectively it did change from the zero or null which would have been assumed it started with. In the case of a radio frequency I would have though it useful for you to react to the initial value, as if it had changed. Most of my Lua plug-ins use the fact that you get the initial value to, er, get the initial value. I don't understand why you need to ignore the initial values? I don't see why event registration could fail just because it fires initially? Also I doubt whether it applies to all events -- some are due to a true event, like those joystick ones detected by scanning, like button presses (though possibly a latched button press will fire initially to show that the switch is 'on'. I don't recall without checking the code (which I'm not doing today)). Aha, I see John has found that it is specific to Offset events. Pete

Either way would work. You just want the value to be near max and min for each press. You should still set a centre zone too. Pete

FSUIPC is a DLL module which, when running, is part of FSX. So if you run FSX in Admin mode (which should NEVER be necessary), then FSUIPC, being part of FSX, will be in Admin mode. Then any and all FSUIPC client programs must also be in Admin mode, or they won't get connected. If you can't get it working either way then it must definitely be a problem with FS_COM. I don't think anything else can conflict with that. So you really need CP FLight support. Ah you sure it is communicating with its devices? Didn't you say it was a USB link? Maybe it's just a configuration problem? Or USB3 v USB2. I think a lot of USB devices aren't compatible with USB3. Pete

The Log shows that FSUIPC is running okay, When you say FS_COM says it is "connecting", does that just stay like that? Isn't there any error message? I would guess that it isn't able to connect because you are running FSX in Admin mode, but not FS_COM (or vice versa). Programs running at different prililege levels cannot exchange data by the methods used by FSUIPC. If that isn't it then you really need to talk to CP Flight, as only they can debug their program or analyise their logs. Pete

MOVED FROM FAQ REFERENCE SECTION! Please never post support requests into reference subforums. They are clearly marked "not for support"! That makes no sense. It either interfaces to SimConnect, or to FSUIPC. Both are interfaces to FSX. As far as I know, nothing by CPFlight uses FSUIPC. If it does use FSUIPC, then with FSX running in Admin Mode, so much all the software wanting to talk to FSUIPC. If you think it is supposed to work through FSUIPC, then please show me the FSUIPC4.LOG. Pete

I'm afraid I know nothing at all about MOBIFLIGHT. That sounds like that particular aircraft does its own thing, ignoring the built-in FS spoiler logic. No. That cannot be if the FS spoiler logic is used. To start with, if you try to test on the ground then as soon as the value 4800 is passed the spoiler will fully deploy, just as they would when you land with armed spoilers. All that is different for spoilers compared to other flight controls is that the range 0 to 4799 does nothing. Note that even with your raw axis values you can calibrate spoilers in FSUIPC by writing the value to 3BB2 (or in fact any of the offsets 3BA8 to 3BC4). Then FSUIPC will detect is as if it was a USB joystick interface, allowing you to calibrate it properly. Then you wouldn't need your formula. However, it sounds like that aircraft takes no notice of the FS spoiler. You need to find out (from documentation of the author) what you can use. Maybe you need to assign it directly to Axis_Spoiler_Set and not calibrate. That would deal with it assuming the aircraft logic traps the control directly, but then you'll need your formula applied. Pete

FSUIPC7 should run automatically when you run MSFS, so try starting MSFS instead of FSUIPC7. Pete

You mean not writing to the offset 0330, I assume. It's got to be that the STD button in that aircraft is not doing what it should. You need to get the author to fix it, I can't. Ah! that's "Set standard altimeter" -- I wouldn't recognise it as "Q1013". So you need to ask FSLabs what is going on. Note that neither PMDG nor FSLabs aircraft use or depend on FSUIPC. They'll be setting the pressure value via SimConnect -- or should be, at least. FSUIPC interfaces to SimConnect to read the value and populate offset 0330. Pete

You simply use the function to PRESS the key(s), then use ipc.sleep for whatever time you want, then use the function again to RELEASE the key(s). Sorry, but I thought that didn't need explaining. 😞 Pete

You need to Monitor offset 0330 (FSUIPC Logging Tab, right-hand side, offset 0330 type U16. For 1013 that will read 1013x16 = 16208, or if it sets it more accurately (1013.25) then 16212. check the option below to write it to the log. If your STD button is not writing this value then that will explain your problem. Sorry, you need to explain that. "Q1013" isn't a control recognised by FSUIPC. Pete

In the lua library document, look at the entry just below ipc.keypress, called ipc.keypressplus. With that you can hold the keypress as long as you wish. Pete

That's normally done by calibrating the spoiler axis. Isn't your potentiometer seen as a joystick axis? If not, how are you reading it? The 4800 value for "arm" is a built-in FS/P3D value. You'd normally calibrate a region of the axis movement so that you can guarantee to set ARM when the lever is in the ARM detente. I don't understand how your formula relates to the potentiometer input. What values do you get from that? If you are writing to 0BDC for flaps then one would expect Aerosoft to respect 0BD0 for the spoilers. If not, what are you supposed to use? Pete

Yes, as normal. The STD pressure, 1013, is set by the aircraft panel, not the other way round. The Kollsman value is held as hPa x 16 in offset 0330 (an unsigned 16-bit word). That sounds rather cock-eyed. The aircraft panel should set 1013 to the offset when STD is pressed. And if it is using Flight Levels if the pressure read is 1013, it will be wrong when that is the true value but you are not above the transition altitude. It is always up to the aircraft programming to set STD mode. It is never automatic in the Sim, as it doesn't know the local TA. It is only changed by the cockpit panel. You adjust it using a dial for the true current pressure which you get from ATIS or from ATC, or by pressing STD to go to Flight Levels. Neither FSUIPC nor the Sim changes it without the correct input. There's also a separately set Kollsman value for the G1000 if that is installed. That's at offset 0332. The behaviour is the same. Pete

I don't know about the limiter in NVI. My frame rate 'limiter' is VSync set in P3d. The FR Limit is set to infinity. I can get 25fps pretty consistently (mainly by limiting the AI Traffic with a frame-rate controlled lower limit in FSUIPC. So I set both Projectors to 25Hz refresh rate with VS on in P3D. With a single P3D screen I think the frame rate control in RTSS does well. There you can set a limit using a divisor of the sync rate. Unfortunately it doesn't work properly with more than the one screen. If you can identify exactly what FSUIPC requests are taking so long then John or I could have a look as see if there is a reason other than lack of processing time. Pete