|
日記・備考録 |
2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012/1 2 3 4 5 6 7 8 9 10 11 12 | 2013 |
| October | November 2012 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 |
December | Home |
...................................................................................................................................
DLR, Cooperative Network for GIOVE Observation (CONGO)
DLRがGPS, GLONASS, Galileoを含めた精密暦 (SP3) の提供を始めていることを教えてもらった。この頁下の方にある、アドレス、ユーザ名、パスワードでDLRのサーバにFTPログインして取得できる。提供は2012/11/22から。10秒間隔、クロックも含まれたSP3で、TUM予報暦を基にクロックだけRETICLEで推定しているらしい。Galileoを含めたPPPに使えるかどうかは検証していないので不明。
...................................................................................................................................
[teqc] what's up with the next teqc release?, May 18, 2012
なんかUNAVCOがTEQCで、 "2.11 extended" 版という独自拡張のRINEXでQZSSをサポートしていることを教えてもらった。今年の5月ってことは、JAXA 2.12拡張案のずっと後で、これを知らないということなのか、それとも2.12サポートするの大変なので、2.11に勝手な拡張加えているのか。いずれにしても、他にも勝手拡張が色々と発生しない様に、早く正式版にしましょう → JAXAさん。
-------------------------------------
午前中、某所で某研修の講師。なんか帰りは「公用車」で駅まで送ってくれた。まだ東京は秋で銀杏の黄葉が綺麗。ちなみに山梨はほとんど冬で昨日の朝の気温は-5度であった。
...................................................................................................................................
内閣府, 準天頂衛星システムの運用等事業の特定事業の選定について, 平成24年11月28日
次のステップに進んだ様で。予定通りなら今週中にも入札公告が出るはず。文書中PSC, PFI-LCC, VFMは、調べたらそれぞれpublic sector comparator, PFI life cycle cost, value for moneyの略らしい。こんな用語、PFIの専門家以外誰も知らんわね。
...................................................................................................................................
D.W.Marquardt, An Algorithm for Least-Square Estimation of Nonlinear Parameters, Journal of the Society for Industrial and Applied Mathmatics, 1963
LM法の原論文らしい。Google Scholarで引用が17,378件ついている。
-------------------------------------
LMよりGNの方が残差が小さくなるケースも出てきたので、最終的には両方実装して、最初にGNでフィッティングして収束しない場合だけLMで推定する様にした。結構時間がかかったけどこれで概ね安定して航法データを生成できる様になった。ただTUM暦からGalileo航法データ作って、RTKPLOTに食わせてみるとTOEが20年ずれている。これ多分Galileo weekロールオーバのバグだな。ということで、ようやくGalileo関係機能のデバッグができる環境が整った訳で、本番はこれから。なおLMのdamping parameterの増減方法は、残差改良したら1/10、しなかったら10倍というごく簡単なもの。スケーリングちゃんと入れた方がよさそうだけどまあ動いてるからいいや。
補足: 察しの良い方はお気づきの様に、これでMADOCAと本変換ユーティリティ使ってQZSSの航法データを生成出来るようになった。後はTLEの初期値入力に対応すれば、完全に観測データのみから航法データを生成できる。(20:05追記)
再補足: 経験的には初期値が100km以内に入っていれば24Hデータでも収束するので初期値はTLEでも十分。まあGNで収束しなければLM使えばいいし。一回収束すれば初期値は前日の軌道を伝搬すれば良い。問題は、軌道制御後だけどこれはノミナルのΔV入力してあげないと厳しいかも。(21:09追記)
-------------------------------------
最新のTLE更新毎にTLEファイルを編集する必要があるのはやはり煩雑なので、衛星名とカタログ番号、国際識別番号の対応表 (例) を別途指定できるようにした。ただ全Compass衛星のTLE取るためにはSpace-Trackにログインしてフルカタログを取得する必要がある。これは beta 6に反映。
...................................................................................................................................
エフェメリスパラメータ決定はやっぱり悪条件の様で、Gauss-Newtonではうまく収束しないケースが出てきた。ということで定番の LM を入れてみる。調べてみるとdamping parameterの増減の方法は必ずしも確立している訳でもないらしい。なんか以前も同じ所で苦労した様な。全然進歩していない。
-------------------------------------
RTKLIB 2.4.2 b5による2012/11/26-12/2 東京におけるGalileo衛星の可視予測。注目すべきは3日に一回は4機見える時間帯があること。従って、IOV-3, 4が信号送信開始し航法データが手に入ればGalileoだけで測位可能。実はそのため精密暦→放送暦変換コード書いたのだけど...。ということで、なんとか大体復活。
-------------------------------------
Beta 5 is now available. INI files are saved to rtklib_<ver>\bin instead of to \windows. Please copy previous INI files in \windows to rtklib_<ver>\bin to succeed the settings. For "Visibility Analysis" menu of RTKPLOT, set TLE Data File and Receiver Position as Lat/Lon/Hgt in Options dialog. Sample TLE files are found in rtklib_<ver>\data.
...................................................................................................................................
T.Takasu, Broadcast Ephemeris Generation by Curve Fitting to Satellite Positions, 2012
精密暦から放送暦への変換メモ。ちゃんとpartial derivativesを求めるのはものすごく面倒。検索したけど見つからなかったのでしかたなく自分で展開したけど、これだけで丸1日かかっている。実際の実装では差分近似でもだいたい問題ない様。なおGPSだとFit interval 2Hで残差3cmには入る。TUM暦からGalileoの航法データ作るためにコード書いたのだけど、実は操作ミスでせっかく書いたソースファイルを消してしまった。さすがに再度書く気力がない。
補足: 差分近似使うとコードが劇的に簡単になるので普通の条件ではこれでもOK。ただ差分近似は桁落ちと非線形性のため精度落ちるので、差分の大きさを適切に調整する必要がある。両方書いて差を比較し、相互検証するのがベスト。あと一部変なところがあったのでファイル差し替え。(11:39追記)
Rev Bに差し替え。(11/28追記)
差分近似だと、差分を調整しても有効桁が8桁ぐらいまで落ちてしまう場合がある。これって概ね単精度まで精度落ちてしまうということで、良条件では問題なくても、非線形性の強い場合の収束性に不安が残る。ということで、面倒でも解析解でヤコビアン求めるのが基本。(11/29追記)
...................................................................................................................................
R.Rama Rao et al., GPS/GNSS Antennas, Artech house, 2012
Amazonで届いた参考書。待望のGNSSアンテナ専門書。Artech House GNSSシリーズ最新刊。筆者はMITREのエンジニア。精密測位用アンテナ、アダプティブアンテナ、グランドプレーンや校正手法についても網羅している。ちょっと高いけど類書が少ないので専門家にはお勧め。
...................................................................................................................................
坂井, SBASにおける規格外メッセージの送信, 測位航法学会論文誌, 2012
SBAS規格外メッセージを航空用SBAS受信機に対する安全を確保して送信する方法について技術検討している。
単純にPRN120-138以外で送ればよいという気も。どんな方法でも「影響を及ぼさない」ことを検証するのは膨大な手間がかかるので、結局現実的ではない様な。ところでSDCMのPRN140、141ってSBAS規格外なんですよね。
...................................................................................................................................
TUM, Muti-GNSS Experiment (MGEX) of the International GNSS Service (IGS)
TUM (ミュンヘン工科大) がQZSSとGalileoの精密暦 (SP3) を提供開始。調べてみると既にGPS Week 1711 (2012/10/21) からの暦がCDDISにupされている。アドレスは、ftp://cddis.gsfc.nasa.gov/gps/products/mgex/%W/tum%W%D.sp3.Z。ということでQZ-visionの「最終暦」はずっと工事中のままで、先越されちゃいました。ところでミュンヘン工科大の校舎内には滑り台があるらしい。すごい。
補足: ちなみにTUM暦、クロック時系が例えばIGS Finalと合ってないので他の暦と組み合わせてもPPPには使えません。というかTUM暦のクロック時系がなんなのか不明。Peterさんが作っているとするとBernese 5.0か5.1で直接クロック推定できないので、クロックだけは放送暦そのまま出している可能性もある。PPP用には、クロック時系を合わせてGPS, GLO, GAL, QZS全部を入れた暦が欲しい、クロックはできれば30秒間隔RINEX CLKで、ということになる。ということで、JAXAさん早く出しましょう。(11:14追記)
再補足: Galileoは今のところ放送暦ないので上はない、とすると普通にCONGOの特定の1局の時計でクロック時系決めている可能性高い。(11:52追記)
...................................................................................................................................
内閣府, 実施方針の変更に関する質問への回答, 平成24年11月21日
とりあえず貼っておく。「ガラパゴス」云々は意味不明。地上用SBAS対応受信機のために手間と金ばかりかかるICAO認証受ける必要ないでしょ、というだけの話の気が。1周波SBASに含みを残しているのは、MSAS後継について政府内で調整しきれていないということなのだろうけど、3月までには決まるんですよね。
補足: システム仕様を決めるにあたって、標準規格は事業面ではむしろ損である、ということも十分考える必要がある。すなわち標準規格を採用するということは海外メーカが容易に端末や応用サービスに参入できるということ。結局、国民の税金使ってうまい所はどんどん海外へという話になる可能性が高い。まあ、メーカ側も事業計画も良く考えた上で技術提案してほしいとは思う。(13:16追記)
-------------------------------------
メモ: EUREFの基準局ネットワークのモニタサイト。
-------------------------------------
ご要望があったのでRTKPLOTに可視衛星予測機能を追加。2012/12/1 東京でのSkyplot、12月の可視衛星数+DOP (仰角マスク5度)、3ヶ月間の「みちびき」の軌道ドリフト。可視衛星数は最大42機。平均GDOP 1.0。なお、Compass G6, Galileo IOV-3, 4は既に衛星に含まれている。この機能はRTKLIB 2.4.2b5に入る。
ところで、ベータ版を頻繁に出すというのは速く品質上げるために良い戦略かなあと思い始めている。あまり試験しなくてもすぐにリリースできるし、バグレポートや要望も集まり易い。ユーザとしても、問題があったらその部分は古い正式版使えば良いので、割と安心して利用できる。ユーザとのやりとりがあるので開発者もモチベーションが維持しやすい。すなわち開発側とユーザ双方が、一致協力して開発プロセスを回しやすい。ということでRTKLIBの開発に寄与したいとお考えの方はベータ版をどんどん使って頂いてバグレポートや評価結果送って頂けるとうれしいです。
...................................................................................................................................
IBM, Technical Notes: Linuxシステムクロックの「うるう秒」調整
メモ: うるう秒が挿入されると、NTP同期したLinuxの場合標準動作ではシステム時刻が逆行する。gettimeofday() で返される時刻も逆行するので、例えばGPSTに同期して周期処理をさせたい場合、うるう秒挿入を知っていて挿入前後で時刻を調整する必要がある。なお、nanosleep() はうるう秒挿入に影響を受けない。
NTP同期したLinux上で、RTKLIBのAPIを使い utc2gpst(timeget()) で現在時刻をGPSTで取得しようとすると、(内部でgettimeofday() を使っているので) 以上の問題から以下の様にGPSTが逆行して飛ぶことになる。標準的な方法ではこれを回避するのは難しい。周期処理の場合は nanosleep() と併用して飛びを検出し、補正をかける方法が使える。なお、うるう秒挿入でなく削除の場合、問題は発生しない。
UTC NTP-LINUX GPST
2012/06/30 23:59:58 23:59:58 00:00:13
23:59:59 23:59:59 00:00:14
23:59:60 23:59:59 00:00:14 *
2012/07/01 00:00:00 00:00:00 00:00:16
00:00:01 00:00:01 00:00:17
...................................................................................................................................
InsideGNSS, Hemisphere GPS seeks to spin off OEM GNSS business, move HQ to Kansas, November 16, 2012
HemisphereがOEM受信機ビジネスから撤退か? これで多周波受信機価格もあと10年は高止まり? ついでなのでminiEclipseあたり投げ売りしてくれないかなあ。
...................................................................................................................................
FAA, Phase II of the GNSS Evolutionary Architecture Study, February 2010
メモ。FAAによるphase II GEASレポート。安全性要求の高い応用向け補強システム設計の参考用。
...................................................................................................................................
ということで、2、3日、色々と書きすぎて作業止まっているのでここで落ちます。
-------------------------------------
J.Liu, The recent progress on high precision application research of BeiDou navigation satellite system, Stanford's 2012 PNT Charenges and Oppotunities Symposium, November 13-14, 2012
今週火水とスタンフォード大で開催されたPNTシンポジウム。Compass関連の状況報告。発表者はWuhan大のLiu。着々と開発してますなあ、という感じ。これで、まともなICDが公開されて、対応受信機も沢山出て、精度も良くて、結構使えるという評価が中国国外で定着すれば、せっかく実用準天整備してアジアオセアニアで事業展開しようと目論んでいても、皆中国に取られちゃうかも。何せ向こうは既に16機。2020年には35機。こっちはその時にやっと4機だもの。やっぱり役所の縄張り争いしてる暇ないよなあ、とは思う。
補足: 逆転の発想でCompassの信号をどんどん利用して、事業のうまいところだけ頂くという手を考えた方が賢いという話もある。ということでLEXにCompassの補強入れたいのだけど、衛星クロック安定度がGPS IIFやQZSSに比較しかなり悪いのが厳しいなあ。(11/18追記)
-------------------------------------
なんか、RTKLIBにdonationしたいから、WebサイトにPaypalでdonationするためのボタンつけろってメール来たぞ。$50だって。寄付大変感謝。
-------------------------------------
昨日書いた「測位技術実証プラットフォーム」、補強システム自体は技術的には成立しそう。次に対応受信機をどう安く開発するか。目標は10万以下。
(1) フル機能 (L1+L2+L5) を全部開発するのは得策ではない。特にL2P(Y) はいまさらセミコードレスでもないし5年位しか使えない。といっても、Galileo対応した3周波受信機のOEMカード、5年後でも10万以下にはならないだろうなあ。APIも必要だし。
(2) ということでL2はあきらめる。これでも可視衛星数15は確保できる。
(3) RFフロントエンドはL1/E1, L5/E5a, E5bの3CH。ここは普通にMAX2769
+ 2112 × 2。サンプリングは16MHzと2448MHz。(12/21修正)
(4) 相関器はまずは普通にFPGAで実装。これはIP化してASICに落とすパスを残すため。最大24衛星で、CH数は64CHあればOK。
(5) L5/E5a, E5bは単純なBPSK (10) なのでそれほど難しくはない。AltBOCはE5aとE5bそれぞれの相関出力を演算してフィードバックかければいいらしいんだけど、ここは要調査。パテントも要ケア。
(6) GPS/QZSのL1はL1C/A追尾すればよい。L1C/Aがなくなることはあり得ないからL1Cは使わなくても良い。これは枯れた技術だから実装は問題ない。
(7) Galileo E1はCBOCでかなりやっかい。技術開発要素の残るところ。オプションとして、L1だけ既存受信機モジュールかOEMボードを流用するというのも考えられる。ただ、Galileo/QZSS対応で、rawが出て、クロック出力できるモジュールが入手できるか。Hemisphereあたり出さないかなあ。
(8) 移動体応用向けに受信機オプションとして慣性センサも必要。とりあえず、MEMS IMU、yawのみ1軸、1度/hr位のもの。3年後を見越せばまあ5万以下位では行けそう。
(9) 後はF/Wだけど、開発そのものはそれほどのこともない。どうせ補強生成側でも性能評価のためユーザアルゴリズムを実装しなければいけないので、そちらで開発したコードを移植すれば良い。
(10) 以上を5年で開発しきれるか。プロトタイプ実装1年、製品実装2年、評価改良2年。ただ受信機開発費そのものは実用準天頂 PFI事業費の枠組み内で出るはず。数が出ることが確実ならASIC化して劇的にコストを下げられるけど、ASIC化コストまで事業費で賄えるのかなあ。FPGAのままで10万以下は難しいかもしれない。
(11) いずれにしても重要なのは補強サービス開始時に、実用的に使えてある程度安価な量産受信機を用意できること。そのために地上系開発と同時並行して受信機開発を進める必要がある。可能なら高精度カーナビや精密農業といった典型的な応用パッケージも同時開発できればベター。
(12) もちろん受信機開発はノウハウを持ってる海外受信機メーカに任せて、F/Wライセンスだけ提供するというのもありうるのだけど、事業として見た場合にそれほど旨みはない。補強システム側を持ってるということは仕様を自由に決められるということで、実質的に他受信機メーカ参入は難しいのである。受信機を自主開発しなければそのメリットを最大限生かすことは難しい。
(13) 私としては補強システムS/Wと受信機F/Wのライセンス収入で悠々自適の生活、などという妄想を書き連ねているのであった。
(14) 妄想ついでに書いておくと、SBASって基本的にFAAとそれに付随する米国の関連メーカや受信機メーカにお金を貢ぐシステムな訳で。それでいて普通のGPSユーザにとってはMSAS、それ何? という状況な訳で。もちろん国交省としては、国際的に約束して既に動いちゃっているものをちゃんと維持していかなきゃいけないという論理も分かるけど、それは最低限にして、やはり税金使うなら、民間事業パスできれば海外展開可能な事業パスの可能性のある技術開発に投資するというのが筋だろう (まあこれも経産の論理かもしれないが)。その点実用準天のL5S CHを民間事業に開放したのは、内閣府の英断だと思う。ということで、せっかくなので皆で知恵を出し合って有効利用しましょう。(8:45追記)
補足: そう言えばL1Sのサブメータ補強も (多分) 民間事業でした。でも、今のシステムでは日本域外れると極端に性能落ちるから海外展開無理だし、少なくとも、Long Term Ephemeris入れるとか、高速インテグリティ入れるとか、付加価値つけないとせっかく端末作っても使う人いないと思う。メッセージングと抱き合わせてなんとかガラケーに入れて、ライセンスフィーで稼ぐというビジネスモデルなのかもしれないけど。(11/18 追記)
こっそり再補足: 実情を聞くと、MSASなんて航空機でもほとんど誰も使ってないという話もあって。まあ壮大な税金の無駄使いで、儲けたのは米FAA関連企業だけという感じか。でも既得権益もあるし、止めるってやっぱり抵抗大きいのでしょうねえ。(11/30追記)
(15) MBOCのパテント問題ってまだ決着付いてないんだよね。でも流石に3年後位には目途付いているでしょう。ただ、製品受信機開発って既存パテントとの戦いだったりするので、まあ実際の開発にはこの辺ノウハウや知財部門持っている国内受信機メーカと連携する方が良いかも。ところでどこか手を上げるところ、ありません? (11:35追記)
(16) 某所からはMSASとQZSSの関係について情報貰った。なるほどね。まあ裏では色々ありますな。情報感謝。(11:47追記)
...................................................................................................................................
Inside GNSS, Long-Awaited Compass-ICD May Appear by End of This Year, November 14, 2012
Compass ICDが年末には公開されるらしい。先週北京で開催されたICG-78で関係者が明言したとのこと。「公式」ICDが使い物になるICDなのかは、いつもの様に公開されてみないと分からないのだけど。まともなICDが出るとして、信号追尾可能な受信機でもF/Wが対応するのに1年はかかるので、実際Compass使えるようになるのは来年末かなあ。一般受信機だとまだ2〜3年はかかるかも。
-------------------------------------
「測位技術実証プラットフォーム」は興味深い課題なのでもう少し具体的に検討してみよう。
(1) 補強対象衛星は2017年の段階でGPS IIA/R/R-M×23, GPS IIF/III×8, GAL×27, QZS×4 計62機。サービスエリアでのGPS/GAL可視衛星を約2/5として平均28機。同時最大30機。入らない場合は優先度をつけて低優先の衛星を落とす。
(2) メッセージ形式はSBAS踏襲、1メッセージ/秒。プリアンブル(8)+MT(6)+本体(212)+CRC(24)。MTはSBASで予約となっているものをアサイン。メッセージ種別は、軌道+クロック補正、高速クロック補正、高速インテグリティの3種。
(3) 軌道+クロック補正は、バージョン(3)＋TOD(17)+更新間隔(4)+衛星ID(8)+IODE(8)+軌道補正(121)+クロック補正(22)+URA(6)+FCB(24)、計212bit。軌道補正、クロック補正はRTCM SSR準拠 (クロックはΔaf0のみ)。FCBはPPP-AR用(L1+L2 or L1+L5)。DCBは航法データ使えば十分なので送らない。
(4) 高速クロック補正は、バージョン(3)＋TOD(17)+更新間隔(3)+衛星ID(8)×9+クロック補正(13)×9、計212bit。(3) に対する高速補正。
(5) 高速インテグリティは、バージョン(3)+TOD(17)+更新間隔(4)+衛星マスク(68)+劣化係数(4)×30、計212bit。L1/L2, L1/L5の悪い方の劣化係数を送る。
(6) メッセージサイクルは、5秒/サイクル。1サイクル、軌道+クロック1、軌道+クロック2、軌道+クロック3、高速クロック、高速インテグリティの順。高速クロックはGPS IIA/R/R-Mのみ。軌道+クロックは5秒×30衛星/3=50秒で1周。
(7) 周期50秒なので1回メッセージ欠損を許容して軌道伝播には最低10^-6m/s^2のモデルが必要。これはユーザ側で実装可能。GPS IIF、Galileo、QZSSのクロック安定度は概ね100秒10^-13なのでこれも50秒×2で誤差3mm位で十分。
(8) 問題はTTFFだけど30秒で半分の衛星の補強情報は受けられるのでまあ許容範囲。どうせエフェメリス取得にも最低30秒かかるし。
(9) 電離層は二周波。対流圏は推定して落とすしかないけど、ここが最終的精度・収束時間を規定するかも。
ということで、ちゃんと検討すると、L5S 250bpsにGPS IIA/IIRも含めて必要な補強情報が大体入ってしまった。擬似距離使えばアンビギュイティ解く必要ないので収束時間の問題はない。AltBOC使えばサブデシm級の精度は得られる。異常信号検知まで10秒、RAIMを併用すれば概ね安全性要求が厳しい応用にも使える。cm級精度が必要なユーザは、収束に30分かかるけど、PPP-ARを適用すれば良い。L1+L5 (+L2) なので受信機側に新規開発要素がほとんどないというのもLEXと比較した大きなポイント。ということで、この提案どこか買いません。
補足: まだL1Sb余っているので日本付近のみ対流圏補正情報送ってもよいかも。大体 50km格子のZTDかZWD送れば十分。LSB 0.3mm、ダイナミックレンジ30cmで1格子点10bit。日本の陸域だけなら格子点数200位なので30秒サイクルで送ったとして必要帯域はL1Sbの半分以下。エリアを広げるか、別の何かを送るか。(15:45追記)
再補足: AltBOC使ってサブデシm級精度が得られるということは、これを使って逆にアンビギュイティを解けるということ。PPP-ARの収束には30分待つ必要なくて数分かな。(15:55追記)
再々補足: 高速クロックを1メッセージ/5秒に変更して見直し。(18:22追記)
再再々補足: AltBOC使っても、本当にサブデシｍ級の精度出るかは要検討。普通の電離層フリー線形結合ではL1(E1)側のマルチパスも載ってくるので単純には無理。CBOCだからL1C/Aよりはマルチパスに有利だけどせいぜい改善は数倍。とすると、サブデシm級の実現には搬送波も使って電離層項をフィルタ推定する必要がある。そうするとスリップの多い移動体で精度が落ちる。ここを慣性センサ使ってフィルタ性能を上げる必要もある。この辺まだ技術開発要素の残っているところ。(19:10追記)
再再再々補足: 軌道伝搬モデル精度に間違いがあったので見直し。10^-7位までの実装はそれほど難しくはない。EOPはもしかすると別に送る必要あるかも。(19:40追記)
再再再再々補足: 本当はconfidentialな事業ネタをこんなところに書き散らかしているのは、内閣府や関連メーカの方がここ読んでいるのを知っていてその意見を誘導したくて書いているのである。まあ、内容信用するかどうかは自分で判断下さい。(19:50追記)
...................................................................................................................................
内閣府, 準天頂衛星システム関連: 調達情報 実施方針の変更, 平成24年11月13日
結構変更されている様で。変更箇所についてはもう一回質問・意見を受けるとのこと。ただし11/16 12:00まで。
補足: 「測位技術実証プラットフォームサービス」って始めて聞く言葉だけど、これ何 ? まさか 11/1 のこの備考録を読んだ内閣府の誰かが、急遽入れたなんてことないよね。(15:25追記)
再補足: 変更後業務要求水準書 (案) を少し良く読んでみた。変更前と大きく変わったのはL5Sの取扱い。二周波SBAS準拠のサブメータ級補強に使うとしてたのが、「測位技術実証プラットフォーム」に使う様に変更になった。伴い、静止衛星のみ、同サービス用L1Sb信号が新設された。邪推するに、二周波SBASは規格自身まだ流動的だし、今要求するのは無理があるとの判断で仕様からはずすことにしたけど、信号余っちゃったので急遽技術実証用に回すことにした、という経緯かな。静止衛星だけL1Sb新設したのはまだ搭載機器に余裕があったから? 個人的には新しい測位補強サービスに使えるCHが増えることは歓迎。ただ、今プロポーザル準備中の方は、多分この変更にどう対応するかでてんてこまいなのでは。(11/15追記)
この変更の理由は、SBAS関係の記述が変更版でほとんど削除されていることを裏読みすれば、大体推測できる。(11/16追記)
再々補足: なんかここ読んでるメーカの方も多い様なので、もし私が新しいL5Sの利用法を聞かれたらどう提案するか参考のため書いておこう。まず、L5が受かるということは受信機は既にL1-L5の二周波対応ということ。従って電離層補正は送る必要ない。また帯域を考えると送る情報を十分絞る必要がある。ということで、GPS IIF/III+Galileo+QZSSの精密軌道クロック補正+高速インテグリティ情報を送る。サービスエリアは海上も含めたアジア・オセアニア全域で対象衛星数は15-20機位。これら衛星はクロック安定度が高いので更新間隔は3分程度でも十分。その代わりリアルタイム信号モニタからインテグリティ情報を作り5秒間隔で送る。これで226bpsの帯域に入るはず。Galileo補強を送るのは当然AltBOCの低マルチパス信号利用を想定している。高速インテグリティ情報は安全性要求の高い移動体応用に必須。これで5年後には高信頼度サブデシm級補強サービスが提供できる。自動車応用には慣性センサ等統合が必要になるが、受信機自体は10万以下で作れるはず (Galileo信号の利用ライセンスや特許問題は要ケア)。多分これに近い仕様で決着するのでは。さて、ここでもマルチGNSS対応のcm級リアルタイム精密軌道クロック決定技術がキーになる訳で。技術を持っていない所は、どこからか技術導入するしかないのだけど。(11/15 8:34追記)
...................................................................................................................................
PCWatch, Intel, HPC向けコプロセッサ「Xeon Phi」を2013年1月より一般向けに出荷開始, 2012年11月13日
ちょっとこれ欲しいかも。現状のGPGPUの最大の問題はプログラミングに特殊な言語が必要な点なので。derectiveベースでオリジナルのソースちょっと直せばコプロセッサで実行できるのであれば大変有難い。行列演算ライブラリも提供されるはずだし。コプロセッサ搭載メモリ容量を超えて大きな行列使えると良いのだけど。ちなみに記事中のTACC Strampedeは、今日発表された最新TOP500で7位となっている (Rmaxの値が合わないのでこれはまだサブセットかも)。
...................................................................................................................................
メモ。Windowsで実行ファイルパスを得るAPI: GetModuleFileName()。
RTKLIB 2.4.2b4で、iniファイルの書き込み権限がなくてプログラムを終了できない問題の指摘を多数もらっているので、書き込み先をexeファイルと同一ディレクトリに変更するため。これはRTKLIB 2.4.2b5に反映。
調べると管理者権限で実行する様に設定したカスタムmanifestファイル作って、これをリンクしても良いみたいだけど、結構面倒なので。Turbo C++でビルドしているRTKLIB 2.4.1では何故今まで問題が発生していなかったのかは永遠の謎。
ちなみにRTKLIB 2.4.2b4でプログラム終了できない場合の暫定対処法。まず、タスクマネージャを起動して、プログラムを強制終了。次に、実行プログラムアイコンの右クリックメニュー「プロパティ」を選択し「互換性」タブの「管理者としてこのプログラムを実行する」にチェックを入れる。
...................................................................................................................................
13" Retina MBPの環境構築。VMWareFusionは表示に不具合があるしオーバヘッドも大きかったので、結局、Boot CampでWindows 7 導入。最新版 (4.1) ではスリープの不具合は既に直っている様。2560×1600表示も字が小さすぎないよう調整されているし、問題はない。特にGEを表示するとやたら綺麗だなあ。あとはWindows上のVMWare PlayerでUbuntu入れる。
補足: Boot CampだとWindowsエキスペリエンスインデックスは7.2, 7.5, 6.5, 6.5, 7.9。OSX-VMWareFusuionだと5.7, 5.5, 5.9, 4.9, 7.9なのでずいぶんと差がある。(11/11追記)
...................................................................................................................................
Several bugs especailly concerning RINEX are fixed.
-------------------------------------
13" Retina MBP来た。2.9GHz Core i7 + SSD 256GB。PDFの論文を2頁見開き表示させても、ちゃんと文字が読めるのはさすが。MBAに比較するとやっぱりちょっと分厚くて重いのと、コネクタが変更されていて (MagSafe2) MBAのACアダプタが流用できなかったのがちょっと誤算。さてWindowsの導入は、VMWare FusionにするかBoot Campにするか。MBAではBoot Campに不具合があってスリープが使えなかったので、RAM 8GBあるしVMWareかなあと。でも、Windows 8 あんまり使う気にならないのだけど。
...................................................................................................................................
オーストラリアCUT07局の39衛星見える時間帯の衛星配置。このプロットを書く場合の問題はGalileoとCompassの衛星位置をどう計算するかだが、エフェメリスがない場合は、NORAD TLEを読み込む様にした。TLEからECEF位置を計算するのはかなり面倒なのだが、頑張ってSTR#3 (Spacetrack Report #3) SGP4のFortranコードを移植した。この機能はRTKLIB 2.4.2に入る。
補足: TLE計算にバグを見つけたので差し替え。TLEエポックのDOYを0から始めていた (1が正しい)。Galileoの可視時間が合わないので気付いた。なお TLEやSGP4モデルの補足としてはこのレポートが詳しい。(15:16追記)
補足: RTKNAVIもTLE対応。もうこれに近いかな。(16:18追記)
補足: 上記のように日本版WikipediaのTLEのLine 1 注2の記述は間違っているので注意 (一日ずれ)。あとPRN番号-衛星名の対応表 (2012/11/1現在)。(22:37追記)
補足: 測位衛星のエフェメリス精度は数mはあるので、これと比較することによりTLE軌道精度を見積もることができる。実際比較してみるとGPSのTLE軌道で最大で30km位の誤差がある様だ (これには地球回転パラメータを無視している分も含まれている)。TLE軌道精度として1 kmとか書いている文献が多いのだけど、これはLEO衛星の値でMEO衛星には当てはまらないのかもしれない。まあ30kmずれてても視線角度にすると0.1度以下なのでskyplotを書く分には問題はない。(11/03追記)
...................................................................................................................................
内閣府, 準天頂衛星システム関連: 調達情報, 実施方針に関する質問への回答, 平成24年10月31日
とりあえず貼っておく。
補足: 質問回答中で「業務要求水準書 (案) の変更版」が参照されているが、これはまだ公開されていない様。質問にもある様に、SBAS準拠は制約が多すぎるので、次期MSAS用トラポンだけ静止衛星に載せて、L1S/L5SはSBAS準拠にこだわるべきでないというのが個人的な意見。もう一機次期MSAS用の衛星がいるけど、これはどこかの通信衛星借りればよい。(11:36追記)
再補足: SBASって1990年代に仕様が策定された様に、現在あるいは未来の (特に地上での) GNSS利用には役不足なレガシーだということ。これを20年先まで使い続けるなんてナンセンス。でも航空機搭載受信機のサポートを切る訳には行かない訳で、共用化は無理があるということ。(18:16追記)
再々補足: SBAS規格のレガシーさは、例えば、補正値の分解能が12.5cmだとかいうのが典型的。IGPのグリッドが固定なのも問題で、例えばある地域だけ電離層補正精度上げるため間隔狭めたいとかもできない。でいながら例えば今のMSASもL1SAIFもかなりの時間無駄なデータを送っている。結局目的が航空機だから、地上で使う目的の仕様になっていないということ。L1S、L5Sの補強メッセージは地上ユーザ、特にビジネスユーザの有効利用のため再設計して最適化すべきだと思う。(11/03追記)
-------------------------------------
RTKLIB 2.4.2 b3での実装の現状 (参照)。
(1) △ (2) ○ (3) △ (4) × (5) × (6) ○ (7) ○ (8) × (9) ○
正式版まで、まだまだ先が長い様で。
-------------------------------------
いつの間にか11月だあ。
...................................................................................................................................
| Home | by T.Takasu |