lonewulf47

Hi Mario, There's nothing you can do about that. It's the AUSOT Server which does not respond at this time. This is beyond our scope. It just means that at this time you are not able to use the AUSOT System. I just fired up my EFB v2 and it loaded the AUSOT normally. So maybe just a momentary inconsistency with the AUSOT Server. Nothing to worry too much about if you're not regularly flying into and out of Australian Airspace.

Hello Frans, What "desired path to FSX:SE" did you set here? What Operating system are you using?

Is SimConnect properly installed?

It is more or less impossible to find the cause for the timeout by analyzing the LogFiles. A timeout happens, if the response time in the communication between Server and/or Client is exceeded. This is basically only possible in two cases: either a communication with an external source fails or the local communication (within the computer) is slowed due to processor overload. We have never seen this happen so far and from our position it is not possible to determine another cause. Just to solve another mystery: did you alter the Logfiles manually in any way? The IP-Address of your computer seems rather unusual, to say the least. I have never seen an independent system creating or using such an IP-Address.

Well, this is what my PFPX reports as valid version after updating with the latest Hotfix: The hotfix is available in the Aerosoft User Forum for PFPX and includes a few important changes is the coordinate format. In addition to this hotfix it is necessary to update PFPX with the latest planning data also available fron teh Download Section of the Aerosoft Forum. It is essential due to the major changes in (mostly) European Airspace regarding direct routings in Free Route Airspace.

I mean Direct Uplink into EFB v2 of course. See the respective method in the Manual. Nevertheless I can load your flightplan into EFB v2 without problems (see below). Apart from that I see that you are not using the latest updated PFPX 1.28.9i. I still fail to recognize your poblem.

Sorry, my fault. I overlooked the "none" in the Online Network window. That was too quick typing...😃 Any cahnce of getting a ClientLogfile also, please?

Whever you change someting in the Settings Dialog, please don't forget to press the "Apply" Button.

A PFPX Planning for this route should in any case show up properly in EFB v2 (as it did in my above example). as long as you don't try to activate a direct uplink. Direct Uplink will only work if the respective NAT track is active. Could you please post the Routing File "KSDFEDDF01.efbr" as created by PFPX?

But you didn't deactivate VATSIM Service in teh Settings Menu, did you? At least I see the VATSIM Connection message still showing up in the ServerLog: 2018-11-25 17:44:00.209 Debug : Profile received: B777-300ER 2018-11-25 17:44:04.584 Debug : Started online service VATSIM After having deactivated VATSIM Service please restart the Server and Client and please also provide the ClientLogfile.

Can you please try to select "none" or"IVAO" in the Settings Menu for a short while and check whether the timeout still occurs?

Yes, they do. The Server maintains connection to the Simulator and provides all necessary information fot one or more Clients.

Hi ??? (please observe the Forum Rules) I see that there were repeatedly issues with VATSIM around this time. Did you try disconnecting from the VATSIM Network for troubleshooting? ATM I have however no explanation for the repetitive timeout of the Client.

Hi Gerrit, The timestamps on Server and Client do not match. Client: 2018-11-25 15:44:45.131 Debug : Trying to connect to server ... 2018-11-25 15:44:51.138 Debug : Trying to connect to server ... ... (repeated) There is no corresponding timestamp in the Server LogFile. Are ou sure that both Server and Client were running at the same time?

I do not have any clue what your planning looks like, but the first thing that comes into my mind is: why are you trying to fly a Eastbound NAT Track at this time of the day? There are ony Westbound NAT Track open. You might need to check out the NAT Track Systen and the validity of the individual tracks. Presently the Westbound Tracks are open from 11:30z till 1900z. Your planning needs to be made outside the presently valid NAT Tracks. Nevertheless I can do a planning with the future NAT W track, which becomes active at 01:00 z and the routings is showing up normally.

Sorry, we can't give any commitment to that... At this moment it's not on our todo list.

Not only but also...😃 AivlaSoft is not the contractual partner of LIDO or Jeppesen. This is the business of Navigraph and NavDataPro. We are only providing the parsers to retrieve data from the Standard ARINC 424 Database. This would require some massive changes within the parser and the whole database layout.

We are retrieving data from the standard ARINC 424 Database. The Holdings are in kind of a sub-database which is not part of this Standard Database.

The LUKOP Holding is only defined as Holding IAF on the AppTrans without specific Holding Inbound and turn direction. Therefore EFB v2 depicts it as a Standard Right Pattern on the following course. Unfortunately we do not have full access to the entire Holding Database.

Hi William, To me it looks like a (unfortunately well known) problem with IVAO, but I'll have Urs to take a closer look into it, as this is not my field of expertise.

Hi Matthias, The path terminator of the latest dataset by NavDataPro Cycle 1812 confirms a Left Holding at SONDU inbd crs 081°. This is correctly depicted here. I do not have a Navigraph Dataset at hand. If the latter does not use the same path terminator then the holding would be drawn as a Standard Right Pattern. LIDO and Jeppesen do not always use the same coding priciples, but this is beyond our scope.

Not really (blush)... I just happened to be (a few times) in the right place at the right time during development of EFB v2...😉 Anyway thanks for the encouraging words.

Oh yess, I have an idea 😃 as I have written and translated a considerable part of the manuals...😉 The "Calibration" warning pops up, whenever the QNH in the A/C's altimeter is not corresponding to the actual (surrounding) pressure. You will note that this warning disappears as soon as you press the "B" key (to adjust the altimeter to local QNH), and it will reappear when climbing through Transition Altitude, if you didn't set the altimeter to standard 1013.25 HP. See Manual "5 Client", chapter 9, Sidebar.

Hi Juergen, No, of course not, that's not the display you should get when using ActiveSky. See attached Screenshot as an example for what you should get: In the Information window (i) you should also get the complete METAR and (if available for that specific airport) TAF strings. Make sure that you have activated Active Sky properly in EFB v2: 1) Set ActiveSky as your meteo source on the CLIENT Settings page 2) Make sure that you have entered the correct path for the "current_wx_snapshot.txt" file in the SERVER Settings 3) Make sure that ActiveSky is running. That should give you the proper indication in any of the Client windows.

Hi Juergen, Yes, my guess is that the detection routine found no RWY and thus interpreted these missing RWY parameters as not fitting into the requirements of the profile. Nevertheless it is something that we need to rework within the routing check. In fact there should be an error message popping up that there is an invalid (=inexistent) airport selected. As SEQU is no longer serviced (although still in the default simulator database), there are no more ARINC data available. Unfortunately this means that you will not be able to select any instrument procedure for this airport. What is still available however is the ILS of the default airport (as it still existing in the default data), but you need to tune it manually in the Airbus' FMGC.