Otto Pylott

Problem solved; thanks for your rapid response. I'll know better next time to defer the Garmin update until the installer gets updated (though probably not because I will likely forget by then!!!)

I'm having the same problem -- I installed the recent Garmin trainer update and now my GTN 750 no longer works (black screen). My rxpGtnSim.dll.log reports: 21/02/09 00:15:06.754 00416 ERROR] trainer not found or not supported

Got it. I knew how to access the settings menu through the XP plugins tab, but didn't know about the "shift + right click" trick. More importantly, I did not recognize the entry in the settings menu for selecting the nav database -- not so obvious to a novice, or even why this would be a configurable item to begin with; i.e., why not just have this value fixed to include all worldwide nav data? I assume there is a reason, but this again is not obvious to me. I now see that this configuration is discussed on p.11 (my version) of the RXP manual. Yet the in-game settings menu for this selection is not clearly labeled as such -- it's just an unlabeled pull-down menu that one could pretty easily overlook (as I did) if one does not antecedently know what one is looking for. In any case, now I know, and thanks again for your assistance!

Thanks again Bert -- see my latest reply just above.

Got it sorted. There is a config file in the my AFL KA350 root folder named "RealityXP.GTN.ini" with an entry labeled "NavDbType = n" where n = 1 or 0, and where (evidently) 0 selects AmrN-DB2 and 1 selects WW-DB2. It further appears that, for some mysterious reason, the single GTN mod that I downloaded for the KA350 had this value set to 0. I changed it to 1 and now have the global/worldwide database enabled. Yet near as I can tell, none of this is (clearly) documented anywhere in the RXP documentation -- I figured it out simply by comparing the files, line by line. I wish I had the last six hours of my life back.

I notice that when running in single GTN mode, it has listed as the active database AmrN-DB2 (I assume meaning "American/US"), but when in dual mode it lists WW-DB2 (worldwide). This difference would explain the discrepancy I am seeing. But in either case, there appears to be no way to change this configuration in-game. More generally, it looks like the only way to get the WW database is to run in dual GTN mode, yet which strikes me as a very strange restriction/anomaly. I am hoping that maybe an RXP rep/expert will eventually chime in here to help sort this out, but I'm not holding my breath...

Thanks Bert. I am aware of this work-around. But I'm not talking about a few waypoints here or there but that all of Europe seems to be missing -- the GTN does not even recognize major airport ICAO codes (I have not yet tried other regions outside of the U.S. besides Europe). I did read an older forum post by RXP (circa 2018) which states something about having to configure the system to use "WW" (worldwide) nav data, but I have no idea what this entails, or whether it is still relevant in the latest release (which is what I have). I have also read reports that RXP provides nav data only for the U.S. But near as I can tell, the RXP website says nothing about such a restriction. EDIT: Some progress: I re-installed the B350 and the dual GTN version recognizes major European airports and waypoints (or at least the small sample I tried so far). I had been running this plane with a single GTN and wonder if this might have caused the problem. But I will continue troubleshooting to see if I can't sort it out -- perhaps I have the in-game GTN configured improperly for a single unit implementation.

I am new to the RXP GTN 750 and am encountering problems with "locked" (missing) waypoints for European flight plans (U.S. plans all seem to work fine). I have searched the forums but find only vague references to a "worldwide" database which seemingly was not installed with my Garmin Trainer package. My nav database folder contains the following files -- does this look correct/complete? Thanks in advance for any help. apt_dir.gca bmap.bin nav_db2.bin nav_db2_grm.bin nav_heli_db2.bin nav_heli_db2_grm.bin safetaxi.bin terrain.odb2 terrain.tdb terrain_heli.odb2

Thanks Dave. Log file is on its way...

Hi Dave, I have a somewhat related question. I just completed an IFR flight to KMSP (Minneapolis). My initial flight plan called for an RNAV approach to RWY 04 on arrival to KMSP. However enroute wind and visibility conditions changed such that an ILS approach to RWY 12R was the better choice. After being handed off from Center to KMSP Approach, I issued a request for radar vectors to the ILS approach for RWY 12R. I received no response from P2A, and it continued to direct me on the RNAV approach to RWY 04. I issued the same request several times with no luck. This may be a consequence of my ATC config. I think maybe most relevantly, under Flt Plan/ATC Options I have the following checked: Force Pilot Runway Selection Match SIM Runway if Known (this works great for matching what XP has marked as the active departure runway) I am still on XP10, and near as I can tell there is really no way to confirm in the sim which runway(s) XP has designated as active (other than listening to an ATIS report). So perhaps in the case described above XP was insisting on RWY 04 and P2A would not allow a pilot override under these circumstances. Or??? (notice that I am not talking about configuring preferred runways). Perhaps you could just outline the best procedure for forcing a pilot-requested change to an alternate destination runway. It would even be kinda' nice to have the ability to issue such request prior to the approach transition phase; while perhaps not common practice, this would reduce tension/work load during the approach. Better yet, I think it would be helpful to have something like a "Force Active Runway" box somewhere on the main panel that allows the user/pilot to simply type in a valid runway number, hit "Apply," and P2A would thereafter just treat this runway as the active destination runway (unless of course a different value is subsequently entered). Ideally, one could do the same for the departure runway (i.e., without having to wait to change runways until issuing a taxi request -- this, in my view, is a bit awkward). Again general speaking, I find entering values in the middle panel of the "Say It" dialogue to be a bit clunky. As I understand, one must first click on a request (one that requires entering a value), enter a relevant value, then hit "Enter," and then press "Say It" (notice that I do not use PTT). I also notice that when a request which requires entering a value -- say for a runway -- the value box is auto-populated with the current active runway. So this requires first deleting that value, or highlighting and then over-typing the desired value. It would be helpful, in my view, to just leave the values box for such requests empty (unpopulated) -- that's why I am issuing the request -- to specify a different value. Anyway, just a friendly suggestion... Hope that was all clear enough, and thanks in advance for your help, Otto

Thanks for the clarification Dave. I was evidently mistaken about this. I had quickly run some tests over the past couple of days and it initially appeared to me that P2A was not reporting correct NOAA data -- even with the Wx source set to NOAA (as opposed to sim). But perhaps I was doing something wrong on my end, and that my comments above were a bit hasty. I'll keep testing and report back if I learn anything new. Quick follow-on question: What prompted your change to HTTPS, and how long ago did this occur? In other words, how did you know, in advance, that this change would eventually become mandatory? My reason for asking is this: I wonder how/why LR did not also anticipate this eventuality and correct for it advance (because again this issue seems to be causing quite a stir in the XP community).

Near as I can tell, the XP world is currently undergoing a "weather catastrophe" because the official government NOAA server -- the data source for a number of XP weather plugins, XP itself, and I assume also P2A's NOAA weather option -- has recently dropped support for non-HTTPS access to its METAR and wind reports, thus leaving everyone who uses the old system in the dark. see: https://developer.x-plane.com/2019/02/x-plane-11-32-real-weather-fix-gpu-memory-fix-maybe/ This issue will reportedly be fixed for XP11's real-world weather download in a near-future release. But my concern is where this leaves folks like me who are still running XP10? (and in my case just dropped $60 on Pilot2ATC, which was a substantial investment for my meager pocketbook, and for a variety of reasons cannot afford at the moment to upgrade to XP11. It seems that I may also be screwed on X-Aviation's Real Weather Connector).

I am cleared to FL200, have reached FL200 as indicated on my altimeter, I am above the transition level of FL180 (inside the U.S.) and have therefore switched to standard barometric pressure (29.92), yet P2A repeatedly commands an expedited climb to FL200??? (i.e., the altitude I have already reached). My "Allowed Altitude Variance" is set at the default of 150 ft. I notice that if I climb to ~20,400 ft., P2A stops complaining that I am below my cleared altitude. Question: Why the discrepancy between my indicated altitude and the altitude at which P2A detects the plane to be? Thanks in advance for any assistance. Related question: Is there a way, in P2A, to view/request the aircraft's current detected altitude (i.e., the altitude at which P2A thinks the aircraft to be)? Details: Pilot2ATC v2.5.07, Windows 10, XP10, Aircraft: Carenado Pilatus PC-12