小ネタ

　このシステム発展させたら某組織とかめっちゃ欲しがりそう。

　西ノ島以降JAMSTECって船上から大型ヘリ/ドローンの離着艦を繰り返してるけど、パイロット/オペレーターの力量で頑張ってる感じがなぁ。結局予算が豊富に使えない組織は人間(一番金がかかるはずなのに)が頑張るほうが安くなるんだろうな。ある程度荒れた海でも使える無人VTOLの自動離着陸(or離着陸支援)設備ってあったら便利そうな気がするけどなー。

　SkyHookって結構大規模な追加機材が必要なイメージだったけど、艦上に作業用のクレーンがあればそれを流用できるのか。まあ、クレーンを積んでる船ってのがそもそも、という話ではあるけど。いや、アーレイ・バーク級Blk II以前と同系統の船だと前甲板と後甲板で同時にリカバリー作業が可能か…… いくら装甲ハッチで守ってるとはいえ、ミサイルキャニスターの真上で大型ドローンのハンドリングは嫌そうだなぁ。

　オペアンプでLPF, HPF, BPF、それとアンチエイリアスフィルタの設計を支援するためのオンラインツール。

https://filterlab.microchip.com/filter

　ログイン等は不要で使えるけど、ローディングアニメーションが消えてLoading widget...が表示されてから使えるようになるまでしばらく(数十秒)かかる。気長に待とう。

　MicrochipのWebサイトなので、当然Microchipのオペアンプを使って設計される。オペアンプを複数個使う回路だと、各段毎に違うオペアンプを使っていたりする。おそらく性能やコストのトレードオフで選んでると思うんだが。なので他社製含めて汎用オペアンプで使える回路というわけではない。まあ、マイコンとかじゃあるまいし、他社製含めて別の製品に載せ替えたら全く動かない、みたいなことはないだろうけど。

　抵抗やコンデンサの精度を設定してモンテカルロシミュレーションしたりとか、色々な機能があるらしい。

　eufyMake E1: the First Personal 3D-Texture UV Printer by eufyMake — Kickstarter

　1時間で目標金額(500kUSD)を達成したらしい。

　ベーシックバンドルでMSRP2499USD、デラックスバンドルで3754USD。予想よりはちょっと安いな。

　E1に投資したらどれくらいの利益が得られるか、みたいな一覧もある。例えばイラスト付きのタンブラーを作ると、タンブラー1個$10、インク代$0.13で、1日16時間作業すれば40個作れて、$24で売れば1日$560の利益になる、とか。スマホケースも同じくらいの金額だけど1日に96個作れるから$1425の利益になる。スマホケースを作るならベーシックバンドルがあれば作れるから、$2500の機械を1台買えば製造2日で元が取れる、ということらしい。200個もスマホケース作ってどうやって売るんだよ、というところが問題な気がするが。

　ある程度ファンがついたイラストレーターが自分でデザインしたアイテム(小さなマグネットとかスマホケース、タンブラー、ステッカー、その他)を少量作って売ったりするには便利そう。フリーとか安いデータを物理商品化して小遣い稼ぎは厳しそうだけど、うまくやればあるいは……

　UH-60。見かけたのはすごい久しぶりな気がする。写真フォルダをざっと見た感じ、一番新しいUH-60の写真は’16年? 実際には飛んでるのかもしれないけど、見たのは体感それくらい前な気がする。

　Mode-3/A/Cはこの時間帯に4機分くらい受信できていて、同定できず。Fr24だとJAL機と航空大機の2機しか写っていないから、UH以外にももう1機なにか飛んでたらしい。

　やっぱり特定の機体のMode-3/A/Cリプライを受信するなら指向性アンテナが欲しいよなー。とはいえ、MANPADSみたいなモノを自衛隊機に向けると良からぬ緊張を引き起こす可能性が。。。ログペリとか八木の3エレくらいのやつを使えばいいんだろうけど。

　ログビューアも使いづらいのでもう少し機能追加したいところではあるのだが。

　あと、Mode-3/A/CとMode-Sを同時にデコードしたいんだよなー。やはりAirspy Miniを買うべきか。。。

　夜中に山道を歩いていたらウサギを見かけた。冬に雪の上に足跡が残っているのはよく見かけたけど、ウサギ自身は見たことない気がする。色が白くて、まだ体毛が抜け替わってない。冬も夏も保護色だから気が付かないだけかも。この時期は色が目立ちやすくて気が付きやすいとか。ただ、眼球の反射もあるので、保護色でも顔がこっちに向いていれば気がつくはずなのだが。

　夜中に歩いていると鹿とか狐とかを見かけるけど、スマホとか取り出して撮ろうとしても全く間に合わないのよな。電源ボタン二度押しでカメラを起動できるとはいえ、ポケットからスマホを取り出すとか、カメラをズームするとか、撮るまでに色々と挙動が多くてモタモタ。

　そういう意味では、昔売ってたウェアラブルカメラのContourは便利だったんだよなー。巨大なスライドスイッチを操作する一挙動で電源ON&録画開始が操作できる。まあ、暗所性能はあまり良くなかったので夜道で使うのは難しいけど。というか、15年前のウェアラブルカメラなんてだいたい似たりよったりな気がするけど。

　ここ何週間かで迷惑メールがものすごい増えた。それ以前は20通/日とかだったけど、最近は100通/日くらい来る。ほとんどは全く縁もゆかりも無い証券会社の名前だけど、数通/日くらいは昔使ってたサービス(単に有名だから衝突してるだけ)が来たりする。迷惑メール、マジ迷惑。

　高周波リレー、例えばG6K-2F-RF-DC4.5だと定格4.5V23.2mAで操作できるわけだけど、RTL-SDR Blog V.3ドングルのBias-Tee(定格4.5V180mA)でON/OFFを切り替えたりできるんだろうか? 片方にはGPSアクティブアンテナを接続して、もう片方には適当な八木アンテナを接続して、1本のドングルで目的の信号を受信しながら、時分割でGPSから高精度な位置・時刻情報を取得する、みたいな使い方ができるんだろうか。あるいは、さすがにRFラインをインダクタンスとはいえ制御コイルに突っ込むと周波数特性悪くなりすぎる?

/* このリレー、メーカーオンラインストアだと1万円くらいで売ってるけど、モノタロウだと1000円強で売ってる。どういうことだよ */

　かつてはスカパーのプレミアムサービス(緯度の違う2個の衛星から放送)を受信する際に、アンテナを切り替えるために専用の切替器が売っていたらしい。いまでこそおそらくIFのFDMAで対応しているから不要だけど、この種のRFスイッチは今でも流通在庫がある。

　このスイッチは0.6Vpp40kHz程度のパルスが乗っているときは切り替わる、という挙動らしい。衛星アンテナはLNB用に15V前後のBias-Teeが必要だから、DCをスイッチングに使えない。ということで適当なパルス信号をBPF経由で検出しているんだろう。実際のスイッチは半導体にしろ機械式にしろ、LNB用のDC電源(9.5-16.5V)を使って、パルス信号はあくまでもON/OFFの制御だけのはず。

　衛星放送用だから帯域は950-2150MHzで、UHFの下の方とかは通らないっぽい。あくまでも必要ないからスペックで規定していない程度であって、わざわざBPFで切ってるとかではないと思うんだけど。

　1090MHzと1575.42MHzを切り替えるなら問題ないだろうけど、今度はBias-Teeが高すぎて使いづらそうだ。12V系のアクティブアンテナが必要になる。

　衛星用アンテナは偏波面(H/V)の切り替えにLNB用電圧を変えて制御するものもあったりするらしくて、とにかく同軸線1本でいかに制御するか色々工夫してるらしい。

　ちょっと興味本位で、TLE(’25年3月1日から10日までで、TBDを除いた58.3万個)の軌道長半径を計算して、9535km(いわゆる地球の時刻静止軌道)に近い宇宙機を探してみた。結果、差の絶対値が20km以下のものは一つもなく、100km以下に広げても15個しか無く、それらはすべて離心率が大きいか軌道傾斜角が大きい。この軌道を使ってる宇宙機って本当に無いんだな。

https://www.jstage.jst.go.jp/article/enrihappyou/16/0/16_72/_pdf

　2016年。GPS L5 SBASで放送する補正データを、LNAV用にするかCNAV用にするかの比較。結論としてはCNAVは十分に精度が高いからSBASで補正するメリットが少なく、LNAV補正信号を出すほうがメリットが大きい。こうやって古い規格が延命されて延々使い続けることになるんだろうなぁ。わざわざLNAV用受信機にL5SBAS受信機能を追加するくらいならL1/L5の2周波CNAV受信機作れよ、って気が。

　CNAVの精度が高くて補正情報が不要ならそもそもL5SBASも不要じゃねという疑問。インテグリティの問題で伝送経路が必要って事なんだろうけど、どうせ同じ衛星を通して放送するなCNAVで出せるようにしておけよって話だし。

　LNAVとCNAVの軌道要素とか時計補正は同じようにして生成するだろうに、なんでこんなに違うんだろう? メッセージの内容が変わるだけでこんなに変わるんだろうか。

http://www.jana.or.jp/denko/data/27_1_2.pdf

　2015年。NICTの人が書いた時計とかの話。

　SI単位や時刻の歴史。

　原子時計の原理とか説明とか色々。

　なぜCs133を使うのか。

　原子時計と一次周波数標準器の違い。

　原子時計と光時計の精度の比較。2000年頃までは原子時計(-15乗)のほうが精度が良かった。2010年頃までに交差。原子時計の精度の改善より光時計の精度の改善が圧倒的に早い。

　光コム。

　光格子時計。

　相対論的効果の説明。

　宇宙関係。軌道とか、重力レンズとか。

　相対論の説明(計算方法)を元にGPSとかQZSで計算してみると、GPSで4.85e-10(実際は4.4647e-10)、QZSで5.69e-10(実際は5.399e-10)、位の結果になった。一応1桁の精度で計算できている。GPSの方は5桁で書いてあるから、せめて3桁くらいの精度が出ると嬉しいんだけど。

　同様に赤道上の時刻と相対的な進みが同じになる高度を求めてみると1.505rp位になる。

　国土地理院の資料曰く、GPSのWコードは「約2μ秒(一定ではない)」とのことで、つまり可変ビットレートってこと? 10.23MHzにコヒーレントなら512kbpsくらいかと思ってたけど、違うのか。だからWikipediaは「約500kHz」みいな微妙な書き方をしていたのか。

　航空機の着陸段階でGPSを使うためのGBASシステム、B78、A38、A35あたりの新しい機種で対応しているらしいけど、L5SBASとの住み分けってどうするんだろう。あくまでもSBASは広域(巡航)での信頼性改善が目的で、自動離着陸はGBASで、みたいなことなんだろうか。

　GBASもL5SBASも検討自体はかなり前からやってるらしくて、航空機業界の歩みの遅さというか、実績重視・信頼性重視の進め方というか。大前提としてとにかく信頼性が重要だから、まずは実データベースで、それを再現できるモデルを作って、でも実データを集めるにも安全第一に進めなきゃいけないし。

　世界中でおそらく何百人という数の技術者を四半世紀とかのスパンである研究に割り当てて、専属じゃないにしても、開発コストすごいことになってそうだよなぁ。

　そういえば、『ダイ・ハード2』でILSの設定を上書きして着陸侵入してきた飛行機を墜落させる描写があって、いやいや、ILSってそういうシステムじゃねーから、とか思ってたわけだが、GBAS Landing System(GLS)だとそういうことができちゃうんだよな。しかもGLSはVHF Data Link(VDL)だから、Lバンド/CDMAのSBASより偽情報の送信が楽そうだし。

　実際にはVDLで偽のグライドパスを送ったところで、RALTやGPWSみたいにGLSとは独立したシステムから先に警報が出るんだろうけど。それとも、脚が出ていて降下速度も正常な範囲で地面に接近した場合、上下方向にちょっとズレた程度のパスを通っていたらGPWSは警報を出してくれない可能性もある?

　一応、地上から航空機の安全系の放送を行うシステムは、送信アンテナから放送された信号を独立した受信アンテナで受信して、送信系システム全体の健全性確認を行うような設計になっているはずだから、外部からジャミングやスプーフィングが行われた場合、システム運用者は把握できるはずだし、航空管制を通じてそれを警告して航空機で使用を禁止するみたいなことはできるはず。

　とはいえ、指向性の強いアンテナで目的の航空機にだけスプーフィング信号を与えるとか、それでも漏れるサイドローブは空港側受信アンテナに弱いジャミング信号を与えて復調させないとか、悪意を持って妨害しようと思えばいくらでもできそうな気がするけど。

　L1やL5が航空機で使えてL2が使えない理由、ITU-R RR Articlesで見ると、L1(1575.42MHz)の範囲(1559-1610MHz)やL5(1176.45MHz)の範囲(1164-1215MHz)はAERONAUTICL RADIONAVIGATION / RADIONAVIGATION-SATELLITEだけに割り当てられているけど、L2(1227.6MHz)の範囲(1215-1240MHz)はEARTH EXPLORATION-SATELLITEとRADIOLOCATION / RADIONAVIGATION-SATELLITEの2つが割り当てられている(航空機専用で割り当てられているわけではない)から、ってことなのかな。

　もうちょっとなにか拘束力のある保護とかありそうなものだけど、ITU-R RR Articlesで割り当てたものは各国で管理するからそこから逸脱した電波(妨害電波とか)は各国の国内法で処理する、ってことなのかな。あるいは別の用途に割り当てられている帯域を使うのは嫌だからRR Articlesで占有できるやつしか使わん、ということなのか。

　TAIとUTCの差(過去のうるう秒の総和)ってどこから取ってくればいいんだろう。

　昔NICTが運用していたhttp/https時刻配信は例えばJSONで現在時刻・最新の閏秒実施時刻・それ以前の積算閏秒数が取れたから、これを見ればTAI-UTC-1が得られた。ただ、これはサーバー負荷が高くなったために2021年度末で運用を終了したらしい。

　そもそもHTTP時刻サーバーはNTP用のポートが空いていない環境で使うことを想定していたらしい(大抵の環境ではHTTPアクセスは通るので)。ただ、最近ではNTPが問題なく使えることが増えたから、HTTPサーバーは不要になっただろう、という判断で終了を決めたらしい。アクセスが増えて安定維持が難しいというのとユーザーが減ったというのは両立しないと思うんだが。どんな事情だったんだろうか。

　元々公開されていたJSONのURL(例えばhttps://ntp-a1.nict.go.jp/cgi-bin/json)は現在では使えなくなっている。Internet Archive(https://web.archive.org/web/20220302162620/https://ntp-a1.nict.go.jp/cgi-bin/json)を見ればどういう情報が乗っていたのかはわかる。

　別ルートでURLを入手すれば、現在でもHTTP/HTTPS経由のJSONで時刻や閏秒の情報を取得できる。QiitaやZennにもこのURLを使った解説記事が何本かある。とはいえ、明らかに普段遣いする事を考えたURLではないし、そもそもの事情(アクセス数が増えて安定運用が難しくなったので閉鎖)を考えると、このURLを使うのはあまり良いやり方とは言えないと思う。

　さて、UTCとTAIを機械的に取得するにはどうすればいいんだろうか……

　まあ、気になったから探してみただけで、今のところTAI-UTCが必要な状況は発生していないから、また必要になったときに考えよう。そもそもUTCとTAIの差を気にしなきゃいけない状況ってそうそう無いだろうしな。

　せっかくなので、NTPを叩いて遊んでみたり。

　NICTとGoogleでは、ほぼ同じ結果が得られる(サーバーとPCの時間差が、NICTで0.587426s、Googleで0.5865752、差は1ミリ秒未満)。

　ラウンドトリップタイムはNICTで24ms、GOOGが61ms。CloudflareやAWSも30ms前後。GoogleのサーバーだけRTTが悪いけど、サーバーどこに置いているんだろう?

　NTPはサーバーがリクエストを受信した時刻とレスポンスを返した時刻をパケットに含めるけど、Google Public NTPは2tick(0.5ナノ秒程度)の差。NICT NTPだと3500ticks(800ns)くらい。

　約0.5nsの逆数は2GHzくらいだから、Googleのサーバーが10Gbpsとか100Gbpsでルーティングされているなら、当たらずとも遠からずといったオーダー? それにしても早いけど。NICTのFPGAサーバーは、当時の高信頼性コンピュータに比べれば圧倒的に低ジッターで実装できたのかもしれないけど、サーバー機器が高性能化してきた昨今、ソフトウェア実装でもゴリ押せば数百ピコ秒オーダーでレスポンスを返せるらしい(実はGoogleもハードウェア実装というオチかもしれないけど)。

　CloudflareやAWSの受信時刻と送信時刻の差は10usとか1usのオーダーかな。これに比べるとNICTのFPGAサーバーは流石に早い。

　いろいろなNTPサーバーに15分毎とかにアクセスして、レイテンシやRTTとか色々記録を取ってみても面白そうだな。

　NTPは48オクテット(12ワード)のパケットを使うけど、NICTサーバーは72オクテット(18ワード)のパケットを送れば、それに応じたレスポンスも返す。拡張フィールド自体はNTPv4の仕様。それをどう使うかはNICTが定義している。

https://www.nict.go.jp/publication/shuppan/kihou-journal/houkoku65-2_HTML/2019S-03-05(02-05).pdf

　このあたりで若干触れられている。NTP以前のNICTの時刻サービスはJSTを基本としていたが、NTPはUTCなので、時差の取り扱いに懸念があった。ということで、拡張フィールドでJST-UTCの情報や夏時間も含めて配信することにしたらしい。

　詳しくはPDFの表を参照してもらうとして、とりあえず72バイトのパケットの一番最初(0番目)に0x23を書いて、51番目に0x14を書いて、NICT NTPに投げると、追加領域に色々と情報が増える。増えると言っても、54番目に0x09(UTC+9)が入って、55番目に0x0A(UTC+10：夏時間)が書いてあるだけだけど。

　他に、53番にサーバーIDが入っているけど、使い道が思いつかない。NICT NTPサーバーは最近神戸にも設置したらしくて、DNSラウンドロビンで振り分けるらしいから、物理的な距離の差を除こうとしたらサーバーIDで見分けたほうがいいのかも。

　夏時間の開始日・終了日も4バイト(秒未満省略?)で含まれているけど、現在はゼロ埋め(実施予定なし)になっている。

　NISTのタイムサーバー一覧

https://tf.nist.gov/tf-cgi/servers.cgi

　数か所にそれぞれいくつかのサーバーが置いてあるから、地理的に近い場所を選んでね、とのこと。

「4秒に1回以上の頻度で問い合わせるのはやめてね(DoS攻撃と認識するから)」だそうで。さすがアメリカは規模がでけーや。

　NTPサーバーはUTC(NIST)を参照しているけど、UTC(NIST)とUTCの差はBIPM Circular Tを参照してね、とのこと。いや、NTPにそんな精度ないだろ……

　UTC(NIST)を返すサーバーだけじゃなくて、UT1を返すサーバーもあるらしい。2個書いてあるけど、片方は止まってる? 天文をやっている人(特に大型の望遠鏡の制御ソフトウェアが入っているPCとか)で使うにはUT1を出力するNTPサーバーがあると便利なのかな。試しに叩いてみたけど、家からだとRTTが160ms以上ある。なお、NISTのUTCサーバーはRTTが320ms以上ある。USNOのタイムサーバーもRTT200msくらい。アメリカのサーバーに日本からアクセスするのは厳しそう。

　ΔUT1(UT1-UTC)はNICTのWebサイトに時々追記されているけど、場合によっては2年以上空いていたりして、いまいちデータとして使いづらい。なんで定期的な数値を書いてくれないんだろう。実際のUT1がわからないので、UT1 NTPサーバーが正しい値を返しているのかも不明。