|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2010 |
| August | September 2009 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
October | Home |
.....................................................................................................................................
S.Gleason et al. (ed), GNSS Applications and Methods, Artech House, 2009
Amazonの予約注文で届いたGPS/GNSS参考書。Artech
HouseのGNSS Technology and Applications Seriesの最新刊。中身を見ると結構色々な人が色々な話題で書いている。付録DVDにソフトGNSSシミュレータやソフト受信機のコードが含まれている様だ。今は時間が無いの細かい中身まで見てられないが、ちょっと面白そうなので時間が出来たらこれもゆっくりと動かしてみたい。
.....................................................................................................................................
SkyTraqからreplyが来たのだけど、案の定 "half-cycle ambiguity resolved"を誤解している様なので再度説明を送る。でも、対応早いしu-bloxとはえらい違いだなあ。
To SkyTraq (9/29)
> I do not want "integer ambiguity"
resolved carrier phase.
> I hope just "half-cycle ambiguity"
resolved carrier phase.
> I agree it is very confusing.
>
> Integer ambiguity is usually resolved
by the relative navigation process with double-
> differencing technique. It is usually
impossible with a single receiver.
>
> "Half-cycle ambiguity" means
the porality of carrier-phase. Standard Costas
PLL locks
> to 180 degee-ambiguous (not 360-degree
ambiguous) carrier to allow received carrier
> inversion by navigation bit transition.
So without any other information, the measured
> carrier-phase must have "half-cycle
ambiguity". But this half-cycle ambiguity
is easily
> resolved by using navigation data pattern
(for example whether the preamble indicates
> 0x8B or 0x74) after decoding the navigation
data.
>
> With "half-cycle" unresolved
carrier-phase, it becomes hard to fix integer
ambiguity
> even outside of the receiver.
>
> Most of receivers with raw data output
have the funciton.
> For example u-blox LEA-4T already supports
such feature.
-------------------
OSGeo Osakaミニイベント
イタリア ミラノ工科大で、低価格GPS受信機を使った高精度測位ソフトであるgoGPSの開発を行っていたEugenio
Realini氏が先日来日し大阪市立大研究員として研究を続けられるとのこと。どうも調べるとGIS関係ではオープンソースソフトウェアの利用がとても活発な様で、FOSS4G
(Free and Open Source Software for Geospatial)
という名前で、色々な研究開発・普及活動がなされている様だ。実は11/2のFOSS4G 2009 Tokyoで少しRTKLIBの話をさせてもらうかもしれない。RTKLIBを公開してから色々なところから声をかけてもらう様になった。詳しくは書けないが先日もちょっと面白いofferがあった。これは来年初めにかけて少し頑張って実装してみる予定。
.....................................................................................................................................
必要あってCDDISからIGS局のデータをダウンロードしようとしたのだけどエラーとなる。どうもCDDISのサーバが死んでいる様だ。メンテの情報は上がっていないので障害かもしれない。しかたないのでSOPACからダウンロード。(17:05)
.....................................................................................................................................
ほとんどSkyTraqのβテスタと化しているが新しいF/Wにまた問題を見つけたので以下をSkyTraqに送った。
Inquiry to SkyTraq (9/26)
> I installed the new F/W (20Hz version)
to my S1315 and check it again.
>
> 1. I confirmed the new document.
> 2. I confirmed the new F/W correctly
outputs polarity-adjusted subframe words.
> 3. I understand. I hope the future version
will support SBAS.
> 4. I confirmed the new F/W outputs correct
values.
> 5. Thank you for changing the format
to output full-cycle carrier-phase.
> I still found some problems for integer
ambiguity for relativer positioning.
> To resolve integer ambiguity, the important
thing is not absolute
> initial phase but relative value beween
satellites. So it is improper to
> determine initial phase by using pseudorange
value. You had better to
> use phase-difference between satellites
to get initial phase. The absolute
> value is meaningless.
> Additionally, I hope F/W outputs "half-cycle
ambiguity resovled" carrier
> -phase by using navigation data polarity.
> 6. Same as no.3.
>
> I found additional problems with new
F/W.
>
> (7) Parity check frequently indicates
the error for raw measurement (0xDD)
> messages.
> (8) Cycle slip flag as bit 3 in channel
indicator does not seem to be set if the
> cycle-slip occures.
-------------------
ION GNSS 2009 Show Daily, SVN49 Panel: Causes, Effects, Possible Solutions, September 25, 2009
ION GNSS 2009 SVN49特別セッションについてこちらでは
> No consensus in feedback from manufacturers
from interviews conducted by
> Stansell. However, users are designing
to (and expecting) recent actual GPS system
> performance, not specified performance.
The Air Force intends to set SVN-49
> operational eventually, but the satellite
will be kept “unhealthy” until mitigations
are in
> place. Meanwhile, the GPS Wing will
continue outreach to users for SVN-49,
> providing technical data to interested
users to develop mitigations.
とある。結局誰からも画期的な解決案は出なかったようで、皆既に諦めているのではないかと思うのだが。
なお、個人的な意見としては、SVN49の問題についてはephemerisだけはちゃんとした値を放送してもらって永久に"unhealthy"のまま運用すればよいと思う。あとは公式な補正用データを公開して誰でも使える様にすれば受信機メーカが新しいF/Wで対応するだろう。結局問題はF/W更新ができないあるいは行わない既存受信機なので今の状況では永久に"healthy"には出来ないという結論にしかならない様に思う。本当の"unhealthy"と区別するために航法メッセージ拡張を行う必要があるかもしれない。ephemeris修正のためにどうせMCSの改修が必要の様なので少し時間をかけて実施すれば良い。多分技術的にはこの方向で決着するだろうと予想しておく。
.....................................................................................................................................
SkyTraq S1315FのF/Wの問題を指摘したメールをSkyTraqに9/21に送っていたのだが、なんかもう更新版F/Wを送ってきた。信じられない早業である。ホントにちゃんと試験しているのだろうかと心配になるが、とりあえず指摘のメールとSkyTraqからの回答を以下に載せる。
Inquiry to SkyTraq (9/21)
> I tried to decode SkyTraq binary from
S1315F and found some problems.
>
> (1) Byte-order the of multi-byte fields
in raw measurement (0xDD) is opposite of
the
> document. The receiver outputs are big-endian.
> (2) Some navigation words in subframe
message (0xE0) is inverted. Without parity,
> users can not correct the polarity.
> (3) Psudorange value of SBAS (MSAS)
satellite in raw measurement is clearly abnormal.
> (4) The sign of Doppler frequency in
raw measurement is opposite.
> (5) Accumulated carrier cycle in raw
measurement is provided as only the difference
> between epochs. Users can not reconstruct
the full cycle carrier-phase. It is hard
to fix
> integer ambiguity because of unknown
initial phases.
> (6) Navigation data for SBAS (MSAS)
is not provided.
>
> I hope the future version F/W will solve
these problems.
Reply from SkyTraq (9/25)
> Thanks to your finding, we have made
some changes to the firmware and updated
the
> AN0024 application note.
>
> 1. The binary message format should
be big-endian instead of little endian.
> 2. Polarity in each of the navigation
words of the subframe is polarity-adjusted
in the
> receiver before output.
> 3. Pseudo-ranges of SBAS satellites
are not incorrectly sent out by the receiver
> 4. Sign of the Doppler frequency is
corrected such that approaching satellite
has positive
> sign.
> 5. The accumulated carrier phase output
is corrected to floating point accumulation
of
> the carrier cycles,
> 6. Currently SBAS is not supported,
both pseudo range and navigation data of
the SBAS
> signals are not output.
-------------------
D.Jewell, Candidate Found for Perfect Handheld GPS
Transceiver? Plus: SVN49, September 24, 2009
GPS WorldのD.JewellがION GNSS2009のSVN49特別セッションに参加して
> My hat is off to the GPS Wing and HQ
Air Force Space Command for the way they
are approaching
> this anomaly resolution because the
bottom line is SVN 49, which is an LMCO IIRM+L5
satellite, will
> be set healthy in the coming months
and it will be useable. That is good news
for everyone.
と書いているのだけどこれ本当かね。
-------------------
NovAtel, OEMStar
ION GNSS2009にあわせて各受信機メーカが新製品を発表しているが、NovAtel社が発表したLow-Cost
L1 GPS+GLONASS受信機 OEMStar。10Hz 擬似距離+搬送波位相出力が可能の様。でも14chしかないというのはせっかくのGLONASSも有効に使えるかは疑問。GLONASSが受かるということはFDMA信号を分離しているということで低価格受信機でどう実現しているはとても興味がある。SuperStarIIがディスコンになったのでその代替品の意味もあるのではないかと思う。いずれにしても"Low-Cost"と謳うからにはSuperStarIIクラスの価格で出るはずなので、今後評価してみたい。なおGLONASS
L1はGPS L1周波数と少しずれがあるので多くのGPSアンテナはそのままでは使えないのではないかと思う。
.....................................................................................................................................
IS-GPS/GNSS-Symposiumのpaper作成。今みたいな自転車 (「じでんしゃ」で何故か変換できない... ) 操業はいい加減なんとかしないといかんなあ。
.....................................................................................................................................
GPS Daily, Proton Launch Delayed Due To Problem With
Glonass Satellite, September 23, 2009
25日に予定されていた3機のGLONASS衛星の打ち上げが遅れるとのこと。3機のうち1機の衛星の機器に問題が見つかったためとしている。
補足: Langleyさんによると打ち上げは10/29になりそうとのこと。(9/25追記)
-------------------
NovAtel Firmware and Software Updates
NovAtel OEMV F/Wがようやく3.700にversion
up。What's newには書かれていないのだけどGLONASS
R10, R14のトラッキング不具合が修正されているはずなのでさっそくupdate。たしかにR14は受かるようになったみたい。少しこれで様子を見てみよう。
補足: R10も問題なく受かることを確認。(16:50追記)
.....................................................................................................................................
topで表示したBB-RTK-RCVのCPU負荷。衛星数は9、10Hz RTK、EmobileでGPSデータサービスのRRSにつなぎ、10Hz解をSDカードに書き込んでいる。コンパイルオプションで最適化を効かせるのを忘れていたので、それを設定しただけで負荷が半分以下に減った。これくらいなら十分実用的と言えるのではないかと思う。
top - 00:08:24 up 24 min, 1 user, load average: 0.16, 0.24, 0.18
Tasks: 46 total, 1 running, 45 sleeping, 0 stopped, 0 zombie
Cpu(s): 24.3%us, 1.3%sy, 0.0%ni, 73.4%id, 0.7%wa, 0.3%hi, 0.0%si, 0.0%st
Mem: 239616k total, 30476k used, 209140k free, 3540k buffers
Swap: 0k total, 0k used, 0k free, 12492k cached
1876 ubuntu 20 0 11896 2344 1256 S 25.1 1.0 4:13.09 rtkrcv
1894 ubuntu 20 0 2492 1160 936 R 0.7 0.5 0:00.16 top
1 root 20 0 2860 1896 572 S 0.0 0.8 0:01.49 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 15 -5 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root 15 -5 0 0 0 S 0.0 0.0 0:00.04 events/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:00.05 khelper
-------------------
ANTTOOL v.1.3で解析した、NovAtel GPS-702-GG + SkyTraq S1315Fによるコードマルチパス (左)、搬送波位相マルチパス (右)。10s間隔 24H。S1315Fのマルチパス特性はとても良い。なお、このグラフではウインドウサイズ100sの移動平均フィルタを掛けているので受信機ノイズがかなり低減されているが、これをはずすとコードノイズはRMS 77cmとなる。ただこの大部分はランダム性の高いノイズなので適切な外部フィルタで削減可能である。これを見る限りKGPS解はもう少し性能が出ても良いと思うがプログラムに問題が残っているのかもしれない。
.....................................................................................................................................
SkyTraq raw+RTKLIBによる単独測位解 (左) とKGPS解 (右)。1Hz 8H分。KGPSは基線長1mで基準局はNovAtel OEMV。アンテナは両方ともNovAtel GPS-702-GG。SkyTraqの航法メッセージは正常にデコードできないのでephemerisはNovAtelを使っている。コードノイズが結構大きい。KGPS解は原因不明の飛びが出ている。スリップも結構多い。F/Wが改善されたとしてもRTK-GPSにはちょっと厳しいかなあという感じである。
補足: SkyTraq S1315F モジュールの値段はサンプル $25、$12.5@250pcs、とのことである。Venus 6が激安GPSスティックにも使われている様に恐ろしく安い。基準発振器やRFフロントエンドの品質等で高価な受信機との差は確かにあると思うが、F/Wのバージョンが上がって問題点が解決されれば激安RTK-GPS受信機用定番モジュールになる可能性もある。(19:55追記)
-------------------
SkyTraq S1315FによるRTK-GPS解。なんとか解は得られたが、かなり色々と問題がある。
(1) byte-orderが仕様書と逆 (big-endian)。
(2) navigation subframeのwordが反転している場合がある。parityが除去されているので結局デコードは困難。
(3) SBASのpseudorange値が異常。
(4) Dopplerの符号が逆
(5) 搬送波位相はエポック間差分値しか得られない。これでは受信機初期位相項が消去できないのでAmbiguityの整数化は多分困難。
ただ、本当に20Hzのrawデータが得られるのでFloat解で良いなら使えないことはないかもしれない。
補足: とりあえずrawデータの問題点として以上を書いてSkyTraqに送った。F/W更新で改善されると良いのだが。(13:10追記)
.....................................................................................................................................
Aviation week, USAF Readies For Multiple Launches, September 18, 2009
来年5月のGPS Block IIF初号機打ち上げは当初予定されていたDelta IVではなくAtlas Vを使って行われる様だ。
.....................................................................................................................................
Inside GNSS, OCX budget Cut Could Slow Program; First
IIF Might Launch by May 2010, September 17,2009
Inside GNSSが空軍関係者の取材からGPS Block
IIF初号機の打ち上げは来年5月になるだろうと伝えている。またIIF初号機は現在ボーイング社の工場で最終インテグレーション試験中で、主な問題は既に解決し12月〜1月に射場
(Cape Canaveral) に送られる予定としている。
衛星といいロンチャといい今度のBlock IIF初号機打ち上げは新しい技術が満載であり技術リスクが高い訳だが、ここで失敗するとGAOレポートの懸念が現実となる可能性が高く、なんとか順調に行って欲しいものである。
-------------------
SkyTraq Venus 6のraw出力F/WバージョンS1315FのEVK (Evaluation Kit)。$99+$25(Fedex)。SkyTraq Raw Measurement Binary Extentionというプロトコルでで20Hzまでのraw (pseudorange+carrier-phase+doppler+ephemeris) 出力に対応しているらしいのだが、はたしてRTK-GPSにまともに使えるであろうか。S1315Fの情報はまだWeb上に掲載されていないので直接SkyTraqに問い合わせた。これは (多分ドイツ人の) Stefanに教えてもらった。
.....................................................................................................................................
ようやくBB-RTK-RCVでRTK-GPS処理が正常に動くようになった。RTKLIBのライブラリ側は2.3.0bから殆ど触っていないので、内蔵LEA-4Tの生観測データとNGS NRTKの6km基線で特に問題なくFix解は得られたが、予想された通り処理性能が少し厳しい。10Hz RTK-GPS動作でCPU負荷が50%前後。一応データ落ちは発生していない。ただこれはファイル出力やネットワーク出力、オプションのIMUも動かしていない状態の値なので実用的な動作状況で10Hz動作が可能かは微妙なところである。やはり浮動小数点演算負荷が支配的でかつソフトフロート処理なのでC2Q 2.4GHzの数10倍は遅いようだ。多分整数演算系は10倍程度しか違わないと思うのでフィルタ処理以外はそれほど問題にならないと思うが、かなりチューニングを頑張らないと実用的と言えないのではないかと思う。
.....................................................................................................................................
BB-RTK-RCV用のコマンドライン版RTK-GPSサーバの実装。
できればtelnetで遠隔制御したい等と考えたのが運のつきで結局telnetサーバもどきを書くはめになってしまった。telnetだけでもちゃんと動かすのは結構大変。ブラウザで制御したいという話もありそのためにはhttpサーバもどきも書く必要がある。なんか本質とは全然違う所で時間が過ぎ去って行く。
.....................................................................................................................................
LEA-5TF/W問題の件、u-blox Japan社から回答をもらった。とりあえずそのまま載せる。
> R&D部門リソースの関係上、弊社本国からのご回答は以下となります。
>
> Customers intending to use LEA-5T for
raw data applications have three options.
> They use LEA-5T as it is, which
may be good enough accuracy in some cases.
> They can use LEA-4T(as most do anyway)
or they wait for LEA-6T, which
> won't have this problem.
> Customer samples of LEA-6T can be expected
in Q1/10.
>
> しかしながら、先にご連絡しておりますように、バグを修正したVersionのみの
> 要求をしておりますが日程等の確約が取れておらず、改めてご確認を致します。
-------------------
LEA-5TのF/Wバグの件、私自身はまだ正式回答をもらっていないのだが、教えて頂いたところによると(1)
返品払い戻し or (2) LEA-4T/AEK-4Tへの交換
or (3) リリース後LEA-6T/EVK-6Tへの交換、とu-blox社から回答を貰った方がいる様だ。すなわちu-blox社としては、LEA-5TのF/Wは6.00で凍結してLEA-6Tに移行、の方針ということになる。
なお本件については正式には各自直接u-blox社に問い合わせ下さい。
.....................................................................................................................................
u-blox, Release Notes u-blox 5 Firmware Version 6.00, Aug 24, 2009
u-blox 5 F/W 6.00のリリースノートが更新されている。
> 1.1 No firmware image will be provided
for LEA-5T receivers.
> 3 Limitagions
> Raw data output rate
> Raw data output cannot be configured
at a different rate than the position fix
rate. Therefore the maximum
> update rate is limited to 2Hz
> Raw data output with insufficient resolution
> The field local time in RXM-RAW has
got insufficient resolution causing a submillisecond
mismatch between
> local time and pseudorange measurements.
This known limitation of FW6.0 concerns the
raw-data mode of
> LEA-5T only, timing feature is not affected
by this.
とのこと。LEA-5Tを購入予定の方は以上の制限を考慮された方が良いと思う。なお、SBAS subsystemをdisableに設定することによりraw data出力レートを4Hzまで上げることができると教えていただいた。
LEA-5Tのcarrier-phase観測値に含まれる異常残差と "Raw data output with insufficient resolution" との関係だが、towの精度不足で最終的なpseudorange, carrier-phase観測値とtime tag値に数cmの不整合が発生しているということではないか。towを倍精度で表すと仮数部52bitなので最悪 604800s/252=1.34x10-10s=4.0cmまで最小桁精度が落ちるので、これに起因する数値演算誤差が観測値に現れているということだと思う。この推測が合っているなら (towの絶対値が小さい) 日曜の朝は問題ないが、週末に近づくにつれて誤差が数cmまで増大するという挙動を示すはずである。と思って以前評価したデータの日付を見てみるとちょうど土曜日であり、多分この推測でどんぴしゃりだろう。これは時刻のF/W内部桁数を増やせば良いだけだが、外部での補正は無理だと思う。従ってF/Wのバージョンアップを待つしかない。精密測位をやっている人ならtowの内部桁数不足問題は誰でも知っていると思うがu-bloxのF/W技術者はこの辺の経験があまりなかったということだと思う。いずれにしてもGPSのF/W S/Wにおける時刻の取り扱いはとてもbugを発生しやすい鬼門ではある。 ちなみに、RTKLIBの時刻の内部表現は typedef struct {time_t time; double sec;} gtime_t; で秒以下の端数だけdoubleに入れている (4B or 8B +8Bなのでちょっとデータが大きすぎるという問題はある。特に観測データの格納効率が悪すぎるのでこれは今後見直すかもしれない)
補足: 日曜日0:00 GPST以降データのみで解析してみたが状況が改善されないので、桁落ちに起因する観測値精度低下が発生しているのかもしれない。(9/9追記)
-------------------
GLONASS Launch Preparations
YouTubeにアップされた、9/25に打ち上げ予定のGLONASS-Mの準備作業ビデオ。貴重な映像である。こちらの2' 50"過ぎにもGLONASS (TAOHACC) の紹介がある。3機の衛星の軌道上展開アニメが面白い。
.....................................................................................................................................
RTKLIB ver.2.2.2
RTKLIB ver.2.2.2 is just released. This version
involves minor changes to fix problems in
ver.2.2.1. Please refer Release Notes for details. English manual is also provided from this version. Next
major version up is planned at the end of
this year, that will be ver.2.3.0.
.....................................................................................................................................
gpsrobocarで海老沼先生が書かれているように最新のGoogle Map航空写真の位置精度は以前に比較し飛躍的によくなっている様だ。以下GEONET MAPで表示させた電子基準点93026 神奈川川崎の例。電子基準点の特徴的なポールの影の根元と基準点座標が見事に一致している。多分1m以内の精度があるだろう。このGEONET MAPを作った2年前には10-20mのずれが見られた地点が多かったのだが、その時に比較して明らかに位置精度が改善されている。もともと航空写真では全地域で真上から撮像できないのでそのままでは位置ずれを防ぐのば難しいのだが、標高データと写真撮像時の飛行機位置を使って画像補正を行っている可能性がある。Googleの技術の進歩は凄いなあ。
補足: Google Mapで電子基準点を探すのは面白い。右は051140
沖の鳥島沖ノ鳥島。この写真を見ると丸い島の真ん中が電子基準点の様なので10m位はずれている様だ。(9/7追記)
この写真をよくよく見ると島の真ん中が電子基準点ではないかもしれない。しかし沖の鳥島沖ノ鳥島の無線は何を使っているのだろう。
(9/7追記)
正しくは"沖ノ鳥島"の様なので修正。調べてみると島
(東小島) の真ん中の黒い丸は小島の侵食を防ぐためのチタン製防護ネットでGoogle Mapの電子基準点位置はほぼ正しい様だ。(9/8追記)
-------------------
R.B.Langley, Re: PRN01 Transmitters Switched Off [correction], September 5, 2009
信号異常を発生しているSVN49/PRN01が2009/9/4
12:00-14:11 UTCまでL1/L2の非標準コードを送信していたとのこと。どうも航法データアップロードに失敗するとGPS衛星側で自動的に非標準コードを送信するモードに入る様になっているらしい。SVN49の信号異常を是正すべくGPS
Wingが色々と試験をしている様なのだが、はたして奇跡の復活はあり得るのであろうか?
.....................................................................................................................................
700gで超薄型長時間駆動、Vaio X欲しいなあ。type Pも買ってしまったけど結局使いづらいのとtype Tがあるのでほとんど使ってない。type Tはまだ現役で十分使えるのだけど、換装したSSDのプチフリが酷くて使っていてストレスが溜まる様になってしまったので、SSDを入れ替えるか新しいノートを買うか迷っていた。実はMacBook Airも候補に考えていたのだけど、今のままではXを買うということになってしまいそう。
-------------------
もうすぐRTKLIBのマイナバージョンアップ (ver.2.2.2) 予定ですが、今英語マニュアルを書いているので少しお待ち下さい。
.....................................................................................................................................
RTKLIBのマイナバージョンアップ (ver.2.2.2) 準備。積み残し不具合の調査/対応と英語マニュアル整備。
なお、RTKLIB ver.2.3.0は今のところ年末リリースで、以下追加予定。
(1) GLONASS, Galileo, QZS対応。Galileo/QZSシミュレーション機能。
(2) 組み込みLinux対応リアルタイムAP。
(3) 運動モデル、IMU対応。
(4) GPS姿勢計対応。
(5) リアルタイムAPの精密暦対応。
長基線RTKやネットワーク解対応は色々と評価しなければいけないので多分来年のver.2.4.0になると思う。
.....................................................................................................................................
下のu-blox 6の話題でC/Aコード1msのAmbiguityをどう解くかという話を書いたが、通常は航法データを再生して航法データから得られたZカウントとデータフレーム先頭からのコード位置で決定するのが正統的である。ただ正統的方法では航法データ再生がどうしても必要なので最低30sの信号が必要になる。よく考えると別に擬似距離観測値が必要ないなら航法解推定と同時に1msのAmbuguityを解くというのは可能である。これは相対測位で搬送波位相の整数バイアスを解くのと同様な話だし、1波長300km相当だから例えば地表面全部を検索するとしても探索空間が爆発する訳でもない。u-blox社の"Capture & Process"ではこの方法が使われている可能性がある。なお、A-GPSでは航法データと同時に携帯基地局位置を送っており、それを使って1msのAmbiguityを解いているはずである。(良く調べたらこの辺のテクニックについてはDiggelen (2009) 4.4.2 Solving for Millisecond Integer Ambiguityに書いてあった。既に確立された技術ということ。)
.....................................................................................................................................
u-blox, u-blox launches ultra-low power GPS technology
platform u-blox 6
u-blox社がu-blox 6と呼ぶGPS受信機モジュールのシリーズを発表。従来受信機に比較し高速捕捉、低消費電力を実現したとしている。"Capture
& Process" とよぶgeotagging機能をサポートしたのも特徴。これは200ms以下のGPS生信号データのみ記録し、後処理計算により記録位置を再生できるというもの。200ms以下では航法データがほんの一部しか得られないので、別途記録された航法データをインターネット経由で参照してパターン照合して再生する様だ。面白いアイデアである。
補足: white paperに原理が書かれているのだが、当然ながらあまり細かい内容は明らかにされていない。問題はどうやってC/Aコード1msのAmbiguityを解いているかという点だが
(通常は航法データを使って解く) 200msでは10bit以下の航法データしか得られないし、ビット極性も再生できないので、複数衛星の航法データを全部合わせて検索しているのではないだろうか。もしかすると後処理時に概算位置をユーザに入力させるのかもしれない。もしそうであれば航法メッセージのパターン照合自体が必要ないということになる。(受信機クロックドリフトもあるのでパターン照合なしで実現するのは無理か)
(9/2追記)
よく考えると色々と疑問が出てくる。次の問題は200msで信号捕捉ができるのかという点である。航法メッセージが
(デバイスでは) 得られないということは、(Almanacが無いので)
Cold Startと同様の条件であり通常の方法では信号捕捉は無理である。従って生データといってもコード位相
(擬似距離) を記録しているわけでなくA/D変換後の生信号を記録し、後処理で信号捕捉や相関処理を行っているということになる。この方法では、2bit×8M/sサンプリング、1/2圧縮として、1回の記録で2x8000000x0.2/8/2=200KBのデータ容量が必要になる。いくら写真のgeotaggingが目的だとしてもこれでは容量が大きすぎるしフラッシュ書き込みの電力も無視できない。例えば10s周期で動作される場合でも必要な記録容量が莫大になるのでGPSロガー用途にも使えないだろう。ということでちょっと考えると実用性には
? がつくのだが、何か他に画期的な秘密が隠されているのだろうか。(9/2追記)
.....................................................................................................................................
| Home | by T.Takasu |
