日記・備考録 |
2005 |
2006 |
2007 |
2008 |
2009 |
2010 |
2011 |
2012 |
2013 |
2014 |
2015 |
2016 |
2017 |
2018/ 1
2
3
4
5
6 7
8
9
10
11
12 |
2019 Search |
September | October 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 31 |
November | Home |
....................................................................................................................................
毎日, 測位衛星「みちびき」1日から運用 宇宙の商業利用の柱, 2018年10月31日
QZSSの正式サービス開始まで残り1日。
....................................................................................................................................
青が4本。下はBD982 (F/W 5.37)。QZSS4機同時受信は自分で購入または入手した市販受信機では初。受信機は秘密。よーく見ないと分からないが、2周波対応である。QZS-3 (PRN199) L1C/AのC/N0は38-40 dBHz。これ位受かるなら、もしかするとスマホでも行けるかもしれない。
....................................................................................................................................
QZSS概況: 2018/10/25 05:20 UTC頃、QZS-1 L1C/A
(PRN193) 信号停止、9:30 UTC頃、信号送信再開したが、11:50頃、再度信号停止、23:50
UTC頃、信号送信再開、アラートON。2018/10/26
15:00 UTC頃、アラートOFF。NAQU2018611によれば、サービス停止期間は1日9時間52分。過去QZS-1で、予定保守以外でL1C/A信号が停止した事象はなかったのではないかと思われ、何らかのトラブルと推測されるが、詳細は不明。まじかに迫った、正式サービス開始に影響がなければよいのだが。
補足: 「QZS-1で、予定保守以外でL1C/A信号が停止した事象はなかった」などと書いてしまってから、本当だろうかと少し心配になって過去の「予期せぬ活動停止」の記録をNAQUで再確認。昨年3月内閣府 移管以降。
2017/07/04 16:53 - 07/04 22:45 NAQU2017031
2017/07/05 02:12 - 07/05 11:05 NAQU2017037
2017/07/05 16:41 - 07/19 06:06 NAQU2017051
2017/08/20 02:00 - 08/20 03:03 NAQU2017067
2017/12/01 15:32 - 12/03 08:26 NAQU2017125
2018/02/11 16:00 - 02/12 05:05 NAQU2018113
2018/02/12 07:00 - 02/14 14:44 NAQU2018121
2018/10/25 05:22 - 10/26 15:16 NAQU2018611
確認している範囲では、このうち、2018/02/11、10/25の障害ではL1C/A信号が停止している。人の記憶は曖昧なものである。(14:48追記)
....................................................................................................................................
QZSS概況: 2018/10/23 18:20 UTC頃、QZS-3 L1C/A (PRN199) アラートOFF。NAQU2018606によれば、サービス停止期間は1日11時間18分。
....................................................................................................................................
QZSS, みちびき2018年11月1日サービス開始
公式頁でカウントダウンが始まった。
-------------------------------------
QZSS概況: 2018/10/22 07:00 UTC頃、QZS-3 L1C/A (PRN199) アラートON。(NAQU2018586)
....................................................................................................................................
RTKLIBで受信機データをRTCM MSM 7に変換しているコードがあって、その出力が、普通には問題ないけど、たまに認識できなくなる事象が発生していた。調べてみると、GPSの衛星数が13以上になると起きる様で、どうもMSM
7のエンコードがRTCM 3のメッセージサイズ上限を超えているみたいだなあ。バッファオーバーフローチェックが入っていないのも、場合によってはメモリ壊すので問題。これ単純なバグなのだけど、直すのにはメッセージを分割する必要があり、かなり面倒。とりあえずの対策としてはMSM 7をMSM 4に変更する等して下さい。また、RTKLIBのコードを何らかのプロジェクトに流用しておられる方は注意を。これ、なるべく早く対策します。
補足: 良く調べてみるとメッセージサイズ上限を超えていた訳ではなく、RTCM MSMメッセージのCell Mask数 (衛星数 x 信号数) 上限 (64) を超えていたのが原因。問題が発生した受信機では、GPSに関して、1C, 1W, 2L, 2W, 5Q 5種の信号を追尾しており、衛星数が13になると、5 x 13 = 65 と上限64を超えてしまう。これはMSM 4 でもMSM 7でも同じなので、MSM 7をMSM 4に変更しても問題を回避できない。なお、RTKLIBでは、RTCM MSM受信時にCell-mask数をチェックし、上限を超えた場合にはメッセージを破棄するが、チェックしない受信機の場合、正常に受信できてしまう可能性もある。RTCM 3.3 にこの辺の注記を見つけたので少し長いが引用しておく (RTCM 3.3 (2016) 3.5.16.3.5)。いずれにしてもメッセージ分割機能の追加は必要。(10/22追記)
> Notes:
> - The size of the cell mask is not fixed,
but is determined after decoding the satellite
and signal masks. The size
> of cell mask is X=Nsat*Nsig, where Nsat
is the number of satellites (the number of
bits, which are set to 1 in
> satellite mask), and Nsig is the number
of Signals (the number of bits, which are
set to 1 in signal mask).
> - The limit X.64 is selected to guarantee
the full size of MSM7 (the largest MSM) fits
into a single RTCM-3
> transport frame.
> Preliminary estimates of the full size of
MSM7 under an X.64 condition do not exceed
5865 bits, which is about
> half of the maximum permissible size for
any RTCM-3 message.
> - In most real time applications, data to
be transmitted will fit the limit of X.64
(e.g. Nsat.16, Nsig.4),
> therefore all data for a given GNSS should
be able to be generated within a single RTCM-3
transmission most of
> the time.
> - In case where there are many satellites
and signals for a given GNSS, it is the responsibility
of the encoding
> software to ensure that the :X.64; rule
by dividing the complete observation set
among several messages. For
> example, if Nsat=14 and Nsig=6 (i.e. up
to 14*6=84 observables), then the encoding
software must use 2 separate
> transmissions, e.g.:
> The first for 7 Satellites and 6 signals
> The second for the remaining 7 Satellites
and 6 signals
> In this case, the multiple message bit must
be set accordingly. For more details, see
section :Multiple MSM
> output below.
再補足: とりあえずSupport Info No.143に追加 (参照)。(10/22追記)
再々補足: 本件、RTCM3エンコーダ側でメッセージ分割するのはコード修正量がかなり多くなるので、APIを呼ぶAP側でメッセージを分割するものとします。以上より、encode_rtcm3() を呼ぶ条件として、入力データの衛星系毎の衛星数×信号数が64を超えないものとし、条件を満足しない場合には正常なメッセージを生成できません。RTKLIBのAPで、このAPIを呼んでいるのは、STRSVRとSTR2STRだけ (受信機データをRTCM3に変換する所で使用) なので、これは今後修正します。何故、こんな細かいことをくどくどと書くかというと、既にこのAPIを直接使ったAPが動いているプロジェクトがあるかもしれないからで、その関係者に注意を喚起するため。(10/22追記)
....................................................................................................................................
Trimble BD982だけど、F/W 5.37からGalileoの信号捕捉性能が悪くなってしまった。ウチにある2台共5.37に上げたのだけど、比較のためそのうち1台を5.34にdowngrade。以下、上がF/W 5.34、下がF/W 5.37。同一の分配機に接続しているので条件はほぼ同じ。F/W 5.34では6機受かっているGalileoがF/W 5.37では3機。F/W 5.37ではGalileoは5機以上は受からない様だ。また、F/W 5.37でQZS-3 (PRN199) に対応したのは嬉しいが、QZSSも最大3機で、4機は同時に受からない様だ (涙)。BD982、Maxwell 6 220CHなので、CH数制限から同時追尾衛星数を絞っているのではないかと推測される。u-bloxみたいに衛星系毎に最大CH数を指定できれば良いのだけど、Trimbleにはその様なオプションは無い様だ。ということで、最新Maxwell 7 336CH、小型、軽量でバッテリ駆動ができそうなBD940が欲しいのだけど、AliExpressの出物でもまだ少し高い (参照) ので我慢している。
....................................................................................................................................
PC Watch, Huawei, 最新フラッグシップスマートフォン「Mate 20」シリーズ発表, 2018年10月17日
Huawei Mate 20が正式発表。"Leading Dual-frequency GPS for Super-precise Positioning L1+L5 vs. L1 Only (iPhone Xs Max, Galaxy Note 9) 10X Positioning accuracy" とのこと。多分, GNSSチップセットはBCM47755ではないかと思う。Android 9 Pie だし、\6万位なら買っちゃうかも。
補足: 一番後ろの方に価格が書いてあった。Mate 20 4GB/128Gが799ユーロ (\103,454) とのこと。最近のスマホは皆高い。(10:38追記)
再補足: QZSS L1+L5にも対応 (参照)、日本版のMate 20/20 ProはFelicaにも対応 (参照)、とのこと。(10:57追記)
-------------------------------------
M8P (GPS+GLO) と M8T+ RTKLIB (GPS+GLO+GAL+QZS+SBS) 移動体RTK比較。M8T + RTKLIBで、FIX率が極端に下がる結果が出て、QZSSを追加したからではないかとしている。
これホントにQZSSが悪さをしているのかなあ。少なくともSBASは入れない方がよい気が。
以上を、確認するためには、時刻タグ付ログをとって、ログ再生で条件を変えて比較してもらえばよい。ただ、2.4.3 bでは時刻タグ付ログ再生RTKが正常にできないバグがあるみたいで。報告もらっていたのだけど、2.4.3 b30での修正を忘れた (2.4.2 p13は正常)。自分でビルドできる人は以下を修正して再ビルド下さい。次のリリースで修正をします。
rtklib 2.4.3 b30: rtklib/src/stream.c L705
t=(unsigned int)((tickget()-file->tick)*file->speed+file->start*1000.0);
->
t=(unsigned int)((tickget()-file->tick)*file->speed+file->start*1000.0);
tick_master = t;
補足: RTKLIB 2.4.3 b30から、Windowsバイナリのビルド環境を、概ねフリーで使えるC++ Bulder 10.2.3 (communty edition) に変更。ただ、メインPCのWindows 7上に、C++ Builder 10.2.3を入れようとして失敗し、元の10.2.1の再インストールも失敗し、使えなくなってしまった。色々とレジストリ削除したがダメ。結局、ノートPCのWindows 10環境に10.2.3を入れて、そちらでビルドしている。メインPC、未だにCore i7 2600Kと7年前のCPUなので (Sandy Bridge、傑作だと思うけど) 、流石にそろそろOS含めて新しくしたい。(9:59追記)
....................................................................................................................................
BlackDot GNSS, Ionosphere Modelling for PPP-RTK, October 13, 2018
広域PPP-RTK用電離層モデルの評価。今、ちょうどPPP-ARのTTFF高速化について少し本格的に取り組もうかなあか、と思っているので。TTFF高速化に電離層モデルがキーであることは間違いない。
ION GNSS+ 2018 のアブストはこちら。筆頭著者はNRCanのSimon、他に、SwiftNavのMichele他の名前も見える。Sebastienって前に低価格RTKの研究やってたはず (参照) だけど、SwiftNavに入ったんだ。
....................................................................................................................................
AliExpressに、ZED-F9PのモジュールとEVKボードが出品されている。各々、$470、$1,129、と結構な値段がする。出荷は2-3週間。さて、そろそろ一般でも入手できそうだが。
-------------------------------------
NASASpaceFlight.com, Long March 3B launch conducts China's 28th launch of the year, October 14, 2018
2018/10/14 04:23 UTC, 2機のBeiDou-3衛星 (3M15, 16), 中国Xichang宇宙センターからLong March 3B/YZ-1ロケットで打ち上げ成功。BeiDou衛星としては9/19のBeiDou-3衛星2機の打ち上げ以来、39, 40機目。軌道はMEO。これで運用停止の衛星を除いて、軌道上のBeiDou衛星は全38機、うちBeiDou-3 21機。今後、11月にBeiDou-3M17, 18 、12月にBeiDou-3 GEOと、今年中にあと3機のBeiDou-3衛星の打ち上げが予定されている。
....................................................................................................................................
u-blox, ZED-F9P u-blox F9 high precision GNSS module Integration Manual, October, 2018
ZED-F9Pのインテグレーションマニュアルが公開。有用な情報が多い。某所から貰ったログには、BeiDou B2Iのデータが含まれていなかったが、3.6を読むと設定でenableに出来る模様。4.7に、やっとUBX-RXM-SFRBXの詳細形式が。実はこれ今まで公式文書はなく、RTKLIBのublox.cは実データを解析してコードを書いていた。GPS/QZSS L2C CNAV (4.7.2)、 Galileo E5b I/NAV (4.7.5.2) は、RTKLIB 2.4.3 b30ではまだ未サポート。そろそろRTKLIBでもCNAVのサポートを追加する必要があるかも。
....................................................................................................................................
GitHub, RTKLIB 2.4.3, RTKLIB_bin 2.4.3
久しぶりにRTKLIB 2.4.3 betaを更新。2.4.3 b30。
某所からu-blox ZED-F9Pのログを送ってもらったので、ZED-F9PのUBX-RXM-RAWX, UBX-RXM-SFRBXサポートが追加されている。
補足: ついでに、RTKLPLOTのGM (Google Map) Viewが正常表示されない問題対応として、RTKPLOTオプションでAPI Keyを入力すればよい様にしました。API Keyを有効にするためにはRTKPLOTの再起動が必要かもしれません。(10/13追記)
....................................................................................................................................
新しいGoogle Pixel 3はQZSSでの測位はできないの、みたいな話 (参照) が出ているが (噂の出所はこれあたり ?)、普通に考えれば、SoCとしてQualcommのSnapdragon 845 (参照) 載ってる訳だがら、QZSSが受からないはずはない。まあ、あえてF/Wでdisableにしている可能性がない訳ではないけど。そのうち誰かが検証してくれるでしょう。BCM47755が載っていればともかく、高すぎるし、個人的にはPixel 3には全然興味がわかない。
補足: Android Developpers のRaw GNSS Measurementsの頁 (参照) が更新されてQZSS対応携帯端末の数が増えている。このリストによれば、QZSSに対応している携帯端末は、Xiaomi Mi 8, LG V40 ThinQ, OnePlust 6T, Samsong Note 9, Huawel P20, Samsong Galaxy S9, Sony Xperia XZ2, Huawei Mate 10 Pro, Google Pixel 2 XL, Google Pixel 2, Samsong S8 (Exynos), Huawei P10。QZSSの頁 (参照) によれば、以上に加えて、Apple iPhone 7/7 Plus/X/8 Plus/8/XS/XS Max/XR, Sharp AQUOS R/R compact/R2/sense plus, Samsong S8+/Galaxy Note8, HTC X2/U11 life, Sony Xperia XZ2 Premium, がQZSSに対応とのこと。といっても以上の端末で、QZS-3の信号を受信できるものはまだないはず。(21:28追記)
-------------------------------------
三菱, 準天頂衛星対応センチメータ級高精度測位端末「AQLOC」発売, 2018年10月5日修正
11/1に発売予定の三菱のQZSSセンチメータ級測位補強サービス対応の受信機AQLOCの仕様が変更になった様だ。発売直前に仕様変更とは、色々と内情が推察されるが、昨年GNSSシンポで三菱の人に質問した際の回答「販売予定価格 100万円以下」は変わらないのでしょうね ? (昨年11/10の記事参照)
-------------------------------------
European GNSS (Galileo) open service Signal-in-space space interface control document, Issue 1.3, December, 2016
GalileoのOS-SIS-ICDがいつの間にかIssue 1.3になっていた。現在、Galileo関係のエンジニアからRTKLIBにプルリクを貰っていて、その中に航法データのSISA (signal-in-space accuracy) の取り扱いについてのものがあったので、確かまだSISA未定義じゃなかったっけ、とよく調べたら、Issue 1.3の5.1.11で規定が追加されていた。SISA index = 255 は、NAPA (no accuracy prediction available) と呼ばれるステータスを表し、障害の可能性を示す場合に送られるとのこと。
-------------------------------------
GPS World, Swift Navigation Starling GNSS engine available with Broadcom BCM47755 chip, October 10, 2018
SwiftNavの "Starling" が何者なのか公式発表見ても全然分からないので、コメントは控えるが、Broadcom BCM47755と組み合わせたデモをやった様だ。
-------------------------------------
多分、意図的なのだとは思うが「QZS-3(GEO:静止衛星)からはL1C/A信号が送信されない」とデマを流す人がいるので注意。といっても、未だに多くの受信機やスマホでQZS-3の信号が受からないのは事実。時間が立てば徐々に対応していくことは間違いないが。
-------------------------------------
BD970用にアップされているBD9xx_WinFlash_537が、BD982にも対応していることが分かったので、これを使ってBD982のF/W更新。手順は、USBケーブルでBD982をPCに接続。WinFlashを実行。Device typeでTrimble OEM Receiver、PC serial portで仮想COMポートを選択。OperationsでLoad GPS softwareを選択。Available SoftwareとしてBD982_FW_V5.37を選択。確認ダイアログのOKをクリック。Software Upgradeダイアログで更新ステータスが表示され、更新が終わると受信機が自動的にリブートされる。リブート直後、GalileoとQZSSはなかなか信号捕捉しないが、しばらく待つと受信できる。QZS-3 L1C/A (PRN199) のC/N0は36.4 dBHz。
これで、やっと全QZSS衛星の信号を本格的に受信できる体制が整った。とてもうれしい。(受信機自身がまだL1C, L5Sには対応していないが)
補足: F/W 5.37からC27,28,30とBeiDou-3のB1I信号も受かる様になったようだ。(7:10追記)
再補足: BD982の公式にもF/W 5.37のイメージがアップ。release notesによると、主な変更点は、Google Mapsサポート削除、BD982と970におけるQZSS PRN199-202のサポート、BeiDou-3のサポート。(10/13追記)
....................................................................................................................................
Trimble, Test Drive Our Receivers
主なTrimbleのOEM受信機は"Test Drive" と称して試験機がweb公開されている。10/9現在、BD982のF/Wが更新されて、5.37 (release date 2018-09-21) になっている。メニュー Satellites - Enable/Disable - QZSS を見ると、やっとQZS-3 (PRN199) がサポートされた様だ。ただ、5.37のF/Wイメージはまだ未公開 (参照)。探してみたけど、入手先は見つけられなかった。もう少し待ってみよう。
....................................................................................................................................
菅原, 西口, 豪州における農業分野での準天頂衛星実証のご紹介, 測位航法学会ニューズレター, 2018
2016年10、12月および2017年2月に豪州で実施した、MADOCA-PPPを使った、農業機械自律走行、およびドローンによるセンシングシステム実証。それぞれの測位誤差評価結果は、H 7.5 cm/V 8.7 cm、およびH 6.7 cm/V 12.1 cm (RMS) とのこと。「MADOCA用受信機」を使ったとのことだが、この時期にQZSS LEX (L6) とMADOCA-PPPをサポートした市販受信機はなかったはずなので、具体的に何を使ったかは良く分からない (MSJ社製の試作機とか ?)。
....................................................................................................................................
QZSS概況: 2018/10/02 11:12 UTC頃、QZS-2, 3, 4 L6E (PRN204, 209, 205) MADOCA-PPP補強データ送信再開。
-------------------------------------
QZSS概況: 2018/10/02 02:10 UTC頃、QZS-3, 4 L6E (PRN209, 205) MADOCA-PPP補強データ停止。QZS-2 (PRN204) の状況は、仰角が低くて確認できてない。GPAS運用情報には停止予定はないので何らかのトラブルではないかと思われる。
補足: GPAS運用情報に利用不能情報が追加されたが、2018/10/02 5:29 UTC現在、まだ復旧していない。(14:29追記)
-------------------------------------
QZSS概況: 2018/10/01 09:00 UTC頃、QZS-1-4 L6D (PRN193, 194, 199, 195) アラートOFF。NAQU2018534, 535によれば、QZS-1,2のセンチメータ級測位補強サービス停止期間は18日8時間49分、NAQU2018536によれば、QZS-3のサービス停止期間は108日0時間55分、NAQU2018537によれば、QZS-4のサービス停止期間は23日8時間49分。NAQU2018538によれば、以降のサービスはIS-QZSS-L6-001 (Draft, August 31, 2018) に基づく。
-------------------------------------
QZSS概況: 2018/10/01 06:30 UTC頃、QZS-3 L1C/A (PRN199) アラートOFF。NAQU2018533によれば、サービス停止期間は12時間22分。
....................................................................................................................................
マイナビ農業, [PR] 日本の人工衛星が農業を変える ! 正確な位置情報がもたらすスマート農業, 2018年09年28日
MSJおよびMSJ製QZSS L6対応受信機の紹介。「CLAS方式とMADOCA方式にダブル対応し、従来の高精度受信機と比べ価格も10分の1程度を設定しています」 とのこと。
-------------------------------------
QZSS概況: QZS-1-4 L6D (PRN193, 194, 199, 195) サービス停止 (アラートON) 中。NAQU20180519-0521によるとQZS-1, 2, 4は9/13から、NAQU2018414によるとQZS-3は6/15から。NAQU20180522によると、サービス停止中 "further system test" の目的で IS-QZSS-L6-001 (Draft, August 31, 2018) に基づいた、センチメータ級測位補強メッセージが送られている。
正式サービス開始予定の1ヶ月前に、仕様を変更した上で、システム試験を目的にサービス停止するとは、正直なところ、11月の正式サービス開始を諦めたとしか思えないのだが...。
-------------------------------------
QZSS概況: 2018/09/30 UTC、QZS-3 L1C/A (PRN199) アラートON。昨夜の台風による停電で受信機が止まっていたので、何時アラートONになったかは確認できていない。
-------------------------------------
10月である。QZSSの正式サービス開始まで残り1カ月。
....................................................................................................................................
Home | by T.Takasu |