GPS garminプロトコルで試す

garminプロトコルのパケットフォーマットを調べたので、さっそく送信してみる
条件は9600bps 8bit start:1 stop:1 nonparity
NMEAはテキスト(ASCII)だが、garminプロトコルはバイナリ送受信

GPSの準備
出力をgarminにする

端末からデータを送信
資料４．１．１．パケットフォーマットで規定してある書式でデータを送ってみた。
端末でデータの送受信の方法を試してマイコンに実装。

送ったデータ

コマンド(16進)			-->応答(16進)
 1  2  3  4  5  6  7		 1  2  3  4  5  6  7  8
10,00,00,00,00,10,03	-->	10,15,02,00,00,E9,10,03
10,01,00,00,00,10,03	-->	10,15,02,01,00,E8,10,03

適当にデータをGPSに送っても何も返して来なかったが、
上記のようにある程度書式にしたがったデータだと返事が返ってくる。

送ったデータ
1Byte目:0x10(DLE)
1Byte目:0x00(パケットID)
2Byte目:0x00(パケットデータサイズ)
3Byte目:0x00(パケットデータ)
4Byte目:0x00(チェックサム)
5Byte目:0x10(DLE)
6Byte目:0x03(ETX)

帰って来たデータ
0Byte目:0x10(DLE)
1Byte目:0x15(パケットID)
2Byte目:0x02(パケットデータサイズ)
3Byte目:0x00(パケットデータ1)
4Byte目:0x00(パケットデータ2)
5Byte目:0xE9(チェックサム)
6Byte目:0x10(DLE)
7Byte目:0x03(ETX)

で解析、GPSへ送ったデータは、意味を持たないフォーマットのガワだけ。
どんな処理を求めているかを示す2バイト目のパケットIDには何も入れていない。
パケットサイズは０、チェックサムも計算されていない(適当)。
こんな感じで送ってみたところ

帰って来たデータの
2バイト目に0x15:NAK
原典(iop_spec.pdf)には

If a NAK packet is received, the data packet was not received correctly and should be sent again.

となっていて、正確なデータが受信できてないと再送を要求してるっぽい
送信データにチェックサムが要求されていることから、これに引っかかったと思われる。

端末からは適当なデータを送ったが、GPSからの返事にはチェックサムが付いてた。
原典には1Byte目～パケット全部のデータを加算して２の補数を
使うとか書いてあるようなので、帰って来たデータを対象に調べてみた。

2's complement of the sum of all bytes from byte 1 to byte n-4

5Byte目の0xE9が出てこれば確認できる

2's complement

0x15+0x02+0x00+0x00=0x17を反転すると0xE8、これに+1して0xE9同じ値が取得できた。
というわけで、前回のデータにまともなチェックサムを付けて再送信。
0x10,0x0A,0x01,0x31,0xC4,0x10,0x03
で帰って来た値は、
0x10,0x06,0x02,0x0A,0x00,0xEE,0x10,0x03

ACKは返ってきたけど、予想した奴とちがうな～