ヤマガタンver9 > GPSロガー＞GT-730F(L)購入

　SkyTraq製のチップを使用した台湾のCanMore社製のGPSロガーGT-730F(L)を購入しました。
　このロガーに使用されている「Venus 5」というチップは、衛星の初期捕捉時間(TTFFと言われる)を短縮する「A-GPS」がサポートされており、その効果を試してみたいと思っておりました。

　形状はUSBドングル型。通常の携帯型ロガーとは違い、電池が内蔵されておらず、外部にUSB電源を用意する必要がありますので、携帯での利用にはあまりお勧めできませんが、車にUSB電源を付けてドライブのログような使用方法では問題ないと思います。


注）
　全く同じ外観でログ機能を持たない「GT-730F」という型番の「レシーバ」も販売されています。(秋月の「GPSstickも同様」)
　ログ機能が必要な方は、型番に「(L)」が付いた物をお求め下さい。

注2)
　いつの頃からか、GPSチップセットが「Venus 5」から「Venes 6」に変更されているようです。(型番は変更なし。本体の外観では区別がつかないと思います。パッケージにｃｈ数が記述してありますが、あまりあてにならないようで・・・(65chのパッケージの「Venus 5」機もあったようですので。)
　SkyTraqのGPS Viewerツールの「Query Software Version」の結果にて確認できるかも知れません。

　ネット上の情報を総合すると、「Venus 6」機は消費電流が低減、トンネル通過後の再補足性アップ(というか、「Venus 5」機がおかしいと思いますが。)しているようです。

　なお電池内蔵の後継機GT-730FL-Sは「Venus 6」機のようです。


　という訳で私が持っているものは「Venus 5」機であり、当サイトの情報は基本的に「Venus 5」機のものです。
　ただし、SkyTraqチップ共通の内容も含まれ、GT-730F(L)の他に、GT-730FL-S(「PhotoTrackr Mini DPL900」,「F-GFL100」),GP-101等の後継機にも関係する内容があります。

　GPSにより位置を特定する場合、GPSレシーバが衛星の位置・軌道を知っている必要があります。
　しかし電源を入れた直後はレシーバがこの情報を持っていない為に、GPSの電波に乗せられてくる情報を受信する事になります。
　しかしそのデータの伝送速度はわずか50BPS。位置を特定する為に最低必要な1.5KBのデータを受信するには30秒要してしまいます。しかもその間に電波が途絶えてしまえばさらに30秒要してしまいます。

　従って地下や屋内の駐車場から出発する場合、駐車場から出て衛星が受信できる状態になってからしばらくたたないと位置が特定できない事になり
　特にビルが多い都市部や森の中などで受信状況が悪い場合はこの情報が完全なデータがなかなか得られず、いつまでたっても位置の算出が出来ない状態になってしまいます。

　しかも衛星の軌道は刻々と変化する為、その情報には「有効期間」が設けられており、通常は4時間とのこと。レシーバの電源が入っていれば情報は「更新」されていきますが、電源切って4時間経過してしまえば、また新たに30秒待って情報を得直さなければなりません。

　このGPSのレシーバの電源を入れてから位置を特定可能になるまでの時間が初期捕捉時間(TTFF，time-to-first-fix)と言われ、その短縮が課題となっています。


　その不便を軽減する為に開発されたのがA-GPS(Assisted GPS)システムで、
・衛星の位置・軌道情報をインターネット経由で提供(Online AGPS)
・衛星の位置・軌道情報を計算で算出する為の情報を提供(Offline AGPS)
等の方法で、刻々と変化する衛星の位置情報または位置を算出する為の情報をインターネット経由で提供する事で、初期捕捉時間を短縮しようというもので、GPSチップ／装置メーカー数社から同様なシステムが提供されているようです。

　Globallocate社：LTO


　SiRF社：SiRFInstantFix

　u-blox社：uBlox AssistNow Offline
http://www.u-blox.com/services/index.html


　SkyTraq社：AGPS
http://www.skytraq.com.tw/news20070410.htm

　Nemerix社：Nemerix's NeX

　Qualcomm社：gpsOneXTRA


　前者は電源投入時にネットワークにオンラインでなければ恩恵を受けにくい方法ですが、後者の「位置・軌道情報を計算で算出」する方法の場合、一度ダウンロードすれば7日から14日程度の効果が期待(ただしダウンロードから時間がたつにつれ精度が低下)されます。

余談）
海外のサイトの本製品情報を見ると、下記のような表記がなされています。
＞Supports A-GPS (aka Assisted GPS),
　この中で「aka」って何だろう？って最初思ったのですが、yahoo翻訳で翻訳した文面みて納得。「別名」と言った意味なんですね。


本項の参考情報）
GpsPasSion Forums
Offline AGPS - InstantFix / Skytraq / gpsOneXTRA
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=47602

　慣れないせいかツールがいまいち使いにくくて・・・(複数のツールがあって、それを使い分けないといけないようでちょっと面倒ですね。)
　最初AGPS無しで測位開始したら、衛星配置のせいか最初自宅から数百m離れた位置を示し、高度も出ず・・・しばらくしたらだんだん本来の位置に戻ってきました。
　位置ズレが大きかったのでNMEAモニタで衛星配置チェックしてしまいましたが、やはり南側に偏ってました。


　LEDの点灯−点滅の関係がRGM-3800と逆なので戸惑いそう。

　その後、AGPSデータダウンロードし部屋の中に置いてみましたが、さすがにFIXしないようです。RGM-3800だと室内でも拾ってしまうのですけど、そこまでは感度良くないようで・・・

　USBドングル型で電池が内蔵されていないので、単独でログを取る場合には別にUSB電源を用意する必要があります。
　手持ちにそのような電源がないので、地元のセブンイレブンで格安で売られていた携帯電話用の充電器(TOPLAND製PDC用，単三2本使用電池交換可能タイプ，オキシライド電池付き)にUSBコネクタ付けてみました。

　ある方が実際に使用してみたら電池が予想より持たないとの事で消費電流を測定してみたらいやに大きいという事でしたので、私も測定してみました。

　その結果・・・

電源をUSB直結での測定で・・・
fixしない状態で約200mA
fix後130〜140mA(LEDの点滅で変化？)
という具合で、カタログスペック(42mA以下)の3倍以上とだいぶかけ離れていました。

　電圧はまず5Vで測定し、その後4V,6Vとチェックしましたが電流はあまり変わりませんでしたので、内部の電源回路はシリーズレギュレータなのでしょうか。

　USBコネクタを付けた携帯電話用充電器を電源にログを取っていると充電器もロガー本体もいやに温まるな・・・とは思っていたのですが、こういう事だったのですね。

その後充電器の電池側の電流を測定してみました。
その結果、NiMH電池動作(電圧2.4V・・・実測していませんが)において、
fixしない状態で約550mA
fix後330〜360mA位といったところでした。


　単三のNiMH電池(2300mAh)2本で10時間は楽に持つだろうと見込んでいたのですが、これではNiMH4本直列したものを直結しないと時間持ちそうにないです。

　それにしてもカタログ表記、かなりいい加減です。包装箱との表記にも違いあるし・・・
　チャンネル数
　　SkyTraqの「Venus 5」のデータシートでは44ch
　　ロガーのカタログスペックは54ch
　　包装箱には65chの文字まで・・・

　消費電流
　　前述の通り

　ログポイント数
　　メモリ容量8MB，1ポイント辺り16byteとある一方、Waypoint1000000point，
　　包装箱には256000RECORDSの表記があるし・・・

11/7追記＞CanMore社のページ見てみたら・・・2MBの仕様のものがあるようで、それが256000RECORDSなのかも？
→後継？のVenus6機の仕様かも？

写真は包装箱の裏側

　説明書の体系が非常に判りにくいですので、整理してみました。
　注）(GPSDGPS: )とあるのは、GPSDGPS社サイトでのファイル名。
　　　(CanMore: )とあるのは、CanMore社サイトでのファイル名。

GT-730F_DataSheet.pdf
(Canmore:D00000012_02.pdf)
　レシーバの仕様書

GT-730F_L_DataSheet.pdf
(CanMore:D00000037_02.pdf)
(GPSDGPS:cammore_gt730f_ce_081009.pdf)
　ロガーの仕様書


GT-730F_UM.pdf(ロガー／レシーバ共通)
(CanMore:D00000012_00.pdf)
(GPSDGPS:cammore_gt730f_mj_081009.pdf・・・日本語版)
　　レシーバ／ロガーの基本的取扱を示したもので、
　　「レシーバ」のマニュアルとして公開されている事が多いですが、
　ハード的な取扱に関してはロガーも共通でこちらを参照する事になるようです。


GT-730F_L_UM.pdf(ロガー専用)
(CanMore:D00000037_00.pdf)
(GPSDGPS:cammore_gt730f_me_tagger_081009.pdf)
　　ロガーのマニュアルというよりは、PhotoTaggerの説明書です。
　　ツールのインストール方法，ロガーからデータを読み込む方法，
　ロガーの設定(仮想USBの通信方法，ログ条件，フルメモリ時の動作指定），
　photoTagging方法,ログデータのエクスポート(NMEA,KMZ,CSV)方法,
　グラフ表示，トラック編集，オプション設定(単位系，トラック分離条件，
　PhotoTagging時のTimezone,他)等


AGPS_User_Manual.pdf(ロガー／レシーバ共通)
(GPSDGPS:cammore_gt730f_mj_agps_081009.pdf・・・日本語版)
　　AGPS設定についての説明書
　　　AGPSツールによる設定方法と、GPS_Viewerによる設定方法が記載して
　　あります。


GPS_Viewer_User_Manual.pdf(ロガー／レシーバ共通)
GPS_Viewerの説明書です。

　GT-730F(L)に使用するツール、こちらもわかりにくいのでざっとまとめてみました。

１．USBドライバ
　PL-2303用の仮想シリアルドライバです。
　　RGM-3800のものがそのまま使用出来ています。


２．GPS PhotoTagger(ロガー専用ツール)
　GT-730F(L)用のツールで、ログ条件設定，写真データへの対応付け，
ログ読み込み＆管理，NMEAやKMZ等へのデータ変換が可能。
　GPSとの接続は38400BPS固定なので注意。
　Google map対応でネットにオンラインならば地図が出ます。
　速度・標高のグラフ表示可能。
　インストール直後はシリアルNoを要求されます。

　このツールですが、iTravel Techという会社に製作を依頼したツールのようです。
　他社チップ/GPSロガーメーカーでも、「PhotoTagger」がツールとしてバンドルされている機器が見られます。
(機器とのインターフェース部分は機器毎で異なると思いますので、相互間の使用は不可だと思います。)

３．GPS_Viewer(ロガー/レシーバ共通ツール)
SkyTraq製NMEAモニタで、ロガーへのA-GPS設定対応。
　　一般のNMEAモニタの場合、SNR表示グラフの受信chは動的に変化しますが、
　このツールは決まった位置に表示されます。
　　特定の衛星に着目して受信状態を確認する場合には有効かと思います。
　　またこのツールで見ると、ログ条件の「上限」の設定も確認出来ます。

　　NMEA出力(g-mouse)の設定，TTFFや2DRMS測定機能あり。
　　このツールで仮想USBの伝送速度変更が可能。
　　データのダウンロード機能あるようだが、専用フォーマット(内部形式？)での
出力のみ？NMEA出力は不可。
＜追加＞→2008.12.12付の書き込みに、他フォーマットへの変換方法記述しました。

　　衛星位置表示部の地図、台湾が中心だけど変更出来ないのかなぁ・・・
　なお本ツールはチップメーカーであるSkyTraq製だと思います。


４．AGPSツール(ロガー/レシーバ共通ツール)
　AGPSデータダウンロード／ロガー(レシーバ)への設定用専用ツール
　本ツールの機能はGPS_Viewerでもサポートされているようなので、特に使用しなくても良いかも？
　なお本ツールはチップメーカーであるSkyTraq製だと思います。


５．その他使用可能なGPS用ツール
　NMEAモニタ
　　38400BPS設定可能なツールであれば大抵大丈夫かと思います。

　地図ソフト
　　カシミール3Dはリアルナビ，NMEAファイル読み込み共OK。
　　　ただしNMEAファイル読み込み時は「衛星の受信状態」のチェックを外す必要があるようです。

実績のある？RGM-3800と速度データの比較をしてみましたが、ほぼピッタリです。
グラフはJR米坂線　羽前椿−米沢駅間を往復した時のもの。

割と素直なデータです。WPL-1000のようなノイズが無くてよかった・・・
ただし内部処理が1km/h単位で行われているようなので、拡大すると波形がカクカクします。

また減速し停止寸前で少々あばれが大きく出るようですが、ホームの屋根の影響で電波が乱れるせいかも知れません。

GT-730Fを使用されている方のサイトに分解した写真が掲載されているのを見て私も開けてみました。
黒いカバー部分がボディの爪にはめ込んであるだけのようですね。

使用されているICは下記
Baseband：SkyTraQ Venus521c
RF Front End： SiGe Semiconductor SE4110L
Flash:SST 25VF016B 16Mbit(2MByte)　　下記へ
USB-Sirial:PL-2303HX

あれっ？メモリ8Mbyteじゃなかったの？
　データシートの表記(下記)、計算合わないなぁと思っていたのですが・・・
＞8M Bytes flash memory for data logging, with 16
＞bytes binary data per record that stores up to
＞1,000,000 data records
　これで計算合いました。でも納得できないなぁ。

→11/14注：ん？合ってねぇじゃん！
　(実際・・・1秒間隔で取ったトータル29時間程のログ(約100kPoint))で容量36%越えてます。
→この割合でいくとトータルのログポイント数は290kPoint程度にしかならないのですが。)

→2010/1/9注：ログポイント数の問題は、後に登場する
SKYTRAQの「Application Note AN0008
Data Logging Extension
For Venus 6(5) GPS Receiver」 で疑問解決しています。
記録は、フルフォーマットで18byte/point，コンパクトフォーマットで8byte/pointとなっているのですが、フルフォーマットで記録されるのは特定の条件の場合だけで、ほとんどの場合コンパクトフォーマットでの記録となる事から、8byte/pointで計算してｏｋ。
メモリ容量が2MBなので約256Kpointとなります。

要はCanMoreのデータシートの
＞16bytes binary data per record
という表記がでたらめ。


それと・・・Venus521cのデータシートに感度等書いてありますが、これってSiGe製のGPS Front Endのチップの特性が一番効いていると思うんですけど・・・


11/13追加＞
内部の概略部品配置，ブロック図を書いてみました。

また使用しているICのデータシートの消費電流を確認し、トータルの消費電流を見積もってみました。

Venus521c max20mA @2.97-3.63V
SE4110L 10mA+8mA(LNA) @2.7-3.3V
25VF016B 〜30mA @2.7-3.6V
PL-2303HX max25mA
※PL-2303HX　onchipのレギュレータは使用していないかも？(GT-730Fの電圧範囲がPL-2303の最大範囲を逸脱しているので。)

ここまで単純に合計して90mA強、「レシーバ」だとしてメモリ分除いて60mA。
max値での計算なので、ここまでは流れないとは思いますが・・・これ以外に何処でそんなに喰っているのでしょうね。

＜10/12/17追加＞
PL-2303ですが、QFN32というパッケージの物が入っています。
"PL-2303HXD"で検索して引っかかるデータシートにQFNタイプのものも掲載されています。
(PL-2303の古いデータシートにはSSOPパッケージのものだけしか掲載されていないようです。)

なお、Exposed Padといわれる、パッケージの「腹」の部分が放熱の為に露出しているパッケージです。
GPSを認識しなくなったので、PL-2303だけ取り外して流用しよう・・・なんて書き込みを見かけましたが、リフロー炉でもないと取り外すのは困難かと・・・
＜追加おわり＞

あまりにも消費電流が多かったので、長時間ログに対応すべく電池ボックス直結タイプを製作しました。

ダイソーで買ったケースの中に単三×3本の電池ボックスを入れ、別の100均で買ったUSB延長ケーブルを切断、メス側をバラして電池ボックスと直結し、ロガーもケースの中に入れて一体化。
(こんな面倒な事するのなら、普通の電池仕様のロガー買ったほうがいいですね。)

とりあえず、これなら電流は130mA程度で、10時間は行けると思うけど・・・

本当なら4本の電池ボックスを使用し、NiMH仕様にしたかったのだけど、田舎のホームセンターに平型の4本の電池ボックスがなかったのと、NiMH電池を使用する場合はショート対策考えないといけなかったので、とりあえずこんな形にしてます。


追加＞
あまり容量が多くないという「トライアル」の格安アルカリ電池で試してみたら、12時間連続ログ出来てます。
この位だとちょっとした旅にはなんとか対応できそうです。

追加２＞
アルカリ電池で使用する場合、あえて４本にする必要はないと思います。
というのも・・・「消費電流がいやに大きい」の書き込み内に書いたように、電圧変えても消費電流があまり変わらないからです。
つまり必要以上に電圧上げてもエネルギー効率が低下するだけですので、もったいないです。

ただしNiMH電池の場合は、3本では電圧が不足する(仕様外)ので、4本必要かと思います。

3連休中に新幹線で東京まで行きました。

手持ちのロガー総動員で？ログを取っており、ログを比較しました。
グラフは郡山〜宇都宮間の軌跡と、福島〜大宮間の速度カーブです。

米沢から福島間の峠区間や、福島から郡山までの間は長いトンネルもありますが、トンネル出た後もログ再開していました。
しかし、郡山から宇都宮間ではトンネル越えしているうちにトンネル抜けてもロストしたままになり(ログを「カシミール」に読ませて地図と照合したところ、新白河駅手前の大崎トンネルからロスト)、その後矢板市付近で一度捉えるもののトンネルで再びロスト、その後ログが復帰したのは宇都宮到着直前位(速度が50km/h位まで落ちた頃)でした。
(速度カーブ描かせたら、停車時の減速のカーブが一部出てきました。)

郡山から宇都宮間の所要時間約30分のうち15分以上はロストしていた感じです。

GT-730Fは先に紹介した電池ボックスを接続し、RGM-3800，WPL-1000と共にポシェットに押し込み、車両の窓かまちに置いてログを取っています。
通路側座席の座席テーブルに置いたPSPでさえも(あちこち抜けてますが)これだけログが取れているのに・・・窓際に置いたのにこの状態です。

いままでのログ比較からトンネル通過後のログ再開がRGM-3800より遅れる傾向があるのを確認していましたが、これほど長い距離(時間)をロストしたままというのは初めてでした。

400系「つばさ」なので最高速度は240km/h。最近の車両と比べると最高速度は低いですが・・・これでも速いというのか？
ちなみに上京の時は、福島駅での併合トラブルにより30分ほど遅れての単独運転でしたが、「回復運転」の様子もなく235km/h位(ログデータ解析)で流している感じでした。
(いや、普通なら「のこぎり」運転なので、がんばって？この速度を維持していたのかも。)


帰りは、東京駅の構内で長時間待った後で、しかも通路側の座席だったもので窓際に置けませんでしたので、ボロボロ。
GT-730Fは途中(郡山過ぎてから！)でデッキに行って窓に密着させるまではロストしたままでした。
RGM-3800はバッテリ切れを恐れて東京駅で電池交換したのがまずかったようで・・・しばらくロスト。それでも久喜市付近で衛星捉えてました。
WPL-1000は東京駅に入る前に衛星捕捉し、その後も電池交換せずそのままだったので、大宮到着する頃にはなんとか衛星捉えてました。


さて今回の旅は、ログ取りがメインではないので都心ではログ取り優先の行動はしていません。
したがって地下街や地下鉄乗車も普通に行い，建物の中などでロストしている時間が長い位。
高層ビルが乱立する中のGPSでのログ取りが難しい事も実感した旅でした。

サンシャイン60や東京タワーのエレベータのログが取れていたら面白かったのですが・・・建物の中のサンシャイン６０はともかく、東京タワーもロストで残念。



注)
もしこのロガーを使用し新幹線や航空機のログを取る場合、GPSViwerにてログ条件のmaxspeed設定を事前に変更しておく必要があります。
初期状態ではログの上限速度が100km/hとなっており、それを越える速度になるとログされないはず。
「Photo tagger」では速度の下限は設定できるものの、上限の変更が出来ないようです。

ロガーを接続しGPSViwerを起動しコネクト
DataLog→Log Statusで現在の設定状態を確認し、
DataLog→Log Configure　でmax_speedを変更。
(とりあえず1000位で良いかと・・・)

現在このような設定にしています。
max T:3600,min T:1
max D:1000,min D:0
max V:1000,min V:0
Datalog:Enable

重いのはロガーの重量ではありません。
ログをロガーからダウンロードする「PhotoTagger」の動作です。

ロガーを接続し「ログの読み込み」操作を行うと、固まってしまったか？と思う位の時間がかかります。
使っているパソコンが遅い(mobileP3-1GHz)という理由もないわけではありませんが・・・
同じ環境で使用し、同じくシリアル-USB経由で通信しているRGM-3800と比べるとかなり見劣りします。

その理由として、下記２つ＋αがあるようです。

１．ロガーとの通信速度が38.4kBPS(RGM-3800は115.2kBPS)
　同じ容量を伝送するのであれば単純に3倍時間がかかる事になります。

２．GT-730F(L)はログをダウンロードする場合、メモリ上のログ全てを落とす。
　これは、通信速度問題より一番効いていると思います。
　RGM-3800はロガーメモリ内のリストを最初表示し、その中から必要なログを選択してダウンロードする方式ですので、必要なログの分しか通信しません。

３．LANが接続されている環境では、GoogleMapとの連携機能が働き、その分処理が増える。
　地図上に表示してくれるのはわかりやすく便利なのは認めないわけではないですが、メモリ上のログ全てを一気に表示しようとしますので、回線が細い場合は処理に必要以上に時間かかってしまいます。
(RGM-3800はツール自体にはこのような機能がありません。
・・・リンクして動作する別ツールはあります。)

　必要なログを選択しそれだけ表示するほうが処理が軽いのでしょうけど・・・
(設定で切換できればいいのに。)


対応策
　このロガーは必要以上にログを残したままにしないほうが良いようです。
　また地図での確認が不要の場合は、LANに接続しないでツールを起動したほうが良いようです。(幸い、ノートPCに無線LANカードさしてネット接続してますので、カード挿さなければオフライン！)

GT-730F(L)の購入のきっかけとして「A-GPSがサポートされており、その効果を試してみたい」と最初に書き、さらにはA-GPSの説明まで書いておきながら、実際の効果について触れていませんでしたね。

A-GPSデータ有効な状態で、屋外で電源入れると10秒前後で捕捉してくれるようです。


昨日「ログ」取るのに久しぶりに電源入れてみましたが、しばらくA-GPSのデータ落としてなかったのでA-GPSのデータ期限が切れた状態のはず。
屋外で電源入れるものの測位開始表示(LED点滅開始)まで40秒位かかったでしょうか。(時計見て計ったわけではなく、自分で数えて・・・のおおよその時間ですが)

やはりA-GPSの効果大です。

そういえば・・・PIONEERのカーナビ「AVIC-T10」のウリは通信機能。
でもA-GPSまではサポートしてないよね・・・
メーカーに要望書こうかな？
(もっとも、通信ユニットまで買ってませんが。)

　下記センテンスがPhoto taggerによるNMEA変換で出力されるようです。

　GPGGA
　　クオリティの項が2にならないので、MSASは非対応？(設定があるのかも？)
　ジオイド高の項は0、標高の項はジオイド高が考慮されていない「楕円体高」のようです。
(2009年5月1日修正・・・「標高」だと思っていましたが勘違いでした。)
　・・・g-mouseモードではNMEAの定義通り「標高」が出力されます。しかし出力されるジオイド高は他社のレシーバ／ロガーとは異なっています。

　GPRMC
　　速度はNMEAフォーマットの通りのノット単位で出力されますが、内部処理はkm/hのようで、1.852倍すると1km単位の区切のいい数字(誤差による端数分は除く)になります。
　　進行方向のデータも出てきます。

追加＞速度情報ですが、ある程度の速度で移動中のログにもかかわらず突然"0"が出力される事があるようです。
同じ位置が連続で測定されているわけではないようですので、バグなのかも知れません。
追加終わり。

　GPGSA
　　受信衛星Noは非出力(ヌル)，PDOP,HDOP，VDOPは0固定のようです。

　ログ開始時の日時が不正な値になる事があるとの情報があったが、現象が発生したので紹介する。

・発生した状況
　連続してログしていた最中、建物の中に入りロスト状態となった。
　その後外に出たものの、しばらくしてからロストしたまま(LEDが点灯したまま)になっていた事に気が付き、電源を再投入しログを継続させました。
　帰宅後Photo taggerにてログを出力させてみると、電源を再投入した以降のログの「軌跡名」の日付がおかしくなっている事に気が付いた。
　出力されたログ(NMEA)を見てみると、最初の3点分が日付が飛んでおり、位置はロスト前のログの最後の値と一致していた。

・ロスト前後のデータ
　GPS Viewerにてログを出力(手順は下記参照)させるとメモリ上のログがすべて出力される事がわかり、それを使って出力したロスト前後のログが図のデータである。
("logg"データにて)

　このように日付が飛んでいる。しかし時刻はロスト直前の値に近い。(若干戻っている？)また位置情報はロスト直前の値を保持している感じであった。
(同じ時刻のデータと合致？)


・GPS Viewerでのログ出力手順
１．DataLog＞Log Read　でログをロガーから読み出しファイル化。(バイナリ形式？)
２．DataLog＞Log Decompress　で、Log Readで保存された ログデータを解凍
(テキスト(.logg)，kml(.kml)，nmea(.nmea,RMCのみ)が出力される。
ただしNMEAのRMC出力はバグっているのか、値がおかしいようです。)

＜追加＞
表の最初の「WNO」「TOW」の値が不明、と書いてしまいましたが、GPSの基本である「週番号」と週内の経過時刻である事が判明しました。
WNO:Week Number
TOW:Time of Week

(西暦2000年問題の時に一緒に騒がれていた「GPSの週番号のロールオーバー」の正体です！)
詳細は、GPS+「週番号」や「ロールオーバー」等で検索すると関連情報が出てくると思います。

なおWNOですが、ロールオーバーを考慮した1024週以降の値が出力されています。
次回のロールオーバーが発生する2019年4月7日、2048週以降の値になってくれるのかはわかりませんが・・・

今までは秋月ではレシーバ版のみの取り扱いでしたが、ロガー版の取り扱いを開始したようです。
しかもUSB電池ボックスを付けてくれるようです。
入手しやすくなりましたね。

電源投入直後の挙動を確認する為、生(LIVEな)NMEAデータの確認及びLOGデータとの比較を行なってみました。

注)実験回数が少ないので、必ずこのようになるとは限らないかも知れません。


実験環境
　LOGTOOL:SkyTraq
　A-GPS有効(残り8h)→翌日期限切れ状態で再実験
　電源切断後1日以上経過(エフェメリスが期限切れ状態)
　最初30秒程は缶に入れ電波を遮断


１．測位時刻出力の挙動
　生NMEA出力による測位時刻の確認結果

1-1.初期時刻
　日時090107 0514(UTC)頃より出力開始
　(実時刻 090707 1024(UTC)頃

・・・前回使用時最後　090106 0726頃
　(22時間程カウントしSTOP？)　挙動未確認


→翌日同様に確認(AGPS期限切れ)
　初期時刻
　日時060628 115953(UTC)・・・大幅に違う？(RTCはバックアップされない？)
　(実時刻 090708 1039(UTC)頃


1-2.捕捉時の変化
　衛星捕捉(GGA 受信クオリティが0から1に変化した時刻)の2点前から
測位時刻が実時刻に補正(但し秒未満は非出力)され、1になった時点から
秒以下の値が出力。

051525
051526
102504
102505
102506.831 ←ここからquality=1(単独測位)
102507.831


２．生NMEA出力とLOG出力との比較

2-1.捕捉開始とLOG開始
　生NMEAでの捕捉時刻:102506.83(UTC)
　LOG出力開始時刻:102510(UTC)
　　捕捉後約3秒後からLOG開始
　　(翌日の実験では捕捉後からだいぶ経過してLOGが開始)


2-2.衛星ロスト時の挙動
　生NMEAでのロスト:102521.83〜102532.83(UTC)
　LOG欠落:102523〜102535(UTC)
　　約1.2秒遅れ？


2-3.同位置ポイントでの測位時刻比較
　同じ位置に対する測位時刻の差
　　生NMEA　　　　LOG
　　102508.83　→　102510　約1.2秒の差
　　(LOST時の挙動と同じ)



３．その他気が付いた事

　衛星LOST時の生NMEA出力の挙動

　　・位置はLOST直前の値を保持　(この処理は好ましい)

　　・衛星LOSTしている間、標高出力のジオイド補正が無くなる。
　　　(「ジオイド高」も0になる。)
　　　　位置情報は保持しているのに・・・
　　→翌日の実験ではジオイド高出力(AGPS期限切れと関係あり？)


　　・GGA&GSA:LOSTしているのにDOP値が直前の値を出力したまま

　　・GSV:仰角，方位が"0"出力なのに、SNR値は残っている。(GSAもヌル)


注）生NMEAを取ったり地図アプリを動作させたりする場合、PC直結だとPCから発生するノイズの影響を受ける場合があります。
(Viewerでモニタした時SNRのグラフがあまり高くならない場合や衛星をなかなか捕捉しない場合はノイズの影響の可能性大。)
　USB延長ケーブルを使用して、PCより離したほうが良いでしょう。(伝送速度が遅いのでUSB1.1仕様の古いケーブルで十分。私は100均で購入したケーブルを使用してます。)

生ログ出力取った際に電源投入直後の初期時刻がおかしい事に気が付き、内蔵のボタン電池の寿命を疑い、さきほど電圧計ったら0.6V程しかありませんでした。

リードの付いたこのサイズのボタン電池など持っているはずもなくどうしようかと思いましたが・・・
USBに電源加えてみると2.7V位になります。もしや二次電池？

電池には「MS621FE Japan」という刻印があります。
台湾メーカーの製品なのに、わざわざ日本製の電池？と思い、型番で調べてみると、案の定、セイコーインスツル製のリチウム二次電池と判明。
容量は5.5mAhとの事。

ただしサイクル寿命が100%充放電だとわずか100回のようです。
(20%なら1000回)
これだと、長時間未使用の後、がっつりログ　という使い方繰り返すとあっという間に電池が寿命迎えそうです。

本ロガーでの充放電特性を確認しておく必要がありそうです。

追加＞
充放電特性、さらっと見てみました。
一応パソコンに接続しての確認です。

初期電圧は0.8V程。(放電具合で異なると思います。)
パソコンを接続すると10秒程で2.7V位まで上昇
その後は微増する程度で、5分経過後で2.8V位。
(充電電流が不明なので、どの位の容量が充電されているかは不明)

ここから放電。(放電電流は不明)
1分経過2.34V
2分経過2.27V
3分経過2.21V
4分経過2.16V
5分経過2.12V
10分経過1.86V
15分経過1.61V
20分経過1.41V

という具合で、5分程の充電ではあっという間に電圧が低下する感じでした。

さらに時間を追ってデータアップ、また充電時間！20分でも確認してみました。
バックアップ(RTCの動作)がどこまで電圧が低下しても機能するのかはわかりませんが、
仮に1Vまでの電圧低下まで保持するとすると、
5分充電で40分，20分充電で110分程となりました。

ちょっと短い気がします。

ロガーを購入したGPSDGPSのサイトのTOPICSのページに、PhotoMate887を使用して取られた「特急スーパーカムイ」のデータが公開されているのに気が付いた。

KMZ形式のデータと、Photo taggerのデータ形式であるitm形式(プロジェクトファイル)の2種類のデータが公開されている。

このロガーのツールはPhoto tagger。
ものは試しと、itm形式のデータをダウンロードし、GT-730F(L)用のPhoto taggerで読ませてみると、バッチリ読めました。
トラックの保存でNMEAへの変換も問題なし。
いつもの要領でEXCELで速度カーブ出せました。

という訳でロガーの機種が違ってもPhototaggerのitm形式データ(プロジェクトファイル)は互換性があるようです。


ついでに、このデータでPhotoMate887が速度計測に十分使えるロガーである事も確認出来ました。
(GT-730のように内部処理が1km/h単位なんて事もないようですし。)

このロガーのチップは、MTKだと思いましたが、MTK製のチップはM-241等のロガーで使用されている感度面でも定評のある奴です。
このロガーのチップはその後継だと思いますが、A-GPSもサポート。
非常に小型なロガーですので、ちょっと興味が沸いてきました。
MTKチップのロガーには以前から興味があったのですが、M-241は速度がログされないとの事で候補から外れた経緯があります。


ロガーネタから外れますが・・・
「特急スーパーカムイ」速え〜。
線形がいいのでしょうか。
最高速度は同じ130km/hですが、多分在来区間の「つばさ」より速い(平均速度:表定速度が高い)と思います。

ログからすると、この列車は旭川発12時0分、札幌着13時20分の「スーパーカムイ24号」。(3分程遅れての到着のようです。)
旭川〜札幌間の営業キロが約134キロで、奥羽線の福島〜芦沢(新庄駅より2駅福島寄り)間位に相当。
「スーパーカムイ」はそれを80分程で走破しているので、表定速度は約103km/h(3分遅れだと約99km/h。)

対する「つばさ」(同じような時間帯の114号、新庄〜福島間の約149キロ)は約2時間で、表定速度は73km/h程ですので、その差は歴然。
「つばさ」は停車駅多いし、急勾配の板谷峠含まれているというハンデがありますが・・・これはちょっと。

SKYTRAQで検索していたら・・・

１．GT-730Fではないですが、こんな表現が引っかかりました。

＞高作動– 低温/常温/高温開始時間: 35/32/1 秒(平均)
コールド／ウォーム／ホットスタートをそのまま低温／常温／高温と訳すとは、GPSの知識不足のあまりにもお粗末な翻訳ですね。
GPS知らない人が見たら、誤解しそう。

ちなみにメーカーサイト
http://www.sja.com.tw/prog/pro5286S3TH.htm
での表現は・・・
Excellent performance - Cold/Warm/Hot start time: 29/25/1 sec. (average)
(数字が違いますが、先に引っかかったほうはVenus5、こちらはVenus6なので、こちらは後継機。)


２．とある大手検索サイト、今まで繰り返し「SKYTRAQ」で検索かけてますが、いつも「"SKYTRAX" ではありませんか？」と聞いてきて、「SKYTRAQ」というキーワードを登録してくれる気がないようです。
　「"SKYTRAX" ではありません。」と教えてあげたいのに、そんな選択肢ありませんしねぇ。

＜追加＞
　その後、関係者がこの書き込みを見たのかは解りませんが、「SKYTRAQ」というキーワードを登録してくれたようで、SKYTRAX" ではありませんか？」と聞いてきいてこなくなりました。
良かった良かった？
＜追加終わり＞と思ったけど、やっぱり直っていませんでした。

検索ネタでもう一件。

Photo Taggerの開発元「iTravel-Tech」で検索して見ると・・・
＞「パーソナルポケットナビ Navi Stick」の製造元判明！
という書き込みが引っかかります。
この方、「iTravel-Tech」が製造元と勘違いされているようですが、「iTravel-Tech」はロガーまで作っていないと思います。
「Navi Stick」の製造元は、やはり先のリンクと同じ。
(Sheng Jay Automation TechnologiesのSkytraq機)

先日ログしたデータを解析してみたのですが、他のロガーのデータと比べると標高が数十ｍ程高めに出ているのです。
どうも、以前のRGM-3800のようにジオイド高が正しく反映されていないような気がするのですが・・・

カシミールでグラフ化してみるとこんな感じになりました。


＜'09/11/1訂正＞
これ、悪いのは「PhotoTagger」のNMEA変換のようです。

'09/10/7付けの書き込み
「Application Note AN0008」にあるように、SkyTraqチップのログはECEF座標のみ。

ログ読み込みのアプリ側にジオイド高のテーブルが無ければ標高は得られない事になります。

＜訂正おわり＞

先日、地元路線でトロッコ列車が走るというので乗ってきましたが、そのログを処理したら、GT-730Fの速度情報がいやにあばれてました。
走行中のログなのに、速度が時々0になる現象は今までもありましたが、今回はそれが酷いのです。
(グラフ上参照)

そこでRGM-3800のログと比較してみました。
同じ時刻の位置どうし、ログの示す位置の距離を計算させてみると、最大120m程の差があり、その差が変化するのです。
(下のグラフ参照)

こういう場合、一番疑わしいのが、衛星配置と受信状態ですが、並べて置いてログしてますので極端に違うとは思えないのですが・・・
増して乗っていたのは窓ガラスのないトロッコ列車。新幹線のような2重ガラスと比べたらはるかに受信条件はいいはずで・・・

その差、速度に比例しているのなら、単なるログ時間の遅れ、と理解できるのですが、速度に関係するわけでもなく変化するので訳が判りません。

注)この現象、3時間程の乗車のうち、ある一部区間でのみ発生したもので、全区間がここまで酷いわけではありません。
もしかすると携帯電話の電波の影響もあるかも知れませんが、未確認です。
またこの後続けて6時間近くログを続けていますので、電池の寿命でもないと思います。

その2ヘ続く

そこでWPL-1000を含む3台分の同じ時刻の20秒分の位置データを、excelの「散布図」機能でプロットして比べてみたら・・・

・GT-730Fだけ位置が遅れてます。
位置の差が少ない時刻のログは遅れ時間？が少なく、位置の差が大きい時刻では遅れ時間も大きい。

・RGM-3800やWPL-1000のログは時刻毎の位置がほぼ等間隔に並んでますが、GT-730Fはバラバラ。
プロットが2つ隣り合わせになっているのも・・・

この事から、時間の間隔が等間隔ではなく、バラバラな状態でログされている感じがします。

ログの処理が追い付かなくなる事があるのでしょうか。
(処理した時刻の列車の速度は25km/hすなわち7m/s程度でしたので、120mの遅れは約17秒遅れに相当しますが、あまりにも遅れ過ぎでしょ。)

(注：WPL-1000は3秒毎，GT-730FとRGM-3800は1秒毎ログの設定)

GPSのログの精度は、GPSアンテナの設置方法に左右される可能性があります。

写真は私が列車でログを取る場合の通常のスタイルです。
100均で購入したマグネット付トレーのマグネットを吸盤に変えたもののトレー上に3台のロガーを並べ、吸盤を列車の窓に貼り付けてます。
(GT-730Fではなく、PSP用のレシーバを載せる場合もあり。)

当サイトではこれを「平面配置」スタイルと呼ぶ事にし、特に断りがないデータはこの配置で取ったものです。

写真ではGT-730Fケース内のロガー本体が手前になっていますが、通常は奥側にしています。
WPL-1000が手前にあるのはLCDの表示が確認できるようにする為です。


なお、ロガー同士の干渉が起こる可能性があるかも知れません。
(漏れ電波による干渉)
測定器がないのでそこまで確認できておらず、この距離で並べて大丈夫なのかどうかは何ともいえません。

一人で行動している時は、可能な範囲で最高のログ精度を得る為「平面配置」スタイルですが、他の人と一緒で行動する場合はさすがにそのスタイルでは厳しいです。

ロガー一式を１つのポーチに押し込んだのが、この「ポーチ」スタイルです。
(写真は内容物がわかるよう一部出してますが、実際には全て押し込み、カバーもしてます。)

手持ちのポーチを使用した関係で制約があります。

RGM-3800は横を向いてます。しかしこれでもほぼ完全にログが取れてしまうんですよね・・・

GT-730FはWPL-1000の下になります。GT-730Fのログ異常は、その影響があったのかどうか・・・

ポーチの材質自体が電波を吸収しないか気になるところではありますが、確認していません。
(g-mouseでNMEAモニタで受信状態を確認しつつ、ポーチから出し入れすればわかるかも知れません。)

家族を連れて出かけた時の「新幹線で試してみました」の時がこれです。
(GT-730Fをどちらの方向で押し込んだかは記憶ありません・・・)

GT-730F(L)はカタログスペックより大幅に消費電流が多い という測定結果が、私を含めいくつかのサイトに情報が出ている。

ところが、最近見つけた下記サイトの報告では、ここまで多くない模様。(このサイト、管理人さんの連絡先がないので私のBlogに掲載)
http://netaro.web.fc2.com/gps/gpsdongle.html

最近の製品は改善されたのでしょうか。


さて・・・電圧特性ですが、秋月で購入した際に添付される電池ボックスにはダイオードが入っているとかで、NiMH電池4本使用時に対応させるべくダイオードをショートさせているという記事も見かけました。

対する私の場合単三アルカリ3本。
どの位まで電圧が低下しても捕捉するかという事で、かなり消耗した電池で遊んでますが・・・2.8V位まで低下してもそこそこ拾っている感じです。
(電波状況悪いとはずれ易くなるかも知れませんが。)

USBでPCに接続、電源だけ別の可変出力電源より供給した状態でGPS Viewerでモニタしながら確認したいところですが、今のところそこまで試してません。

電圧低下時の動作確認してみました。

電源だけ別電源から供給するように細工したUSBケーブルを準備し、電源及びパソコン，GT-730F(L)を改造ケーブルで接続、GPS Viewerで受信状態をモニタ(電源ONとうまくタイミング取らないとUSB認識してくれないようです)し、電圧・電流を測定しながら5Vから徐々に電圧を下げていきました。

すると3Vを切ったあたりでGPS Viewerに表示されるNMEAの表示が停止しましたが、GT-730F(L)のLEDは点滅しています。
おそらくGT-730F(L)内のシリアル-USBブリッジPL-2303の動作が停止したものと思われます。
ただ、GPS Viewerに表示されるSNR表示は5V入力時から停止直前までほとんど変化ありませんでしたので、この時点での電圧低下による受信状況の悪化はないようです。

さらに電圧を下げていくと、2.6V位でGT-730F(L)のLEDの点滅が停止しました。
どうもこの辺が動作下限電圧のようです。
ログ確認しましたが、位置が大きくあばれる事もないようでした。


注）実際電池で運用していると、寿命末期で電圧が低下してくるとログがいきなりあばれ出します。
LEDが極端に暗くなってきたら(極端ってどれ位？)電池を交換したほうが良いです。


再現性が低いのですが、面白い挙動もありました。
3.6〜3.7V付近でですが、電流が70〜80mAまで減少する場合がありました。
この現象、必ず発生するわけでもなく、また電圧がこれ以下になっても普通(130〜140mA)のレベルに戻りますので、何が起こっているのか良くわかりません。



なお回路の抵抗や電圧・電流を測定するテスタの内部抵抗による影響を抑える為、電流は0.1Ωの抵抗の両端の電圧を測定する方法で測定し、電圧はGT-730F(L)側のUSBコネクタ直近で測定しています。
使用した電源ですが、LM317という可変電圧出力の三端子レギュレータを使用したもので、電圧の微調整が出来るよう10回転のポテンショメータにて電圧を調整しています。

A-GPSにより測位開始時間が短縮されているGT-730F(L)ですが、測位開始から位置が安定するまで若干時間が必要です。

g-mouse状態でGPS Viewerに出力されるログを調べると・・・
測位開始から1分程度経たないと「本来の」位置になってくれない感じです。
(内部のbackupバッテリ切れ状態で、時刻が06年06月28日11時59分52秒からスタート　という条件にて。)

特に高度は0mから出力開始され、徐々に本来の高度に近づくような挙動です。

デジタルフィルタ処理により前のデータとの平均化を取っているものと思いますが、その時定数が30秒以上ある感じです。
(要は前のデータ×29/30+最新データ×1/30が出力値　というイメージ)

トンネル通過中や通過後に変なところに飛ぶ事がよくあるGT-730F(L)ですが、以前取ったトンネル通過時のg-mouse出力ログを調べてみました。

その結果、こんな挙動が見えてきました。

・トンネルに入り受信衛星数が0になった後3点ほどデータが出力されるようです。
　ただしGPGGAの「Position Fix Indicator」項は、RGM-3800のように、"6"(「Dead Reckoning Mode」・・・推測航法モード・・・)が出力される事もなく"1"(通常のFIX状態)のまま。
　この3点の位置データは、0になる直前のデータの変化をそのまま直線的に予測したようなデータが出力されているようです。

・トンネル内にもかかわらず、受信衛星数が3以上になっている事があります。
　ノイズになんかで勝手に出力している感じが・・・(こういう時に変な所に飛んでしまうのでしょうね。受信衛星数が0に戻るとそのまま予測出力が3点続いてます。)
　感度ばかり上げたが「トンネル内」(受信不可)の判定がうまく行っていない感じがします。

・RGM-3800の同時刻のログをつき合わせてみる(RGM-3800側はトンネル突入時の「Dead Reckoning Mode」となっているはずの5点のログを差し引いて考え)と・・・
　GT-730Fはトンネルに入り受信衛星数が0になったにもかかわらず(先に判明した3点分の予測ログを除いても)余計なログを吐き続け、トンネルを出た時には再補足が遅れるようです。
　再補足の遅れは、RGM-3800と数秒程度の時もあれば20秒近く遅れる時もあります。どうも短いトンネルを次々と通過するような時に遅れが増えるような・・・

・さらにGT-730F(L)の「ログ」出力を同時刻で比較してみると・・・
　g-mouse出力よりさらに1〜2秒遅れての記録が・・・(なお位置の比較はまだ。)

GPS Viewer(SkyTraq 0.4.223) というツールの詳細マニュアルがないようなので、まとめてみました。（一部推定含む）

　なお、＜＞で囲んだメニューはグレー表示で機能せず(説明も略します)
　またレシーバとの通信が必要なメニューは、コネクト状態にしてから操作する必要があるようです。

File
　Save NMEA NMEAデータのセーブ(ログ)
　Clean NMEA Messageウインドウのクリア
　Exit SkyTraqの終了


Binary
　System Restart リスタート(オプション設定有)
　　　Mode No Change/Hot Start/Warm start/Cold start/Test mode
　　　No Change以外はDate,Time,Positionの初期値？設定可。
　Query Software Version F/Wのバージョン表示
　Query CRC Checksum F/Wのチェックサム表示
　＜Query Datum＞
　Set Factory Default 工場出荷値に設定(初期化，オプション設定有)
　　　No Reboot
　　　Reboot after setting to factory defaults
　Configure Serial Port シリアルポート設定
　Configure NMEA Output NMEA出力設定(出力するセンテンス，周期設定)
　＜Configure Datum＞
　＜Configure DOP Mask＞
　＜Configure Elevation Mask＞
　＜Configure Binary Data＞
　Software Image Download F/Wのアップデート(F/Wのデータ必要)


Ephemeris
　Get Ephemeris EphemerisデータをGPSレシーバより読み込みファイルにセーブ。

　This is a request message which is issued from
GPS receiver to the host to retrieve Ephemeris data.
これは、Ephemerisデータを検索するためにGPSレシーバーからホストまで出される要請メッセージです。

　Set Ephemeris セーブされたEphemerisデータをGPSレシーバに設定


AGPS
　AGPS Configure AGPSの有効/無効切換
　AGPS Status AGPSの設定状況表示(データの有効期間，有効/無効の設定)
　AGPS Download AGPSデータのダウンロード＆GPSレシーバへの設定

DataLog
　Log Read ログデータ読み込み(バイナリ形式？)
　Log Configure ログ条件の設定
　　　　　　　　　　max_time/min_time/max_distance/min_distance/
　　　　　　　　　　max_speed/min_speed/DataLog Disable/Enable
　Log Clear ログのクリア
　Log Status ログ条件設定状態の表示
　Log Decompress ログデータの解凍(Log Readで保存されたデータを
　　　　　　　　　　テキスト(.logg)，kml(.kml)，nmea(.nmea,RMCのみ)
　　　　　　　　　　に変換
Help
　Help SkyTraqツールのバージョン表示

久しぶりにCanmore社のサイトを見に行ったら大幅にリニューアルされていた。
バッテリ内蔵の新製品GT-730FL-Sは置いといて・・・

Downloadのページに置いてあるツールが新しい版に変わっているようだった。

1.PhotoTagger
PhotoTaggerは私が購入した物に添付されていたものはVersion 1.2.2(作成日Jul 23 2008)だったが、今回のはV1.2.3の模様(インストールしていないので詳細未確認)

また従来ロガーとの接続が384kBPS接続用のみだったが、今回4.8kBPS接続用(と思われる)の版が公開されている。(版は同じV1.2.3)

2.Phototracker
　使用していないので詳細不明

3.USB Driver
　ダウンロードしていませんので詳細未確認。(問題ないので必要性を感じていないので)

4.AGPS Manual & Tool
　Bluetooth対応かつVenus6用という事なのかも？
　ただし後述のViewerは旧版？(0.4.223)

5.Configure Serial Port_Baudrate
　Canmoreのサイトにはなかった情報です。
　(アメリカだったかの販売店サイトで同様の情報を見た事があります。)
　このアーカイブの中にViewerの新版(0.4.473)があります。
　詳細は後述

6.Check Data Logger Function
　これも今までなかったように思います。
　ハンドヘルドPC用のViewerツールらしく、XPで起動したらウィンドウのサイズが合いませんでした。


7.Viewer新版について

7-1.バージョン表記は・・・
SkyTraq 0.4.473 (2007/04/19)
・・・(日時はHelpで出てきたバージョン表記のものだが旧版から変わっていない。)

7-2.旧版からのメニュー構成の変更点
　Binary関係が大きく変わってます。
　DataLogは少し変わってました。
　Converter(新設) NMEAデータをKMLや圧縮ログ形式に変換？
　WAAS(新設) WAAS対応のON/OFF設定のようです。

　※Venus6用なのか、Venus5のGT-730F(L)では正常に機能しない
(Queryを表示しようとしても拒否されている感じ)メニューがあるようです。

　※画面下部に「Download」というボタンが追加。
　おそらくSkyTraq 0.4.223のBinaryメニュー下にあった
「Software Image Download」と同じ機能と思われる

7-3.新版0.4.473のメニュー構成
　とりあえずメニューの構成をリストアップしてみました。

File
Save NMEA
Clean NMEA
-------------
Exit

Binary
System Restart
----------------------
Query Software Version
Query CRC Checksum
Query Position Update Rate
Query Datum
Query Position Pinning
Query 1PPS
-----------------------
Set Factory Default
→No Reboot
Rebot after setting to factory default
-----------------------
Configure Serial Port
Configure NMEA Output
Configure Message Type
Configure Binary Message Interval
Configure Position Update Rate
Configure Datum
Configure Power Mode
Configure Position Pinning
Configure Pinning Parameter
Configure 1PPS

Ephemeris
Get Ephemeris
Set Ephemeris

Navigation Mode
Configure Navigation Mode
→Car or 歩行者の選択肢がありました。
(何のパラメータ変えているのでしょう？
フィルタ処理の定数かも？)
Query Navigation Mode


AGPS
AGPS Configure
AGPS Status
AGPS Download

DataLog
Log Configure
Log Clear
Log Status
Log Decompress
Log Read Batch

Converter
Compress (NMEA(TXT) to KML & Compress Log File)
Decompress DataLogメニューの「Log Decompress」と同じ？
Kml (TXT to KML)

WAAS
WAAS Configure
WAAS Status
→Status確認したらEnableでした。やはりMSASは非対応。

Help
Help

GT-730F(L)の電源ですが、当初は携帯電話の充電器の出力にUSBコネクタを接続したものを使用し、その後電池寿命の点から単三電池3本を直結したものに変更した。

最近単三電池2本からUSBコネクタで5Vを出力する物が一部の100円ショップで販売されるようになった。
電池寿命の点では単三電池3本直結以上のものは考えられないが、サイズが非常にコンパクトなので味見として接続実験を行ってみた。

品物は、100円ショップ「シルク」で販売されているエコプラス製「USB充電用電池BOX」EP-024CHA。
(下記アドレスで紹介済)
http://samidare.jp/jr7cwk/lavo.php?p=log&lid=151751

充電直後のNiMH電池を「USB充電用電池BOX」に入れ、GT-730F(L)に接続し電池側にテスタを接続して電流を測定してみた。
(今回の電流測定はテスタの電流レンジ使用なので、電圧降下が大きめである。・・・DC-DCコンバータ負荷なので電流が大きめに測定される可能性がある。)

電池側消費電流測定結果
・FIXしていない状態(LED点灯):450mA(電圧は2.75V)
・FIX状態(LED点滅):300mA前後(時折450mA位まで増加)(電圧は2.6V程度)

　という訳で、2000mAhのNiMHだと電池寿命は6時間程度ではないかと思われる。

　最初に使用したTOPLANDの携帯電話充電器「縦型」
よりは若干変換効率が良いような気がします。

　実は出力電圧をGT-730F(L)の(カタログスペックの)下限電圧である4V位まで電圧を下げられれば、5Vで使用した場合と比べ電池の寿命をもう少し伸ばせるはずなのだが・・・(単純計算で1.2倍)
　残念ながら「USB充電用電池BOX」の出力電圧は5V固定で、内部に使用されているICの設計上電圧を変更する事が出来ない。


という訳で、長旅のログ取りはやはり単三3本が良いようです。

Venus6仕様GT-730F(L)、実在が確認できました。(下記アドレス参照)
http://www.notlogical.net/medio/blog/2009/09/usbgps.html

メーカーのサイトの仕様がいつの頃からかVenus6に変わっていたのですが、「あの」CanMoreだけにサイトの情報、あまり信用してなかったのですが・・・


それにしても外観(微妙には違うのかも知れませんが)も型番も変えずにチップセットが切り替わるなんて、反則です。


以前「消費電流が少なくなった？」という書き込みをしましたが、これもVenus6機なのかも知れません。

ネットで検索していたら、
「Application Note AN0008
Data Logging Extension
For
Venus 6(5) GPS Receiver」
という資料がいくつか引っかかった。

この資料はデータロギングに関するVenusチップの制御方法(ログ条件の設定，ログ読み出し，ログ消去等のコマンド)について記載してある。
(Viewerでのログ読み出しについても触れられてあるようだ。)


引っかかった中では、
「Jan. 05, 2009付 Ver 1.4.11」が、For Venus 6
「Aug. 28, 2007付 Ver 0.4.8」が、For Venus 5
の資料であった。

最終ページに変更の履歴が付いており、Ver 1.4.11の資料の履歴にはVer 0.4.8も含まれている事から、Venus6はVenus5の上位互換の制御体系と思われる。
→資料を比較してみた所、単純な追加ではなく、一部コマンドの変更が見られました。
(ログ読み込みコマンドが変更され、セクタ指定可等。)


Ver 1.4.11資料の最後のほうにフラッシュメモリに記録されるデータログのフォーマットが記載してある。

これを見ると・・・
メモリには下記のようなデータが記録されている。
・データのヘッダー
・速度
・GPS週番号
・GPS週内時刻(絶対時刻orデータ間の差分)
・ECEF座標X,Y,Z(絶対座標orデータ間の差分)

　メモリ使用容量を減らす為か、差分がある条件以下の場合は差分データのみ記録しているようだ。(ヘッダーで区別。フル・フォーマットが18バイト/ポイント，コンパクト・フォーマットは8バイト/ポイント。)

　これを見てもわかるように、「緯度・経度・高度」では記録されておらず、ダウンロードユーティリティで変換を行っている模様。

　各データのデータサイズも記載してあるが・・・
　速度はなんと10bit。つまり、0〜1023km/hの範囲の「整数」しか表現できない事になる。(もしかすると指数形式かも知れないが。)
　ログ情報の「速度」が1km/h単位という背景は、どうもここにありそう。


なお、この資料の他
「Application Note AN0003
Binary Messages
Of
SkyTraq Venus 6 GPS Receiver」
という資料も出くる。
こちらはSkyTraqバイナリフォーマットのデータの説明。

＜10/18追加＞
Application Note AN0011
というのもあるようです。
こちらはAGPS関連のコマンド関係の説明のようです。

Application Note AN0008を見ながらログデータの解析を行ってみた。
Viewerの「Log Read」で読み出して出来た「.LOG」拡張子のファイルはフラッシュメモリに記録されているデータそのもののようであり、AN0008に記載されているデータフォーマットの資料に基づいて「解読」が出来るようだ。
全てのデータの確認は取れていないが、Viewerの「Log Decompress」で出来たECEF_X,Y,Zのデータとの整合が取れた。

さらにECEF_X,Y,Zのデータを緯度・経度・楕円体高の変換を
「独立行政法人　電子航法研究所」サイトの「GPS測位計算プログラム入門」のページ
http://www.enri.go.jp/%7Efks442/K_MUSEN/
にある解説記事
「WGS84と座標変換のはなし」に掲載されている計算式＆プログラムリストを元に、excelのシート上で変換する試みも行い、Viewerが吐き出した緯度・経度・楕円体高との一致も確認できた。

さて・・・この計算の過程でGT-730F(L)がログするECEF_X,Y,Z座標は1m単位である事が確認できた。
要は1mの直方体のメッシュ単位で座標が記録されている事になる。
これは移動方向によっては最悪1.7m単位(1mの直方体の角〜角)のデータしか残っていないという事に・・・
しかも差分形式でデータが記録されているので、処理方法がマズいと端数分の誤差が累積される可能性が・・・

まぁGPSの測位精度を考えれば十分といえば十分なんでしょうけど、せめてあと1bit下位まで(0.5m単位)で記録できれば端数処理による誤差が出にくいのでしょうけど・・・
先の書き込みで「速度も1km/h単位で記録」という事とあわせて考えると、低速度域は苦手という、今までうすうす感じていた事が裏づけられたような気がします。

電池内蔵のGT-730FL-Sの発売に伴い、GT-730F(L)の価格が引き下げられたようですが・・・
本件はVenus6でも同じ仕様のようですから・・・Venus6のロガーに手を出す事はないと思います。

Application Note AN0008を見ながらログデータの解析を行っている時、ふとViewerが吐き出したログデータのWNO(週番号)とTOW(週内時刻)から日時を算出してみた。すると・・・
同じくViewerが吐き出した日時と比較すると13秒の差がある。

これが「うるう秒」の累積によるGPS時刻の差だな・・・なんて思っていたのだが・・・13秒っておかしいような・・・

という訳で購入直後(08年11月1日)に読み出したデータと、最近読み出したデータで同じように算出してみたら、どちらも13秒。
今年の1月1日にうるう秒が入ったので1秒増加し、GPS時刻とUTCの差は15秒のはずなのに・・・単に13秒補正しているだけではないのか？
(というか、ログデータからはWNOとTOWしか得られないので、Viewer側がうるう秒がいつ入ったのかというテーブルを持っていない限り補正しようがないわけで・・・)

Viewerで変換したログとPhototaggerで変換したログは同じ日時を出力します。
つまり・・・どっちもバグってる事に。
現在2秒差のログを出力する事になっているようです。


「生NMEA vs LOG比較」の書き込みで、
＞2-2.衛星ロスト時の挙動
＞2-3.同位置ポイントでの測位時刻比較
ともに1.2秒の差を感じたわけだが、どうもこれが影響していそう。

Viewer新版「SkyTraq 0.4.473」にて変換したLOG(拡張子が".logg"のファイル)には「Mode」という項目が追加されており、1または2のデータが出力されている。
このデータ、最初は衛星の捕捉状況(2D or 3D)なのかと思っていたのだが、Application Note AN0008の記述よりフラッシュメモリに記録されているログデータには捕捉情報が入っていない事が判明し、捕捉情報でない事は明らか。

　データをいろいろ調べてみると、フラッシュメモリに記録された各データが「フル・フォーマット」なのか「コンパクト・フォーマット」(差分情報)なのかを示すデータのようである。
　値が1の時が「フル・フォーマット」，値が2の時が「コンパクト・フォーマット」で記録されたデータを示すようで、「フル・フォーマット」×18byte+「コンパクト・フォーマット」×8byteで計算した値が、フラッシュメモリからダウンロードして出来たログファイル(.log拡張子のファイル)のファイルサイズと一致した。

　さて、この過程で判明した新たな事がいくつか・・・
・「フル・フォーマット」で記録されたデータのDECEF_X DECEF_Y DECEF_Z(ECEF座標の差分)の各データが0となっている事。
・Application Note AN0008にはメモリのセクタをまたがる場合(4096byte毎)は「フル・フォーマット」で記録されるような記述があるが、長いログを調べてみると「フル・フォーマット」で記録されるタイミングが若干ズレてくる模様。
(メモリ上では仕様通りに記録されていて、ログ読み込み時にセクタ間のデータが記録されていない部分が削除されている可能性がないとも言えないが。)

　1m単位で記録されているECEF座標を使用してポイント間の距離計算を行おうというのであれば注意が必要かも知れない。


　それにしても・・・
　ログ動作等で不審点があまりなければ、こんなバグ出しみたいな解析行う必要ないのに・・・
　お陰で・・・GPSのシステム自体含めていろいろ勉強させて頂いてます。(笑)

位置情報から距離を計算したいケースは良くあると思います。
しかし、緯度・経度から距離を計算するのは意外に大変なようです。
計算用のEXCELシートを公開されている方がおられ、私も活用させて頂いています。

ふと、GPS Viewerで変換されたECEF座標のデータを見ていたら、この値だけで距離計算できるのではないか？と思いはじめました。

地点1のECEF座標をX1,Y1,Z1，地点2のECEF座標をX2,Y2,Z2とした場合、地点間の距離Lは下記で求まるはず。

L=SQRT((X1-X2)^2+(Y1-Y2)^2+(Z1-Z2)^2)
(3次元のベクトルの合成？)

この方法でポイント間の距離を計算して3.6倍し、ポイント間の時間(1秒間隔で取得していれば1(衛星ロストしてなければ))で割るとkm/h単位の速度が得られる事になります。
ただしGT-730F(L)(というか、SkyTraq Venus5と6のどちらも)のログ元が1m単位の座標なので、ログとして出力されている速度情報と比較すると差が出てきます。もっともログ出力の速度情報もなんか怪しい時があるので、どっちが本当かわかりませんけど・・・

注)地球の丸い形状を考慮しない直線距離が算出されるはずです。
　地点間が離れている場合はこの計算だけではNGかも。


＜11/1補足＞
GPSでの速度情報が、衛星との見かけ上の移動に伴うドップラー効果による周波数の変化で計測されているかのような書き込みが2chで見られましたが・・・
少なくとも市販のナビやGPSロガー程度のハードウエアに受信周波数の変化を計測するようなハードウエアが積まれているとは考えにくいです。

個々の衛星がバラバラな方向に移動してますので、ドップラー効果で速度計測となると、受信可能な衛星全て(または一部)について計測する事になるはず。
比較的単純な信号ならFFT処理などで周波数を求める事は可能ですが、GPSの場合全く同じ周波数に複数の衛星の信号が送信されています。(厳密にはスペクトル拡散という技術で、衛星毎のコードに従って周波数が変化しているはずですが。)
コードの受信だけならともかく、スペクトル拡散された個々の衛星の周波数の変化を測定するとなると、ただ事ではすまないはずだからです。

FFT処理の場合、サンプリング周波数とサンプル数により周波数分解能が決まるという事情もあり、測定精度面の問題も生ずるはずです。


また、GPSレシーバより直接出力される速度情報の精度と、位置情報から算出される速度情報の精度に差が出るのは・・・
位置情報の出力がレシーバ内部で持っている位置情報より桁が丸められているからと考えるのが妥当です。

おそらくレシーバ内では上記のECEF座標から速度を算出していると考えられますが、ECEF座標を緯度・経度・高度に変換した段階で桁の丸めによる計算誤差が相当入るはず。
しかもシリアルに出力する段階でさらに丸めが入り・・・
(それがログ情報ともなると、ログメモリ容量と記録時間との兼ね合いからさらに桁を丸めて記録されたり・・・)

その位置情報から後処理で速度に変換すると、さらに丸め誤差が入り・・・
誤差が累積し相当大きな誤差になる事が考えられます。

なにせ、1秒毎の位置情報から速度を求めるとして、速度の誤差を±1km/hに収めるには、位置情報の誤差範囲は約0.28m以内のにする必要がありますから・・・
処理段階の丸めや計算誤差による影響は相当効いてくるはずです。
(もちろん、計算の前提である1秒毎、の「1秒」も正しくなれけば誤差につながります。)
＜補足おわり＞

canmore社のサイトで公開されているPhototrackrのdemo版を試用してみました。
バッテリ内蔵の新製品GT-730FL-Sの秋月扱い分のログ処理ソフトとして付属しているのが、このGiSTEQ Phototrackrのようです。

手持ちのGT-730F(L)(Venus5チップ)で試してみましたが、問題なくログの読み込みが可能でした。
(helpファイルに対応機種載ってますが、書いてあるのはVenus6仕様のGT-730F(L)でした。)

ウイザード形式でロガーからのログ読み込みから写真管理までの一連の操作を通して行う機能もあるようです。

読み込んだ結果はPhotoTagger同様、Google Earth上に表示され(上記イメージはネットとオフライン状態で動かした時のものなので地図は出ていません)、NMEA等のファイルにエクスポートする機能があるのも確認しました。
(ログを読み込んだ状態で、写真管理の「旅記録」の画面右に表示されるトラックの一覧上で右クリックすると、エクスポートのメニューが表示されるようです。)

しかも、PhotoTaggerでの変換では「楕円体高」だったGPGGAの「高度」の項が「標高」で出力されるようです。
＜11/2訂正＞
　「高度」よくよく調べるとおかしいです。
　標高約600mの板谷峠を列車で越えた時のログを変換したら・・・400m位の値しか出てきません。
　計算、バグっているようです。
　ネットを調べると「GT-730FL/Sで標高2千数百メートル以上の場所にいたのに1300m位の値しか出なかった・・・」という書き込みを見かけましたが、再現した感じです。
＜訂正終わり＞


本ソフトのログファイルとして.gpsという拡張子のファイルが出来るようですが、テキストエディタで確認したところ、NMEAファイルの先頭になんらかのデータ(内容不明)が付いた内容でした。
＜11/2追加＞
　サンプルデータが入ってましたが、先頭に付くデータにtagというコメントが付いてました。
　ファイル名ですが、先頭1文字が登録したユーザの番号(ドライバーID)で、以下ロガーからダウンロードした日時が付くようです。
＜追加おわり＞

さてインストールする時、「.Net Framework 2.0」のインストールの要求があり、そのD/Lとインストールに結構時間がかかりました。

また使用条件未確認なので、いつまで使えるのか・・・


Phototrackrのマニュアルですが、そのもののファイルはcanmoreのサイトにはないようです(解凍・インストールして初めて出てきます。)が、GisTEQのサイトにありました。
http://www.gisteq.com/program-update.html

インストールする前に機能を確認したい方は、こちらを参照されると良いと思います。
(ただしCanmoreに公開されているものとは若干仕様が異なるようです。)

Phototrackrの試用してみて、いくつか気になった事。

・メニューが日本語なのに、ウィザードやhelpの表示は英文のまま。
　インストールした直後に起動したら、いきなり日本語のメニューで起動しびっくりしたのですが・・・
　残念ながら一連の作業を通して行うウィザードは英文のままでした。
　helpも英文のままで・・・

・長いトンネルを通過する度にログが分断
　長いトンネルなど、電波が遮断された時間が長いとログが分断されるようです。
(ちなみにPhotoTaggerは、受信出来ない時間の設定項目があり、適当に設定してあげればログを続けたり、分断させたり出来ます。
なおSkyTraqのチップは「Application Note AN0008」を見ても解るように、「電波が遮断した点にログの終了マークが付く」、という事はありません。ログ遮断の時間によりログを分離しているだけのようです。)

・「ユーザー管理」
　個人使用の場合は、「ユーザー」ではなく「旅行」(行先とか)の管理として使用したほうが良いのかも・・・
(ログファイルの管理でファイル名の区別に良さそう)
・・・ロガーのデータを削除せずにD/L操作を繰り返すと、D/Lした日付で新しいファイルがどんどん出来るので・・・

標高のデータを比較してみました。

このログは米沢発福島行きの各駅停車の列車内で取ったもので、米沢〜峠駅間。
(グラフ左側が米沢駅、右側が峠駅。途切れている所はトンネル通過等で電波が途切れているところ)

青線がGT-730F(L)のログをPhotoTaggerでNMEAにエクスポートしたデータをグラフ化したもの。
(楕円体高が出力されています)

ピンクがGT-730F(L)のログをPhotoTrackrでNMEAにエクスポートしたデータをグラフ化したもの。

黄線がRGM-3800のログをグラフ化したもの。
(「標高」が出力されています)

このようにPhotoTrackrで変換したデータは全体的に低めに出ています。


どうも、1.852倍すると、PhotoTaggerでエクスポートしたデータ(楕円体高)と一致するようですが・・・

「GPRMC」センテンス用の速度のノット変換のルーチンを間違って通してしまっているみたいです。


＜11/8追加＞
ネットを検索してみたら、GisTEQ扱いのMTKチップのロガーDPL700用のPhototrackrのMac版に標高データ読み込みの修正を行った版があるようなのですが・・・
他機種(canmore向けのOEM版含む)のツールの不具合には気がついていないのかな？
＜追加おわり＞

＜10/5/20追加＞
本ツールの標高問題、canmoreが悪いのか、秋月もあきらめているのか、修正される気配がないようで・・・
標高もある程度の精度で値が欲しいのに、どうしてもGT-730FL-Sにこだわりたい方は・・・
１．添付ツールがPhotoTaggerである東川の販売店で購入
２．Phototrackrで出力したログをカシミール3Dで読み込ませカシミールで補正(但しこの方法は地上でのログ限定)
３．gpsbabelを使用してログを読み込む。＜10/12/14追加＞
といった対応が必要かと・・・

なお、Phototrackrで出力した値を1.852倍して出てくるのは、「楕円体高」であって「標高」ではありません。
(PhotoTaggerでの変換も「楕円体高」)
厳密にあわせたい場合は、4riverさん作成のツール、「Geoid correction Utility」を通すと良いかも。
(もっとも、それ以前にどうやって1.852倍の処理を入れるかが問題か。)
＜追加おわり＞

私が使用しているGT-730F(L)の後継機であるGT-730FL-Sの分解写真を掲載されているサイトがありました。
(誤ってウェアと一緒に洗濯されてしまったとか・・・分解して乾燥させなんとか復活されたそうでなにより)
http://braven3.hp2.jp/blog/?p=527

基板の形状みてびっくり。
新しいモデルなので基板の形状も大きく違っているのかと思ったらGT-730Fとそっくり。

一瞬書き込みにある機種名を再確認してしまいました。

寸法までは解りませんが、もしかすると大きさも同じで、基板をカットする金型もそのまま流用なんでしょうか。
ある意味、低コストを維持する秘訣かとも思います。

先日福島まで列車で往復した時のこと。
例によってロガーを並べてログを取っていたが・・・準備が悪く帰路でGT-730F(L)の電池が寿命となってしまった。

あいにく単三アルカリの予備が手元に無かったので、NiMHを3本入れてみた。
まぁ結果的には問題無しです。

GT-730F(L)の動作電圧範囲はカタログスペックでは3.8Vからですが、「動作電圧の下限」の項で説明しているように3Vを切ってもログ動作を継続する事を確認済ですし、NiMH電池の電圧も公称1.2Vとは言え充電直後なら1.4V,少々放置しても初期的には1.3V位ありますので、3本直列で十分みたいです。

「動作電圧の下限」の実験で2.6V位でログが停止するようですので、このタイミングで電池交換すれば電池を過放電((低負荷時)1Vを切ると電極を傷める)させる前の交換の目安になりそうです。

Phototrackrの操作方法を確認しようと思ったら期限切れでした。
デモ版の試用期間は30日のようです。
(試用期間は起動時にメッセージ出てくれればいいのに・・・)

SkyTraq製Viewer「SkyTraq 0.4.473」で変換したログ(.loggファイル)のデータがおかしい事に気が付いた。
ログ日時も位置もまるでおかしいのだ。

いろいろ試してわかったのだが、
DataLog＞Log Decompress
で変換すると問題なく、

Converter＞Decompress
で変換すると正しく変換されないようです。

なお、あくまでVenus5機のログの場合であり、Venus6機については未確認。

電源の供給をちょっとでも切った後は、時刻が「初期値」に戻ってしまうようになりました。

内部のバックアップ電池(以前書き込んだようにリチウム二次電池です)の電圧を測定すると、USBからの電源供給を切ると、すぐに電圧が低下してしまいます。

電池が遂に寿命となったようです。

やはり・・・どうしようもない設計みたいで・・・

SkyTraq 0.4.473を使用してWAAS(SBAS)をON(Enable)にしてみました。

すると、50番(PRN137のMTSAT2)が現われました。
WAAS(SBAS)をOFF(Disable)にすると消えます。

ただし、ON(Enable)にしてもGPGGAやGPRMCセンテンスを見るとDGPSモードにはなっていないようです。
その代わり・・・普通のGPS衛星のように捉えているようで、普通に認識してます。
でも衛星位置が変です。

TripMate850では同衛星は172度-45度で見えているのに、GT-730F(L)では197度-47度と、いう具合。

これでは測位が狂ってしまいそう。

※図は「VisualGPS」での表示になっていますが、SkyTraqでは位置の変動を確認出来ないので「VisualGPS」を使用しています。
(SkyTraqでWAAS ONに切換えてからSkyTraqを切断し、「VisualGPS」を「接続」)

＜10/29追加＞
実際にSkyTraq 0.4.473でWAAS ON/OFFを切替えてScatterグラフに表示される位置の変化を見てみましたが、切替えたからと言って変わる様子はないようです。
いずれにしてもDGPSモードになったNMEAは出力されないので、SBASの効果は出ていないのかも。(これも要調査だな。)

もうひとつ。
SkyTraq 0.4.473で表示されるSNRグラフ。
前にも書きましたが、一般的なNMEAモニタソフトと違って、
NMEA出力の順序にかかわらず衛星のPRNに従って固定位置になっています。
グラフは1から56までありますが、1から32までが通常のGPS衛星分。
今回の実験でわかったように33以降はどうもSBAS衛星分のようです。

ただし実際のPRN番号からはシフトされ、33から56がPRN120からPRN143に対応するものと思われます。
(要はMTKチップのレシーバと同じ見え方)
42番でPRN129が見えそうですが、なぜか拾わないみたい。

＜追加おわり＞

＜11/2追加＞
10/29追加分に、
＞ただし実際のPRN番号からはシフトされ、33から56がPRN120からPRN143に対応するものと思われます。
と書きましたが、
「Application Note AN0014
NMEA Messages Of SkyTraq Venus 6 GPS Receiver」
という資料に答えがありました。
GPGSVの「Satellite ID」の説明として、
＞Satellite ID number, GPS: 01 ~ 32, SBAS: 33 ~ 64 (33 = PRN120)
と。
＜追加おわり＞

＜11/3追加＞
10/29の追加分で、
＞42番でPRN129が見えそうですが、なぜか拾わないみたい。
と書きましたが、昨晩確認したら42番を拾う事もありました。
が、50番と同時に拾う事はなくどちらか一方で、どっちを拾うかは受信状態なのかタイミングなのか・・・

＜追加おわり＞

Viewerの新しい版がないか「skytraq viwer」をキーにで検索してみたら、sparkfunのサイトで「GPS Viewer_0422-1.zip」というファイルがみつかった。
解凍して起動してみると「SkyTraq 0.4.603」であった。
Binaryのメニューに、今までの版にはなかった項目が追加されている事を確認した。


「SkyTraq 0.4.603」メニューの一覧と「SkyTraq 0.4.473」との相違点

File
Save NMEA
Clean NMEA
-------------
Exit

Binary
System Restart
----------------------
Query Software Version
Query CRC Checksum
Query Position Update Rate
Query Datum
Query Position Pinning
Query GPS Measurement Mode ←追加
Query DR Info ←追加
Query DR HW Parameter ←追加
(Query 1PPSはないようです)
-----------------------
Set Factory Default
→No Reboot
Rebot after setting to factory default
-----------------------
Configure Serial Port
Configure NMEA Output
Configure Message Type
Configure Binary Message Interval
Configure Position Update Rate
Configure Datum
Configure Power Mode
Configure Position Pinning
Configure Pinning Parameter
Configure GPS Measurment Mode
(Configure 1PPSはないようです。)

Ephemeris
Get Ephemeris
Set Ephemeris
Get Alamnac ←追加
Set Alamnac ←追加

Navigation Mode
Configure Navigation Mode
Query Navigation Mode


AGPS
AGPS Configure
AGPS Status
AGPS Download

DataLog
Log Configure
Log Clear
Log Status
Log Decompress
Log Read Batch

Converter
Compress (NMEA(TXT) to KML & Compress Log File)
Decompress DataLogメニューの「Log Decompress」と同じ？
Kml (TXT to KML)

WAAS
WAAS Configure
WAAS Status

Help
Help
→SkyTraq 0.4.603 (2007/04/19)・・・バージョンは変わりましたが、日付が全く変わっていない。


DRというのは衛星が受信できない場合に推測して位置を出力する、
「Dead Reckoning Mode」関連だとは思いますが、SkyTraqチップにもあったんですね。

またAlamnacの取り込みも出来るようになっているようです。

skytraqをキーに検索していたら、GLONASS対応のVenus7が発表されている事を知り、本家SkyTraqのサイトを見に行ったら、DOWNLOADのページに「SkyTraq 0.4.723」がありました。

早速D/Lし解凍、実行してみました。

Binaryメニューの項目がだいぶ増えたようです。
メニュー構成の詳しい調査は別途・・・

＜10/12/12追加＞
・Binaryメニューのイメージ追加しました。

・Log変換し、旧版での変換結果と比較したら、Altitudeの値だけ異なっていました。
PhotoTaggerでの変換結果と共にグラフ化してみた結果、どうもジオイド高を考慮した値になっているみたいです。

・WarmStart及びColdStartを行う際に、日時及び位置の初期値を入力・設定出来るようになったみたいです。

＜追加おわり＞

＜10/12/17追加＞
ログ読み込み・変換して解ったのですが、「うるう秒」の補正分が15秒に修正されていました。

しかし、「うるう秒」のテーブルがあって変換している訳ではないようで、前回のうるう秒挿入を跨ったログの変換しても挿入前のログも一律15秒でした。

＜追加おわり＞

ところで、Venus7ですが・・・
GLONASSの対応は書かれていますが、QZSSという文字が見当たらないのが残念。
88chだそうですが、データシートに対応するPRNが記載されていません。(GLONASS分が増えただけ、と考えればいいのか。)
今後、GNSS対応でどんなPRNの衛星が打ち上げられるかわからない(PRN割り当ては登録制で管理しているようですが。)ので、レシーバが対応するPRNに制約を設けるべきではない、というのが最近の私の考えです。

(テーブルかなんか設けて、自由に受信したいPRNを設定できるようにするとか・・・特殊な軌道や特殊なコードを送信する衛星に対応する為「デバイスドライバ」的にコードが追加できるような設計にしないといけないのではかなろうかと。
→SBAS衛星のPRNを33以降に「シフト」させる機能もそろそろ止めたほうが・・・)


また、Venus6の20Hzモデルのチップの発表もされているようです。

Mac等の環境でGT-730F(L)やGT-730FL-Sを使用されている方、GT-730FL-S付属のPhotoTrackrに耐えられなくなった方は、GPSBabelを使用されているようです。

折角の有効なツールなので、インストールして試用中。


変換時のパラメータがよくわかりませんでしたが、なんとか変換出来ました。


変換されたデータの解析中です。


気が付いた事(GPSBabelの版は1.4.2)
・GPGGAのAltitude項、楕円体高が出力されています。(12/22訂正)
　(本項、公開当初「ジオイド高を考慮された「標高」が出力されているみたい」と書きましたが誤りでした。
　確認したらPhotoTaggerから出力される値とほぼ同じです。よって・・・
「折角なのでジオイド高も出力してくれたらいいのに。」は無し。

・ログが一続きになります。ログを分離するパラメータが変換時の「Filter」の設定にあるような気がしますが、まだうまくいっていません。

・時刻がGPSView(最新版？0.4.723を使用)での変換結果と微妙に違います。例によって「うるう秒」に関わる処理の関係だと思いますが・・・
＜12/22追加＞
　トンネル追加時のデータで比べたらPhotoTaggerでの変換結果と同じ時刻でした。(13秒固定で変換されている模様)
＜追加おわり＞

・GPSBabelでロガー内部形式(Binaryデータ)を保存してくれますが・・・GPSViewにより保存されたデータ(Data.log)と比較すると、0Ahの前に勝手に0Dhが付加されているような・・・
＜12/26追加＞
　GPSBabelで保存されたBinaryデータをGPSBabelで変換しようとすると、
＞skytraq: Error 0 while processing data item #11 (starts at 98)
＞Error running gpsbabel: Process exited unsucessfully with code 1
なんてエラーが出てうまく行きません、
試しにGPSViewで保存された"Data.log"を入力ファイルに指定してもやはりエラー。
ただし、メッセージの最初の"item #11"部分の数字は違います。
ちなみに"item #11"ですが、ちょうど11番目のデータが0Ahの前に0Dhが付加された異常データです。
＜追加おわり＞

最近あるネット系ショップで「F-GFL100」という型番で「GT-730FL-S」を販売しているようだが・・・

通常価格24,800円を85%offで3,780円って、「通常価格」があまりにも酷すぎ。
こんな常識のないショップから購入してはいけません。


おそらく「価格についての不当表示〜不当な二重価格」に引っかかりますよね〜。
(（社）全国公正取引協議会連合会のサイトより)
http://www.jfftc.org/manga/hyouji/q_18.pdf

GT-730F(L)においてlogの最後が欠けている事がある。
帰宅時までlogを取っているはず(電源OFF時点でLED点滅を確認)なのに
MAPにplotしても途中までしか出てこない。という現象を幾度となく経験した。


この現象、発生状況・条件が見えてきた。

・logが溜まってきた時に起こる

・PhotoTaggerでD/Lした時だけでなく、SKYTRAQ純正?GPSViewで
　D/Lしても同様に欠落する。

・欠落するのは最後の1sector分?
　Skytraq chipはsector単位(1sector=4096byte)単位でDATAが転送されるようだ。
　欠落したlog(GPSViewでD/Lし、解凍(Decompress)したもの)を調べてみると、
D/LしたDataの最後はMode=1(最初のSector(必ずそうとは限らないが))から数えて
4096byteを超える点である事。

　※4096byte毎にsectorの境界(Boundary of FLASH Sector)があり、1point分のDataは
　Sectorを跨がないよう管理されている。(AN0008の「Data Logging Algorithm」項参照)
　※Mode=1の時(full storage format)は18byte,Mode=2の時(compact storage format)
　は8byte使用する。(AN0008のDatalog Storage Format項参照)

発生理由は正確にはわからないが、下記のような理由が考えられる。
・SKYTRAQ Chip側でなんらかの拍子にLOG時のsectorのカウントが抜ける?
　(残りsector数はGPSViewの menuで確認可)

・D/L toolの処理ミス
　(D/Lすべきsector数を1つ少なく計数)


・対策
　必要分LOGをとった後もしばらくlogを継続する。
(1秒毎LOGを取る設定で約9分:4096(byte)/8(byte/sec)=512(sec)=8.53(min))

　上記が出来なかった場合、D/Lする前に約9分dummyのlogを実施。


　なおこの不具合、Venus6チップのロガーで発生するのかどうかは不明。

PhotoTaggerですが、GoogleMapのAPIキー更新に伴う更新版が出ているようです。
更新しないとPhotoTaggerを開いた際に上記のようなError表示が出て、地図が表示されません。
(地図か表示されないだけでデータの変換作業等は可能だと思います。)

本件、CanmoreのGT-730系/GP-101用のPhotoTaggerだけでなく、Canmore/GiSTEQ Phototrackr,
TransystemのTripmate850/852用及び747系用PhotoTagger、HOLUXのM-241用の「ezTour」も関係するようです。

※私が使用しているPhotoTagger V1.2.2ではerrorは発生しないようなので、errorが発生するのはV1.2.3かも知れません。
(PhotoTrackrも、以前評価したV 2.6.331.0Sも大丈夫そう。)

なお上記のerror表示は、Tripmate850/852用のV1.2.3 h14でのものです。

最近、途中からLOGが残らない現象が起こっています。
FIXしているのにかからわずです。

いろいろ調べてみると・・・
FIXしている状態で「SkyTraq」ツールによりモニタしながらLog　Statusをチェックすると、FIX状態にもかかわらずいつまでたっても「Sector left」(メモリ残容量)が減らないのです。

1秒間隔でlogする設定にしているので、約9分で1カウントするはずなのですが。
(正確には・・・4096byte/(8byte/sec)=512sec=8.533min
※1sector=4096byte)

使用したメモリのカウントをミスっているみたいですが、はっきりした理由は不明です。

カウンタのメモリがVenes5チップ内にあるのか、フラッシュメモリ側にあるのかは不明。
後者ならフラッシュメモリだけ交換すれば復活するはずですが、そこまでやるのなら、ロガー本体を「新品」にしたほうが・・・(笑)

久しぶりにCANMORE社のサイトをのぞいてみたら・・・
「GT-730F(G)」なるレシーバ(ロガー？)が掲載されていた。
GLONASS対応らしく、チップセットはST-MICRO製らしい。

ST-MICROのチップセットは今まで試した事がないので、国内で取り扱いがあったら入手してみたいところ。
ただ、名称が「GPS/GLONASS Dongle」との記述のみで、サイトに掲載されているデータシートを見てもログ容量に関する記述が見当たらず、「レシーバ」なのかも・・・

canmore社のLCD付きロガー「GP-101」を購入し、log解析を行っている。

「GP-101」に関するスレ
GPSロガー＞GP-101


その過程で、古い「PhotoTagger」は、255km/h超の速度で記録されているポイント
を正しく読み込まないという bug がある事を確認した。

改めて、新幹線乗車時のGT-730F(L)にて取得し「PhotoTagger」でD/Lしたlogを調べたところ、255km/h超のログのデータが欠落している事を確認した。

同じlogを「Viewer」にてD/L・解凍したデータは255km/h超のポイントも正しく出力されているので、ロガーそのものの問題ではない。

なお、いつの版から不具合が解消されたのかは不明。
ちなみに不具合を確認した版は、GT-730F(L)購入時に添付されていたもの。
(Version 1.2.2,作成日:Jul 23 2008)



■不具合発生の原因の推察

「Application Note AN0008
Data Logging Extension
For Venus 6 GPS Receiver
Ver 1.4.11,Jan. 05, 2009」によると・・・

　Skytraq系チップのlogは、16bit単位で構成(1word)されており
　「速度情報」のあるwordは、下位10bitがkm/h単位の「速度」、上位3bitがlogの「記録形式」(ENPTY/FIX_FULL/FIX_COMPACT/FIX_FULL_POIの種別)を示している

　もし1wordのlogを8bitずつ分けて処理しているとすると、「記録形式」のあるbyteの下位の2bitに速度情報の9,10bit目を含む事になる。
　255km/h超のログは速度情報の9,10bit目が1が立つが、もし「記録形式」を含むbyteの下位bitのmaskを正しく行わず処理を行えば、「記録形式」の情報が「不正」と判断し、そのポイントのdataを無効とする、といった処理がなされていると推察される。

255km/h超の速度域を含んだlogを「PhotoTagger」，「Viewer」以外のtoolでD/Lしてみた。

１．「PhotoTrackr」
　255km/h超の速度域のlogも無事変換してくれました。

※確認を行った版は、GiSTEQ社サイトよりD/Lした「GiSTEQ PhotoTrackr」
　(PhotoTrackr Mini DPL900用　Version 2.6.331.0S)


２．「GPSBabel」
　255km/h超の速度域のlogも無事変換してくれました。

※確認を行った版は、version 1.4.2
(最新版ではない。)

canmore社のサイトを見てみると・・・

SkyTraq Venus6だったはずのGT-730FL-Sのチップセットが、SiRF STAR IVに変わっているではありませんか。

仕様を見ると・・・
＞48 track verification channels
＞SIRF-IV low power chipset

商品名そのままで、チップセットのメーカーまで変えてしまう、大胆さにびっくり。


＞Data Logger & Photo Tracker function
とありますので、添付ツールは、「Photo Tracker」みたいです。

＜'15/01/26追加＞
　14年10月頃の話ですが、秋月扱いの商品が新ロットからSiRF STAR IV版になるというインフォメーションが出てました。
　今販売されている物は、既に切り替わっているものと思われます。
　なおツールは、「GT-740FL」及び「GP-102+」でも使用されている「CanWay」です。
　ドライバは(おそらく)PL-2303系ではなく、「GT-740FL」でも使用されている「VCP」(「STMicroelectronics Vertual COM Port」)だと思います。

　回路的にはGT-740FLと同等ではないかと思っていますが、だとすると・・・
　GPSチップこそSTAR-IVですが、内部に別のCPUを持っており、Logに関しては、SkyTraqチップの動作をエミュレートしているものと思われ、
　PhotoTrackr及び、GPSbabel，SkyTraqのViwerツール「SkyTraq」からのアクセスが可能、PhotoTaggerでのアクセスは不可だと思われます。

　関連情報は、「GT-740FL」の項(下記アドレス)を参照下さい。
http://samidare.jp/jr7cwk/lavo.php?p=log&lid=347759
＜追加おわり＞

CanMoreからUSBドングル形の新機種、GT-740FLがリリースしたようです。
国内では秋月で扱っているのを確認。

バッテリ内蔵で、GT-730FL-Sの後継モデルという位置づけになりそう。

GPSチップは、LCD付きモデルのGP-102+でも使用されているSiRF STAR IV。

CanMoreのサイトと秋月のサイトで情報確認していますが、なぜかツール関係の情報がマニュアルにもなし。
CanMoreのサイトにツールのリンクがあるのですが、サイトに本体が置いてないのかD/L不可で、詳細不明です。

＜'14/3/8追加＞
そのGT-740FL入手しました。
詳細は下記アドレスへ
http://samidare.jp/jr7cwk/lavo.php?p=log&lid=347759
＜追加おわり＞