MobiFlight Community Support

Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.

You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks! 

icon
Avatar
neustart84
Posts: 2
Hi, friends!
I have a problem: Somtimes a switch event is lost. In the FAQ section there is a solution to this problem: "Unfortunately some users report that they have issues with lost events when using a switch or button. It means that you use a switch and the desired action in your simulator.
This can be done as a workaround:
Under "settings", enable "Logging Mode" and set Level to "Debug"
Reduce the FSUIPC Polling Interval, e.g. less or equal than 300ms." and it helps.
But why does this happen? Is this a problem with arduino, FSUIPC,Mobyflight or something else?
Thanks!
[Last edited by neustart84, 2018-01-30 04:16]
2018-01-30 04:09
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3322
Supporter
If you can awnser this question i will spent you 50 ltr of beer :w00t:

Thats a secret we never can solve. This problem is only on some users systems. Myself i got it. Sebastian NOT got it.
So it´s not possible to fix it until now cause HE can´t see the problem finaly at his own Computer !

I already think THIS is a Hardware Problem.... Cause i can confirm the Issue only happens if my CPU Cores are in High work state. If i minimize the FSX and controll the functions then there are no problems.... Only if CPU (Core Alpha) is in 95-100% ( Like in normal flight) then the problem come allive.

At the moment i have no monney to buy a complete new Computer ( specialy build for FlightSim ) .... But i belive in a "perfect" Hardware System this problem is gone.
"Maby" it is possible to solve this in Software, too so "slower" Computers work fine too.... But Again: We not know how !

Sorry for that !
Good Luck !
2018-01-31 10:16
Avatar
neustart84
Posts: 2
iconpizman82:

If you can awnser this question i will spent you 50 ltr of beer :w00t:

Thats a secret we never can solve. This problem is only on some users systems. Myself i got it. Sebastian NOT got it.
So it´s not possible to fix it until now cause HE can´t see the problem finaly at his own Computer !

I already think THIS is a Hardware Problem.... Cause i can confirm the Issue only happens if my CPU Cores are in High work state. If i minimize the FSX and controll the functions then there are no problems.... Only if CPU (Core Alpha) is in 95-100% ( Like in normal flight) then the problem come allive.

At the moment i have no monney to buy a complete new Computer ( specialy build for FlightSim ) .... But i belive in a "perfect" Hardware System this problem is gone.
"Maby" it is possible to solve this in Software, too so "slower" Computers work fine too.... But Again: We not know how !

Sorry for that !



Thanks for info! I love beer! :)) It seems to me a problem in the speed of data exchange. But it's not clear why the debug mode fixes this. Logically, it should slow down the work.
2018-02-01 04:16
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3322
Supporter
The DEBUG String is basicly only a additional "line" in every config.
So the system must print a text on the screen on every input. I agree... this millisecond more work maby helps that a command is executed 1 internal clock later like normal.

BUT I think the Problem is at FSUIPC side.... Cause in the logging you can see that the Inputs are basicly executed by Mobiflight correct.... But FSUIPC can´t recive them.
The critical point is the READ/WRITE interface.... A Input is not written if there is a Read same time.
And Mobiflight have the logic to readout a Offset (Input) all the time (To make Precondition and If/Else possible.)
If a Offset would be not read then the Write on the Offset works 100%.... But if it´s read same time then maby 30-50% of Input writes are not recived.

Final Problem is.... Sebastian maby can fix the problem that INPUT Offsets are not Read all the time and only controlled read 1 Time befor executing a command.... BUT Then the Problem is already when we need to Readout a Offset for a LED and We need to write the SAME Offset for a Switch..... Then its read out all the time again !
Good Luck !
2018-02-01 12:20
Avatar
DeltaBravo
From: Schneeberg, Germany
Posts: 77
Hey Folks,

I've got the same problem now. My MIP 747 based on PMDGs 747 v3 @ P3Dv4 is nearly completed and I want to use the front outside view without VC. But sometimes I loose some switch events from my Homecockpit buttons/switches. So I have to control by going back to VC and check, if every switch is in the correct position.
I often read in different threads, that a high cpu usage triggers the effect. My system is quite fast - 4C 8T @ 4,5GHz 1070gtx 16GBRam

Via Windows taskmanager the user can set priority to diffrent programs. So the mobiflight priority could be set to high or even realtime. Also the user can select a specific core, on which mobiflight should run.
Did anybody checked this method already to prevent event losts?

@Sebastian: Did you try to contact Pete Dawson from fsuipc? I read some of his postings and had the feeling, he tries to help everyone.

Greetz,
Stephan
PMDG based 747 Homecockpit, 3 Beamer
P3Dv4.3 QOTSII FSUIPC 5full ArduinoMega vrinsight CDU2 + cpFlight 747MCP
2019-02-12 22:27
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3322
Supporter
Hi

As i wrote above i think the Problem is already FSUIPC itself... Or better said the com interface that tell FSUIPC to read/write a Offset.

So your idea is good but wont work... I got the same idea 2 Years ago, too.
Problem is that FSUIPC is itself a part of the FSX/P3D its a DLL as i know and not a selfrunning programm.

If my suggstion is correct that a High CPU usage occure in FSUIPC issues THEN we not must get prior to a core for Mobilfight..... We need it for FSUIPC.
In fact its a Part of FSX/P3D we can prior only the Sim itself... BUT As you know . Exactly the Core of the Sim is the problematic one that is in high usage.

I read somewhere that its possible to split FSUIPC to other cores... But that wont work for me . Maby i did something wrong.

******

Important !

iconDeltaBravo:


@Sebastian: Did you try to contact Pete Dawson from fsuipc? I read some of his postings and had the feeling, he tries to help everyone.



100% Agree.
I know its a bit "hurt proud" to ask for help.... But i think this problem would be solved verry fast, if the Mastermind of FSUIPC see the Situation.
A also agree, that Pete is a verry nice guy. Reply within 24 hrs and help me on every request in the past. I´m pretty sure he will support a project like mobiflight that is used by hundrets of Cockpitbuilders all over the world !
Good Luck !
2019-02-13 10:02
Avatar
DeltaBravo
From: Schneeberg, Germany
Posts: 77
Debug Mode is no solution to me. It´s too slow. When i try my switches, the change is recognized 15 seconds later.
You realy mean Extras -> Preferences -> Logging --> DEBUG ?
I´ve many lines in my Mobiflight and it´s only the MIP with Glareshield... :sleep:
Okay, every switchprocess called the right function, but much too late. When i press a key with an annunciator behind, i don´t want to wait 10 secondes before
the switchtrigger is recognized and another 10 seconds before the annunciator fires up.

:cry:
PMDG based 747 Homecockpit, 3 Beamer
P3Dv4.3 QOTSII FSUIPC 5full ArduinoMega vrinsight CDU2 + cpFlight 747MCP
2019-02-14 12:59
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3322
Supporter
Hi Again Delta

Here there is a missunderstanding by yourself !
That occure when you reopen a Topic that is 1 year old !

In the PAST when this topic was written the DEBUG Mode was the correct solution.
Today with 7.5.2 the Debug Mode will not longer work and is only to find issues.
Your right. active DEBUG Mode will slow down the system a lot.

Whatever a 10 Second delay ( not sure if you overstate here) is not normal. 0,5 to 1 Sec is normal with Debug Mode. all More is also a indice for a maby untidy System, a slow BUS (no SSD Harddisk) , Less Memmory or a bad Network situation. Check this if you realy got more then 2 Sec Delay in a input.


*****+
summary recommend system in 7.5.2

1. NOT use Debug Mode enable while Flying ( Only to find issues in configs or to check function of switches while building process)
2. Set FSUIPC Polling Rate to the Point where no missing Events occure.
(Some Users can work with 200ms. Normaly 300 should be ok for most Users .... 400 should work for the rest.... 500 is not recommend in case of slow Displays ! )

Please report expirience.
Good Luck !
2019-02-14 18:34
Avatar
DeltaBravo
From: Schneeberg, Germany
Posts: 77
Hi Pizman,

i did not overstate - it was more like a interpolation. When i started my test in debugmode, i used 8 to 15 switchpositions and buttons and nothing happend.
After a long while - more than 10 seconds - every action was done in my PMDG 747 virtual cockpit rapidly in short sequence. After this initial circumstances,
everything worked with a delay of 1 to 2 seconds.
I now use 450ms pulling time for fsuipc. Not everythings is okay, but better.
But i´m wondering about one effect:
I think, that when i used a switch few times, mobiflight don´t lose the following actions anymore :confused:


Greetz
PMDG based 747 Homecockpit, 3 Beamer
P3Dv4.3 QOTSII FSUIPC 5full ArduinoMega vrinsight CDU2 + cpFlight 747MCP
2019-02-20 18:27
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3322
Supporter
Ok...About the 10 Seconds and the sequence execute of commands i´m out..... Not understand that. Maby a problem in FSUIPC.

About the situation with more better feeling after using a button multiple time.
That can be explaned logical.

Mobiflight basicly READ all used Outputs in a "Endless Process" multiple time per second ( corespondending to the FSUIPC Polling rate)
INPUTS are not read directly at beginning.

BUT As you know a INPUT also must be read to make for example a Function in Parameter field..... For example you say $+5 or you say if($=1,0,1)
In that case Mobiflight must READ the current Status of offset to calculate the needed value we like to SEND to sim by our Button Press.
This Read will be done once when you use a Input Button FIRST Time. BUT then this Offset also get into the "Endless Loop" and will be read all time.

So YES.... There is a different of function when you use a button first time after systemstart OR if it was used already before ( Different Read Logic)

Basicly THAT is a big part of the Problem with lost events !

Summary... I hope already Sebastian can give us a good solution finaly.... maby in co-work with Pete Dowson !
Good Luck !
2019-02-21 00:06
icon