abax2000

Which makes sense of course...but I am referring in having both the sim and EFB on the same machine.

I have noticed that EFB (at least the latest versions) do carry a lot of impact on FSX performance, even if the sim runs on cores 1,2,3 and EFB on core 0. What is the experience of the other users on performance impact? Or is it just my old tired machine?

True, that is I am looking for the "theory" behind it. From what I read around, simconnect "overloads" with other things too (internal fs operations), beyond addons communicating with it. The only ones I am using are FSUIPC, AS2012 and EFB (and probably FSrecorder if it is also hooked on simconnect), which normally should not overload it; except if some of these "misbehave" or there are also other parameters.

Hi Urs, I had forgotten that this is connected to simconnect timeout. Thanks for refreshing. Is there any internet source (post/document) that elaborates on what can overload simconnect (except the obvious, i.e. addons connected through it)? In the first google search could not find something. Apostolos

It happens lately that Data Provider crashes unexpectedly in mid flight (with no apparent reason or something special happening). The log only states thi kind of messages 2013-06-15 15:38:30,863 [1] WARN AivlaSoft.Efb.DataProvider [(null)] - DefWndProc (isConnected=true): Exception from HRESULT: 0xC000014B What can be wrong and where to look ?

There are times that the FSX METAR wind and temp lists have double records (two lines per altitude). What would be the reason for that? PS. The question is not related to any kind of problem with EFB, which is working fine. I am just trying to figure out anything useful for some other problem (related to weather.dll).

ok, that solved it. Thnx Timonier.

The link gets you to the download page in which there is no 1.3.5. Can you please fix the link?

Urs, a summary of what I have seen so far: 1. "Save" button with no SID yet selected, gives a IFRxxx.pln with a default (?) runway (I used LGAV as an example, so this was 03R) 2. "Save" button with SID selected, gives a IFRxxx.pln with the correct runway (21R in my example) 3. "Activate" produces a EFBxxx.pln with the correct runway this time. At the same time, EFB_current_garmin.pln gets updated, but with no departing runway. So, conclusions so far: 1. In order to get the right runway into EFBxxx.pln you have to "Save" then "Activate", and not just "Activate" (in this case no runway is defined even if SID is defined). 2. I understand that EFB_current_garmin.pln is what is fed to FSX, and that does not get the runway definition anyhow. 3. With no runway assigned in the EFB_current_garmin.pln, ATR seems to define its own "default" runway (in this example, 03L), but this now seems irrelevant. Note: (not sure if this is helpful) the SID transition point in EFBxxx.pln has a NEVR1E notation, while in EFB_current_garmin.pln not.

...and just discovered that when the "Save" button is used (instead of "Activate"), you get a differently named .pln (IFRxxx.pln), in which everything seems right: <?xml version="1.0" encoding="UTF-8"?> AceXML Document LGAV to LGSY IFR LowAlt 9000 LGAV N37° 56' 12.10",E23° 56' 40.20",+000307.00 LGSY N38° 58' 6.00",E24° 29' 17.00",+000047.00 LGAV, LGSY 03R Eleftherios Venizelos Intl Skiros AB 10 61472 Airport N37° 56' 12.10",E23° 56' 40.20",+000307.00 LGAV Intersection N37° 55' 25.50",E23° 56' 36.40",+000000.00 *RW03R User N37° 56' 52.50",E23° 57' 59.50",+000000.00 [alt] User N37° 57' 6.20",E23° 58' 21.20",+000000.00 [alt] Intersection N37° 59' 36.60",E24° 23' 21.90",+000000.00 D266E VOR N37° 59' 38.90",E24° 29' 41.70",+000000.00 KRO Intersection N38° 10' 6.00",E24° 33' 37.00",+000000.00 NEVR1J NEVRA ............................................................ Now I'll have to check if this version will do the trick.

Urs, I started checking your instructions. Findings so far: the FSX flight plan (EFBxxx.pln) created after pressing "Activate" does not have anything defined in . This is the same with SID defined or not. If SID is defined, the waypoints of the SID are properly defined. So, the .pln created looks like this: <?xml version="1.0" encoding="UTF-8"?> AceXML Document LGAV to LGSY IFR LowAlt 9000 LGAV N37° 56' 12.10",E23° 56' 40.20",+000307.00 LGSY N38° 58' 6.00",E24° 29' 17.00",+000047.00 LGAV, LGSY Eleftherios Venizelos Intl Skiros AB 10 61472 Airport N37° 56' 12.10",E23° 56' 40.20",+000307.00 LGAV User N37° 56' 52.50",E23° 57' 59.50",+000000.00 [alt] User N37° 57' 6.20",E23° 58' 21.20",+000000.00 [alt] Intersection N37° 59' 36.60",E24° 23' 21.90",+000000.00 D266E VOR N37° 59' 38.90",E24° 29' 41.70",+000000.00 KRO Intersection N38° 10' 6.00",E24° 33' 37.00",+000000.00 NEVR1J NEVRA ......................

Travis, thnx for caring, although the post was not aiming EFB official support, just the experience of fellow users. And this just for the reason of EFB forums being so alive and full of knowledgeable people (more than can be said for ATR forums and support). The FSX version of ATR is known to be haunted by some unresolved issues, so most probably this is part of the list. It is certainly not any kind of EFB problem. As to your questions (and to the best of my knowledge): 1. The flight plan is the FSX flight plan created by EFB (EFB_xxxx.pln) residing in My Documents\Flight Simulator X Files. 2. Runway as defined in flight plan (I guess indirectly) through selected SID. 3. The flight plan contains an SID for rwyX, but in ATR FMS (after loading the flight plan) you get departing runwayY. Cheers Apostolos

While trying to load a flight plan created in EFB to ATR72, it usually gets assigned the wrong departing rwy. If any other fellow EFB user flies the F1ATR, please advise on how (if possible) can correctly load flight plan.

When trying to "Select Approach" for HTKJ, the following message poped up in a window. "OK" was not working, as no other button, even "x" (top right close) until DisplayUnit crashed. "Could not draw the profile view for procedure HTKJ ILS rwy 09 (KV) because of: Element Count<2" regards, Apostolos

Thanx Travis for clarifying, I hadn't notice the null size. So, it will be a request to GEX.