Pete Dowson
-
Posts
38,265 -
Joined
-
Days Won
168
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Pete Dowson
-
-
3 hours ago, nevmun said:
How do I install FSUIPC4 into FSX SE - do I need to do both Again?
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
-
18 hours ago, MarkStallen said:
If you use FSUIPC, you don't need vrsim or serialfp2. Most buttons and rotary switches for my combo are programmed in the button-section of FSUIPC. The only thing what LINDA does for me (for instance the heading) is indeed writing 07CC back to the combo-device.
So if I disable Linda then I can turn the heading knob FSUIPC executes the events and that works fine in the sim but the display of the combo does not match the heading shown in the aircraft. Using Linda matches the display with 07CC.
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
-
47 minutes ago, MarkStallen said:
If I test with VriSim or serialFP2. then turning doesn't give a jump an the combo display.
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
-
15 hours ago, bodmore said:
This is with the default Cessna 172. When FSUIPC is used to control flap movement the buttons presses are either ignored or else result in erroneous flap movements (such as over or under flap movement). If I use the FSX button control assignment to assign flap incr/decr to the X52 buttons everything is fine. Likewise, the FSX F6/F7 direct flap controls work fine. I have tried various "two way centre-off switches" on the X52 with the same result. So there may be subtleties in using FSUIPC for this function which escape me and I'd like to understand this.
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
-
29 minutes ago, Knox1423 said:
It was set to 9600, and I read that's where it should be. I just remember coming across a note where there's a certain type of PFC module that requires 19200, so I tried that, but defaulted back to 9600 since it didn't change anything.
This is a great lead. I'll go ahead and order a serial ports card for my computer to give that a try and see what I come up with. I'm not at home at the moment but will double-check that I have the correct files later.
During my testing, I tried a number of different planes, just in case. I tried a single-prop, double-prop, and twin-engine jet. I have the same throttle quadrant shown in the picture you attached - 6 levers, 2/2/2, same colors.
I really appreciate the advice, and will update when I get further.
Thank you!
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
-
1 hour ago, Knox1423 said:
I navigated over to FSUIPC, then to the PFC Add-On. I went to the Flight Controls tab for configuration, and noticed the Aileron input was changing without me moving the yoke. When I checked the throttle controls, two of them were jumping between inputs as well. I went through every calibration tab, enabled the appropriate column for which I had control (e.g. yoke, throttle, cowl flaps, etc.) and tried testing/calibrating. None of them seemed to work though; the only input being shown was the random input number changes that wasn't me.
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
-
28 minutes ago, nantelp said:
I have found a way by assigning a button on my joystick to arm/disarm the ground spoiler. But I am not able to configure the arm on my PFC to manage the speed brake arm.
...
I have separated the arming of the ground spoiler from the speed break movement, is this ok?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
-
17 hours ago, aua668 said:
So as you can see, the function is fired immediately, when I register the offset, although frequencydid not change
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.
QuoteAs a consequence I would have now to add similar code to all my event functions, to avoid firing during the event registration process.
I don't understand why you need to ignore the initial values?
QuoteAs I currently have massive problems, where events are not registered although they are defined in the same way since many years, I try to nail my problem down.
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
-
1
-
-
11 hours ago, Reco said:
Or should I set the elevator on its own move the cyclic left set max then move cyclic right set min and do the same with the Ailerons
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
-
11 hours ago, Adooli said:
Would installing FSUIPC in admin mode help? Or running it in admin mode? That is if either is possible.
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
-
On 8/25/2021 at 2:15 AM, Adooli said:
When I launch FS_COM (the CP Flight addon) it shows up that it is connecting and then nothing and does not connect to the Sim
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"!
10 hours ago, Adooli said:CP Flight uses the Simconnect.dll to link with FSX/PMDG via FSUIPC.
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
-
5 hours ago, Thiago Duarte said:
In this configuration, I have no way to calibrate the spoiler directly in FSUIPC, because the Arduino is not recognized as a USB JOYSTICK. That's why I need to use MOBIFLIGHT.
I'm afraid I know nothing at all about MOBIFLIGHT.
5 hours ago, Thiago Duarte said:Now when I return the offset to 0BD0 (SPOILER) I have no success. It appears that something is preventing it from extending and moving the spoiler lever. As I also said, this same code for the spoiler works on STANDARD FSX aircraft like Airbus and Boeing.
That sounds like that particular aircraft does its own thing, ignoring the built-in FS spoiler logic.
5 hours ago, Thiago Duarte said:I believe it has something to do with this range from 4800 to 5619, and when the potentiometer value goes through it, it must be going into the range of spoiler armed function and thus blocks the operation of the spoiler lever.
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
-
1 hour ago, CatalinaFly said:
I recently installed FSUIPC7 on my new computer. It installed great but when I try to run it I get a message steam: 1250410 Application not found.
FSUIPC7 should run automatically when you run MSFS, so try starting MSFS instead of FSUIPC7.
Pete
-
1 hour ago, GillyTheKid said:
It is indeed not writing to the log
You mean not writing to the offset 0330, I assume.
1 hour ago, GillyTheKid said:what would be the reason for this and is there any was to fix it?
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.
1 hour ago, GillyTheKid said:The hotkey option within FSUIPC itself.
Ah! that's "Set standard altimeter" -- I wouldn't recognise it as "Q1013".
1 hour ago, GillyTheKid said:Just an addition to this - it seems like it may be an issue with the FSLabs. I ran two tests, one with the FSLabs and the other with the PMDG 777. Both named log files are attached below. PMDG 777 clearly writes the correct offset value, whereas the FSLabs is just not writing it at all.
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
-
2 hours ago, cellular55 said:
thanks a lot.. but I do not undestand where I have to specify the number of seconds
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
-
2 hours ago, GillyTheKid said:
I do change to barometric pressure to STD above the TA, but it does not seem to effect the level displayed on Merlin. It still reads it as the pressure that I had previously in below the TA; the flight level shown is a reference to the QNH I had previously, rather than that shown on the PFD on the aircraft, with STD selected.
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.
2 hours ago, GillyTheKid said:I managed to work out some sort of work around by assigning a key directly to Q1013 in FSUIPC itself
Sorry, you need to explain that. "Q1013" isn't a control recognised by FSUIPC.
Pete
-
19 minutes ago, cellular55 said:
I need to find a way to simulate a keypress for a specific number of seconds.
Seems that ipc.keypress do not have that kind of option.
Is there a sort of workaround or another method to use in lua?
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
-
On 8/20/2021 at 3:06 PM, Thiago Duarte said:
Checking the documentation I see there is an instruction to use OFFSET "OBDO" "Spoilers control, 0 off, 4800 arm, then 5620 (7%) to 16383 (100% fully deployed)...". I don't know how to implement this code. I would be grateful if someone can help me.
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
-
15 hours ago, GillyTheKid said:
Normally, once STD pressure is selected, the altitude tracking will change to flight level, rather than specific values
Yes, as normal.
15 hours ago, GillyTheKid said:The FSLabs and FSUIPC aren't interacting properly and FSUIPC can't sense the change of barometric pressure and send that to Merlin.
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).
15 hours ago, GillyTheKid said:He says that Merlin checks the Kollsman value sent from FSUIPC and crosschecks it with the current altitude; if there is a value of 1013, the altitude displayed in the flight tracking will be FL rather than local altitude
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.
15 hours ago, GillyTheKid said:When flying the FSLabs, the Kollsman value doesn't seem to change from that of the one that is displayed on sim load up. Is there any reason for this value not changing
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
-
20 hours ago, Luke Kolin said:
2) Just so I am clear, if I'm setting the frame rate limiter in the driver (via NV Inspector?) I assume that does the same thing as the internal P3D limiter or vsync? I'm never getting below 15 or so fps, but with the limiter never above 45.
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
SendMessage timeouts
in FSUIPC Support Pete Dowson Modules
Posted
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