RESOLVED
Ugh. This is my bad.
Last night, as I was drifting off to sleep, I had another idea–thinking that maybe this had to do with Navigraph on my PC. After doing some research, it didn’t look to be installed correctly. so after I took care of that, the G1000 is performing flawlessly–indeed, I’m even having fewer CTDs than previously…I’m not sure why. 
Anyway, thanks for your help and time with this.
A RNAV(RNP) approach is a RNAV(RNP) approach, not a LNAV/VNAV approach. RNP is different than GPS because RNP uses aircraft specs to calculate the approach path. There are other requirements for RNP approaches.
I don’t think the Garmin displays “RNP” when flying an approach. The Garmin is probably only using the GPS to fly a RNP approach and displays LNAV+V in the HSI. The “DA(H)” is actually “RNP 0.30 DA”.
Confusing? I think for most GA aircraft, RNP can be flown as a “GPS” approach. Airliners are faster and have AutoThrottle that may not be able to fly a RNP approach correctly.
Could this maybe explain my experiences yesterday? Few minutes after takeoff oil temperature jumped to maximum and I lost half of the power. This was repeatable with C172 w/G1000, C172 without G1000, SR22; all live weather. I did not look at the outside temperature though, would that have been an indication?
Most published RNP approaches have minimums for LPV, LNAV/VNAV as well as LNAV. From what I see now is that indeed the WT NXi does not have Baro-VNAV so that if there is no LPV it reverts to LNAV+V.
I was a little bit confused since when you select an approach from the available approaches it always lists LNAV+V and not LNAV/VNAV (which would be published name if there is no LPV). My only explanation is that the NXi translates this to LNAV+V because that is the maximum it can provide (again, if there is no LPV available).
Not having Baro-VNAV capabilities also explains the LNAV+V indication in the HSI.
I would appreciate if someone from Working Title could confirm my thoughts or correct me.
Almost certainly, yes. I had a 1.5 hour flight through a part of Utah last night, and did not see this effect myself. I think I was at around 6000ft at the time.
I’m having a flight plan issue that I believe is related to the G1000 NXi, however before I communicate this here, could someone who knows please verify this for me:
If the NXi is installed, does its presence take charge of the World Map’s flight planner, too, for G1000 equipped aircraft?
In other words, if I’ve got the Diamond DA62 selected and setup an IFR route on the World Map, is the WT G1000 NXi taking responsibility for establishing/building the flight plan?
Thanks.
I think no. The planner plans, the GPS implements.
Ok, then I’m thinking this is the correct place for the issue.
First, I’m pretty new to IFR – specifically GPS-based. I’ve mostly focused on VFR within the sim, however I’ve tried to educate myself. Be forgiving of errors in terminology please.
I selected the DA62 and setup a flight plan departing KSBP parking 13, arriving KSLC auto-selected runway arrival in the World Map. I changed it from VFR-direct to IFR low altitude, keeping the default flight plan as constructed by the World Map.
It showed departing KSBP via an AVILA FOUR departure with Morro Bay Transition (AVILA4.MQO). All looks as it should on the World Map – take off, turn towards AVILA, turn towards MQO and you’re on your way.
Ok.
When I load into the cockpit, however, I can see it has added a Gaviota Transition (AVILA4.GVO), which would have me take off, turn towards AVILA, turn the opposite direction of MQO towards ORCUT then GVO, make a 180º turn back towards ORCUT then AVILA then MQO and I’m on my way. This is a ~100NM roundtrip superfluous transition.
Departure reference: https://flightaware.com/resources/airport/SBP/DP/AVILA+FOUR/pdf
I was able to erase both the ORCUT & GVO waypoints in the flight plan from the NXi, which is great as a workaround, but the question remains: Who’s responsible for adding the superfluous transition – WT or Asobo?
I just want to route the error to the appropriate place.
BTW, I’ve been able to easily reproduce this.
As an aside, I had an absolute panic attack for the testing process of this whole mechanism. How could one ever hope to test every iteration of flight plan to look for these sorts of mishaps?
The additions of superfluous WP’s is, whether it’s Asobo or WT is irrelevant, at least to me as it shouldn’t be there in the first place. The offending WP’s (way points) have to be deleted. At one stage, the Nav map didn’t accept these deletions all of the time. However, after SU8, this appears to be fixed. Great work by the WT team.
I understand this from a logical perspective, however the issue is either being generated via the NXi (WT) or via the data being handed (Asobo) to the Nxi.
If we want to see these sorts of things addressed, then its relevant in terms of routing the issue to the appropriate “desk” for addressing.
The world map plan is being sent to the NXi with transition index of 0, which is the GVO transition. There are 3 transitions defined in the data:
Therefore we add the waypoints for the GVO transition. I believe what is actually happening here is that the world map planner is actually choosing no transition at all (and you’re just incidentally getting MQO since it’s in the right path), but does not send us an indicator of -1 to say no departure transition is selected, instead defaulting to 0, which is a valid transition index in the data.
Welcome to one small peek into one tiny slice of what is a ludicrously (and necessarily) enormous testing surface of MSFS. One avionics system alone has more code than a lot of entire indie games. It’s very difficult!
-Matt | Working Title
This is what I feared as it isn’t your issue and, most likely, won’t be addressed by the party responsible.
Thanks, Matt, you’re truly a gem here. I’ve nearly read all 1811 posts on this thread and have been beyond impressed by you and others at WT who have been communicative and patient with all of us.
Thanks for your hard work and support to make this sim what it can be.
Hasn’t MS put you all in charge of fixing the planner next year? It could be a case of be careful what you ask for 
Best of luck!
We’re in constant contact with the other arms of the MSFS team, and so we are often discussing many such topics. I of course can’t make any promises about any one particular bug fix, but I can say that communication is excellent. 
Several months ago I created and flew IFR from KLAX to KPHX (KLAX/25L DOTSS2 CNERY DCT BLH HYDRR1 KPHX/R07RY). The departure SID DOTSS2 was flown correctly until the CNERY transition exit gate. The GPS then flew the aircraft back to the start of the other departure transition at DOTSS then proceeded to fly the other transition CLEEE. The same thing happened with the STAR except in reverse. The GPS would fly one transition, then turn around to fly another until all the transitions had been flown.
I am going to fly this plan again to see if this particular “flyback” problem has been fixed.
Edit: Update: I tried the same flight and the same errors occurred. What is baffling is where in the flight plan pipeline the flight plan is breaking. Generally there are three “outputs” of the flight plan in the cockpit: 1) GPS/FMS, 2j Navlog, 3) VFR Map. There is one input which is the flight plan file. All should be l most the same. The Navlog and VFR Map show the flight plan correctly. The G1000 NXi doesn’t. The NXi creates a flight plan route that fly each transition for the SID and STAR.
Looking at the flight plan itself, the SID and STAR are in the flight plan but without any transitions specified. The flight plan contains each waypoint for the SID and STAR. This creates a jumbled mess because the FMS adds all the waypoints for the wrong transition AND keeps all the waypoints for the correct transition. The mess is complicated when the SID/STAR transition is corrected manually in the FMS, the FMS adds the correct waypoints for the correct transition but does NOT delete the “original” correct waypoints. This has the aircraft flying each SID and STAR twice.
An earlier post described how MSFS passes an index to the FMS indicating the transition. (IMHO a very bad design even if it works correctly). If MSFS is sending a “zero” instead of a 1 or a 2, then this is a huge bug that breaks the NXi (and the WT CJ4). The flight plan only works correctly when the transition waypoint is in the zero slot.
Instead of messing around with an index for each SID/STAR, the flight plan should include the transitions for the SID/STAR.
This is precisely what is happening. I just set up the flight plan again. This time I looked more carefully at the Procedures pre-loaded into the NXi. Sure enough, it’s got the GVO transition set. As you also stated, it looks like its just using AVILA and MQO as enroute waypoints.
Changing the Departure to the correct MQO transition still requires the deletion of the enroute waypoint AVILA (which takes enroute MQO away along with it), otherwise it’s got me flying back and forth one “lap” between AVILA and MQO prior to engaging the Airway to KSLC.
Fascinating stuff from a programming perspective.
Thanks again, Matt, for helping me sort this.
AHRS failure, now what?
I had a notification this evening that the G1000 NXi had an update in the content manager. I did the update and loaded into the Cessna 208 Grand Caravan where I was greeted by an AHRS failure indication that looked just like it looks in a real G1000 (IE red "X"s across the attitude indicator with an attitude failed message and that the wings must be level during the TAWS check).
MSFS 2020 is my first exposure to the G1000, so I figured this was a new failure mode added by the development team. I found a POH on the web and read through it looking for suggestions. It sounded to me like when you have an AHRS failure, all you can do is get the plane on the ground and let maintenance deal with it. So how do I clear this in the simulator? I loaded another G1000 airplane and it did not have the error. I loaded back into the Caravan and still had the AHRS failure. It does not seem like a bug because it looks just like the failure indication in a real G1000 based airplane. Where do I go from here…?
Just found out this is a brand new bug introduced by this evening’s G1000 NXi update. It affects the Caravan, the Asobo Pilatus and one of the Diamond aircraft, but I don’t remember which one.
Critical Notice: Presently the Caravan, DA-62, and PC-6 are unable to start: the PFD will show a number of failed red Xs and be in a persistent AHRS align state. We expect to be able to push a hotfix for this issue in short order.
