2016/02/01〜

...................................................................................................................................

2016/01/31

ちょっと買い物に出かけるついでにM8T F/W 3.01で移動体のデータ取ってきた (GPS+QZS+GAL+BDS, RXM-RAWX+RXM-SFRBX, 10Hz)。05:08:00-05:28:00 N=12001 (100.0%)。素晴らしい。

-------------------------------------

平成28年度 測位航法学会全国大会, 2016年4月26-28日, 東京海洋大学 越中島

正式発表が出ました。昨年度に引き続きRTKLIBセミナーを実施します。非学会員の方も歓迎です。セミナーまでには 2.4.3 (または 2.5.0) がリリースされるはずなので、講義内容には新バージョンの解説も入る予定。

-------------------------------------

[time-nuts] Fwd: CGSIC FW: Official Press Release - GPS Ground System Anomaly

これは教えてもらったのだけど、1/26にGPS地上システムの障害が発生していたらしい (GPS World, InsideGNSS)。米国空軍の公式発表によると、SVN23 (PRN32) の退役に伴った地上系ソフトウェアの問題に起因して、UTCタイミング信号が13μ秒ずれる事象が発生。この問題は6:10 MSTに解決したが、全世界のユーザが数時間にわたって影響を受けた。地上系ソフト改修までは、問題が再現しない様に運用手順を変更する。

「UTCタイミング信号」の意味が良く分からなかったので、少し検索。このスレッドあたりに細かい情報が上がっている。Martin Burnichkiさんが細かく調べてくれているが、

> The problem was that some satellites were sending invalid UTC correction
> parameters. The UTC correction parameter set not only contains current
> leap second information but also coefficients (A0, A1, WNt, tot) for a
> polynomial used to compensate the fractional difference between GPS time
> and UTC(USNO).
>
> Normally A0 (the constant offset) is very small, close to 0. WNt and tot
> give the week number (truncated to 8 bits) and second-of-week for which
>A0 is valid, i.e. the reference time for the time correction parameters.
> WNt is currently about 89.
>
> Today the faulty satellites sent about 13.7 microseconds for A0, and WNt
> as well as tot were both 0. So when the GPS receiver updated its UTC
> correction parameters from a faulty satellite the UTC correction jumped
> from close to 0 to about 13.7 microseconds, which let the UTC time step,
> and when the GPS receiver received the UTC parameter set from a healthy
> satellite the UTC time stepped back.

とのこと。一部衛星から一時的にUTCパラメータとしてA0=-13.696 usの異常値が送信されたらしい。GPS同期型の基準周波数発生器の中には止まってしまうものもあるかも。測位にはほぼ影響はない。でも、WNtも異常値が送られているので、受信機側でちゃんと検査していれば該当データを除外できそうな気もするけど。

これ、実は全然他人事ではなかったりする訳で。多分、色々なイベントケースを模擬して試験しなければ見つかりっこないバグなので。

...................................................................................................................................

2016/01/30

メモ: u-center 8.20のインストールが悪さをしているのではないかと思うのだけど、Windows 10でu-blox受信機が仮想COMデバイスとして認識されなくなる問題が発生する様になった (Windows 7では発生していない)。とりあえずの回避方法。

(1) デバイスマネージャで [センサー] - [u-blox GNSS Location Sensor] を右クリックし「削除」実行。
(2) 「このデバイスのドライバーソフトを削除する」をチェックして「OK」。
(3) u-bloxのUSBケーブルを抜いて、再度刺す。
(4) 一時的に仮想COMデバイスが復活するが、自動的に「u-blox GNSS Location Sensor」のドライバが再インストールされ、仮想COMデバイスが無効になる。
(5) 再度、デバイスマネージャで [センサー] - [u-blox GNSS Location Sensor] を右クリックし「プロパティ」実行。
(6) [ドライバー] - [ドライバーを元に戻す] を実行。仮想COMデバイスが復活する。(!) のついた仮想COMデバイスが残るのでこれは削除。
(7)「u-blox GNSS Location Sensor」としてu-bloxに接続すると、受信機側の色々な設定がリセットされてしまう様で、u-center等を使って再設定が必要。

以上、多分u-blox GNSS Location Sensorドライバのバグ起因ではないかと思うが、ドライバの完全アンインストールはうまくいっていない (pnputilで削除してもゾンビの様に復活する)。

補足: この問題まだ上がってないみたいだけどとりあえず u-blox サポートフォーラム。(13:08追記)

...................................................................................................................................

2016/01/28

RTKLIB 2.4.3 beta

RTKLIB 2.4.3 b8に反映。betaなのであんまり試験はしていない。

-------------------------------------

ということで、こんなことをやっている暇はないのだけど、悔しいのでGalileo航法データデコーダを書く。OS-SIS-ICD 1.2。

(1) RXM-SFRBXのメッセージサイズは52bytes。E1-Bなので含まれているのI/NAVのはず。細かくは、F/W 3.01 protocol specification 9.5参照。
(2) I/NAVの構造はICD 4.3参照。frame/720s、sub-frame/30s、nominal page/2s、120bits/page。
(3) CRCはtail fieldをのぞいた114 + 82 bit。crc_24q()を使えるが8で割り切れないので右詰が必要。
(4) word type=1〜4がephemeris, word type=5がiono, BGD,SVH, word type=6がUTCパラメータ。

なぜか、クロックパラメータがNovAtelと一致しないのだけど、一応は動いた。

F/W 3.01では10Hzでも概ね問題なく動く様だ。あと、UBX-CFG-GNSSのflagsが拡張されているので、ubx_m8t_glo_raw_1hz.cmdとubx_m8t_bds_raw_1hz.cmdは少し直す必要がある。

補足: NovAtelと食い違っていたのは、NovAtelのGALEPHEMERISBにはF/NAVのTOC, af0, af1, af2が含まれており、そちらを優先していたため。GalileoではI/NAVとF/NAVのクロックパラメータは異なる。novatel.cを修正しI/NAV優先にして比較したら一致したので多分OK。(21:20追記)

-------------------------------------

M8TでもM8Nと同じF/Wイメージでアップデートできると教えて頂きました。ということでNEO-M8TカードもF/W 3.01にアップデート。RXM-RAWXはちゃんと出力されている。静止条件なら5Hzでも問題ない様。昨日書いたように2.4.2 p11ではまだ航法データが使えないので、GalileoはSkyPlotには出ない。

補足: 改めて書くまでもないですが、u-bloxがちゃんと保証しているか微妙なところなので、M8TのF/Wアップデートは自己責任で。(8:46追記)

再補足: これも教えてもらいましたが、u-blox社としては公式のM8TのF/Wアップデートは一般公開しないとのこと。ということでM8N用F/Wによる、M8TのF/Wアップデートは保証されない利用となり、一部機能が失われる場合がありますのでご注意を。(2/1追記)

...................................................................................................................................

2016/01/27

CSG-shop u-blox NEO-M8NカードのF/Wを3.01にアップデートしてみる。

(1) u-center 8.20をインストール。
(2) M8 firmware v 3.01をダウンロード。(UBX_M8_301_SPG.911f2b77b649eb90f4be14ce56717b49.bin)
(3) u-center 8.20でu-blox M8Nに接続。
(4) u-centerのメニュー [Tools] - [Firmware Update u-blox 5 - 8] を実行。
(5) Firmware imageに (2) のbinファイルを指定。Flash Information Structure (FIS) fileにC:\Program Files (x86)\u-blox\u-center_v8.20\flash.xmlを指定。Use this Baurate for updateに115200を指定。OKを押下。
(6) 書き込みログが表示されて、ログウインドウが緑色になればOK。
(7) u-centerのメニュー [View] - [Configuration View] でConfiguration Viewを出して [GNSS] Galileoのenableをチェックして[Send]。
(8) UBX-SVINFO及びUBX-RXM-SFRBXのMessage View。Galileo E22, E30が受かってかつRXM-SFRBXが出力されていることが分かる (SkyPlotではE22のみ)。流石にM8NではRXM-RAWXは出ない。

(9) UBX-MON-VER
Software Version: EXT CORE 3.01 (107900)
Hardware Version: 00080000
Extension(s): ROM BASE 2.01 [75331], FWVER=SPG 3.01, PROTVER=18.00, FIS=0xEF4015 [100111], GPS:GLO:GAL:BDS:SBAS:IMES:QZSS

補足: TRK-MEAS (0x0310), TRK-SFRBX (0x030F) は出なくなったみたい。でも (0x2700) というメッセージが出てるけどこれ何だろう。(23:49追記)

再補足: 誰かがクラックしてくれるのを待つか。とりあえずフォローするためのロシア語フォーラム。(1/28追記)

-------------------------------------

u-blox, u-blox M8マルチGNSSレシーバー, エンベッドセキュリティーで最高レベルのパフォーマンスを達成 新しいu-blox M8, Galileoのサポートを追加, 感度とセキュリティが向上, 2016年1月26日

F/W 3.01がリリースされてGalileoのサポートが加わったみたいだけど (F/WはまだWebサイトにアップされていない)、M8Tもアップデートできるのかなあ。Reachも入れると手元にM8T受信機7台もあるのだけど (M8Nを加えると10台)。

補足: RTKLIB 2.4.2 p11では、RXM-SFRBXのGalileo航法データデコード機能がまだ未実装なので、F/W 3.01でサポートが追加されたとしてもGalileoはまだ使えない見込み。どこかで対応はする予定ではあるけど、航法データのデコードってかなり面倒なのでいつになるかは不明。(9:54追記)

再補足: F/W 3.01。ただしM8N用。M8Tに入れるとRXM-RAWXが使えなくなるらしいので注意。 (1/28削除) リリースノートを読むとRXM-SFRBXが "now a standard feature" とあるのでM8NでもRXM-SFRBXがサポートされる様になるらしい。(22:43追記)

https://www.u-blox.com/en/product-resources/10986

...................................................................................................................................

2016/01/25

構造計画研究所, 〜GNSS位置測位セミナー〜 〜GPS-Studio & SDR-SATの発売記念!〜, 2016年2月4日

まだ、空きあるみたいだなあ。

-------------------------------------

小暮, 高精度測位技術の応用について, 第13回クリティカルソフトウェアワークショップ (13thWOCS2), 2016年1月19-21日

小暮さん、お忙しそうである。

...................................................................................................................................

2016/01/23

SpaceFlightNow, PSLV lofts satellite for India's indigenous navigation system, January 20, 2016

2016/01/20 04:01 UTC, IRNSS-1E衛星, インド サティシュ・ダワン宇宙センタより, PSLVロケットで打ち上げ成功。軌道はIGSOで中心経度111.75E、軌道傾斜角28.1度。IRNSSはIGSO×4 + GEO×3の構成で、現在軌道上の衛星は、1A/1B (IGSO, 55E)、1C (GEO, 83E), 1D/1E (IGSO, 111.75E) の5機。残りのIRNSS-1F/1G衛星 (GEO, 34E/132E) は、2, 3月に打ち上げられる予定。

...................................................................................................................................

2016/01/19

UART1のProtocol in/outをnoneに、Baurateを921600に、設定してとりあえずデータ取ってきた。かなり改善はされるがやはり結構落ちる。これどうにかならないのか。

補足: データを10分間切り出してRINEX変換してエポック数を見る。N=2409 (80.3%)。念のため静止条件の5Hzデータ。N=3000 (100.0%)。あとなんか手はないのか。(17:32追記)

-------------------------------------

1/15に書いたu-blox NEO-M8Tのデータ落ちの件、UARTのビットレート設定を上げる必要がある、とご指摘いただいた。

調べてみるとUART1のBaurateがデフォルトの9600のままとなっていた。とりあえずProtocol in, Protocol outをnoneに、Baudrateを921600に設定して再度データを取ってみよう。

...................................................................................................................................

2016/01/18

Google Earth API (deprecated)

今さらながら、"The API will shut down in early 2016, and will continue to work on supported browsers until that date." とのこと。理由はNPAPIのセキュリティ問題。以前の発表では終了は2015年12月12日となっていたが、2016年1月現在、まだ使える様だ。RTKPLOTのGE ViewはWebブラウザコンポーネント上でこのAPIを使っているので、サービス終了に伴い、GE Viewは使えなくなる見込み。GE Viewとても使いやすいので残念。何らかの代替サービスが提供されると良いのだけど。

...................................................................................................................................

2016/01/15

TallysmanのL1/L2アンテナTW3865来た。Digi-Keyで\30,377也 (税込)。パッチが二階建てになっている。一応PRECISと組み合わせて低価格PPPの評価用。L6受かるかもという期待もあるのだけど、仕様的には無理だろうなあ (LNA改造すれば可能かも)。

-------------------------------------

Michele's GNSS blog, NT1065 review

MicheleがNTLabの4CHフロントエンドNT1065のレビューをしている。GNSS L帯信号全部対応しているし、帯域も25MHzまでとれるみたいで、結構良さそうな感じ。これ4つ使って16素子 (アクティブ) フェーズドアレイアンテナとか誰か作りません。

-------------------------------------

トラ技オフ会のネタ用に少しだけ移動体1周波RTK実験。受信機はCSG-ShopのNEO-M8Tカード。アンテナはTW2400とTW4721。WinタブはONDA V919 Air CH。基準局はLEA-M8TとGPS-703-GGG。

やはりTW4721はTW2400に比較してRTK性能が落ちる。あとM8T+GPS+QZS+BDS+5Hzではデータが結構欠落する。NMEAとかSBASは全部disableにしている。これ何とかならないのだろうか。

(RTKNAVI 2.4.3 b4, Rover: NEO-M8T+TW2400 (left), NEO-M8T+TW4721 (right), Ref: LEA-M8T+GPS-703-GGG, GPS+QZS+BDS, 5Hz)

補足: 静止観測では5Hzでも殆ど欠落は発生しない。移動体の場合衛星の入れ替わりが激しく、信号再補足の際にCPU負荷が高くなってデータを落としているのではないか。(17:18追記)

再補足: TW2400もTW4721もGPS-703-GGGに比較するとBeiDou B1 (1561.098MHz) のC/N0が3〜4dB落ちる。アンテナの仕様を見ると帯域がTW2400: 1574〜1606MHz、TW4721: 1559〜1606MHzとなっており、TW4721が有利に思えるが、実際にはTW2400でもTW4721でもBeiDou B1のC/N0は殆ど変わらない。(18:23追記)

再々補足: RTKNAVIオプションはGPS+QZS+BDS, Elev Mask=25, RAIM FDE=ON, AR=Fix and Hold+BDS ON, Elev to Hold Amb=30。後はデフォルト。Elev Maskは30の方が良いかも。せっかくなので取ったデータも時刻タグ付きで公開。(19:27追記)

再々々補足: RXM-SFRBXをdisableにして、4Hz、2Hzでも取り直してみたけど、2Hzでもやはりデータがかなり落ちる。これ何とかならないのか。(1/17追記)

...................................................................................................................................

2016/01/13

電子基準点 お知らせ

メモ: 2015/12/31 21:00-2016/01/01 21:00 UTCにかけて、一部のTrimble NETR9受信機でGLONASSの信号が正常に追尾できなくなる異常が発生していた様だ。GEONET局, IGS局以外でも問題を確認している。現在は復旧している。受信機F/Wの不具合の可能性もあるがTrimbleのサイトでは関連情報は見つけられなかった。

...................................................................................................................................

2016/01/09

トラ技, 衛星クロック搭載! GPS電子工作, 2016年2月号

少しだけRTKLIBの記事書きました。オフ会にも出席予定。

...................................................................................................................................

2016/01/06

Michele's GNSS blog

NV08C-RTKとNV08C-RTK-Aについて、"Rumors say that they both run an highly reworked version of RTKLIB on a LPC32xx microcontroller (ARM926EJ-S processor with VFP unit)." なんて書いているけどホントかなあ。

...................................................................................................................................

2016/01/05

QSS, 準天頂衛星「みちびき」2〜4号機のCG画像, 2015年12月23日

実用準天頂衛星2〜4号機のCG。1号機に比較すると、太陽電池パネルが3枚折りから2枚折りになって、アンテナもヘリカルからパッチに変更になったという理解で良いのかな。ただ三菱が公開している絵に比較しても、明らかにパネルのパースが変な気がする。設計情報なので、CG屋さんにちゃんとした構造図面渡していないのかもしれないけど。

...................................................................................................................................

2016/01/01

新年あけましておめでとうございます。今年も一年ご愛顧を。

...................................................................................................................................

〜2015/12/31