Garmin Aviation In (Series 400)

[dfournie]

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.

[Pete Dowson]

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?

Attached. I don't think it's from Garmin. It appears to be only part of a larger document, but it was sent to me just like this. Sorry, I don't recall who by, it was many years ago.

Regards,

Pete

Aviation GPS Format.zip

[dfournie]

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 Dowson]

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 only have fields A B C D Q T (but blanked ------) listed as relevant to what GPSout can do. I you want to see the output from GPSout, grab Portmn from http://www.systeminternals.com and monitor the data as is goes out.

It appears to be sequencing the flight plan by receiving some data from GPSOut as opposed doing it internally.

I wouldn't know how it does that. GPSout knows nothing about any flight plans.

Perhaps a symptom of receiving the next waypoint data from GPSOut Aviation In fields K and L above.

No, GPSout has no idea what your plan is and makes absolutely no attempt to send any waypoint data. Sorry.

Regards,

Pete

[dfournie]

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.

[Pete Dowson]

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.

Hmmm. Strange. I've looked at the code and can't see why that should happen -- it is obviously something to do with the rounding. I'l need to put a check in to guard against that.

Regards,

Pete

[Pete Dowson]

Can you try the attached version 2.602, please, and let me know. I'm not sure I'm adjusting the right things here.

Regards,

Pete

GSPout2602.zip

[dfournie]

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

[dfournie]

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

[dfournie]

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.

[Pete Dowson]

I'm not picking on your great work Pete, but apparently the Garmin spec (and those units that support it) are -very, very- picky.

It's okay. I'm just a bit bemused that this is the first problem reported with AV400 since I added it several years ago. It seems strange that the person originally asking for it didnt have problems. Maybe he never actually used it, or didn't use such a fussy unit?

Anyway, I've re-written the Lat/Lon rounding algorithm, removed the Q code, and deleted one of the -'s after the T, so this, version 2.603, should be perfect. No?

BTW from FSX onwards, GPSout will be bundled into FSUIPC as part of the user facilities, and will need user registration. Part of my plan to both reduce the number of different modules I have to keep track of, and to make paying for FSUIPC more attractive. ;-)

Regards

Pete

GPSout2603.zip

[dfournie]

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.

[Pete Dowson]

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.

Hmmm .... I don't understand that. All I did was do the same rounding as before (exactly the same) except inserting a check for the last two digits being >99 in which case I replace them with 99. I can't see how that can lose all other values except 00 and 01 -- that is totally weird! It should just fix those cases of xx100 to make them xx99.

The minutes calculation hasn't been changed at all -- that is still EXACTLY as it was. Only the two hundredths digits are revised, just be that check.

The code is several years old. I'll need to leave all this till I have time to work through it properly. I was trying to help in little bits of time here and there, but evidently this is a much bigger problem than I thought. It'll have to wait a week or three. Sorry.

Erjust one thought. Do you have "PosTo6Decimal=No" set? It looks like it will go completely wrong if you try to set 6 decimal places -- which is defaulted by the looks of things. That was a recent change for more accuracy on NMEA devices.

Even then, that would only affect the hundredths, not the minutes pair!

Regards,

Pete

[Pete Dowson]

Latitude and Longitude degrees look OK. Minutes and Hundreths of minutes for both are off.

Okay. I was a bit restless so I had another look before going to bed.

The clue was in my last message. It's all to do with that change from 4 to 6 decimal places in the NMEA data. The fraction was being divided by 10000 to cope with it, but for 4 places it should be divided by 100.

The thing I don't understand is why this didn't affect the previous two versions I sent youas I said, I'd not changed anything much that last time. The hundredths of minutes should have been wrong in both 2.602 and 2.603. Perhaps they were and you didn't notice, or forgot to mention?

Anyway, this one (2.604) seems okay, and I've made the AV400 output independent of the 4/6 decimal option setting.

Regards,

Pete

GPSout2604.zip

[dfournie]

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.

[dfournie]

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

[dfournie]

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)

[dfournie]

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.

[Pete Dowson]

Pete, can you change 2.604 to output Field C in TRUE instead of MAG? I would forever be in your debt.

Try 2.605, attached.

Pete

GPSout2605.zip

[dfournie]

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.

[Pete Dowson]

For our application (FS2004) he stated that it would need MAG track (Field C) and user MagVar (Field Q) both output in the sentence.

...

Ah, a complete circle, eh?

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.

What is the serial port speed set? That's really the limitation -- if the defalut speed of 4800 is set then that's only 480 bytes per second which would only allow 48 bytes in each burst with a 100 m/sec delay. What would happen is that a big backlog of data would occur in the PC's serial port driver buffers, until they overflowed and you got some errors., then it might start all over again. meanwhile there's be an increasing delay noticable in the results on the device as it got further and further behind.

I'll put the Q and C fields back as they were ...

Pete

[Pete Dowson]

Here's 2.606!

Pete

GPSout2606.zip

[dfournie]

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.

[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.

[Pete Dowson]

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.

I keep things parallelled, don't fret.

Pete