mogul

Pete Just for everyones info I tried the garmin295 hooked up to my laptop computer today using the new dll and a USB to com converter and installing garmins usb drivers and it works great. used this ini [GPSout] Sentences=AV400 Interval=1000 Port=COM4 Speed=9600 PosTo6Decimal=Yes to find out which port the adaptor calls it's self I used garmins gps updater and noted which comport it seen the gps on ,this also verifies the gps and your computer is communicating You should tell garmin about this .It makes a good training tool for anyone using their products ,maybe they would give you $$$ to let them include it with their gps info.I noticed they also have some emulators of there new gps 430,530,and 480, has anyone tried these with fs9 Brent

Pete I know it's about 3am where you are and I just wanted to make your day as great as you just made mine! The new mdl works wonderfull,I have all the proper data showing on the garmin 295 It even shows vertical speed, even gives warnings on airspace and restricted spaces exactly as in real flight. I flew a mission today(real plane) and took along my gps to get used to it.I can't tell you how much it helps to be able to pratice learning all the funtions of this gps while sitting at my sim at home ,before you get in the plane. I knew you could do it :) THANKS AGAIN FOR TAKING THE TIME TO HELP ! Brent 1Lt CAP

Pete This is where I got the impression Tuomas sent you a protcol , a quote from his post 12/26/03( new post nov 15 2005) "Someone is going to search for this stuff on the forum anyway, so I thought I'd write up some stuff so they know this stuff works So, as of the last version or so of GPSOut, there's support for AV400 format. This is the "Aviation" format that some Garmin (and other brand) GPS units use to talk to each other. So the panel mounted unit can output the gps location, heading and airspeed etc to the other device. Handy if the other thing has a better antenna etc.. This in real life. For simulator use we have other ideas.. So, I found this document that describes this protocol, and mailed it to Pete. In short, he sent me back a test dll and it worked pretty much "out of the box" - the Garmin was convinced that FS2004 was actually a nice panel mounted GPS device instead of a $50 game. Very handy if you bought a GPS for real-life flying. " I did find this: Interfacing Garmin 295 the following formats are supported for connection external devices: Garmin propietary, Garmin peoprietary differential GPS(DGPS) NMEA 0183 output (version 2.30) ASCII text output, RTCM SC-104 input (version 2.0) I noticed a few other posts where they had this gps working with GPSOUT ,and I have left messages to them, for info on how they made it work I'll still keep looking for the golden key Thanks Brent

Pete this is serial protocol for garmin is it any help? If you tell me what Tuomas sent you to get the garmin 195 to work I will try to get it from garmin Thanks Brent Serial Protocol The Serial Protocol is based on RS-232. The voltage characteristics are compatible with most hosts; however, the device transmits positive voltages only, whereas the RS-232 standard requires both positive and negative voltages. Also, the voltage swing between mark and space may not be large enough to meet the strict requirements of the RS-232 standard. Still, the device voltage characteristics are compatible with most hosts as long as the interface cable is wired correctly. The other electrical characteristics are full duplex, serial data, 9600 baud, 8 data bits, no parity bits, and 1 stop bit. The mechanical characteristics vary among devices; most devices have custom-designed interface connectors in order to meet Garmin packaging requirements. The electrical and mechanical connections to standard DB-9 or DB-25 connectors can be accomplished with special cables that are available from Garmin. Serial Packet Format All data is transferred in byte-oriented packets. A packet contains a three-byte header (DLE, ID, and Size), followed by a variable number of data bytes, followed by a three-byte trailer (Checksum, DLE, and ETX). The following table shows the format of a packet: Table 2 – Serial Packet Format Byte Number Byte Description Notes 0 Data Link Escape ASCII DLE character (16 decimal) 1 Packet ID identifies the type of packet 2 Size of Packet Data number of bytes of packet data (bytes 3 to n-4) 3 to n-4 Packet Data 0 to 255 bytes n-3 Checksum 2's complement of the sum of all bytes from byte 1 to byte n-4 n-2 Data Link Escape ASCII DLE character (16 decimal) n-1 End of Text ASCII ETX character (3 decimal) 3.1.2 DLE Stuffing If any byte in the Size, Packet Data, or Checksum fields is equal to DLE, then a second DLE is inserted immediately following the byte. This extra DLE is not included in the size or checksum calculation. This procedure allows the DLE character to be used to delimit the boundaries of a packet. 3.1.3 ACK/NAK Handshaking Unless otherwise noted in this document, a device that receives a data packet must send an ACK or NAK packet to the transmitting device to indicate whether or not the data packet was successfully received. Normally, the transmitting device does not send any additional packets until an ACK or NAK is received (this is sometimes referred to as a “stop and wait” protocol). The ACK packet has a Packet ID equal to 6 decimal (the ASCII ACK character), while the NAK packet has a Packet ID equal to 21 decimal (the ASCII NAK character). Both ACK and NAK packets contain an 8-bit integer in their packet data to indicate the Packet ID of the acknowledged packet. Note: some devices will report a Packet Data Size of two bytes for ACK and NAK packets; however, only the first byte should be considered. Note: Some devices may work sporadically if only one byte ACK/NAK packets are sent. The host should send two byte ACK/NAK packets to ensure consistency. If an ACK packet is received, the data packet was received correctly and communication may continue. If a NAK packet is received, the data packet was not received correctly and should be sent again. NAKs are used only to indicate errors in the communications link, not errors in any higher-layer protocol. For example, consider the following higherlayer protocol error: a Pid_Wpt_Data packet was expected by the device, but a valid Pid_Xfer_Cmplt packet was received instead. This higher-layer protocol error does not cause the device to generate a NAK. Some devices may send NAK packets during communication timeout conditions. For example, when the device is waiting for a packet in the middle of a protocol sequence, it will periodically send NAK packets (typically every 2-5 seconds) if no data is received from the host. The purpose of this NAK Packet is to guard against a deadlock condition in which the host is waiting for an ACK or NAK in response to a data packet that was never received by the device (perhaps due to cable disconnection during the middle of a protocol sequence). Not all devices provide NAKs during timeout conditions, so the host should not rely on this behavior. It is recommended that the host implement its own timeout and retransmission strategy to guard against deadlock. For example, if the host does not receive an ACK within a reasonable amount of time, it could warn the user and give the option of aborting or re-initiating the transfer. The Serial Protocol Packet ID values are defined using the enumerations shown below: enum { Pid_Ack_Byte = 6, Pid_Nak_Byte = 21 };

Pete in SDK this may mean something "Older software versions in certain devices use slightly different enumerated values for fix. The list of devices and the last version of software in which these different values are used is: Device Last SW Version eMap 2.64 GPSMAP 162 2.62 GPSMAP 295 2.19 eTrex 2.10" my gps295 has SW version 2.50 which would use slightly different enumerated values for fix. Brent

Pete There is a device interface SDK doc at http://www.garmin.com/support/commProtocol.html I'll read thru it and see if I see any clues Do you know what cable Tuomas used to connect his 195 to his computer

Pete I tried that to "NO",also tried "4800" on speed,also tried leaving different lines out of ini. Maybe the garmin 295 takes a newer type of "aviation in"format than the 195? Brent

Tuomas I am trying to get a garmin 295 to work with FS9 using gpsout problem is it is not showing my correct place in the world.When I am in slc,UT it shows me south of japan,place plane in cal, and it shows in N Canada Track is good ,speed is good,alt is good . I'm using the cable that came with the gps for updates 9pin computer end and 4 pin on gps end,which is pin 3(com port)=data in(gps) and pin 2(com port)=data out(gps) I've tried changing the ini to different things but can't find the one that works I have gps set to "aviation in "interface and simulator mode "WSG84 " map datum "hddd'mm.mmm' "format position " gps out ini is: Sentences=AV400. Interval=1000 Speed=9600 PosTo6Decimal=Yes port=com1 (com 1 is seeing gps for updates ,and sees speed and alt on gps thru gpsout) tried turning off any addon scenery,rebooting would appreciate any help thanks Brent