Babbo

Nothing visible on the surface that gives any hint, just a dll in the background.

Yes, correctly understood. And as concerns your question, that potential SASL-problem: no idea, but is there anything I can do?

Sorry, Jean-Luc, for causing a misunderstanding: what you really couldn't know, that nice-advice-comment (you quoted above) was not directed to you ... And, of course, here is the OGL-result: absolutely stable GTNs 650 and 750! (... and incredible 30! frames less 😞)

Thanks for the reply! - Yes, it's Vulkan-only. And, I was aware of XP's known-bug-confirmation. However, I absoluetly doubt - as it is often argued - that this is an AMD-exclusive fault. How else could it be that some planes, actually a clear majority, perfectly collaborate with your GTNs and some other ones struggle - not to forget: under the same Adrenalin-driver. This is something I can't really understand. (Unfortunately, the nice and fast-selling advice, Turn off Vulkan, isn't really a nice one.)

Dear all, dear Jean-Luc, Running Win10pro, AMD's Adrenalin driver under Vulkan, X-Plane, RXP's GTNs and Torquesim Islanders, BN-2B and BN-2T, all of it up to date, I encountered heavy GTN 650 and 750 flickering, but as tested so far, only with these two specific planes. I already asked the developer and he argued with well-known OpenGL/Vulkan/bridge-issues, only solvable by AMD. So, consequently, as in Torquesim's case, I’m far away from making you responsible for anything. But, on the other hand, maybe, it cannot be excluded that RXP experts or some forum readers have an idea. Many thanks for considering!

Yes, that was me. I just opened this other thread here, because I thought import- and leg-troubles are two different pairs of shoes ... @first remark: that one is related, but I never loaded approaches after importing, just imported flight plans with and without approaches. @second remark (second paragraph): sounds good, but I'm not really expert enough to follow these words to the last detail. "Activation of the final approach to the FAF". I thought, at a FAF a final approach starts, which would correspond to another wording. e.g. activate the final approach to the runway ... And finally, FAF and approach transition (JAIME above), are these synonyms?

Bert, exactly, that's it: I activated the flight plan (directly after import) and not the approach. Jean-Luc, thanks for the link, but I couldn't find any substantial hint to solve/explain my problem.

Importing RXP’s example gfp, KSLE_KSLE.gfp, to a GTN750, I found that, after activation, the first active leg is strangely located. Expectedly, I thought it would be the first leg between departure airport and the first (of two) subsequent user waypoints. However, what really becomes activated while TERM is annunciated, is the leg to the approach transition JAIME for ILS-runway 31 at the (same) arrival airport KSLE. For clearance, here’s the flight plan: FPN/RI:F:KSLE:F:N45223W121419:F:N42568W122067:AA:KSLE:AP:I31.JAIME So overall, it seems that the two user waypoints are simply ignored! Actually, flying that plan, behaves as described, i.e. the user waypoints are skipped. Only if I activate the “expected” first leg manually, the flight’s initial direction goes to USR000 (even after some weird turns, because USR000 is extremely off the runway, oriented to the far left), and some (long) time later TERM switches to ENR. Accept excuses for a maybe simple error of myself or a false setting, but I’m a beginner. Have my thanks for your help.

Yes indeed, thanks again to fppilot for his help, I will study these links ...! For now let's close that environment/path&registry-debate; even if I didn't fully check the reasoning why things (=paths) evolved as they did, but most importantly, locating FPLN at the trainer's side (please see above), I managed the import wanted. Two other points still apply: One question hasn't been answered at all: a flightplan, designed in a GTN or imported into a GTN and altered there in some way, can it be exported, e.g. in order to load it into Little Navmap? Maybe it's a good idea to make my troublesome flightplan public. As noted, it can be imported into my GTN, but activation fails for whatever reason (TERM). Actually, this is a toy example, right, but its fms-equivalent was successfully used in a GNS430/530. Please find here that LOWG_LOWG.gfp from above - maybe someone has a sudden brainstorm! FPN/RI:F:LOWG:F:N46521E015273:F:N46507E015246:F:N46493E015245:F:N46483E015261:F:N46491E015282:F:LOWG (Note, this gfp was created by loading the fms into Little Navmap and using its export-save-as-GARMIN-function.)

I'm aware of that registry node. In my case, not to say consequently, i have BinPath = J:\Programme\Fly\Garmin\Trainers\ DataPath = J:\Programme\Fly\Garmin\Trainers\ProgramData\ DBDatapath = J:\Programme\Fly\Garmin\Trainers\ProgramData\Databases\ In the end, I don't have an idea why I also have a c:\ProgramData dir and what it is for, why nonvol is targeted there, but FPLN must be in the trainer dir, and some things more - but, not surprisingly, I will keep everything as it is. Additional thanks for the fppilot-link (even if can't follow your normal-argument).

Hello again & right from the start, thanks for your patience ... I have - partially - good news. First let me answer your questions. Let's start with the prominent c:\ProgramData\Garmin\. Originally, it contained a \GTN Trainer Data\GTN\ with an empty GTN1nonvol and my first-trial \FPLN\ . Both appeared outdated, so I deleted \GTN Trainer Data\GTN\ and these two subdirs. Now, after the update (first the trainer, then, following you, the RXP-software) that branch, c:\ProgramData\Garmin\, was extended (i.e. during the update process) to c:\ProgramData\Garmin\Trainers\Databases\ and c:\ProgramData\Garmin\Trainers\GTN\ The first received my flightplan-dir, i.e. became c:\ProgramData\Garmin\Trainers\Databases\FPLN\ (FPLN manually added), where I put 3 files: the waypoints and two flightplans, your user.wpt and KSLE_KSLE.gfp and an own LOWG_LOWG.gfp (Yepp, greetings from Austria!) re-saved from fms to gfp with (the newest) Little Navmap. The second extension now ends as c:\ProgramData\Garmin\Trainers\GTN\nonvol\, holding 4 EEPROM-files and 3 sys_nand-files. As mentioned, that FPLN-approach did not work. There are no other subdirs. Now the good news. Following endless hours of trial, (re)search & error, I moved my FPLN-dir from c:\ProgramData\Garmin\Trainers\Databases\FPLN\ to, guess what, the non-default dir of my trainer-software: j:\Programme\Fly\Garmin\Trainers\ProgramData\Databases\FPLN\ All without any env-vars. And it worked. Crazy(!) thing is, that this approach perfectly feeds X-Plane, but not the trainer standalone. Finally, relating back to my "partially" good news running X-Plane: my GTN650 imports KSLE_KSLE.gfp, also successfully activates it (statusbar says ENR), and it imports my LOWG_LOWG.gfp, but the latter activation ends with a TERM(inaton), some conflict, which I cannot resolve, even after reading manuals a/o consulting the internet. Now the two most recent logs requested: 19/10/28 17:06:18.256 12100 - ] # win.xpl version 2.5.20.2 19/10/28 17:06:18.256 12100 INFO ] 19/10/28 17:06:21.809 12100 - ] # rxpGtnSim64.dll version 2.5.20.0 19/10/28 17:06:21.808 12100 INFO ] 19/10/28 17:06:59.173 12100 INFO ] GTN 650.1 - TRAINER 6620 19/10/28 18:23:30.018 12100 INFO ] GTN 650.1 - TRAINER 6620 Sorry couldn't do it shorter. Hope, I was sufficiently concise. Basically, from my view, the following questions remain: Does this all make sense for you, should I keep my trainer-FPLN-dir? Why can I not import with the trainer standalone? How can I get my LOWG_LOWG.gfp correctly activated in X-Plane? (note: its fms-counterpart did the job in the GNS430/530 perfectly) As always, thanks for reading and thinking ...

Got it running again, no additional RXP-settings-crash, but flightplan issue remains.

c:\ProgramData\Garmin\Trainers\Databases\FPLN\ did not work. No log-file unfortunately, it's already overwritten. Meanwhile, X-Plane hangs after opening an aircraft.

You argue via the env-var GTNNAVDATA, which defines the FPLN-location, on the other side you wanted me to get rid of env-vars, aren't we running in circles? Also, as already stated: p.9: Databases (plural) and p.17: Database (singular) ...(?) "Do you mean the RXP Settings Panel?" (CTD) - yes, exactly. "Was it you doing this?" (reopening of 650 #1 device) - no.

Why? In many discussions one gets advised to define env-vars if the trainer is not installed at its default location. Anyway, I deleted all vars and got the following clean logs ... 19/10/27 17:24:26.708 07220 - ] # win.xpl version 2.5.20.2 19/10/27 17:24:26.708 07220 INFO ] 19/10/27 17:24:30.170 07220 - ] # rxpGtnSim64.dll version 2.5.20.0 19/10/27 17:24:30.170 07220 INFO ] 19/10/27 17:25:08.046 07220 INFO ] GTN 650.1 - TRAINER 6620 19/10/27 17:25:32.806 07220 INFO ] GTN 650.1 - TRAINER 6620 ... and still no import button around. New annoying X-Plane insight: scrolling down the settings menu of the GTN650 crashes the sim to desktop.

Ok, confused some env-names, but the following - deemed correct - are still wrong in some sense: GTNAPPDATA=j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data GTNNAVDATA=c:\ProgramData\Garmin\Trainers\Databases\ GTNSIMPATH=j:\Programme\Fly\Garmin\Trainers\Packages\GTN\bin\ which gives (from an X-Plane start): rxpGTN.xpl: 19/10/26 20:33:13.213 06248 - ] # win.xpl version 2.5.20.2 19/10/26 20:33:13.213 06248 INFO ] 19/10/26 20:33:17.035 06248 INFO ] using GTNSIMPATH = "j:\Programme\Fly\Garmin\Trainers\Packages\GTN\bin" 19/10/26 20:33:17.039 06248 INFO ] using GTNAPPDATA = "j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data" 19/10/26 20:33:17.043 06248 INFO ] using GTNNAVDATA = "c:\ProgramData\Garmin\Trainers\Databases" rxpGtnSim.dll.log: 19/10/26 20:33:16.643 06248 - ] # rxpGtnSim64.dll version 2.5.20.0 19/10/26 20:33:16.642 06248 INFO ] 19/10/26 20:33:48.767 06248 INFO ] using: j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data 19/10/26 20:33:48.773 06248 WARN ] not found: c:\ProgramData\Garmin\Trainers\Databases (NAV) 19/10/26 20:33:48.782 06248 INFO ] GTN 650.1 - TRAINER 6620 19/10/26 20:34:50.145 06248 INFO ] using: j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data 19/10/26 20:34:50.150 06248 WARN ] not found: c:\ProgramData\Garmin\Trainers\Databases (NAV) 19/10/26 20:34:50.158 06248 INFO ] GTN 650.1 - TRAINER 6620 There still is a NAVDATA-problem around ... : c:\ProgramData\Garmin\Trainers\Databases just contains my FPLN-dir, what is missing?

Wait, found a typo: GTNSIMPATJ ... Edit, lol: GTNSIMPATJ ... 2nd Edit: its not GTNSIMDATA, but GTNSIMPATH ...

Great, problem 2 (blank screen in X-Plane) solved. Thank you, the RXP-update worked! But still no success with the flightpln import, neither in the trainer nor in X-plane. So I defined your 3 environment variables from p.17: GTNAPPDATA=j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data GTNNAVDATA=c:\ProgramData\Garmin\Trainers\Databases\ GTNSIMPATJ=j:\Programme\Fly\Garmin\Trainers\Packages\GTN\bin\ (where all paths correspond to existing paths on my PC). That's the result: rxpGTN.xpl.log: 19/10/26 20:06:59.630 11752 - ] # win.xpl version 2.5.20.2 19/10/26 20:06:59.630 11752 INFO ] 19/10/26 20:07:03.309 11752 INFO ] using GTNAPPDATA = "j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data" 19/10/26 20:07:03.314 11752 INFO ] using GTNNAVDATA = "c:\ProgramData\Garmin\Trainers\Databases" rxpGtnSim.dll: 19/10/26 20:07:02.907 11752 - ] # rxpGtnSim64.dll version 2.5.20.0 19/10/26 20:07:02.906 11752 INFO ] 19/10/26 20:07:39.646 11752 WARN ] not found: j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data (APP) 19/10/26 20:07:39.650 11752 WARN ] not found: c:\ProgramData\Garmin\Trainers\Databases (NAV) 19/10/26 20:07:39.707 11752 INFO ] GTN 650.1 - TRAINER 6620 19/10/26 20:09:19.101 11752 WARN ] not found: j:\Programme\Fly\Garmin\Trainers\Packages\GTN\data (APP) 19/10/26 20:09:19.110 11752 WARN ] not found: c:\ProgramData\Garmin\Trainers\Databases (NAV) 19/10/26 20:09:19.164 11752 INFO ] GTN 650.1 - TRAINER 6620 Obviously, there is a conflict ...! My FPLN-dir sits in the databases-dir (2nd from above). By the way, correctness, I found it a little confusing that on p.9 the manual speaks of "...\Databases\FPLN" (as it is in my way) and on p.17 a variable "GTNNAVDATA\..\Database" (singular, not bases) is defined. Could that be the source of my importproblem?

Well then, here's another iteration. And a worse one. After another bunch of hours, I thought it would be a good idea to check whether my flightplan problems, maybe, don't exist in X-Plane itself (since up to now, I only investigated these with the trainer). Guess what: launching X-Plane with my current favourite aircraft (vFlyteAir's Piper Arrow III), I did not reach that stage of investigation at all, because the GTN650 remains blank with a black screen (both, 3D-panel and window)! The only, reasonable logical reason, since it worked in the trainer and in X-Plane, must have been the trainer update performed recently. Summarizing facts: The GTN650 worked in the trainer and in X-Plane before, simply say, the troubles started The GTN650 now works in the trainer (even though without flightplan import capability), but not in X-Plane rxpGTN.xpl.log: 19/10/26 12:02:16.057 04876 - ] # win.xpl version 2.5.3.0 19/10/26 12:02:16.057 04876 INFO ] rxpGtnSim.dll.log: 19/10/26 12:02:19.545 04876 - ] # rxpGtnSim64.dll version 2.5.3.0 19/10/26 12:02:19.544 04876 INFO ] 19/10/26 12:04:06.373 04876 WARN ] can't find trainer installer path Regardung environment variables and the last line. I didn't/don't actively set any. Also, checking my environment variables via Windows 10 system shows that there is no such entry ... Nevertheless, a command "set" (I mean "DOS"-level) reveals that some mechanism really generates a GTNSIMDATA=c:\ProgramData\Garmin\Trainers\GTN Also of interest, maybe, the fact that the trainer is not at its default place, but in j:\Programme\Fly\Garmin\Trainers\ containing three subdirs \Launcher, \Packages and \ProgramData. However, I'm convinced that this special location shouldn't be a problem now, since, as mentioned, it worked in the Trainer and in X-Plane for years, and, note, it did that without setting any environment variable by myself. That's my bad state of the weekend, thanks for reading and your suggestions!

Hello all! Yes, right at the start, I do know, this has been discussed a million times but ... sorry ... ... whatever I tried, nothing worked: the goal is to actually import RXP's example KSLE_KSLE.gfp into a GTN650, to be more precise into the GTN-Trainer environment. I checked several versions of the "Reality XP GTN User's Manual (XPlane).pdf" and many internet advices (use an FPLN-directory, use a GTNNAVDATA-, GTNAPPDATA- or GTNSIMDATA-directory - connected with a c:\ProgramData\Garmin\GTN Trainer Data-directory, which also comes as short Trainers-directory ... interfaced (or not) with a GTN-directory ... the mystical import-button never appeared! To give some information, I should note that I'm using a new updated trainer (Ver.6.62.0) and I'm working with a c:\ProgramData\Garmin\GTN Trainer Data\GTN\-directory, which now contains an FPLN-dir (with KSLE_KSLE.gfp and that user.wpt) from my last trial and, second, after the update, a GTN1nonvol1-dir which still contains my unsuccessful gfp/wpt-files from my trials before the update. My flightplan catalog contains just a KPDX-KPDX-plan (no idea, where that one is stored) and the Flight Plan Catalog Menu does not come up / never came up with said import-button. My final question, and I didn't find that one discussed in the net (or elsewhere), is: if I create a flightplan in a GTN (trainer or X-Plane directly), can that plan be stored (for later uses in the trainer or X-Plane) and, moreover, can one export that plan for some different external application (e.g. export to Little Navmap, to be edited there)? Many thanks for any help!

Thank you, will check it.

Which 'automatic' do you mean and which ini-file?

Here we go: You're right with your first paragraph: using the plugin menu for ON causes no delay, but any OFF-setting considerably does. Regarding, the battery switch (accordingly invoked), the behaviour is somewhat erratic: OFF always works immediately, ON (after OFF) causes freezes and even crashes of XP11. Your "hooks". Checked that with intensive commitment: antivirus, defenders of all kinds, services, processes (handles, mappings ...) in general. Not a single cause found. (Actually, I would have been surprised, this is my dedicated machine, everything is well maintained and literally no issues are present.) May I remind you of our early discussion, my initial Black Friday discount problem ... I would be willing to invest into a 650 - as discussed - and check that one for a maybe better coexistence with my stubborn system!?

XP11-loading completely normal, C172 with active GTN again normal. Switch to EMB110 with non-active GTN about 40 secs. Then, after enabling GTN, switching back to the same C172 (i.e. from active to active) about 5 minutes 50. Finally, quitting XP about 50 secs. All in all, more than 7 minutes idling ... Simply, too much.

Any news or suggestions?