2021/02/01〜

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

2021/01/29

中川 他, 精密単独測位 (PPP-AR) を用いたGNSS定常解析システムの開発, 国土地理院時報133集, 2020

補正情報生成にはMADOCA、解析には「RTKLIB version 2.4.3 (Takasu, 2011) を改良したもの」を使用とのこと。

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

N.V.ナン 他, 低価格多周波GNSS装置の性能評価とロボット農機への適用可能性, 農研機構技報No.7, 2020

u-blox F9PのRTK性能評価。評価項目は測位精度、再FIX時間、方位角、自動化農作業航法精度。比較としてHemisphere Eclipse P326とA325。衛星測位分野では、9kmを「長基線」と言うことはあんまりないと思うが農業分野では普通なのかも (人によって違うかもしれないが「長基線」と言ったら100km超の感じ)。

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

B.Duan and U.Hugentobler, Enhanced solar radiation pressure model for GPS satellites considering various physical effects, GPS Solutions, 2021

GPS SRPモデルの改良。Open Access。対象はBlock IIA, IIR, IIFで、IIIは含まれていない。詳しくは後で読む。

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

2021/01/27

QZSS, サービス性能評価結果の公開について, 2021年01月27日

とのこと。今回は2020/4/1-9/30分。評価内容は衛星測位サービス (PNT) はSIS Accucary (95%)、SLASはPositioning accuracy (95%)、CLASはStatic Positioning Accucary (95%) とKinematic Positioning Accucary (95%) のみ。PS-QZSS-002にある、PNT: Ionosphere Parameter Accucary (4.3.2)、UTC Accuracy (4.3.3)、Almanac Accucary (4.3.4)、EOP Accuracy (4.3.5)、GGTO Accucary (4.3.6)、Availability (4.4)、SLAS: Availability (5.4)、Time to First Fix (5.7)、CLAS: Availability (6.4)、Time to First Fix (6.7) も性能評価対象にすべきと思う。また、2018/11/1-2020/3/31分の結果公開も望む。

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

https://forum.openstreetmap.org/viewtopic.php?id=9451&p=100

> ... rtklibの作成者は、覚えていれば、precision-gps.org（別名Kinematic）の機能から始めました
> が、何らかの理由で意図的にsirf2を嫌い、コードから完全に除外しました。それは「rtklib.com」
> でもありました。つまり、彼の目標は、コミュニティプロジェクトではなく、彼が唯一の作者とな
> る商用製品を作成することでしたが、問題が発生し、このビジネスを放棄しました。
(Google翻訳)

なんて書いてあるけど、もともと「商用製品を作成する」意図など全くないよ。RTKLIBの開発の目的は最初は研究の一環、後からは趣味と義務感。sirf2を嫌ったことは確かだけど、これは情報が少なすぎたから。ところで Kinematicはまだメンテされているのかな ?

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

2021/01/26

Google Research, Android smartphones high accuracy GNSS datasets

GoogleがGNSS raw dataのプロモーション用にAndroidスマホで収集したGNSS datasetを公開。形式はGoogle GnssLogger logとRINEX 3。使用スマホはPixel 4, Pixel 4XL、及び Xiaomi Mi8。比較用に同時に取ったNovAtel SPAN NMEA解とチップセットNMEA解も含まれるが、RTK/PPK用の近隣基準局データは含まれない。細かい点は、データセットに含まれるION GNSS 2020のpaperやプレゼンビデオを参照。

サイトに登録してダウンロードしてみた (圧縮ファイルで1GB位)。例えば、training\2020-05-14-US-MTV-1の下にある、RINEX3ファイルが4.5MBなのに比較して、GnssLogger Logは125.5MBと30倍近い大きさとなっている。中身を見てみると、GNSS生データ以外にセンサ (ジャイロ・加速度計・磁気計) データが含まれてはいるが、さすがにデータ格納効率の面で実用性がないと思う。ということで、今後、Google GnssLoggerが適当なバイナリ形式をサポートすることを望む。

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

2021/01/25

Zenn, Raspberry Piは本当に壊れやすいのか, 2021/1/6

ラズパイを組込機器に使うのはやっぱり心配、と思う人は多いと思うが、「どれくらい壊れやすいか」を評価した良記事。これを読む限り、シャットダウンしないで電源落としてSDカード壊すケースが最も多い様で、ファイルシステムのRAM化は必須の様。PocketRTKも、これが結構面倒で作業がずっと止まっている (ZED-F9Tが安くならず、モチベーションが上がらないのも理由の一つ)。

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

Core, Cohac ∞ CM-1 低価格3周波GNSS受信機

ニュースリリース (参照) には「Septentrio社のmosaic-X5を搭載し」と書いてある。「低価格」がどれくらいか興味があるが、ニュースリリースでは「50万円を大幅に下回る」とのこと。ただ、mosaic-X5 EVK (アンテナ付) がDigikey USで$985.01 (参照, \102,156) なのでちょっと高い。

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

2021/01/23

三神, 「みちびき」サービスの利活用加速に向けたSPACの取組み, 第18回SPACフォーラム, 2020年12月16日

SPAC (衛星測位利用推進センター) は4/1にJSS (宇宙システム開発利用推進機構) と合併。

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

https://twitter.com/Septentrio/status/1352620954162253827

mosaicHAT (参照) + ラズパイ。アンテナは最初 HC975 (参照) かと思ったがよく見ると少し違う。何だろ。mosaicHATも公開版とは異なる版の様で、micro SDカードスロット付。オールインワンで使いやすそうである。材料費だけだったら$1,000位で出来そうだが。

補足: 鈴木先生から連絡頂いて、アンテナはHC977 (参照) とのことである。現在改修中で、詳細は今後GitHubで公開予定とのこと。(1/25追記)

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

2021/01/22

https://github.com/YizeZhang/Net_Diff

精密GNSS測位解析ツールNet_Diff。パッケージに "A Comparison of Net_Diff and RTKLIB" (参照) という文書が含まれている。10年位前のアルゴリズムやモデルのまま進化していない (?) RTKLIBに比較して、新しめのアルゴリズムやモデルが含まれている様だ。開発は、東京海洋大 久保研究室ポスドク研究員のYize Zhang君 (参照, Google Scholar)。ツール本体のコードは主にMATLABで書かれている様だが、残念ながら配布はコンパイル済の実行形式のみ。可能ならソースを公開して欲しい。

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

H.Namie and N.Kubo, Performance Evaluation of Centimeter-Level Augumentation Positioning L6-CLAS/MADOCA at the Begining of Official Operation of QZSS, IEEJ Journal of Industry Application, 2020

正式サービス開始 (2018年11月) 後のCLAS/MADOCAの実性能評価 (MADOCAは技術実証)。受信機はMSJ。2019年6月、オープンスカイ固定点のRMS誤差で、CLAS: E 4.87cm, N 3.52cm, U 9.41cm、MADOCA: E 6.64cm, N 6.08cm, U 11.1cm (Table 4)。CLASについては、要求仕様 水平≦3.47cm、垂直≦6.13cm (RMS, PS-QZSS-002, Table 6.3-1) を満足していない。この原因が、サービス、受信機、周辺環境の何処に起因するか不明だが、客観的で継続的な性能評価が必要だろう。

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

2021/01/19

GitHub, maplibre/maplibre-gl-js

Proprietary化されたMapbox GL JSを置き換えるための、OSS web地図ライブラリMapLibre GL。プロジェクトが開始されたばかりだが、今のところこれが一番有力そう。

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

A.A-Zadeh et al., POD of small LEO satellites based on precise real-time MADOCA and SBAS-aided PPP corrections, GPS Solutions, 2021

real-time PPPによるLEO衛星POD (precise orbit determination) の性能評価。暦はJAXA MADOCA及びAU/NZ SBAS-aided PPPサービス。 SBAS-aided PPPサービスはAU/NZ SBAS test bedとしてGEO衛星 (Inmarsat-4F1) 経由で既に放送中とのこと。POD対象LEO衛星はGRACE-FO及びSentinel-3。比較のため、暦としてIGS暦、IGS RT暦、CNES暦も使っている。IGS最終暦比較でMADOCA暦, SBAS-aided PPP暦軌道の3DRMS誤差は、それぞれ3.8cmと7.9cm、クロック標準偏差は、それぞれ0.08nsと0.16ns。duty-cycle 40-100%を前提としたreduced dynamic POD解の3DRMS誤差が、それぞれ2.3-5.2cmと4.6-8.0cm。kinematic POD解の3DRMS誤差が、それぞれ5.2-7.7cmと14.3-16.7cmとしている。この結果だけからはMADOCA暦はかなり精度が良い様に見える。

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

2021/01/14

GSA, European GNSS (Galileo) Open Service Signal-In-Space Interface Control Document Issue 2.0, January, 2021

Galileo OS-SIS-ICD Issue 2, Rev. 0。改訂履歴によるとIssue １, Rev. 3 (Dec 2016) からの主な変更点は、(1) Secondary synchronisation patternの追加 (5.1.9.5)。(2) I/NAV word type 16 (Reduced clock and ephemeris data) の追加 (4.3.5)。(3) I/NAV word type 17, 18, 19, 20 (FEC2 RS for clock and ephemeris data) の追加 (4.3.5)。この通知によると、この新しいI/NAVは2021-22年にtest campaignを行い、2023年までに送信開始するとのこと。

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

2021/01/13

Hexagon, RTK From the Sky^(TM) Introducing the future of PPP

報道発表 (参照, 参照) だけで技術詳細は分からないのでコメントしずらいが、”world wide" の "instant fix" PPPサービスとのことである。研究開発状況の発表で、実用化可能性やサービス (開始) スケジュールは不明。Simonのblog (参照) でも触れていて、コメント回答では、その内容は "without regional ionosphere model" による "multi-GNSS and multi-frequency (in paticular E6) PPP" ではないかとしている。短中基線RTKにおいて、3, 4周波の (2周波に比較した) 性能面の寄与はそれほど大きくない、というのが一般的な理解であるが、長基線やPPPでは異なるのかも。一部の受信機 (OEM729やBD990) では普通にGalileo4周波信号 (E1, E5a, E5b, E6) を追尾できるので、まずはRTKやPPKで4周波AR性能を評価してみるのは面白いテーマかもしれない。

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

2021/01/10

NTTdocomo, 最高時速290kmのフォーミュラカーで誤差約10cmの測位に成功, 2020年12月14日

F1のブレーキによる加速度は4G位 (参照) になる様だ (加速はもっと穏やか)。問題はこの加速度でPLLのロックがはずれないかどうか。OSQZSSさんの記事 (参照) によると市販受信機で4Gはギリギリの様だが。といっても実効上は衛星視線方向の加速度だから、通常はほとんどのケースで問題ないということなのかも。なお、Septentrioは受信機設定でPLL bandwidthを変更できるし、defaultでも追尾ループパラメータの”Adaptive mode”がONになっているので、ある程度自動的に調整されるのかもしれない。

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

2021/01/05

ぼちぼちとb34の不具合報告が。b33からかなりコードをいじっているので仕方ないとはいえいくつか致命的な問題が。早々にb35出さないとダメかも。

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

2021/01/03

RINEX: The Receiver Independent Exchange Format version 3.05, December 1, 2020

RINEX 3.05。やっと3.04に追いついたと思ったら既に3.05が出ていた。大きな変更としてはGLONASS航法データレコードの拡張。delta_TAU_n 結構効くので、これは歓迎。2.4.3の正式版までには対応したい。

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

2021/01/01

旧年中は大変お世話になりました。今年もご愛顧を。

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

〜2020/12/31