aivlasoft

Phil, there is another easy way: 1) navigate to the installation folder of EFB (e.g. C:\Program Files\AivlaSoft\EFB) 2) below this folder you will find a folder called "plugins" 3) remove the file "AivlaSoft.FlightPlanHandlers.iFly.dll" (or if you intend to use it at a later time then save it to another directory) 4) restart DisplayUnit Hope this helps.

thanks for reporting this. I will address this with version 2.0.

Hi Glen, from my point of view it's a Navigraph related issue. If you have a look into the file "EGKK.txt" (in folder "[FSX]\AivlaSoft\SIDSTARS") you will notice that four SIDs (HARD5M, HARD5V, KENE2M and KENE2V) are described like " ... TRK 259 UNTIL 10.5 FROM FIX MID ...". In my opinion it should be " ... TO FIX ..." instead of "... FROM ...". If you change these 4 items, then reset the airport data cache (System -> Settings -> Miscellaneous -> Reset airport data cache) and reload the airport.

Hi Pete, Does it happen all the time, or was it only a "one-time" issue? I'm asking this because from the code I cannot see how it could happen.

Fixed with SP4.

Dave, thanks a lot for this detailed report. Now I could locate the bug . SP4 is underway ...

Björn, thanks for this info. Please be aware of the fact that such manual additions will be overwritten as soon as "the Eye" updates its files. The better way would be to ask someone at IVAO to add this line to their "official" data file.

Thanks Phil, much appreciated .

Grzegorz, regarding your latest post in the Navigraph forum, I'd like to ask whether you have any third-party scenery installed for either EPGD or EPWA or for both? Could it be that the runways.txt file is not configured properly?

Dave, thanks for investigating ... If such a situation occurs again, could you please additionally take a snapshot of the page http://de1.www.ivao.aero/whazzup.txt (right click on the page and then save as "whazzup.txt"). This page shows all the currently active controllers and pilots. This is the data that EFB considers.

Iain, please see this document http://www.aivlasoft.com/download/EFB%2 ... 011.05.pdf It contains all the information about the file formats that are currently supported by EFB.

Hi Björn, it's not MY datafile ... it's the official "firs.dat" file from IVAO. All the entries in that file must correspond to the "fir.dat" file which contains the data for the FIR boundaries. If wildcards like "EHAA_*_CTR" or similar patterns were allowed then it is no longer possible to show the corresponding FIR boundaries on the charts. The controllers must use correct callsigns or IVAO must update the "firs.dat" file.

Hi Glen, Currently not, I'm sorry.

Hi Neal, There are two different data streams that are considered by EFB. Stream 1: As soon as the online network is selected and activated (from the route setup), EFB is getting "online data" from the server (either IVAO data or VATSIM data). This data is updated every 2 minutes (VATSIM) or every 5 minutes (IVAO). Stream 2: As soon as FSInn / Squawkbox / IvAp are connected with their networks, they download pilot and ATC data in a much more frequent way than "stream 1" does. This data is then "injected" into FSX which shows it as "online traffic". OTPV is checking stream 1 to get a rough overview (preview) before you connect stream 2. Because of the slow data update intervals of stream 1 it might happen that other programs (with a higher refresh rate) will show you some online traffic which is not yet contained in stream 1. Hope this helps.

Don, pressing one of the four buttons on the top of the flight log sets the current time. You cannot manually select or set an individual time other than the current system time. Once a time is set (either automatically detected by the flight phase recognition, or manually pressed) it cannot be changed/overridden anymore until a new route has been created and activated. Hope this helps.

Apostolos, if you don't select a SID then EFB takes one of the identifiers of the longest runway for use in the FSX flight plan (e.g. create a route from LSZH to EDDM without a SID and press "Save". EFB creates a FSX flightplan which contains runway 16 as departure position). If you select a SID then EFB takes the corresponding runway identifier. So you can easy check what the ATR system does. Before you load it into the ATR system, please open the flight plan using notepad.exe (or any other text editor) and search for the 999 node (where 999 stands for the actual runway identifier). Normally it is line #14 in the flight plan. If the ATR system doesn't show the same runway identifier than you see in the flight plan, I guess that this must be a bug, or better "an unwanted feature" of that system. But maybe the system is much more smart than we: maybe it automatically takes the runway identifier of the currently active runway instead of the runway in the flight plan? It's just a guess

Robert, many thanks for the detailed description about the issue you encountered. I don't think that you did something wrong. The "direct-to" function is meant to work like you expected. If you open the "direct-to" dialog it is preset with the option "route only". As soon as you select any waypoint from that list, the OK-button should become enabled. It should only be disabled as long as there is no waypoint selected. After pressing the OK-button a new flightplan (only for the Garmin GPS) will be created and loaded into FSX. This makes the Garmin GPS system to fly to the "direct-to" waypoint. On the EFB chart the "direct-to" waypoint becomes the active one and a blue dashed line points towards this waypoint. So far the theory ... It is not (yet) clear to me why the OK button didn't become enabled as you describe. Maybe you can send me (support@aivlasoft.com) the exact flight plan that you used and I can try to reproduce it? What AIRAC cycle do you use?

Hi Robert, welcome aboard . The chart-relevant functions (like selecting a certain approach procedure) are available by pressing the "blue" button on the main menu. Please see also the operations manual, section 7, page 29. The moving map button is only available if FSX is running and the DataProvider is properly connected to FSX. Please see the operations manual, section 7, page 13 for more details on the chart toolbar.

The holding over SPR is part of the missed approach procedure (all approach procedures for runways 05 and 23).

Hi Tim, You may set the values for the timeouts via the settings dialog. By default they are set to "5 / 5 / 10". That means that a disconnect will be determined as soon as there is no reply from the recipient of any message within the amount of seconds. E.g. Timeout Sending = 5 seconds. If the DataProvider sends a message to the DisplayUnit and the DisplayUnit doesn't send back an acknowledge within 5 seconds, then the DataProvider must assume that the connection to the DisplayUnit is broken or the DisplayUnit is no longer running. If there is no reply within 5 seconds (which is quite a long time for network traffic) it seems that either the network is not performing very good (often see with wirless), or the DisplayUnit/DataProvider is not able the send the acknowledge because it is somehow overloaded or is not getting the required CPU time to do so. Anything that helps to increase the network performance or also increase the performance of the EFB components will be helpful to get rid of this "disconnected" message.

Björn, I often see it that controllers are logged in with an "unknown" callsign. What is an "unknown" callsign: Both (Vatsim and IVAO) have listed their FIRs/ARTCCs in a datafile which is considered by EFB. EFB can only recognize services that are listed in these files. Normally such a callsign consists of the FIR's identifier and an additional information about the kind of service that the controller is providing, e.g. LSAS_CTR means Switzerland Radar. LSAS for Switzerland, and CTR for Center/Radar. In big FIRs/ARTCCs it can happen that an area is subdivided in several sub-FIRs which mostly have an additional identifier like "S", "W" etc. Therefore a controller in the Langen Radar area can login with a callsign like "EDGG_S_CTR". As long as a callsign is used that can be recognized by EFB, EFB will show you this. But several times the callsign doesn't match the definitions and therefore it cannot be recognized, e.g. if a controller were using a callsign like "EDGG_Z_CTR", then it cannot be shown in EFB since it cannot be recognized. Hope this helps.

Hi Marc, good to know that you've sorted out the issue with the runways. If the traffic button is selected it will be displayed with a yellow border. If you don't see this yellow border then you must have changed the Windows color schema, maybe to "Windows classic" or similar?

Hi Marc, I just downloaded 1107 cycle to be "up-to-date". I assume that your post is related to this cycle? Let's check step by step: 1) EFB procedure selection: EFB shows only runways which have at least one procedure available. This can be verified in the file "AAAA.txt" in the folder "[FSX]\AivlaSoft\SIDSTARS", whereas AAAA stands for the 4-letter ICAO code. For LEMH this would be "LEMH.txt". Don't look in the "airports.dat" file because only the files in the "..\SIDSTARS" folder is considered. The current cycle 1107 offers SIDs for 01L and 19R. 2) Runways.txt file: It is important that entries in this file are only added if there is a difference between FSX runway identifiers and Navigraph runway identifiers. Most probably you won't need this if you have an add-on scenery installed that reflects the most recent real-world situation. If you run the FSX stock scenery then you need to add the following two lines: LEMH 01 01L LEMH 19 19R Which runway identifiers are used by this Aerosoft scenery?

Marc, thanks for the kind words. EFB always shows the frequencies from FSX, not the frequencies from Navigraph. So I must assume that this frequency comes from the EBBR Mega Airport scenery.

Pascal, Currently it is not possible to use the touchscreen-keyboard to add text to a webpage. Please bear in mind that RouteFinder (and VATRoute) are websites which are displayed in a browser window.