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
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
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
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:
Pid_Ack_Byte = 6,
Pid_Nak_Byte = 21