Jump to content

alpha117

Members
  • Posts

    171
  • Joined

  • Last visited

Posts posted by alpha117

  1. Hi Bob, 

     

    I've never used it before, always used PFPX. Just be across to Sim Brief, yep there is no a CFMU validate button.

     

    So, everything is good for the FP imports from all the software that is available to use.

  2. Oskar,

     

    I've just used vroute and got your flight  into EFB in less than 20 seconds. 

     

    vroute1_zpsuuab8cjt.png

     

    vroute2_zpsq5zaizfi.png

     

    vroute3_zpsks8lhww7.png

     

     

    You can already use SimBrief, Vroute, PFPX,  and many others already.  

     

    My advice, don't use routefinder, as you have found out it is slow. There are other reasons, by not for here.

    Download Vroute, if you do not have PFPX, in fact download Vroute anyway, its simple and quick to use, as you have just seen here

     

  3. Just want to add about 'Vroute', I've never used this until I saw it mentioned here by ATC guy. So I downloaded it to give it a try.  VERY, good indeed. Take the routes into PFPX and they validate straight away, some need a small tweak to get thought EuroControl, but spot on and quicker.

     

    Yes, it does cover Europe, USA and other parts of the worlds. 

     

    SimBrief issue for me is their routes will not validate without a lot of work

     

    Highly recommended

     

     

  4. EFB can already IMPORT FPs, with the same expectations as a realWorld EFB, not sure how many times it has to be said that EFBs DO NOT export FPs and its not a flight planning tool.

     

    Urs, has provided so many different functions that cover all possibilities to IMPORT a flight plan. That's it job done.  It needs a few tweaks, but I'm sure that will be done in good time.

     

    Why would you want an EFB to EXPORT a Flight plan to any FMC, makes no sense at all. Use the correct tool for the correct job, simple as that. Does not matter what was in V1, EFB has moved on, get used to it.

  5. just want to add to 'Oskar's' post, EFB's are what they say on the tin an Electronic Flight Bag', and that is it will give you data for you flight, they are NOT a flightplanning tool at all, so why should EFB export flight plans?  

     

    Now what EFB does currently is accept 'basic' flight plans from 3rd parties like ProATC/X which is a step forward and also provides 98% of the data that is required for a flight.

     

    I'm currently in conversion with Urs, about EFB  auto up-linking flightplans that have 'Pseudo waypoints' in them, so the future could be good on that point.

     

    Airline parking, again already been mentioned in other threads will get implemented going forward. 

     

    TOD, TOC flight distance, already implemented. Tailwinds, headwinds already implemented, performance calculations again already implemented. 

     

    The biggest issue, and again it has already been mentioned is the incorrectly displayed airport runways in certain situations, again this is something that could be fixed going forward.

     

    So, not sure what is 'really'  missing from EFB v2.0. it's about what an EFB should do and not what you think it should do.

     

    A few issues identified within the first week and they have been fixed by Urs VERY quickly, spot on, couldn't ask for more to be honest.

     

    What aircraft does ProATC/X not support on FP export???

     

    Stefan, has already found out that the ATC clearance 'basic' flight plan from ProATC/X will get auto 'uplinked to EFB, so all good so far

     

  6. Ray,

     

    It not German and It is in your interest to have a basic knowledge of how P3D works which includes BGL files.

     

    CL =Closed for landeing

    CT = Closed for takeoff

     

     

    Difficult to answer that question. You might be better asking on the FlyTampa forum as this is not a specific problem with EFB.

     

    Why is this not a 'specific problem with EFB?

  7. Guys, I think this thread has run its course and Urs along with Ray agree this is how it should be in EFB. So now that everyone is aware that there will be airports that will not be correctly displayed in EFB, this does not now come as a surprise. 

     

    Everyone now moves on, and does not dwell on this small issue.

     

     

  8. lfbd9_zpsjblvrwzg.png

     

    Does this BGL hold airport data, pull it into ADE and have a look....it's blank which is correct. 

     

    the BGL that contains the airport data is the one that comes with the scenery, hence if you make changes to that one then EFB collates that data, again which is correct.

     

    Again, all I had to do was to 'open' the runway in the scenery AFCAD make the changes and EFB finds it and displays it correctly on  new DB build.

     

    So, this issue is not where EFB is getting the data (its all correct BTW) it how it is dealing with it when it finds it.

     

    This can be fixed, quiet easily by Urs in a future update, if he so wishes 

     

    So, explain why the runways are  now displayed correctly and I did not have to change the BGL in the screenshot(LFBD.BGL)?

     

    Look at how Little Nav Map displays ALL the BGLs that contain the airport, and how it put them in scenery order. fantastic for debugging and fixing user issues.

    FSCaptian does the same kind of thing, but just diplays the BGL that is used for airport data.  

     

    So there are ways of making it helpful not just for the user but for support staff as well.

     

    It looks like EFB currently show the 'top' BGL that has that airport, again not an issue, as what you see in this screenshot, might change going forwrd in what data this BGL will hold and 'override' the scenery BGL, hence it is at the top of the scenery list already as it holds relevant data that overrides the other BGL data.

     

     

    As I've said already this is a potential issue but only for 'high end' users, 30 years ago they were very few, but today they are getting more and more and their expectations get greater and greater, they want all the 'real world' stuff, but this comes at a cost and increase in development time.

     

    All I have done is looked at a users issue, can I replicate that issue, yes I can. Then find out why, and also how to fix it and come up with a  potential solution that could work, if Urs so wishes, there may be a better,easier solution,or none at all that is down to Urs.  

     

     

  9. correct, that's not the issue though look at the R5 data this is what EFB sees from the BGL when it builds the DB and I have just proved that in this little test 

     

    Look at my little map screenshot, what is the top most BGL file that has airport data?

     

    What BGL do you think I have just had to change to get the runway to appear, with a NEW DB build?

     

    I didn't have to rerun makerunways to achieve this, as EFB does not use that data, so it was very quick to prove the issue

  10. Yep, that is the issue

     

    lfbd8_zpstbz9ca00.png

     

     

     

    So, this has a massive potential issue to be honest, but only at AFCAD level. If you are updating the AFCAD to reflect real world operations and also making sure that AI  use the correct runway, then EFB display of the airport will be incorrect, as seen in this example.

     

    Off the top of my head the same issue will be at LIRF and probably quiet a few other airports around the world.

     

    Urs, maybe if EFB see 'CT AND CL' during the DB build it could change the runway box to RED and still display it??

     

    Next question :  what if runway is only closed for landing (CL)..will it display then, also what about preferential runways that are set?

     

    Maybe

     

    Green: Preferred runway 

    Orange: normal operations

    RED: Closed

     

  11. Question: is it because I have 11/29 closed??

     

    Here is my R5.CSV entry

     

    LFBD,0050,44.819118,-0.728989,166,46.420,10165,0,148,-1.000,44.828903,-0.714988,0,,
    LFBD,0110,44.831547,-0.729249,166,107.450,7915,0,148,-1.000,44.828472,-0.714570,0,CT,CL
    LFBD,0230,44.838688,-0.700987,166,226.420,10165,110.30BDG,148,-1.000,44.828903,-0.714988,0,,
    LFBD,0290,44.825397,-0.699890,166,287.450,7915,111.15BDG,148,-1.000,44.828472,-0.714570,0,CT,CL

     

    ProATC/X  shows this also ?

     

    If that is the case, then Closed runways should still be displayed but referenced as closed.

  12. Hmm, I have the same issue, even after a DB rebuild with this morning update.

     

    EFB shows this:

     

    lfbd4_zps2a4myszm.png

     

    DB shows this

     

    lfbd5_zpsjozoizcc.png

     

     

    Airport AFCAD show the correct runways

     

    lfbd2_zpsz8bexrrp.png

     

     

    Little NavMap show the correct runways and also shows the BGL files that have reference to LFBD(and show the correct layer order)

    LFBD1_zpsmtbrepn2.png

     

    ProATC/X also show correct runways

     

    lfbd3_zpsj1ek28i1.png

     

     

    So, lost on this one to be honest

  13. Morning Frank

     

    All you have to do in ProATC/X is 'add' the path to the EFB 'uplink' folder in ProATC/X (options > Folder-Paths>Add)

     

    When you click 'fly now' in ProATC/X make sure you 'untick' add SID /STAR to flight plan. 

     

    Once you have received clearance EFB will  then automatically receive the flight plan from ProATC/X

     

    I've already tested this and it works just fine.

     

    Job Done.

     

    Frank, please see your ProATC/X BETA team newsletter?

     

    If anyone could translate this to German for Frank that would be good

     

    Thanks

     

×
×
  • Create New...