dfournie

Thanks for the help Pete. That was a rather roundabout trip. :) I really appreciate your patience in creating the test builds. 2.606 works great. I hope this feature can be included in the new FSUIPC/GPSOut you have for the upcoming FSX.

He said the spec called for 9600 baud, which is what I have set in gpsout.ini. He also said that the format we call AV400 is actually called Bendix/King ARNAV R-30. It's not a new format and is also used by Garmin for some fuel flow controllers that interface into their 430/530 series panel mount GPS units. The 196/296/396 appears to have much more capability of receiving information other than just GPS positional data. The R-30 format also sends fuel flow, waypoints, atmosphereic data, remote radio tuning, etc.

I finally gave in and called Garmin aviation products field support. According to their engineer the AV400 format can send out either TRUE track or MAG track based on the installation in the particular aircraft. (My 172 is set for TRUE output). For our application (FS2004) he stated that it would need MAG track (Field C) and user MagVar (Field Q) both output in the sentence. This is contrary to what I had found earlier, but the manufacturer assures that this is the only way the AV400 sentences would provide the information necessary for a GPS III Pilot/196/296/396 unit to work correctly as a moving map for FS2002/4. I'm sorry for the confusion Pete. In the end it appears that 2.601 with the Latitude/Longitude rounding error fixed is exactly as it needs to be to operate correctly (for our purposes) with the Aviation In format. One thing he did note, was that the output rate of the sentences going to the 196/296/396 needs to be considerably faster than once per second as the AV400 spec calls out. He recommended 3 - 5 times per second. I've set the rate at 100msec output in GPSOut and it does not appear to cause any problems to either FS2004 or the Garmin. The engineer was rather impressed by the whole thing, as he could not believe that someone was able to integrate this Garmin output format in such a clever was as you have done in FS2002/4.

This whole magvar issue has been driving me crazy so I flew a Cessna 172 and ran a Garmin PC diagnostic software tool in flight on the Panel Mount Garmin GNS 430 while connected to a GPS 396. It seems that in order for the AV400 output from GPSOut to correctly mimic the same output from the real Garmin GNS unit, that Field Q needs to be removed (which it is in the beta 2.604) and Field C (track in whole degrees) must be output in TRUE degrees. It is currently output in MAG. That allows the Garmin 396 to perform the correct calculation to acheive the desired magnetic track in degrees. I did find a limitation in the Garmin 396 however; if it is receiving its magvar from an external source it switches into a user mag var mode. If the incoming value is considerably larger/smaller that the value the 396 is expecting to see from its internal auto mag var database, the 396 begins to act very unusual. Pete, can you change 2.604 to output Field C in TRUE instead of MAG? I would forever be in your debt.

Very interesting. It seems Adam Szofran is now employed by Microsoft ACE Game Studios. Pete, given any thought to relocating to Redmond, Washington? :0 Before the confirmation that FSUIPC will still be available for FSX I was leaning toward the notion that Microsoft could just as well absorb the concept and make FSUIPC/GPSOut/etc. directly a part of FSX. I am glad that does not appear to be the case.

Here's more of what I have found: There is a fair amount of difference between the current world Magvar and the one in MSFS. Having the magvar field in GPSOut is indeed a useful feature. With a flight plan loaded in my Garmin GPS, 2.603 and 2.604 seem to work quite well. Without a flight plan loaded in my Garmin, for some unknown reason it is not able to process the ground track field from GPSout 2.603 and 2.604. The airplane tracks across the map in the correct direction, but the nose always appears to be pointed north. Strangely enough using 2.601, the Garmin is OK with and without a flight plan loaded (except for the original rounding issue)

Trying 2.604, will post results as soon as I can.

I just had a chance to experiment with 2.603 and did indeed note that changing the posto6decimal causes bad things to happen when set to NO. When set to YES, everything appears to operate as it should. I will try 2.604 to verify. I appreciate your help, Pete.

Latitude and Longitude degrees look OK. Minutes and Hundreths of minutes for both are off. They look to be too rounded now. (ie not enough position resolution) Hundreths of minutes does not appear to be actually giving minutes/100, but just going back and forth from 00 to 01 in portmn. The position output from the original 2.601 was perfect except for the overflow in the lat/long field. The MagVar is now correctly deduced automatically from within the GPS unit.

It also appears that field T needs to have 9 dashes, it looks to have 10. Field Q is also not necessary, and actually confuses the Aviation units because they calculate the MagVar automatically. I'm not picking on your great work Pete, but apparently the Garmin spec (and those units that support it) are -very, very- picky. The aircraft equipment I'm using doesn't appear to have much of an ability to handle any characters out of the order it's expecting them to be in.

On second look, it appears to have the same problem with both latitude and longitude.

2.602 still exhibits same problem. Only appears to be latitude field.

I looked at the outgoing data which appears to be 73 bytes per message sent. I have noticed that occaisonally there appears a sentence with 74 bytes. It looks as if it happens when the latitude field exceeds it's alotted space. I have a attached a small screen capture that shows what I'm talking about. This coincides with the unusual activity I've seen my Garmin 396 do.

Thanks Pete, that gave me the clues I needed to find the entire document. It's from the installation manual for the Garmin panel mount series of Aviation GPS. One question in reference to the data being generated by GPSOut for the format in question (Aviation In); are the fields that would normally contain the waypoint information empty? (Field K - {Destination Waypoint} and L {Bearing to dest waypoint} in output sentence type 1). I'm seeing some unusual activity when I have a flight plan loaded on my real Garmin 396. It appears to be sequencing the flight plan by receiving some data from GPSOut as opposed doing it internally. i.e. if the flight plan is A-B-C-D..., MSFS flys A-B-C-D..., but the Garmin with the same flight plan loaded receives the Aviation In data and flies something like A-B-D... - essentially it seems to skip over waypoints randomly. Perhaps a symptom of receiving the next waypoint data from GPSOut Aviation In fields K and L above.

Pete, Do you have the specific information you used to provide support in GPSOut for the Garmin Aviation In format? Something like an Interface Control Document or specification document from Garmin? Apparently there is a function available in the Garmin 296/396 series that allows them to also be connected to a transponder in the aircraft. From what I read this mode is called "TIS Input" and can display aircraft in proximity to your own. I'm hoping the information you used for the Garmin 400 Series Aviation In format would also cover the basics of the TIS format.

I have suspected one of the potentiometers was acting strange and drifting, now I'm sure of it. If you've only had to calibrate a couple of times with the amount of flying you do, then I need to look more closely at replacing some hardware. Thanks.

Pete, Is there a way to have an offset location that would accept a value that resets the yoke/rudder to a default (automatic) calibration? The same way as manually opening the PFC.DLL dialog and selecting >automatic calibration> for aileron, elevator and rudder in the flight controls calibration page.

The latest versions of X-Plane - 8.15, .16... have this feature already built in. Look in the pages where you select joystick/external COM ports. Don't need GPSOUT. GPSOUT only works with Microsoft Flight Sim.

Bank and pitch controls from Pete's autopilot feedback facility work great with a Collins FGS-3000 autopilot. If it works with the real thing, it will work with anything someone else can code in. Takes a bit of tweaking of the fiddle factor numbers, along with dampening out the stability of the flight model you plan to use for your autopilot to control.

I got this to work earlier in the year. Using the DAFIF nav database and identifying stations that had co-located VOR/DMEs I was able to get my system to perform routine DME holds. Great for shooting DME arcs. This week I started to get TACAN to work the same way. By consulting the DAFIF nav database and looking for TACAN stations, I'm able to use the data available from VORTACs, and where the TACAN station is not co-located with a VOR, to simulate the station being there through a simple triangulation routine.

I'm using the Hot Key function to restart the PFC driver. I've mapped it to Shift-C on the keyboard and it fixes the problem I have been seeing with unresponsive flight controls. I would suggest the feature to perform the Hot Key PFC driver restart be left in, as it appears to cure the problems I've been having. What I'm looking for is an FSUIPC offset that could perform the same function as the PFC Driver Hot Key restart. Perhaps a location that needs a value written to it to perform the same thing as my pressing the key command assigned to the PFC Driver restart on my system. Can I write a keystroke (through my application) to a particular offset to accomplish this?

Pete, I have enabled the feature in my registered FSUIPC to reset the PFC flight controls through a keyboard Shift-C. I do not however, see any FSUIPC offsets available to be used to perform this same type of reset. Is this possible? Did I miss it in the documentation? I've looked through both the PFC docs, and FSUIPC docs.

I was experimenting with the autopilot feedback facility and turning off the roll and pitch inputs from the yoke to FS when the autopilot was connected. When the autopilot disconnects I am setting the appropriate control axis flags back to regain roll and pitch input. I thought this may have been the culprit - that for some reason the control flags were still set to disable yoke input. Even after completely removing my application from the mix, I still saw the problem described above. I am now waiting for it to occur again so I can perform the PFC hot key restart. That should fix the problem.

Pete, I've had this happen a few times now over the last couple of weeks on 2 dfferent computers: FS2004 starts up fine, PFC yoke/throttle passes connections checks and operates OK in FS2004. After a situation reset or two, the controls stop operating the aircraft flight controls. The PFC dialog menu still shows the proper inputs being received from roll, pitch, rudders, and throttle with no corresponding action in the FS2004 aircraft. I am using 1.92/registered FSUIPC 3.50. I have been trying feverishly to find the circumstances to recreate the problem on a consistent basis, but can't. To get it working again takes a complete exit from FS2004 and a restart of the program. It has done this on 2 different computers each with different USB-to-serial converters, and after switching to a standard RS-232 port, even on that one. It happens maybe once out of every 20 FS2004 sessions.

Pete, We use several hardware devices in one of our applications that FS2004 provides the info (through FSUIPC) to. Each device comes from its vendor with an API so that we can control the device in software we develop (in c++). The APIs provide a header file (.h) with function definitions that we include in our software, a library file (.lib) that we link to, and a DLL (.dll) file that we run with. If we want Flight Simulator to run an application that we provide the DLL for, what do we need to do in Flight Simulator? For instance, the DLL has one function - how does Flight Simulator know the name of the function so it can call it? Or does the DLL need to be defined in such a way that Flight Simulator doesn't need to know the name of the function? That way every time FS starts my .DLL would properly load/execute. This is what PFC.DLL does using the serial port.