lonewulf47

Hi Alfredo, Yes, I understand what you mean, but this is not the way a DME ARC is defined and used. EFB v1 just didn't use the proper method yet for drawing AF and RF legs. If you fly a DME ARC manually the Standard Procedure to fly would be the so-called spider-web method. You turn to 90° of the RMI bearing and follow it in 10° steps. You might google "DME ARC Spider Web" to find relevant tips. It's a standard IFR procedure.

Hold on. We need to investigate this. So far I haven't seen this behaviour and - what is more annoying - I cannot duplicate it here.

As far as I can see on the server log nothing seems to be wrong on the server side. The client seems to be locked from any unknown reason. Personally I haven't see anything similar so far. According to the logfiles I see that you are running Server and Client on the same computer. Please shutdown Server and Client, then go to this path of the Client: C:\Users\<Username>\Documents\AivlaSoft\EFB2\Client\Settings and delete the following file: clientSettings.txt. Do not delete anything else. Now Restart the Server and the Client. Upon restarting the client it will again ask you for the location of the Server. This is normal after resetting the abovementioned file.

Yes, ok. That looks indeed very strange. What I'm seeing is that you have a flightplan active. Can you from this position at least open the Flightplan window, clear the Flightplan and restart the Client?

And where is the A/C actually standing?

Hi Brian, I'm afraid that Transition Altitudes are no longer accessible by third party programs as during the databuilding process they are retrieved from the ARINC dataset and - as being airport specific in many countries - included in the airport.bin file.

According to the Client logfile the Client did not receive an ICAO-Code for the actual airport. Could you make a screenshot with the Sim running after the Client is freshly loaded?

At what airport were you located when this error occurred?

https://forum.aivlasoft.com/topic/3046-how-to-create-a-support-file/ And please post the two zipped logfiles here in this forum. Furthermore it would be VERY interesting to have more information about your EFB v2 setup.

See the FAQ section in this forum.

Please post the support files.

Hi Manfred, Looks great! We will of course neverthelss investigate but for the moment I see that you are done with Hervè Sors' Navaids Update. Thanky for reporting!

For the moment just wait for the results of cour investigation. I have done a few tests with other standalone DMEs. In fact if a navaid is not existing in a BGL, then it should be depicted "greyed out" as a virtual navaid, which is not tuneable, but still available as waypoint in EFB v2. This worked satisfactorily on other DMEs like HOC (Hochwald) and others. They are all depicted in grey and will show up in the list if needed. For the time being it's only WTP (there may of course be others) that does NOT show up (I have tested with NavDataPro database). We need to thoroughly check WTP DME in the ARINC dataset to find out what inhibits its display. Just make sure that, even if it shows up, it will not be tuneable (not indicating on the DME receiver) if it is not part of any BGL. To improve this situation we recommend the use of http://www.aero.sors.fr/navaids3.html to reflect the actual state of all navaids worldwide.

Manfred, there are two more things: 1. The WTP DME in my install is tuneable, which means that it is contained in the repective default BGL. If it were only contained in the ARINC ddataset, it wouldn't be tuneable. 2. The fact, that you have TWO databases with TWO different cycles (1810 outdated and 1811 actual) is in fact something that should neither happen nor be possible. In fact only ONE database per Simulator and per Data Provider is possible. In any case you should delete both databases and build a (single) new one. That fact that the WTP DME is tuneable in my install is clearly attributed to my regular update of the default BGLs by Hervé Sors' fabulous free update service for Navaids. http://www.aero.sors.fr/navaids3.html For waypoints (also available) it is not necessary as in EFB v2 all waypoints are derived from the ARINC dataset, unlike all navaids, as the latter need to be tuneable and therefore are taken from the BGLs in first priority. If a Navaid is not tuneable and only derived from ARINC data, it should show up greyed out (virtual navaid). Why this is not the case in your install we will yet need to find out.

Thanks Manfred, It seems to me that during the database building process this DME is "getting lost" for whatever reason it may be. We will have to investigate. ATM Urs is AFK, so it will take a bit until investigations can start. We will keep you advised ASAP.

There is not too much that I can add: First thing is that WTP DME is still contained in the Irish AIP as an Enroute Navaid. See Chapter GEN 2.5. List Of Navaids And also in ENR 4.1: It is (obviously) also contained in the NavDataPro Database 1811 that I'm using. I see it in the navaids.txt list: Based on the above Facts I see it also on my EFB v2 World Map: So, it's a bit difficult to say what happened here. On my side with the NavDataPro Cycle 1811 everything looks as it should. It might be worth investigating with the Navigraph 1811 cycle. I'm unable at my end, as I'm not using Navigraph.

I'm aware of that, however DME remain operational mainly to support basic DME/DME RNAV which is still being used in many A/C not being equipped with GPS or as Backup Navigation System. Usually as soon as the VOR part is decommissioned, teh remaining DME ist not being used as an RNAV Waypoint. Well, only Urs can tell us that, as from the EFB MAP I canot say whether it's stemming from a BGL file or from the ARINC dataset. The only way to determine that would be to fly to the place and try tuning it. If it tunes then it's definitely from within a BGL...?

We have noticed that Users of Bullguard Firewall may run into problems when Server Startup is hampered producing a TCP Error Message in the ServerLog. It seems that Bullguard Firewall is influencing TCP port handling of EFB v2. This might need some more investigation from our side. As an immediate remedy please check this thread: https://forum.aivlasoft.com/topic/3266-error-tcplistener-throws-an-exception-message/?do=findComment&amp;comment=20453

Hi Cliff, Please check this thread: https://forum.aivlasoft.com/topic/3266-error-tcplistener-throws-an-exception-message/ This is describing the same error message that your ServerLofgile is reporting. Something is obviously restricting access to TCP port 51748. Do you use Bullguard Firewall? In any case it might be worth checking Windows Defender Firewall as described. This error report by .NET also refers to missing user rights. Be sure you always start the Server with Full Admin Rights.

Which Nav Database of which cycle are you using? I see WTP DME on my EFB v2 map, however it is very uncommon to use a DME as an enroute waypoint. No idea why ProATCX is doing that. We might need to investigate why WTP is not recognized.

Hi Lukas, The figure in your profile is completely wrong! We are talking about Radius! The wingspan of the B748 is 68.4 m, thus the radius is 34.2 m, rounded up to 35 m. You can change this easily on your profile. No idea where you got this figure from. If you donwnolad the profiles from our Contributions/Profile page, then the radus is correct: https://forum.aivlasoft.com/topic/3002-profiles/

Lukas, Yes, grey simply means that the Parking Radius set in the present A/C profile is too small for the parking spot. This is something that we don't have any influence. It is the scenery designer's task to create parking spots to accomodate for the necessesary A/C category. In ORBX/ESSA the largest parking spot has a radius of 33 m. Regarding EDDF it will of course also depend on the Add-On. The on I use is Aerosoft's EDDF and it has many parking spots suitable for the B748, see screenshot:

Hi Michael, Yes, that's the default limitation set by freeware FSUIPC. In the paware version this limit can be increased..

Hi unknown??? (please observe the forum rules) We have decided to renounce aural warnings as far as possible. We have introduced an aircraft specific warning system for the Altimeter setting. Please see the Manual "5 Client", chapter "9. Sidebar", page 78. An additional reason to do without aural warning is the fact that also IRL there is no A/C producing an aural alert for transitions passing. High sophisticated FMC/FMGC A/C however have a visual warning on the PFC usually depicting the actual QNH setting in AMBER if not correct. We have adhered to this rule.

Hi Lukas, Have you by chance pressed the day/night button? (Leftmost, just right of the Master Menu Button) At the time being there is no disctinction of the state on the button itself. We might need to change that. EDIT: Ups , sorry. Re-reading your text I see that you are talking of the Parking Positions. This simply means that the Radius requirement for the b747-8i is bigger than the biggest parking position. Obvioulsy the parking positions in ESSA are a bit tight.... According to the wingspan the min. radius for parking is set to 35 m which is obviously bigger than the biggest parking spot in that AFCAD file of ESSA. EDIT 2: I just checked with my ESSA install from ORBX ( I guess that's the one you use..?). The largest parking radius is 33 m. No wonder that all positions are greyed out...?