Alexey
-
Posts
12 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Alexey
-
-
Hi!
I have a custom FFB yoke and try to setup MSFS with FSUIPC7 in the same way I had in P3D with FSUIPC5/6.
* I don't have joystick device for my yoke. Instead, I directly set axis values through offsets 0x0BB2, 0x0BB6.
* For P3D it works with DirectAxesToCalibs=All set in .ini file
* I don't need any calibration/nonlinearity (the yoke has full range already).
In MSFS this approach generally works, but comparing virtual yoke and real yoke motion I see that virtual MSFS yoke doesn't move linearly comparing to real one. There is a sensitivity curve introduced somewhere which makes it more sensitive at center.
It works same way with and without FSUIPC calibration enabled (with FSUIPC calibration set to linear). I can compensate it via FSUIPC at the expense of movement accuracy (inverse curve), but that's undesirable scenario.
Note: I cannot set or see calibration curves for ailerons and elevator in MSFS because I don't have joystick device for my hardware.
Is there a way to have linear motion in this case? Am I missing something in FSUIPC or MSFS configuration?
Thanks!
Version: FSUIPC 7.3.1.1
Environment: MSFS 1.27.21.0, Win10
-
Hi Pete! Thanks for quick response!
QuoteIt is really a very bad idea to have flight controls such as yoke connected to your flight simulator via a Network. You need to connect all axes direct to the main PC. This is why WideClient only provides support for buttons and switches.
Good or bad, this is typical setup for control loading applications. They itself load 1-2 cores for calculations and communications, so I don't want to stress main rendering PC even more.
The lag is under 5-10ms (with UDP), which 100% enough for yoke movements. What is bad here?
QuoteI've no idea what is causing your need to have WideClient reconnect.
Obviously it's because something wrong with WideClient... It should not increase its memory footprint continuously, because the number of variables is constant (I think under 10-15 offsets, or event less if I setup only yoke app).
Also, why it stops sending joystick buttons after reconnect? Again doesn't sound like correct behaviour.
QuoteAnd the excessive loading by WideClient on your PC will be caused by Client program request process, nothing else.
It's not excessive, it works very good until WideClient reach 100% load of its core.
I believe that under any constant loading and working network stack WideClient should not uncontrollably grow its memory footprint and CPU load.
Do you agree with this statement?
-
Hi!
I'm using WideFS with P3D 4.4: the client is installed on a second machine, and there are three programs that using it: force feedback yoke, motorised trim wheel, and a shaker controller (all from bffsimulation.com). Also yoke joystick buttons are connected via WideFS.
When WideFS client connects to the server, its cpu usage is ~3-5% (from 4 cores) and it takes ~10Mb RAM.
Then it starts to increase slowly, but noticeably. After about 15 mins, CPU load rises to 25% (full single core) and RAM is ~60Mb. I can see yoke movements becoming "coarse" and laggy (they are written to FSUIPC offsets via WideFS). Same for joystick buttons - when I start simulation, P3D reacts almost instant, but after time, it takes couple of seconds to react. Most probably it's the result of 100% CPU core loading on the second machine.
I set WideFS to auto reconnect each minute, and it helps. After reconnection CPU load and RAM back to normal and start increasing again. But there is annoying side effect - after reconnect joystick buttons stops transmitting to server. I don't see reaction to pressing those buttons in FSUIPC settings. This looks like another issue (shutdown and restart of WideFS fixes this till next reconnect). And reconnection unfortunately introduces visible momentary jump in yoke movement, that's not great on final approach, etc.
Does it look look like anything known?
Tech specs and notes:
- FSUIPC 5.150b and WideFS 7.151 (latest to date), P3D 4.4, Windows 10 x64, Core i5 6600k 16Gb RAM (second PC with WideFS). Local gigabit ethernet.
- Tried various WideFS client and server settings, no positive effect to this issue (TCP and UDP, different ApplicationDelay, run as admin, etc.).
- Logs don't show any errors and look generally normal. Adding Log=Yes shows tons of offsets being written and that's all.
- Interesting that WideFS usually stay in processes when I close all clients and close it's window. Takes zero CPU, but memory still allocated. Has to kill it manually.
- My case maybe a little bit specific because WideFS client constantly writes FSUIPC offsets multiple times per second.
- Behaviour is the same if I only leave a single client application (any).
- Process Explorer shows several threads inside WideFS process and only one thread takes all the core. Others are less that 1%.
- With increase of ApplicationDelay parameter RAM and CPU load increases slowly.
- P3D frames locked at 30 FPS all the time.
Attached config and some short last session logs (with reconnect enabled, so actually not showing the problem). I'll post logs with disabled reconnect within 1-2 days.
-
On 1/4/2019 at 7:30 PM, John Dowson said:
Hi,
Pete's still away, but I took a look and could reproduce and it seemed to be an easy enough fix, so please try the following:
I'm not too familiar with this flag/functionality, so I'll get Pete to verify when he's back.
Cheers.
Hi John!
Working as expected now, thanks!
-
Hi Pete!
Just noticed that brake axes calibration is not saved into .ini file.
* I set DirectAxesToCalibs=All
* open FSUIPC calibration tab, go to Left/Right brake
* press "Set", do some changes
* close the dialog
* then open again => no calibration for brakes axes (nothing in .ini files).
Can you pls check on your side?
-
Hi Pete!
Downloaded 5.150a and tested - working as expected! Thanks!
P.S. "DirectAxesToCalibs=All" sounds good to me.
-
Thanks for an explanation!
But why are brakes axes so different? From here it looks like same questions are valid for other axes, including elevator and aileron. How that axis vs offset conflict is solved for them? I'd expect same behaviour for brakes, no matter which one.
BTW, there is x310A offset to disconnect joystick from main controls, maybe something like this for brakes would resolve the issue?
Personally I'd agree with any simplest workaround allowing me to calibrate that axis
-
18 minutes ago, Pete Dowson said:
I've tested your problem here. I don't have your FFB yoke, so I've only tested with the DirectAxesToCalibs=Yes parameter. And I can now confirm this problem. I will have to run it in debug mode to find out why.
Sorry, I probably won't have time to do this till Tuesday now (busy tomorrow and away on Monday).
Ok, thanks!
-
Just to be 100% clear, here is the screenshot from what I'm getting:
Left part (prop, mixture) is a an example of what happening when I press "Set" button there.
Right part is what happens when I press "Set" on Left/Right brakes. I.e. nothing is happening (looks like it immediately returning to the original state).
If I change DirectAxesToCalibs to No, brakes start working just as all other axes.
-
Hi Pete!
QuoteMaybe I will need to see your INI, which didn't appear to be attached to your message.
I can reproduce the issue with default .ini with a single changed line (i.e. DirectAxesToCalibs) . Pls find that .ini attached and logs also.
QuoteAnd, since the facility you are using (DirectAxesToCalibs) is intercepting FSUIPC Offset writes in order to calibrate them, could you please list what offsets are used for each control on your FFB yoke if you know them?
Yes, here they are:
0x0BB2 - elevator
0x0BB6 - aileron
However, to reproduce the problem, I don't need to start the app that uses those offsets (normally it starts on another PC via WideFS).
QuoteAre the brakes and otheraxes (throttles?) controlled by normal joystick inputs? If so, then this seems an odd thing to say:
Yes, I have a rudder/brakes and throttles. This is the reason I want to calibrate brakes axes (rudder is calibrated perfectly).
But I have this issue reproducible without any joystick devices connected (tried).
Quotebecause if a "normal" axis isn't assigned, obviously it won't be able to reach calibration.
I mean that I can enable calibration for any group box in "Calibration" tab, except for brakes.
And this situation does not depend on particular axis assignments. E.g. I can assign right brake to my joystick axis, or I can skip this assignment - still "Set" button in Calibration->Brakes doesn't change anything.
-
Hi!
I need DirectAxesToCalibs=Yes option to be able controlling A2A airplanes with my FFB Yoke (it uses FSUIPC offsets to control yoke position and this approach doesn't work with A2A without DirectAxesToCalibs).
I found that when this option is enabled, left/right brake calibration doesn't work. When I press "Set" for brakes in Calibration tab, simply nothing happens. Other axes work fine.
Version: FSUIPC 5.15
Environment: P3D 4.4 (same behaviour with P3D 4.3 and previous FSUIPC version), Win10
Repro steps:
- (optional) reset fpuipc.ini (delete, restart p3d, close p3d)
- set DirectAxesToCalibs=Yes in fsuipc.ini
- start P3D
- go to Axis Calibration -> Left (or Right) Brake
- press Set
Expected: usual calibration controls will be shown, button text changes to "Reset"
Actual: nothing is changed, still only "Set" button is visible in the Brake groupbox
Notes:
- obviously with DirectAxesToCalibs=No (default value) calibration is working
- other axes still calibrated fine
- if calibrate the axis with DirectAxesToCalibs=No, save to .ini file and then start P3D with DirectAxesToCalibs=Yes, calibration values deleted from .ini file (only for brakes!)
- in my case seems the behaviour doesn't depend on aircraft (though I'm testing mostly with A2A Comanche)
- same result whether axis is assigned or not.
Similar report: https://forum.simflight.com/topic/78135-ch-pedals-calibrate-brake-axis/
Direct axis control with FSUIPC has unwanted nonlinearity in MSFS
in FSUIPC7 MSFS
Posted
Yes, agree. This is legacy stuff I blindly moved from P3D (it was needed specifically for A2A aircrafts).
Set DirectAxesToCalibs back to No, but the behavior is the same - sim yoke movements not linear. With the obvious difference that I now don't see the axes in FSUIPC calibration dialog - but I don't need anyways.
Can't say, because this SU10 is when I first tried. Maybe I can try with SU11 beta.
Attached please find FSUIPC7.ini and log file (I removed name & email). Log shows values coming from WideFS (2nd pc), but that I hope irrelevant to the issue.
Log contents left me puzzled: what I see in values, looks fairly linear:
59625 25784 Monitor IPC:0BB6 (S16) = 0
59640 25784 SimRead: 0BB6="AILERON POSITION"
FLT64: 0
60984 25784 Monitor IPC:0BB6 (S16) = 8216
61000 25784 SimRead: 0BB6="AILERON POSITION"
FLT64: 0.501464961099
62328 25784 Monitor IPC:0BB6 (S16) = 15957
62344 25784 SimRead: 0BB6="AILERON POSITION"
FLT64: 0.973938106511
But look at the screenshot (also attached). The title bar shows current 0x0BB6 value ˜8000, so my expectation for yoke rotation angle to be about 45 deg, but in MSFS it just started moving from straight position. Same behavior for three airplanes I tested.
So no idea.. Maybe it's just visualization issue.
FSUIPC7.ini FSUIPC7.log.zip