全てのデバイスはこの文書で前述したデフォルトの物理プロトコルと基本リンクプロトコルを使用して 製品データプロトコルを実装する必要があります。 製品データプロトコル (Product Data Protocol) はデバイスの製品 ID を発見するために使用されます。 そしてさらにどのデータ転送プロトコルが接続中のデバイスでサポートされているかを決定するために ホストによって使用されます (8.2章参照)。
製品データプロトコルのパケット順序は以下の通り:
パケット 0 (Pid_Product_Rqst) はデバイスに送信される特別な製品要求パケットです。
ホストにはデバイスを認識するためのデータが含まれたパケット 1 (Pid_Product_Data) が
返されます。このパケットに包含されるデータは Product_Data_Type です。
パケット 2 (Pid_Ext_Product_Data) から N-1 (Pid_Ext_Product_Data) までは
どのデバイスにも実装されていません。これはデータ型 Ext_Product_Data_Type で提供される
デバイスに関する追加情報を含んでいます。
Product_Data_Type は 2 つの 16 ビット整数とそれに続く null 終端文字列で構成されて
います。
最初の整数は製品 ID を示し、2 番目はソフトウェアバージョン番号に 100 をかけた数値を示します
(例えばバージョン 3.11 は 10 進数の 311 となる)。
これらの整数に続いて一つ以上の null 終端文字列が存在します。
最初の文字列はデバイスとソフトウェアバージョンのテキスト説明を提供します;
この文字列はホスト側のユーザに対して "about" ダイアログボックスに表示することを意図しています。
ホストはそれ以降の全ての文字列を無視すべきです; これらはそれ以外のデバイス情報を確認するために
製造過程で使用されるものでありエンドユーザに表示するようにはフォーマットされていません。
Product_Data_Type 定義は以下の通り:
typedef struct
{
uint16 product_ID;
sint16 software_version;
/* char product_description[]; null 終端文字列 */
/* ... 0 個以上の追加の null 終端文字列 */
} Product_Data_Type;
Ext_Product_Data_Type は 0 個以上の null 終端文字列を保持しています。
ホストはこれらの文字列を無視すべきです; これらは別のデバイス情報を確認するために製造過程で
使用されるものでありエンドユーザに表示するようにはフォーマットされていません。
typedef struct
{
/* ... 0 個以上の null 終端文字列 */
} Ext_Product_Data_Type;
プロトコル能力プロトコル (Protocol Capability Protocol) はデバイスのプロトコル能力とデバイス固有 のデータ型をホストに報告するための一方向プロトコルです。 このプロトコルがデバイスでサポートされている場合、製品データプロトコルが完了した直後にデバイスから 自動的に開始されます。 ホストはこのプロトコルを使用してデバイスがサポートしている全てのプロトコルとデータ型のリストを取得 します。
プロトコル能力プロトコルのパケット順序は以下の通り:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | Device to Host | Pid_Protocol_Array | Protocol_Array_Type |
パケット 0 (Pid_Protocol_Array) は Protocol_Data_Type 構造の配列を保持
しており、それぞれはタグ化されたプロトコル情報です。
配列要素の順序はデータ型をプロトコルに結びつけるために使用されます。 例えば 2 つのデータ型 <D0> と <D1> が必要なプロトコルのタグ化されたプロトコル ID には 後ろに 2 つのタグ化されたデータ型 ID が続きます。 ここで最初のデータ型 ID は <D0> であり 2 つ目のデータ型 ID は <D1> です。
Protocol_Array_Type は Protocol_Data_Type の配列です。
配列に含まれる Protocol_Data_Type 構造の数は受信したパケットデータの数を得ることに
より決定することが出来ます。
typedef Protocol_Data_Type Protocol_Array_Type[];
Protocol_Data_Type は 1 バイトのタグフィールドと 2 バイトのデータフィールドで構成
されています。
タグはどの種類の ID がデータフィールドに含まれているかを表し、データフィールドには実際の ID が
含まれます。
typedef struct
{
uint8 tag;
uint16 data;
} Protocol_Data_Type;
タグ値とデータ値の組み合わせはこの文書で指定しているプロトコルやデータ型の一つと一致しなければ
なりません。
例えばこのドキュメントでは "A100" で識別されるウェイポイント転送プロトコルを説明して
います。
このプロトコルはタグ値 'A' とデータフィールドの値 100 で表されます。
Protocol_Data_Type の tag メンバーに対する列挙値は以下の通り。
表されている文字は ASCII 文字セットでの数値に変換されます。
enum
{
Tag_Phys_Prot_Id = ‘P’, /* 物理プロトコル ID のタグ */
Tag_Link_Prot_Id = ‘L’, /* Link protocol ID のタグ */
Tag_Appl_Prot_Id = ‘A’, /* アプリケーションプロトコル ID のタグ */
Tag_Data_Type_Id = ‘D’ /* データ型 ID のタグ */
};
以下のテーブルはプロトコル能力プロトコルでやり取りしている間にホストが受信するかもしれない一連の 3 バイトレコードを示します:
デバイスは上記の転送から以下のプロトコルを省略します。
A000 は全てのデバイスがサポートしているため省略されています。 A001 はプロトコル情報を通信するために使用されているまさにそのプロトコルであるため省略されています。
この章ではデバイスコマンドプロトコル (Device Command Protocol) として知られる類似したプロトコルの
グループについて説明します。
これらのプロトコルはデバイスに命令を送信するために使用されます; 例えばホストはデバイスにその
ウェイポイントを送信するよう命令を出すかもしれません。
全てのデバイスはデバイスコマンドプロトコルのうち一つを実装することを要求されます。
しかしいくつかのコマンドはデバイスで実装されないかもしれません
(実装されていないコマンドの受信はデバイス側ではエラーになりません; 単純に無視されます)。
それぞれのデバイスコマンドプロトコルの違いは Command_Id_Type に対して列挙された値が
異なるという事だけです (後述のそれぞれのデバイスコマンドプロトコルの章を参照)。
ホストやデバイスは他方のデバイスからのコマンドなしに転送の開始を許可されている点に注意が必要です (例えばホストがデバイスにデータを転送する時や、ユーザが転送を開始するためにデバイスのボタンを押した 場合など)。 それぞれのデバイスコマンドプロトコルのパケット順序は以下の通り:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | Device1 to Device2 | Pid_Command_Data | Command_Id_Type |
パケット 0 (Pid_Command_Data) はコマンドと識別するためのデータをデータ型
Command_Id_Type で保持しています。
Command_Id_Type は特定のコマンドを示す 16 ビット整数です。
Command_Id_Type に対する型定義は以下の通り:
typedef uint16 Command_Id_Type;
このプロトコルは大多数のデバイス (8.2章参照) で実装されています。
Command_Id_Type に対する列挙値は以下の通り:
enum
{
Cmnd_Abort_Transfer = 0, /* 現在の転送を中断 */
Cmnd_Transfer_Alm = 1, /* 軌道要素を転送 */
Cmnd_Transfer_Posn = 2, /* transfer position */
Cmnd_Transfer_Prx = 3, /* 近接ウェイポイントを転送 */
Cmnd_Transfer_Rte = 4, /* ルートを転送 */
Cmnd_Transfer_Time = 5, /* 時刻を転送 */
Cmnd_Transfer_Trk = 6, /* トラックログを転送 */
Cmnd_Transfer_Wpt = 7, /* ウェイポイントを転送 */
Cmnd_Turn_Off_Pwr = 8, /* 電源断 */
Cmnd_Start_Pvt_Data = 49, /* PVT データの転送開始 */
Cmnd_Stop_Pvt_Data = 50, /* PVT データの転送終了 */
Cmnd_FlightBook_Transfer = 92, /* フライトレコードの転送 */
Cmnd_Transfer_Laps = 117, /* フィットネスラップの転送 */
Cmnd_Transfer_Wpt_Cats = 121, /* ウェイポイントカテゴリの転送 */
Cmnd_Transfer_Runs = 450, /* フィットネスランの転送 */
Cmnd_Transfer_Workouts = 451, /* ワークアウトの転送 */
Cmnd_Transfer_Workout_Occurrences = 452, /* ワークアウト繰り返しの転送 */
Cmnd_Transfer_Fitness_User_Profile = 453, /* フィットネスユーザプロファイルの転送 */
Cmnd_Transfer_Workout_Limits = 454, /* ワークアウト上限の転送 */
Cmnd_Transfer_Courses = 561, /* フィットネスコースの転送 */
Cmnd_Transfer_Course_Laps = 562, /* フィットネスコースラップの転送 */
Cmnd_Transfer_Course_Points = 563, /* フィットネスコースポイントの転送 */
Cmnd_Transfer_Course_Tracks = 564, /* フィットネスコーストラックの転送 */
Cmnd_Transfer_Course_Limits = 565 /* フィットネスコース上限の転送 */
};
注意: "Cmnd_Turn_Off_Pwr" コマンドはデバイスからの応答が行われないでしょう。
注意: PC は転送をキャンセルするためにデータの転送途中でデバイスへ Cmnd_Abort_Transfer
を送信することが出来ます。
このプロトコルは主にパネルに搭載された航空デバイス (8.2章参照) で実装されています。
Command_Id_Type に対する列挙値は以下の通り:
enum
{
Cmnd_Abort_Transfer = 0, /* 現在の転送を中断 */
Cmnd_Transfer_Alm = 4, /* 軌道要素の転送 */
Cmnd_Transfer_Rte = 8, /* ルートの転送 */
Cmnd_Transfer_Prx = 17, /* 近接ウェイポイントの転送 */
Cmnd_Transfer_Time = 20, /* 時刻の転送 */
Cmnd_Transfer_Wpt = 21, /* ウェイポイントの転送 */
Cmnd_Turn_Off_Pwr = 26 /* 電源断 */
};
ウェイポイント転送プロトコル (Waypoint Transfer Protocol) はデバイスとの間でウェイポイントを転送 するために使用されます。 ホストがデバイスにウェイポイントを送信するよう命令した場合、そのデバイスはそのデータベースに保存 されている全てのウェイポイントを送信するでしょう。 ホストがデバイスにウェイポイントを送信する場合、ホスト側で選択したウェイポイントを選択的に送る 事が出来ます。
ウェイポイント転送プロトコルのパケット順序は以下の通り:
最初と最後のパケット (パケット 0 と パケット n-1) は標準の開始/終了パケットです
(5.4章参照)。
パケット n-1 に含まれる Command_Id_Type 値は Cmnd_Transfer_Wpt です。
これはデバイスからのウェイポイントの転送を開始するためにホストによって使用されたコマンド値でも
あります。
パケット 1 から n-2 (Pid_Wpt_Data) それぞれはデバイス固有のデータ型 <D0> で
提供されるウェイポイントを一つ保持しています。
通常このデータ型は識別文字列、緯度、経度、そのほかのデバイス固有データが含まれています。
ウェイポイントカテゴリ転送プロトコル (Waypoint Category Transfer Protocol) はデバイスとの間で ウェイポイントカテゴリを転送するために使用されます。 デバイスがウェイポイントカテゴリを転送するよう命令された場合、デバイスはそのデータベースに保存され ている全てのウェイポイントカテゴリを送信するでしょう。 ウェイポイントカテゴリ転送プロトコルのパケット順序は以下の通り:
最初と最後のパケット (パケット 0 と パケット n-1) は標準の開始/終了パケットです
(5.4章参照)。
パケット n-1 に含まれる Command_Id_Type 値は Cmnd_Transfer_Wpt_Cats
です。これはデバイスからのウェイポイントカテゴリの転送を開始するためにホストによって使用された
コマンド値でもあります。
パケット 1 から n-2 (Pid_Wpt_Cat) それぞれはデバイス固有のデータ型 <D0> で
提供されるウェイポイントカテゴリを一つ保持しています。
パケット 1 から n-2 までのパケット順序は特定のカテゴリに対する受信データの関連を示しています。
例えば、パケット 1 はカテゴリ 1 に関連付けられたデータを含み、パケット 3 はカテゴリ 3 に関連付け
られています。
それぞれのデバイスはあるウェイポイントカテゴリの上限数を含む能力があります。
デバイスがその上限数を超えてデータパケットを受信した場合、その上限数より大きいデータパケットは無視
されます。
ルート転送プロトコル (Route Transfer Protocol) はデバイスとの間でルートを転送するために使用されます。 ホストがデバイスにルートを送信するよう命令した場合、デバイスはそのデータベースに保存されている全て のルートを送信するでしょう。 ホストがデバイスにルートを送信する場合、ホスト側で選択したルートを選択的に送ることが出来ます。
特定のデバイスはウェイポイント情報の内部データベースを保持しています。
例えば大部分の航空デバイスは航行ウェイポイントの内部データベースを持ち、StreetPilot は陸上の
ウェイポイントを持ちます。
ホストからこのようなデバイスの一つにルートが転送された場合、デバイスはその内部データベースに保持
しているルートウェイポイントを内部データベースのウェイポイントと合わせようとします。
最初に、デバイスは入ってきたルートウェイポイントの "wpt_class" メンバーを調べます;
もしそれが非ユーザウェイポイントを示す場合、デバイスはルートウェイポイントの他のメンバーに含まれる
値を使用して内部データベースから探します。
航空デバイスでは内部データベースから探すために "ident" と "cc" メンバー
が使用されます; StreetPilot では内部データベースから探すために "subclass" メンバーが
使用されます。
もし一致するものが存在すれば、内部データベースからのウェイポイントがルートに対して使用されます;
そうでなければ新しいユーザウェイポイントが作成されルートに使用されます。
A200 ルート転送プロトコルに対するパケット順序は以下の通り:
最初と最後のパケット (パケット 0 とパケット n-1) は標準の開始/終了パケットです (5.4章参照)。 パケット n-1 に含まれている Command_Id_Type 値は Cmnd_Transfer_Rte であり、ホストからルート転送を 初期化するためにデバイスへ送られたコマンド値と同じです。
パケット 1 (Pid_Rte_Hdr) はルートヘッダ情報を保持しており、これはデバイス仕様のデータ型 <D0> で提供されます。このデータ型は通常ルートをユニークに識別する情報を含んでいます。 パケット 2 から n-2 (Pid_Rte_Wpt_Data) のそれぞれは単一のルートウェイポイントのデータを含んでいます。 これはデバイス仕様のデータ型 <D1> で提供されます。 このデータ型は通常ウェイポイント転送プロトコルで使用されるウェイポイントデータと同じウェイポイントを 含んでいます。
More than one route can be transferred during the protocol by sending another set of packets that resemble Packets 1 through n-2 in the table above. This additional set of packets is sent immediately after the previous set of route packets. In other words, it is not necessary to send Pid_Xfer_Cmplt until all route packets have been sent for the multiple routes. Device2 must monitor the Packet ID to detect the beginning of a new route, which is indicated by a Packet ID equal to Pid_Rte_Hdr. Any number of routes may be transferred in this fashion.
A201 ルート転送プロトコルに対するパケット順序は以下の通り:
The first and last packets (Packet 0 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet n-1 is Cmnd_Transfer_Rte, which is also the command value used by the host to initiate a transfer of routes from the device.
Packet 1 (Pid_Rte_Hdr) contains route header information, which is provided in device-specific data type <D0>. This data type usually contains information that uniquely identifies the route. Even numbered packets starting with packet 2 contain data for one route waypoint, which is provided in device-specific data type <D1>. Odd numbered packets starting with packet 3 and excluding packet n-1 (Pid_Xfer_Cmplt) contain data for one link between the adjacent waypoints. This link data is provided in device-specific data type <D2>.
More than one route can be transferred during the protocol by sending another set of packets that resemble Packets 1 through n-2 in the table above. This additional set of packets is sent immediately after the previous set of route packets. In other words, it is not necessary to send Pid_Xfer_Cmplt until all route packets have been sent for the multiple routes. Device2 must monitor the Packet ID to detect the beginning of a new route, which is indicated by a Packet ID equal to Pid_Rte_Hdr. Any number of routes may be transferred in this fashion.
ホストからデバイスへトラックログを転送する場合、デバイスはそれぞれのトラックログ地点での到着時刻 を無視し、その内部データベースに時刻としてゼロを設定します。 もし後でデバイスからホストへトラックログを戻したら時刻値はゼロになっているでしょう。 このため、ホストは実際にデバイスで記録されたトラックログと外部のホストからデバイスに転送された トラックログを区別する事が出来ます。
注意: いくつかのデバイスは不正な時刻値を示すゼロの代わりに 0x7FFFFFFF や 0xFFFFFFFF を使用します。
The Track Log Transfer Protocol is used to transfer track logs between devices. Some devices store only one track log (called the “active” track log), however, other devices can store multiple track logs (in addition to the active track log). When the host commands the device to send track logs, the device will concatenate all track logs (i.e., the active track log plus any stored track logs) to form one track log consisting of multiple segments; i.e., the protocol does not provide a way for the host to request selective track logs from the device, nor is there a way for the host to decompose the concatenated track log into its original set of track logs. When the host sends track logs to the device, the track log is always stored in the active track log within the device; i.e., there is no way to transfer track logs into the database of stored track logs. None of these limitations affect devices that store only one track log.
The packet sequence for the Track Log Transfer Protocol is shown below:
The first and last packets (Packet 0 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet n-1 is Cmnd_Transfer_Trk, which is also the command value used by the host to initiate a transfer of track logs from the device.
Packets 1 through n-2 (Pid_Trk_Data) each contain data for one track log point, which is provided in device-specific data type <D0>. This data type usually contains four elements: latitude, longitude, time, and a boolean flag indicating whether the point marks the beginning of a new track log segment.
トラックログ転送プロトコルのパケット順序は以下の通り:
最初と最後のパケット (パケット 0 と パケット n-1) は標準の開始/終了パケットです
(5.4章参照)。
パケット n-1 に含まれる Command_Id_Type 値は Cmnd_Transfer_Trk
です。これはデバイスからのウェイポイントカテゴリの転送を開始するためにホストによって使用された
コマンド値です。
パケット 1 (Pid_Trk_Hdr) はデバイス固有のデータ型 <D0> で提供されるトラック
ヘッダ情報を保持しています。
通常このデータ型はトラックログを一意に識別する情報を含んでいます。
パケット 2 から n-2 (Pid_Trk_Data) までのそれぞれはデバイス固有のデータ型 <D1>
で提供されるトラックログ地点の一つを含んでいます。
上記の表におけるパケット 1 から n-2 と同様の別のパケットセットを送信することで、プロトコル処理中に
複数のトラックログを転送することが出来ます。
このパケットの追加セットは前のトラックログパケットセットの直後に送信されます。
言い換えると、複数のトラックログに対する全てのトラックログパケットが送信されるまで
Pid_Xfer_Cmplt が送られてはいけません。
Device2 はパケット ID Pid_Trk_Hdr によって示される新しいトラックログの開始を検出する
ためにシーケンス上のパケット ID を監視しなければいけません。
多くのトラックログはこの形式で送信されるでしょう。
The A302 Track Log Transfer Protocol is used in fitness devices to transfer tracks from the device to the Host. The packet sequence for the protocol is identical to A301, except that the Host may only receive tracks from the device, and not send them.
The Proximity Waypoint Transfer Protocol is used to transfer proximity waypoints between devices. When the host commands the device to send proximity waypoints, the device will send all proximity waypoints stored in its database. When the host sends proximity waypoints to the device, the host may selectively transfer any proximity waypoint it chooses.
The packet sequence for the Proximity Waypoint Transfer Protocol is shown below:
The first and last packets (Packet 0 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet n-1 is Cmnd_Transfer_Prx, which is also the command value used by the host to initiate a transfer of proximity waypoints from the device.
Packets 1 through n-2 (Pid_Prx_Wpt_Data) each contain data for one proximity waypoint, which is provided in devicespecific data type <D0>. This data type usually contains the same waypoint data that is transferred during the Waypoint Transfer Protocol, plus a valid proximity alarm distance.
Some devices (e.g. aviation panel mounts) require a delay of one or more seconds between proximity waypoints when the host transfers proximity waypoints to the device.
軌道要素 (Almanac) 転送プロトコルはデバイス間で軌道要素を転送するために使用するプロトコルです。 このプロトコルの主な目的は、6 ヶ月以上保管されていたデバイスやメモリクリア操作を受けたデバイスを ホストが更新出来るようにすることです。 潜在的に長時間かかる自動初期化手順を回避するために、デバイスは現在の衛星軌道要素とおおよその日付、 時刻、位置を持つ必要があります。 従って、デバイスに軌道要素を転送した後、ホストは続けて後述の A600 - 日付/時刻初期化プロトコル (6.10章参照) や A700 - 位置初期化プロトコル (6.12章参照) を使用してデバイスに日付、時刻、位置を (この順で) 転送する必要が あります。 軌道要素を受信した後、デバイスはデバイスコマンドプロトコルを使用して時刻要求や位置要求を行う 事が出来ます。
ユーザがデバイスの軌道要素をアーカイブしたり他のデバイスに転送できるよう、デバイスからホストへ 軌道要素を転送することも出来ます。
軌道要素転送プロトコルのパケット順序は以下の通り:
最初と最後のパケット (パケット 0 と パケット n-1) は標準の開始/終了パケット (5.4章参照) です。 パケット n-1 の Command_Id_Type 値は Cmnd_Transfer_Alm であり、これは デバイスから軌道要素の転送を初期化するためにホストによって使用された値です。 パケット 1 から n-2 (Pid_Almanac_Data) のそれぞれは衛星の軌道要素データを保持しています。 これらはデバイス仕様のデータ型 <D0> で提供されます。 このデータ型は衛星の軌道特性に関する詳しいデータを保持しています。
いくつかのデバイス仕様データ型 (<D0>) ではそれぞれのデータパケットを GPS 軌道の特定の衛星と 関連付けるための衛星 ID を保持していません。 このようなデータ型に対して、デバイス 1 は正確に 32 個の Pid_Almanac_Data パケットを送らなければ ならず、そしてそれらのパケットは PRN 順序で送られなければいけません (つまり最初のパケットは PRN-01 のデータを保持し、以降 PRN-32 までそのようになります)。 特定の衛星に対するデータが欠落していたり衛星が存在しない場合、週番号 (week number) はデータが 無効であることを示すために負の値に設定されなければいけません。
日付/時刻初期化プロトコルはデバイスとの間で現在時刻を転送するために使用するプロトコルです。 通常これはデバイスとの軌道要素 (Almanac) 転送と関連して行われます (6.9章参照)。
日付/時刻初期化プロトコルのパケット順序は以下の通り:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | デバイス1 → デバイス2 | Pid_Date_Time_Data | <D0> |
パケット 0 (Pid_Date_Time_Data) はデバイス仕様のデータ型 <D0> によって提供される日付と時刻 を保持しています。
The FlightBook Transfer Protocol is used to transfer auto-generated FlightBook data to the host. The packet sequence for the FlightBook Transfer Protocol is shown below:
Packet 0 (Pid_Command_Data) commands the device to initiate a FlightBook transfer. Packets 1 and n-1 are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value in packets 0 and n- 1 is Cmnd_FlightBook_Transfer. Packets 2 through n-2 each contain a FlightBook record using device-specific data type <D0>.
位置初期化プロトコルはデバイスとの間で現在の位置を転送するために使用するプロトコルです。 通常これはデバイスとの軌道要素 (Almanac) 転送と関連して行われます (6.9章参照)。 位置初期化プロトコルのパケット順序は以下の通り:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | デバイス1 → デバイス2 | Pid_Position_Data | <D0> |
パケット 0 (Pid_Position_Data) はデバイス仕様のデータ型 <D0> によって提供される位置データを 保持しています。 デバイスが有効な位置測位を行えている場合やシミュレータモードで動作している場合、このプロトコルに よって提供される位置データを無視する事が出来ます。
PVT プロトコルはデバイスからホストに対しておおよそ 1 秒ごとに転送されるリアルタイムの位置 (Position)、速度 (Velocity)、時刻 (Time) を提供するために使用されます。 このプロトコルは、ユーザがデバイス上で NMEA フォーマットと Garmin フォーマットをこまめに切り替える 代わりに Garmin フォーマットを恒常的に選んでおけるよう、NMEA に代わるものとして提供されます。
ホストはデバイスコマンドプロトコル (6.3章参照) を使用して PVT をオン/オフできます。
PVT はホストが Cmnd_Start_Pvt_Data コマンドを送信したときにオンとなり、
Cmnd_Stop_Pvt_Data を送信したときにオフとなります。
副作用として、ほとんどのデバイスが製品データプロトコルに応答する時は必ず PVT がオフとなる事に注意
してください。
ACK と NAK パケットはこのプロトコルでは省略可能です; ただし、他のプロトコルと違い、デバイスは ホストから受信した NAK への応答で PVT を再送信しません。
PVT プロトコルのパケット順序は以下の通り:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | Device to Host | ACK/NAK | (省略化) Pid_Pvt_Data <D0> |
パケット 0 (Pid_Pvt_Data) はデバイス固有のデータ型 <D0> で提供される位置、速度、
日時を保持しています。
The Lap Transfer Protocol is used to transfer fitness laps to the host. The packet sequence for the Lap Transfer Protocol is shown below:
The first and last packets (Packet 0 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet n-1 is Cmnd_Transfer_Laps, which is also the command value used by the host to initiate a transfer of laps from the device.
Packets 1 through n-2 (Pid_Lap) each contain data for one lap, which is provided in device-specific data type <D0>.
The Run Transfer Protocol is used to transfer fitness runs to the host.
The packet sequence for the Run Transfer Protocol is shown below:
The first and last packets for each transfer sequence (Packet 1 and Packet k-1, Packet k+1 and Packet m-1, and Packet m+1 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet 0 and Packet k-1 is Cmnd_Transfer_Runs. The Command_Id_Type value contained in Packet k and Packet m-1 is Cmnd_Transfer_Laps. The Command_Id_Type value contained in Packet m and Packet n-1 is Cmnd_Transfer_Trk.
Packets 2 through k-2 (Pid_Run) each contain data for one run, which is provided in device-specific data type <D0>. Packets k+2 through m-2 (Pid_Lap) each contain data for one lap, which is provided in device-specific data type <Lap_Type>. Data type <Lap_Type> is the data type associated with A906 in the Protocol Capability Protocol (see section 6.2 on page 9). Packet m+2 (Pid_Trk_Hdr) contains track header information, which is provided in devicespecific data type <Trk_Hdr_Type>. Packets m+3 through n-2 each contain data for one track log point, which is provided in device-specific data type <Trk_Data_Type>. Data types <Trk_Hdr_Type> and <Trk_Data_Type> are the data types associated with A302 in the Protocol Capability Protocol, as reported by the device.
The device may transfer more than one track log during the protocol by sending another set of packets that resemble packets m+2 through n-2 in the table above. This additional set of packets is sent immediately after the previous set of track log packets. In other words, Pid_Xfer_Cmplt will not be sent until all track log packets have been sent for the multiple track logs. The Host must monitor the Packet ID to detect the beginning of a new track log, which is indicated by a Packet ID of Pid_Trk_Hdr. Any number of track logs may be transferred in this fashion.
The Workout Transfer Protocol is used to transfer workouts between devices.
The packet sequence for the Workout Transfer Protocol is shown below:
The first and last packets for each transfer sequence (Packet 1 and Packet m-1, and Packet m+1 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet 0 and Packet m-1 is Cmnd_Transfer_Workouts. The Command_Id_Type value contained in Packet m and Packet n-1 is Cmnd_Transfer_Workout_Occurrences.
Packets 2 through m-2 (Pid_Workout) each contain data for one workout, which is provided in device-specific data type <D0>. Packets m+2 through n-2 each contain data for one workout occurrence, which is provided in devicespecific data type <Workout_Occurrence_Type>. Data type <Workout_Occurrence_Type> is the data type associated with A1003 in the Protocol Capability Protocol (see section 6.2 on page 9), as reported by the device.
The Fitness User Profile Transfer Protocol is used to transfer a fitness user profile between devices.
The packet sequence for the Fitness User Profile Transfer Protocol is shown below:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0* | Device1 to Device2 | Pid_Command_Data | Command_Id_Type |
| 1 | Device2 to Device1 | Pid_Fitness_User_Profile | <D0> |
The Command_Id_Type value contained in Packet 0 is Cmnd_Transfer_Fitness_User_Profile. Packet1 contains a fitness user profile, which is provided in device-specific data type <D0>.
The Workout Limits Transfer Protocol is used to transfer limits on workout data to the host.
The packet sequence for the Workout Limits Transfer Protocol is shown below:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | Host to Device | Pid_Command_Data | Command_Id_Type |
| 1 | Device to Host | Pid_Workout_Limits | <D0> |
The Command_Id_Type value contained in Packet 0 is Cmnd_Transfer_Workout_Limits. Packet 1 contains the workout limits, which are provided in device-specific data type <D0>.
The Course Transfer Protocol is used to transfer fitness courses between devices.
The packet sequence for the Course Transfer Protocol is shown below:
The first and last packets for each transfer sequence (Packet 1 and Packet j-1, Packet j+1 and Packet k-1, Packet k+1 and Packet m-1, and Packet m+1 and Packet n-1) are the standard beginning and ending packets (see section 5.4 on page 8). The Command_Id_Type value contained in Packet 0 and Packet j-1 is Cmnd_Transfer_Courses. The Command_Id_Type value contained in Packet j and Packet k-1 is Cmnd_Transfer_Course_Laps. The Command_Id_Type value contained in Packet k and Packet m-1 is Cmnd_Transfer_Course_Tracks. The Command_Id_Type value contained in Packet m and Packet n-1 is Cmnd_Transfer_Course_Points.
Packets 2 through j-2 (Pid_Course) each contain data for one course, which is provided in device-specific data type <D0>. Packets j+2 through k-2 (Pid_Course_Lap) each contain data for one course lap, which is provided in device- specific data type <Crs_Lap_Type>. Data type <Crs_Lap_Type> is the data type associated with A1007 in the Protocol Capability Protocol (see section 6.2 on page 9), as reported by the device. Packet k+2 (Pid_Course_Trk_Hdr) contains course track header information, which is provided in device-specific data type <Crs_Trk_Hdr_Type>. Packets k+3 through m-2 each contain data for one course track log point, which is provided in device-specific data type <Crs_Trk_Data_Type). If the Protocol Capability Protocol on the device reports A1012, then data types <Crs_Trk_Hdr_Type> and <Crs_Trk_Data_Type> are the first and second data types associated with A1012, respectively. Otherwise the data types <Crs_Trk_Hdr_Type> and <Crs_Trk_Data_Type> are the data types used by the A302 Track Transfer Protocol (see section 6.7.4 on page 16). Packets m+2 through n-2 (Pid_Course_Point) each contain data for one course point, which is provided in device-specific data type <Crs_Pt_Type>. Data type <Crs_Pt_Type> is the data type associated with A1008 in the Protocol Capability Protocol, as reported by the device. More than one course track log can be transferred during the protocol by sending another set of packets that resemble packets k+2 through m-2 in the table above. This additional set of packets is sent immediately after the previous set of course track log packets. In other words, it is not necessary to send Pid_Xfer_Cmplt until all course track log packets have been sent for the multiple course track logs. The Host must monitor the Packet ID to detect the beginning of a new course track log, which is indicated by a Packet ID of Pid_Course_Trk_Hdr. Any number of course track logs may be transferred in this fashion.
The Course Limits Transfer Protocol is used to transfer limits on courses to the host.
The packet sequence for the Course Limits Transfer Protocol is shown below:
| N | 方向 | パケット ID | パケットデータ型 |
|---|---|---|---|
| 0 | Host to Device | Pid_Command_Data | Command_Id_Type |
| 1 | Device to Host | Pid_Course_Limits | <D0> |
The Command_Id_Type value contained in Packet 0 is Cmnd_Transfer_Course_Limits. Packet 1 contains the course limits, which are provided in device-specific data type <D0>.