FSUIPC - remote client connection fails

[Ken Denman]

Hi,

Sim is current version of MSFS 2020, running the updated FBW B787-10 (B78XH-v0.1.12)

FSUIPC7, Version 7.2.13 (19th November 2021)

Wide client and FSUIPC Registered

Only MSFS 2020 and FSUIPC/FSWide run on this machine: Windows 10.

 

Remote machine: Windows 10

Runs: Wide Client compatible version, Vpilot, BAV Merlin and Navigraph Charts.

No Merlin Report was due.

Flight State:

In the cruise FL390 for more than two hours, BAV Merlin disappeared after stating "Aircraft paused for too long"

MSFS 2020 aircraft was running completely normally and updating distance, FMC active in all respects. It continued running normally until shut down manually.

Connection to VPilot and Charts seemed to be unaffected.

Relevant logs are attached

It would appear that somehow the remote connection was lost which only affected Merlin.

If you need further info, please let me know.

 

Thanks,

 

Ken

 

 

 

 

 

WideClient.log WideClient0.log FSUIPC7.log FSUIPC7_prev.log WideServer.log WideServer0.log

[John Dowson]

22 minutes ago, Ken Denman said:

running the updated FBW B787-10 (B78XH-v0.1.12)

Do you mean the Heavy Division mod (https://github.com/Heavy-Division/B78XH)? Thats not FBW...

Some strange things in your WideClient log:
  - it seems that a 2nd BAV Merlin client is being started at around the 1h44min mark:

Quote

   30610 New Client Application: "BAV Merlin" (Id=1160)
  6232563 New Client Application: "BAV Merlin" (Id=1220)
 

  - Connection is then lost but reconnected at around the 2h 28min mark:
 

Quote

  8879203 Timed out response: connection assumed lost!
  8879203 Ready to try connection again
  8880250 Attempting to connect now
  8880250 Server = KENDENMAN003
  8882532 Trying TCP/IP host "KENDENMAN003" port 8002 ...
  8882532 ... Okay, IP Address = 192.168.0.18
  8882532 Connection made okay!

  - Connection lost again at around 5hours:
 

Quote

18279547 Timed out response: connection assumed lost!
 18279547 Ready to try connection again
 18280578 Attempting to connect now
 18280578 Server = KENDENMAN003
 

 

Maybe the second BAV Merlin client started affected the first one? Or did you the first BAV merlin client exit due to the  "Aircraft paused for too long" message and you manually restarted? 

Having said that, I think your issue looks to be with the BAV merlin client. As the sim/aircraft was not paused, why did this client think it was? Maybe you can contact the provider/developer of that 3rd party client to determiner what is triggering this message.

Otherwise, you could try setting the ReconnectMinutes WideClient ini parameter,  but as your other clients are ok I doubt it is to do with the WideServer/WideClient connection, but rather the WideClient/BAV Merlin connection...
 

John

[Ken Denman]

Yes John you are correct, it is the B78XH Mod.

As for the BAV client, it was not restarted by me.

I will check with the BAV people,

 

Thanks a lot for the quick return,

 

Bests,

 

Ken

 

 

[Ken Denman]

Hi John,

The response from the BAV people

" It's recommended to NOT use WideFS with Merlin.

The timings are too inconsistent across the network to allow many of the measurements we take/rely on to be useful.

While it may appear to run OK, even Pete/John Dowson have suggested that timings in general can be very delayed and messages between WideFS and FSUIPC can be lost."

My bad, I shall run Merlin on the man MSFS platform from now.

Thanks for all your help,

Case closed,

Best regards,

Ken

 

 

 

[John Dowson]

13 hours ago, Ken Denman said:

The response from the BAV people

" It's recommended to NOT use WideFS with Merlin.

The timings are too inconsistent across the network to allow many of the measurements we take/rely on to be useful.

While it may appear to run OK, even Pete/John Dowson have suggested that timings in general can be very delayed and messages between WideFS and FSUIPC can be lost."

This did not sound quite right to me, so I checked with Pete, and this is his response:

Quote

No. Messages are guaranteed, and in order, using TCP. UDP has no checks and can lose frames or get them out of order, though with most modern Networking gear and cables this is unlikely.

Perhaps he means that some changes in offset values are missed. This can be true if the offsets are changing faster than WideServer can deal with (same, really, as with our Monitor logging option. WideServer frames are throttled back to something like 24-30 fps no matter what the true frame rate.
 

I don’t know what time-critical items they want. I suppose, with FSUIPC7 being a separate process to MSFS there’s an added delay element.

Looking at the thread, this sort of error:

          8879203 Timed out response: connection assumed lost!

can obviously lose update frames. Such errors shouldn’t occur all being well.

 

But the BAV response is potentially true if they are measuring things like aircraft performance.

The timings are too inconsistent across the network to allow many of the measurements we take/rely on to be useful.

But surely ACARS is to do with non-time critical matters?

Looking through the use of that second class of message I would doubt that any would be time critical to the extent that the throttled frame rate would cause any significant problems.

The fact that the program started again, seemingly (according to the OP) all by itself seems very strange.

Perhaps the OP needs to look at the loading on the Client. If MSFS + FSUIPC7 are running okay at acceptable frame rates, timing problems may be more at the Client end. The Server log also suggests this:

 

  9433610 Error 10053: client socket disconnected at Client: removing (skt=1496) TCP

  9436906 Incoming connection Accepted ok (skt=1548) TCP

 

 

John