Sean Green,

 

Thanks for sharing your professional pilot's view here.

 

I would also be interested (if you later test) in the types of approaches (LNAV, LPV etc.) that show up for various airports that are currently using the Navdata / departure / approach procedures.for selection/activation in the Garmins.

 

Which type of procedures are actually working as in the real Garmins?

 

Are the SIDs/STARs  current .. correct departure / approach plates for todays Airac cycle.

Sean Green,

 

Thanks for sharing your professional pilot's view here.

 

I would also be interested (if you later test) in the types of approaches (LNAV, LPV etc.) that show up for various airports that are currently using the Navdata / departure / approach procedures.for selection/activation in the Garmins.

 

Which type of procedures are actually working as in the real Garmins?

 

Are the SIDs/STARs  current .. correct departure / approach plates for todays Airac cycle.

Vaughan I am not a professional pilot by any means just a PPL rated for VFR only, but thanks for thinking so .

 

I have not purchased the NAVDATA yet as I am not sure I will really be using this GNS in FSX after some further testing.  If TWHarrel could maybe respond and let me know if updated NAVDATA might improve some things I'm seeing.

 

I went to KSAN to try a PEBBLE4 DEP SXC transistion to test out the PROC which I do with the RXP 530.  The MS unit did not recognize KSAN and instead put XXXXX in the FPL page.  I tried changing the departure airport but was unable to.   I thought maybe it was just the addon airport I'm using so I loaded up another default plane with default GPS and it recongnized KSAN.  Not sure if this is a navdata thing or not.

 

So I then went to KDFW to try a Departure procedure from there but the Mindstar had the Departure Procedures grayed out so I could not pick one to fly.  The default GPS also does this.  This could be a case of FSX just not having any procedures in its nav database which means for specific dep and arrival procedures you do need to purchase navdata.  

 

 

I'm also getting a fatal error on exiting FSX due to : MPI_GNS.GAU_unloaded.  NTDLL fatal errors and API errors.  I don't get these issues if I don't load the MPI GNS into FSX.  I'm not saying its a Mindstar issue but this is really a first for me to have FSX crash on exiting; still trying to figure it out.

 

Not really ready to put another $40 into this until I hear from beta testers on some of the things I'm seeing.  I need to know if its user error.

Sean,

 

Thanks for the follow up.

I guess Mindstar does not have an open forum for tech support .. do you happen to know? I asked previous but no reply.

 

Windows Event Viewer (module that caused the problem).
Look in your Windows Event Viewer, Windows Logs, Application.

It will tell you which "Module" caused the crash.

The log keeps many days of activity so just scroll down the listing until you see a RED (!) Error.

Click on that error line and post the results here for us to look at.

I answered my own question and deleted the prose but alas I must enter, something. So perhaps I'll mention that the whole purpose of following this thread and my interest in these gauges is that I would like to create a Garmin enhanced 172 or 182 cockpit in the most realistic way possible, in P3D. It does not necessarily have to be the most up to date Nav system available, so long as the data is up to date. I find the Simlink96 program from Flight1, combined with a real WAAS enabled Garmin 496, to be an interesting, although expensive, solution. The handheld unit could then be used in real flight training.

Would it be possible to follow a WAAS vertical guidance display manually? I don't really care if the autopilot can do it or not.

 

What he appears to be saying is that they can't drive the glideslope needle, so I'm guessing that the answer would be a no.  I'm still confused about why that is, since the equivalent RXP units are capable of doing this.

What he appears to be saying is that they can't drive the glideslope needle, so I'm guessing that the answer would be a no. I'm still confused about why that is, since the equivalent RXP units are capable of doing this.

After I thought for a second, my question was a bit silly. If one were flying IFR manually, it wouldn't be prudent to be looking right to follow a glideslope as primary guidance.

IE 11 does not like the post interface. Anyway, KingGidorah, the question I posed was not well thought out. If one were flying IFR manually, they would be looking at the instuments in front of them, not to the side at a GPS, as a primary source of navigation.

To my understanding, RXP developers found a way to basically interface Garmin code with their gauge. They did not write the whole program. MS has taken a different approach in that they have coded from the ground up, the whole program. As such, there are limitations.

 

 

If one were flying IFR manually, they would be looking at the instuments in front of them, not to the side at a GPS, as a primary source of navigation.

 

Well... sort of.  Yes, of course you're going to be looking at "the needles", not the GPS when flying an approach, but if you're flying a WAAS approach, the GPS is the primary source of that information, just as a traditional nav radio is when flying an ILS or VOR approach.  The issue here is that while the MS units can provide horizontal guidance, they apparently can't provide GS, so there'll be no vertical guidance for an LPV approach.  This means the MS units do not currently support precision WAAS approaches.  Part of what makes a GPS WAAS certified IRL is the ability to drive an external HSI/CDI display.

 

Given the rapid deployment and expansion of WAAS here in North American, this unfortunately makes it of somewhat lesser value as an IFR training/practice tool in my part of world.  Just as others have noted, I certainly don't understand the underlying issues here, but I hope they can ultimately be addressed.

 

Scott

Well... sort of.  Yes, of course you're going to be looking at "the needles", not the GPS when flying an approach, but if you're flying a WAAS approach, the GPS is the primary source of that information, just as a traditional nav radio is when flying an ILS or VOR approach.  The issue here is that while the MS units can provide horizontal guidance, they apparently can't provide GS, so there'll be no vertical guidance for an LPV approach.  This means the MS units do not currently support precision WAAS approaches.  Part of what makes a GPS WAAS certified IRL is the ability to drive an external HSI/CDI display.

 

Given the rapid deployment and expansion of WAAS here in North American, this unfortunately makes it of somewhat lesser value as an IFR training/practice tool in my part of world.  Just as others have noted, I certainly don't understand the underlying issues here, but I hope they can ultimately be addressed.

 

Scott

Sounds like what's needed is a custom HSI/CDI gauge to go along with the GNSses?

So I then went to KDFW to try a Departure procedure from there but the Mindstar had the Departure Procedures grayed out so I could not pick one to fly.  The default GPS also does this.  This could be a case of FSX just not having any procedures in its nav database which means for specific dep and arrival procedures you do need to purchase navdata.

Sean, neither FSX nor P3D (any version) have Departure Procedures included. The STAR Procedures present are limited to "ancient" ones dating back to the time FSX was still being development.

What he appears to be saying is that they can't drive the glideslope needle, so I'm guessing that the answer would be a no.  I'm still confused about why that is, since the equivalent RXP units are capable of doing this.

The only reason why Milviz is able to drive the CDI and GSI needles in their aircraft is because the gauge logic and the model are set up to allow for this.

 

Some products are able to do so only because some developers don't feel bound to adhere to Microsoft's EULA prohibition about reverse-engineering. :blink:

If it doesn't drive a Gsi/CDi gauge let alone a autopilot coupling, its basically a moving map and not a Nav device?. I have plenty of them.

 

 

If it doesn't drive a Gsi/CDi gauge let alone a autopilot coupling, its basically a moving map and not a Nav device?. I have plenty of them.

 

Rendi, as I understand things the issue is specific to glideslope display on precision WAAS approaches.  If LPV approaches aren't important to you, or you don't fly in North America, this won't matter.  If you do, it might.

 

Scott

If it doesn't drive a Gsi/CDi gauge let alone a autopilot coupling, its basically a moving map and not a Nav device?. I have plenty of them.

It sounds like a pretty valid evaluation of this thing. The little bit of info that has been pulled out of this guy make it seem as though it has less functions than the default units. Does any of the mods or anyone else know anything about this guy or the company. I looked at their website and it seems pretty "flight by Night" to me. I am not sure I would want to chance putting their stuff on my computer at this point. Can't say I have seen a new product come at in this way before. Really kind of strange.

If it doesn't drive a Gsi/CDi gauge let alone a autopilot coupling, its basically a moving map and not a Nav device?. I have plenty of them.

It does drive the lateral deviation needle of an FSX default CDI/HSI and the lateral Nav input of the default autopilot. It won't drive the vertical deviation needle or AP vertical modes.

 

In that regard, it emulates the all of functionality of a "plain" GNS-430, which does not have vertical Nav in GPS mode. As I understand it, the Mindstar GNS WILL track the lateral portion of a WAAS LPV approach, and while not a full LPV implementation, it still (typically) would permit lower minimums than a non-LPV approach to the same runway - probably comparable to the minimums of a localizer-only approach to an ILS with an inop glideslope.

 

A custom gauge and/or autopilot would be the way to go for VNAV. I don't think Mindstar is planning to create such, but perhaps they would be willing to provide an SDK for developers who might want to explore that option.

I looked at their website and it seems pretty "flight by Night" to me.

I wouldn't go that far, they're involved in professional flight simulation as well. There's more info on their Facebook page. Fr. Bill makes a valid point as well as Ed (dev) when they mention the limitations in place by Micro$oft.

It sounds like a pretty valid evaluation of this thing. The little bit of info that has been pulled out of this guy make it seem as though it has less functions than the default units. Does any of the mods or anyone else know anything about this guy or the company. I looked at their website and it seems pretty "flight by Night" to me. I am not sure I would want to chance putting their stuff on my computer at this point. Can't say I have seen a new product come at in this way before. Really kind of strange.

 

It is not a "fly by night company" entertainment flight sim is not their main market, their main market is professional training.