2018/03/01〜

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

2018/02/27

GPAS, お知らせ, 2018/02/26

> 2018年2月25日深夜（日本時間）より、準天頂衛星システム 「センチメータ級測位補強サービス（技術実証）」における
> 技術実証用補正情報が システム不具合のため停止しております。ただいまのところ復旧日時は未定です。ご利用の皆様に
> は大変ご迷惑をおかけし申し訳ございません。

とのこと。2018/02/27 12:00 UTC現在、まだ復旧していない。

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

2018/02/26

QZSS, データ提供サービス, L1S/L6データ提供サービス

> ※軌道時刻予報提供サービスの取り止めのお知らせ
> 初期測位時間の短縮のため、軌道時刻予報（OTF）の配信を検討してまいりましたが、組み込み装置の演算リソースや消費電力の観点およ
> び携帯電話やスマートフォンにおけるGPSアシストデータの利用の普及により、優位性を明確に示せる状況ではないため、OTF情報の配信
> を取りやめることとしました。利用者の皆さまには、ご理解いただきますようお願い申し上げます。

いつのまに、こんなアナウンスが。これって、サブメータ級測位補強サービスの説明会資料 (参照) にある、メッセージタイプ40, 41の放送もなくなったという理解で良いのかなあ。取りやめ理由が全く理解も納得もできないし、個人的にはとても残念。

補足: 「全く理解も納得もできない」というのは、私の理解では、もともと携帯電話やスマートフォン向けのサービスではないから。オンラインデータが利用できなくても、TTFFを早くしたい、消費電力を削減したいという、潜在GNSSユーザは沢山いるし、市場もあると思っているから。正直、... (以下省略)。(9:55追記)

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

QZS-3は信号受信できる受信機がほとんど存在せず、運用状況が分かりにくいので、整理のため試験サービス開始後の運用状況をNAQUを基にまとめておく。(時刻はUTC, NAQUはL1C/A, 2018/2/26 0:00 UTC現在)

2017/12/18 09:26 QZS-3試験サービス開始 (NAQU2017129)
2017/12/26 01:59 - 2017/12/27 17:25 QZS-3サービス停止 (39h 26m) (NAQU2017143)
2018/01/01 23:18 - 2018/01/02 13:39 QZS-3サービス停止 (14h 21m) (NAQU2018008)
2018/01/10 02:59 - 2018/01/11 08:13 QZS-3サービス停止 (17h 14m) (NAQU2018015)
2018/01/21 08:59 - 2018/01/22 02:14 QZS-3サービス停止 (15h 15m) (NAQU2018028)
2018/01/23 10:59 - 2018/01/23 14:16 QZS-3サービス停止 ( 3h 17m) (NAQU2018033)
2018/01/31 04:59 - 2018/01/31 08:00 QZS-3サービス停止 ( 3h 01m) (NAQU2018056)
2018/02/02 05:09 - 2018/02/02 12:12 QZS-3サービス停止 ( 7h 03m) (NAQU2018082)
2018/02/04 09:45 - ???? QZS-3サービス停止 (518h 15m) (NAQU2018090)

稼働率は 982.7H / 1670.6H = 58.8%。既に衛星単独service availability仕様の80%を下回っている。

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

QZSS概況: 2018/02/25 15:40 UTC頃から、QZS-2,4 L6E (PRN204, 205) MADOCA-PPP補強データ停止。信号は送信されているがデータがNULL。実証信号なので停止自体は仕方ないと思うが、公共のリソース使っている訳だから、ちゃんとアナウンスをして欲しい。QZS-3は未だ復活しない。サービス停止から3週間、最後の信号送信から2週間以上たつので、これも何らかの公式アナウンスがあってしかるべきだと思う。

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

2018/02/22

u-blox, u-blox announces u-blox F9 robust and versatile high precisiion positioning technology for industrial and automotive applications, February 22, 2018

u-blox F9発表。"multiple frequency bands (L1/L2/L5)", "all GNSS constellations", "optional on-chip Real Time Kinematic (RTK)", とのこと。ただし細かい技術仕様はまだ上がっていない。

補足: 2018/3/30 に「マルチバンド GNSSレシーバー F9 発表セミナー」@東京海洋大 越中島、開催 (参照)。(22:30追記)

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

2018/02/20

QZSS概況: 2018/02/20 05:15 UTC頃、QZS-4 L1C/A (PRN195) アラートOFF (NAQU)。QZS-3は未だ復活しない。

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

ライトハウステクノロジー・アンド・コンサルティング, ライトハウス、GNSS 4波のフロントエンドを開発、4月に発売、2018年2月20日

とりあえず、貼っておく。さて、これいくらで出すんだろう。

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

2018/02/19

QZSS概況: 2018/02/19 06:59 〜 02/22 06:59 UTC、QZS-4 L1C/A (PRN195) サービス停止 (NAQU)。アラートとSVHはONだが、信号は送信中。L6 (PRN195, 205) は通常通り。QZS-3は未だ復活しない。

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

2018/02/18

おととい書いた、snprintf() の落とし穴。問題はsnprintf() の戻り値。Linuxのman snprintfでは、

> The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')).
> If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating
> null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size
> or more means that the output was truncated. (See also below under NOTES.)

ということで、snprintf() からは、バッファに書きだした文字数ではなく、十分なスペースがあった場合に書き出すであろう文字数が返る。MSDNでも同様の記述 (参照) があるので、glibcの仕様は正しいのだろう。ただ、C, A reference manual, 5th ed., (2002) を探しても、以上の記述を見つけられなかった。ということで、以下の様なsnprintf() のラッパーを書いて、snprintf() を全部それに置換。

int my_snprintf(char *buff, size_t size, const char *format, ...)
{
va_list ap;
int n;
va_start(ap, format);
n = vsnprintf(buff, size, format, ap);
va_end(ap);
return n <= (int)size ? n : (int)size;
}

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

2018/02/16

QZSS概況: QZS-3信号復活せず。2018/02/18に復帰予定だったL1S, L6もサービス停止期間が延長され、"UNTIL FURTHER NOTICE" となった。復活を願う。

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

長い文字列を作成する際に以下の様なコードは良く書く。

char buff[1024] = "";
int n = 0;
n += sprintf(buff + n, ...);
n += sprintf(buff + n, ...);
...

sprintf() はバッファオーバフローを検出できず、セキュリティホールになりやすいということで、VSでは_CRT_SECURE_NO_WARNINGS オプションを付けないと警告が出る。ということで、以下の様に、最近のCコンパイラで大体サポートされており、C99でも規格化されている snprintf() を代わりに使うわけだが、

n += snprintf(buff + n, sizeof(buff) - n, ...);
n += snprintf(buff + n, sizeof(buff) - n, ...);
...

一見、全く問題なさそうに見える。ただこのコードは (少なくともglibcでは) ちゃんと動かず、バッファオーバフローを防げないのである。何故ちゃんと動かないのか考えてみてほしい。コアダンプするプログラムをデバッグしていて見つけた snprintf() の落とし穴。ということで、かなりの部分書き直し。

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

2018/02/15

三神, 準天頂衛星システム (QZSS) の測位補強サービスとその利用について, 日本航空宇宙工業会会報「航空と宇宙」2月号, 2018

CLASはともかく「MADOCAの補強情報から既存のRTK測量機を駆動させる」のは無理な気がするが。まあ「駆動」というのは別にRTKの性能を指している訳ではないのかもしれない。

補足: 「既存のRTK測量機」の入力は普通RTCM等の基準点データだけど、MADOCAの補強情報には、電離層、対流圏、衛星初期位相の情報が含まれていないから、結局基準点相当のデータを作ることはできない。色々と代替の実現方法を考えたけど、結論としては無理。(2/16追記)

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

2018/02/12

NASASpaceFlight.com, Long March 3B launches BeiDou-3 MEO-3 & MEO-4, February 12, 2018

2018/02/12 05:03 UTC, 2機のBeiDou-3 衛星, 中国Xichang宇宙センタから, Long March 3Bロケットで打ち上げ成功。BeiDou衛星としては、1/11の打ち上げ以来、28及び29機目。軌道はMEO。この記事では、衛星番号はBeiDou-3MEO3と4MEOで、1月に打ち上げられた衛星をBeiDou-3MEO7, MEO8としている。どうも衛星番号には未だ混乱がある。

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

QZSS概況: 2018/02/12 00:20 UTC頃、QZS-1, 2 L1C/A (PRN193, 194) 信号再開、01:10 UTC頃 QZS-4 L1C/A (PRN195) 信号再開。ただしアラートはON。L6D/Eは正常そうに見える。受信機によって色々と挙動が違うのが面白い。

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

QZSS概況: 2018/02/11 16:00 UTC頃、QZS-1, 2, 4 L1C/A (PRN193, 194, 195) 信号停止。連続運用しているBD982の受信状況を以下に。なお試験中の某受信機によると、QZS-4のL2C (PRN195) 、QZS-1, 2, 4のL1S (PRN183, 184, 185) は信号を送信している。それ以外のL1C/A, L2C, L5は全滅 (L1Cは未確認)。TrimbleでL2Cが受かっていないのは、L1C/AパイロットでL2Cを復調しているからか。NAQU。L6のNAQUは出ていないので、L6信号に問題は発生していない可能性がある (L1C/Aがないので未確認)。

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

2018/02/09

QZSS概況: 2018/02/09 11:00 UTC頃、QZS-3 L1C/A (PRN199) 再度信号停止。結構やばいかも。

補足: NAQU見ると10:15からL1SとL6の計画停止が予定されているので計画停止の可能性もある。そうだといいなあ。(11:00追記)

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

QZSS概況: 2018/02/09 07:00 UTC頃、QZS-3 L1C/A (PRN199) 信号送信再開。アラートはON。ただし、正常値に比較して信号レベルが8dB位低い (正常値C/N0 43dBHz前後に比較して、現在35dBHz)。L6 (PRN199, 209) は問題ない様に見える。L1パイロットでL6復調する受信機なので確認できないが、L1C/A信号の停止中もL6は正常送信されていた可能性はある。

補足: 2018/02/09 9:00 UTC現在、C/N0が41dBHzと概ね正常値に復帰。衛星の送信系ウォームアップに時間かかるのかも。航法データは乗っているがアラートはまだON。(18:15追記)

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

2018/02/08

KiwiSDR

QZS-3 (PRN199) の信号を受信可能なGNSS受信機に関して情報を頂きました。ありがとうございます。

KiwiSDRと呼ぶオープンソースSDR受信機。もともとはGPSのみ対応の様だがFourumへ打診したら2日で対応してくれたらしい。ただし、現在QZS-3の信号が止まっているため、受信確認はできていないとのこと。

Seeed Studioの製造で、日本では秋月でも扱っている (参照)。BeagleBone GreenかBlackと接続して動作し、10KHz-30MHzのVLF-HF帯とGPS L1帯の2CH。GPSフロントエンドはSE4150L。OpenWebRXというWebインタフェースが付いていてブラウザで操作できるらしい。ケースを含めてアクセサリも色々と揃っている。面白そうなので、ちょっと考えてから、買ってしまうかもしれない (まあ、いつもの様に受信機買いすぎという話はある)

補足: QZS-3の信号送信再開に伴い、KiwiSDRでのQZS-3 L1C/A信号 (PRN199) 受信を確認した、との報告を頂きました。おめでとうございます。まだQZS-3の信号受信した人世界中でも少ししかいないはずで、SDRの威力を改めて確認という感じです。(18:20追記)

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

2018/02/07

NNA ASIA, 日豪政府、QZSSの利用促進呼びかけ、2018/02/07

WSのプログラムと発表資料はこちら。GPAS資料p.10によると、MADOCA-PPPの測位精度は水平5cm、垂直10cm以下 (RMS)、収束時間は30分以下とされている。CLASの精度仕様は、水平6cm、垂直12cm以下 (静止、95%) なので、今のところ「同等の測位精度」ということはない。GPASの仕様見てもMADOCA-SEADに含まれていたFCBの仕様が抜かれているが、MADOCA-PPPでPPP-ARサポートする気ないのかしら。(JAXAの研究開発では既に実装は終わっている (参照)、まだ安定性に問題があるのかもしれないけど、使うか使わないかは受信機側で決められるし、技術実証なので、送れば良いのにとは思う)

補足: Trimble CenterPoint RTXの公称精度が "< 4cm (1.5") horizontal accuracy (in-field performance 95% of the time)" (参照) なので、現行MADOCA-PPPは差がある。経験的には、フロート解だと3-4cm 水平RMS位が限界で、RTX並みの精度を出そうとするとARが必要。あと衛星数も重要なので、QZS-2-4 とGalileoサポートを早く。ここまで行ってCLASの精度仕様を何とかという感じ。(21:45追記)

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

2018/02/06

QZSS概況: 2018/02/06 04:30 UTC頃から、QZS-2, 4 L6E (PRN204, 205) MADOCA-PPP補強データ停止。信号は送られているがデータが全てNULL。L6EがNAQU対象なのかどうか不明だが、NAQUは発行されていない。配信元 (?) であるGPASからの公式アナウンスもない。QZS-3の信号は止まったままだし、開発中の某受信機の試験が止まってしまって困っている。

補足: 2018/02/07 0:00 UTC現在、L6E PRN204, 205にデータは載る様になったが、周期的にベンダIDが不正の無効フレームが混じる。どうも正常動作では無い様に見える。これってどこに問い合わせれば良いのだろう。QSS ? Melco ? GPAS ? JAXA ? (2/7追記)

再補足: 2018/02/07 01:40 UTC現在、GLONASSの軌道時刻も載る様になったし、概ね正常に復帰した様に見える。L6EがNAQU対象外なのであれば、サービス中断予告と報告だけでもGPASが公式アナウンスとして出してくれると、ユーザとしてはとても助かるのだけど。(2/7 10:45追記)

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

2018/02/05

QZSS概況: 2018/02/04 9:45 UTC頃、QZS-3 L1C/A (PRN199) 信号停止。14:00 UTC頃、信号復帰したが、信号レベルが5dB程低い。23:30 UTC頃、再び信号停止。NAQU2018090。これも何らかの障害と思われる。信号レベルが下がるケースは初めてと思われるので、衛星側の送信系トラブルが疑われるが大丈夫であろうか。

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

2018/02/02

QZSS概況: 2018/02/02 08:50 UTC頃、QZS-3 L1C/A (PRN199)、L6 (PRN199, 209) 信号復帰。ただし、09:00UTC現在、L1C/Aのアラートフラグは立ったまま。L6 (PRN199) のアラートフラグは解除されている。

補足: NAQU2018082によると、停止期間は2018/02/02 05:09 - 12:12 UTC、7時間3分。(23:55追記)

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

QZSS概況: 2018/02/02 05:10 UTC頃、QZS-3 L1C/A (PRN199) 信号停止。05:37 UTC現在、まだ復旧していない。NAQUにないので、何らかの障害と予想される。

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

2018/02/01

Training Course on Global Navigation Satellite Systems, January, 23-26, 2018, AIT, Bankok, Thailand

先週、バンコクAITで行われたGNSSトレーニングコース。資料を見るとかなり本格的な感じ。講師は東大 Manandharさん、海洋大 久保先生、RMIT Choyさんら。

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

RESPONSE, 豊田通商など、タイで高精度ルートガイダンスシステムを実用化実証へ... 準天頂衛星システム「みちびき」を活用, 2018年1月31日

図によると、MADOCAから「高精度軌道時刻推定ツールを活用したグローバル補正データと電子基準点を活用したローカル補正データを配信」するとのこと。

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

〜2018/01/31