小ネタ

　JA21DK。北海道警察のH135。

　prime videoに挿入されるprime videoのCM、その作品に興味を持っても自分で検索しなきゃいけないの結構アホの仕様では? なんで「ウォッチリストへ追加する」ボタンが無いんだろう。

　Fire Tabletの充電、ACアダプタを変えても、モバイルバッテリーを使っても、ケーブルを変えても、何をやってもアダプタの容量不足の警告が出て、5Wくらいしか吸い込まれなくて、朝まで放置してもまだ充電中みたいな有り様だったんだけど、試しに付属のACアダプタを使ってみたら警告無しで充電できた。とはいえ10Wくらいしか吸ってないから、2倍程度の差だけど。

　付属のACアダプタは定格が5.2V1.8A9.0Wと書いてある。電圧を監視して十分に高ければ(普通のACアダプタより有意に高ければ)ハイレートで充電する、みたいな挙動なのかな。USBって規定外の電圧を出すアダプタって建前としては禁止しているはずなんだが。4%の違い程度は定格範囲内ってことなのかな。

　Fr24に表示される機体で、LatLng有り、BaroAlt有り、ICAOアドレス無し、Squawk無し、機種情報有り、みたいなやつ、いったいどうやって表示してるんだろう。ICAOアドレスが無いならMode-S非対応だけど、MLATならSquawkも取れるはず。MLATだと機種情報は得られないけど、機種情報が得られているならICAOアドレスも取れるはず。時々明らかにADS-Bっぽい機体(民間のB76とか)でもSquawkが表示されないことがあるから、Fr24側の不具合かもしれないけど。

　家で受信しているMode-3/A/Cの信号、なぜか北方向が異様に電波強度が高い。旭川空港を離着陸する飛行機はかなり低い高度まで強く受信できるし、相当離れた場所を飛んでいても高い強度で受信できる。Fr24のフィードステータス画面でも南東方向は20nm未満なのに北西方向は90nm以上受信できている。以前キューブサットのビーコンを受信していたときも、南方向に比べて明らかに北方向が強かったような気がする。いったいどういう理由があって電波信号の非対称性が生まれるんだろう?

　科学を変えた10のコンピューターコード | Nature ダイジェスト | Nature Portfolio

　FFTに関して、「ドイツの数学者カール・フリードリヒ・ガウス（Carl Friedrich Gauss）は1805年にこのことを発見していたが、発表することはなかった」という記述。

　FFTアルゴリズムをガウスが発見していたという逸話、こういう小さい記述はいくつかのWebサイトやWikipedia(日本語版・英語版含め)では見かけるけど、いまいちちゃんとした場所に書いてあるのが見当たらない。

　カール・フリードリヒ・ガウスにちなんで名づけられたものの一覧 - Wikipedia

　こんな一覧があるのか。日本語版Wikipediaの「物理学に関する一覧」の中でタイトルに個人名が含まれる記事としては唯一のもの(ただしファインマン・ダイアグラムの一覧という記事がある)。数学だとオイラーとか数人の記事がある。

***

　いくつかのNTPサーバーとの時刻差のログ

　クロックエラーがそれなりに大きくて、260ms/36h(2ppm)くらいの誤差がある。とはいえTCXOくらいの精度はあるかな。

　時差が増えると0秒まで引き戻して、また発散するという感じらしい。

　途中で16時間くらいログが止まっているが、その間にステップ状の変化はなさそう。たぶんNTPに問い合わせて1秒以上ズレていたら強制的に引き戻すみたいな処理なんだろう。

　各サーバーとのラウンドトリップタイム

　Cloudflareが最優秀でほとんどすべて25msを維持している。NICTも良いときは25msを維持するが、場合によって32msあたりまで悪化する。AWSと水沢は常に32msあたりを維持している。Googleは常に62msあたり。NISTが145ms、USNOが200ms、あたり。

　やはりCDN大手のノウハウが有るのか、Cloudflareが一番優秀。国家機関としてNICTも頑張っている。水沢はタイムサービスには大して力を入れていないはず(UTCしかり)。その割にRTTが低めなのは、単に国内にサーバーがあるから、ということかな。AWSは水沢より若干優秀だけど、大きな差はない。

　Googleはアジア圏で1箇所のサーバーのはずだから、国外のサーバーに問い合わせに行っているはず。

　NISTとUSNOはアメリカまで行くから、その分RTTが大きい。NISTのゲイザースバーグとUSNOのワシントンDCは日本から見ればほとんど同じ場所だけど、明らかにRTTに差がある。USNOは米軍向けのタイムサービスだから民間回線からはファイヤーウォールを挟んでいる分遅いとかなのかな?

　PCとNTPサーバーの時差から適当な1次関数をオフセットして、サーバー間の差を見やすくしたグラフ。

　最初の42時間くらい(ステップ状に引き込む前)と、それ以降では時間の進み方にかなり違いがある。とはいえ、差分を取ってようやく見える程度の小さな変化だけど。

　1日19時(UTC)頃に傾きが大きく変化した場所があるけど、ここは窓を開けて部屋の空気を換気したところ。気温が大幅に変化したので、それに釣られて水晶も変動している。温度特性悪そう。

　NTPはCloudflareやNICT、AWS、Googleあたりが優秀だけど、ジッタやバイアスがあるから、精度が欲しいなら5個以上のサーバーに問い合わせて上下2個を除外した複数サーバーの平均を使う、みたいなアルゴリズムにしたほうが良さそう。一つのサーバーに連続してアクセスするとアクセス頻度の問題やバイアスを除去できないといった問題がある。

　ただし最近のNTPサーバ(特にIT系企業が運用しているもの)は閏秒の取り扱いに一貫性がないから、閏秒前後の1日程度で複数サーバーから外れ値/平均値を取ろうとすると問題がある。smearingを行うサーバーはおそらくLeap Indicatorはクリアのままだから、そういう操作を実施している事自体が把握できない。標準研究所(NICT、NIST、USNO、等)が運用しているサーバーはLIを正しく実装しているはずだから、それらのサーバーを問い合わせ先に含めておいて、どれかがLIを出しているときは、LIを出していないサーバーを除外する、みたいな挙動が必要になりそう。ただ、LIに関しても、サーバーによって「今月末に閏秒を実施する」とか「今日の最後に閏秒を実施する」とか、実装が別れているらしい。企業間・研究所間で閏秒の取り扱いがバラバラなのを見ると、閏秒を廃止したいってのもまあ分かる気がする。問題を先送りしているだけとはいえ。

*

　NTPのログが面白そうだということで、もう少し真面目にコードを書き直して、安定して動くように改造。本当に安定しているかはわからん。前のコードで10時間ぐらい止まっていたのは、サーバーの一つから応答がなかったからそこで止まったので、今回は1秒位でタイムアウトしてそのサーバーはその時はスキップするようにしている。ただ、今のところはタイムアウトは起きてないっぽい。いくらUDPとはいえ今どきのインターネットで応答がないってことはそうそう起きないだろうしなぁ。

　サーバーリストをハードコードから外部ファイルへ移動して、プログラムの実行中に書き換えても次の取得時には反映されるようにしたのと、ログに生データを入れて後で再解析できるようにしたり、ログにIPアドレスを含めたのが大きな違いかな。IPアドレスが残っていると、ラウンドロビンでサーバーが切り替わる場合に、そのデータをどのサーバーから取得したかがわかる。

　PCとNTPの差

　W32Timeが停止していたので、4日12時Zに開始させたけど、直後は特に変化は見られない。ただ、その後ステップ状に戻すときの処理が積分フィルタな挙動になっている。その後も定期的に似たような動きをしつつ、PCとNTPの差の傾きが少しずつ小さくなっていってる。2^15秒(約9.1時間)毎に誤差を修正していってる感じ。

　一つ(ut1-time.colorado.edu)だけ有意にバイアスがあるけど、これはUTCではなくUT1を出しているため。

　それと、途中でtime.nist.govが大きく(ちょうど2秒)ジャンプしている部分がある。ログを見ると、特定のサーバー(2610:20:6f96:96::6、NISTコロラド州ボルダー)にアクセスしたときだけジャンプする。いきなりIPアドレスの保存が役に立ったな。最後に値がジャンプしていたのが4日12時Z頃で、夏時間含めてUTC-6hなので、現地時間で朝6時頃。職員が普通に出勤してきたにしてはちょっと早い気がする。とはいえ常駐の職員が対応したにしては時計がズレてから修正されるまでに24時間かかっている。やっぱりNTPサーバーの外れ値を除くために複数サーバーにアクセスする挙動って重要なんだな。しかし、NIST(アメリカ国立標準技術研究所)が管理するタイムサーバーもこういう挙動があるのか……

　ラウンドトリップタイム

　特にどうということはない。アメリカにあるUSNO、NIST、コロラド大学ボルダー校は150-200msくらいのRTT。Googleのアジアサーバーは安定して60msくらい。

　残りの国内サーバーはCloudflareやNISTの24msから水沢の33msくらいまで、ほぼ安定したRTTが得られる。

　タイミングサービス専門企業のアマノセキュアジャパンが公開しているサーバーは26ms程度と、NIST/Cloudflareには2ミリ秒程度負けるが、かなり早い。また、自宅で契約しているプロバイダが公開しているNTPサーバーも同程度のRTT。アマノはIT系企業だから早い回線を確保しているとして、水沢はタイミングは本業ではないから(かつてはともかくとしても)注力しているわけではなく既設の回線を使っているとして、AWSがIT系企業のわりに遅いのはなんでだろう? いや、そんな事言い始めたらGoogleはどうなんだよという話なんだけど。

　PC-NTPの差を一次関数でオフセットしたグラフ

　縦軸の間隔はサーバー間のバイアスを示しているが、絶対値に意味はない。

　大抵のNTPサーバーは0付近に固まっているが、UT1サーバーは0.07秒弱のバイアスがある。つまり現在のDUT1(UT1-UTC)は0.07秒位ということになる。

　全米にサーバーが点在しているNISTは明らかにジッターが大きい。

　時間軸を拡大

　このグラフだと水沢のバイアスがだいぶ少ないように感じるけど、他のサーバーが増えて目立たなくなっているだけだと思う。NICTやGoogle、USNO、AWSみたいに中央に分布しているやつから比べると明らかにバイアスがある。プロバイダのNTPサーバーは水沢とほぼ同じバイアスがある。もしかしたら水沢をソースにしているのかな?

　前半でCloudflareのジッターとバイアスが大きい。後半はかなり収束しているが。常に高い精度の時刻が得られるわけではないということか。1,2ミリ秒くらいの精度が欲しいなら特定のサーバーだけ取りに行くのではなくて、複数のNTPサーバーを参照して外れ値を除去した平均値を使うのは有効なんだろうな。

　今回見た範囲だと、ジッターとバイアスが少ないのはAWS、USNO、NICT、Google、あたりか。USNOはRTTが大きい割に非常に優秀。Cloudflareはバイアスが大きくなることがあるから外れ値を除去できるなら使う、アマノは若干(1ms程度)バイアス有り、水沢も若干(3ms程度)バイアス有り、NISTは論外(ジッターとバイアスが大きすぎる)、という感じ。

　W32Timeで引き込んでいる最中のPCとNTPの差を拡大

　定期的に引き込んでいるが、クロックエラーを吸収するのにはかなり長い時間がかかる。2ppmのズレは48時間かけても修正が終わらない。10ms/6h(0.4ppm)くらいで制御が終わっている感じがする。

　NISTの誤差が大きいのはいつものこととして、この図だと見づらいけど、やはりCloudflareに少しバイアスがある。それと、NICTと水沢も1回ずつ(6日9時Z前後)大きな誤差がある。ネットワークの問題だと思うけど。やはり複数サーバーへ同時に問い合わせて外れ値除去は大事そうだ。

　とはいえ、多数決は単純にNTPトラフィックが数倍に膨れるから(複数のサーバーに分散させるとはいえ)、サーバー側の負荷も大きそう。そもそも今回はW32Timeが止まっていたのが問題であって、正常に動いていればシステムクロックで十分な精度を維持できるだろうし、というかミリ秒精度が必要な事自体ほとんどないだろうけど。ガチで時刻精度が必要な用途ならローカルにGPSでStratum1サーバー立てろって話だしな。超微弱なRFを信用できるかはまた別の話として。

　NTPサーバーを比較してみるとそれぞれに特性があって面白いけど、自分でサーバーを探してくるのが結構面倒くさい。NTPサーバーの一覧みたいなところを見ても「定期的にアクセスするなら管理者に許可をもらってね」みたいなサーバーが非常に多くて、OSのNTPクライアントに設定することすらできないサーバーがかなり多い。なんでこんなポリシーのサーバーばっかりなんだろう?

　NTPプールDNSに5分周期とかでアクセスしてIPアドレスでグルーピングしてグラフ化すればいいのかもしれないけど、シンプルなラウンドロビンでなく、経路的に近いサーバーを返すような実装になっていると、地理的に偏ったサーバー群しか見えない可能性があるんだよな。

***

　Bulletin D - all available versions

　IERSが公開しているDUT1の値。めちゃくちゃ飛び飛びの間隔。NICTが公表しているDUT1が飛び飛びなのが謎なんだけど、NICTはIERSの値を転記しているだけで、その大本のIERSの公表データが飛び飛びなのか。

　IERSのデータをグラフ化したもの

　1995年以降は閏秒のステップを除いて0.1秒以上の変化の度に値が公開されているらしいから、最近のDUT1の報告がないのはDUT1の変化が無いからということなのかな。DUT1の報告が「精度0.1秒」というのは、「最新の報告値から0.1秒以上ずれる場合は報告します」みたいな意味なのか。

　1999年頃までは定義の秒と地球の秒の差がかなり大きくて、1999年から2005年頃までは傾斜が緩やかで、それ以降はまた傾斜が増えているけど、2019年頃からは急激に傾斜が小さくなっている。2024年はまた傾斜が大きくなったけど、傾向が見えるほどサンプルがない。

　The GOES Time Code Service, 1974–2004: A Retrospective - PMC

　GOESタイムコードの説明というか回想。初期の通信衛星(Echoとか)から段階を追って色々と説明している。

　GOES TCは衛星から配信した初めての時刻情報で、送信位置情報を載せた初めての時刻情報らしい。例えばLORAN-CだってPNTコードなわけだから送信場所の位置情報は既知だけど、双曲線航法は送信場所の位置情報はあまり重要ではないから、伝搬遅延を高精度に推定するみたいな使い方はしていなかったのかも。そもそも伝搬時間も電離層の状態によって大きく変化するだろうし。

　GOESタイムコードの仕組みとしては、DCP interrogationのヘッダにタイムコード(時刻・周波数)や衛星のLat/Lng/Radialが含まれているので、タイミングパルス単体で数十ms精度の時刻を得たり、自身と衛星の位置から伝搬遅延を求めて100us以下の時刻を得ることができる。

　2000年代に入るとGPSタイムサービスを使うユーザーが増えてきたのでGOESタイムサービスを終了することになったが、それでもGOES受信機を使い続けるユーザーがいたため、GPSアンテナにGPS受信機やGOESエンコーダを内蔵して、アンテナだけ交換して電源を通せば既存のGOESシステムをそのまま使えるようにするシステムもあったらしい。

　FAAではMode-SレーダでGOESタイムコードを使っていたんだそうだ。/* Mode-Sはレーダーカバレッジが重複している範囲では一つのレーダだけで追尾を行い、それ以外のレーダには伝送回線を使って同じ情報を配信することで、輻輳を防ぐ。おそらくそれ用のタイムスタンプとして使っていたんだろう */ FAAがいくらGPSを嫌ったとしても2000年代に入れば否が応でも使わざるを得ないらしい。2003年時点でFAAが使っていたGOES受信機は400台を優に超えるとのこと(冗長系でGOES-Westと-Eastの2つの受信機を使っているから、拠点数で言えば半分程度)。

　GOESのタイムパルスを受信するシステム

https://nvlpubs.nist.gov/nistpubs/Legacy/TN/nbstechnicalnote681.pdf

　Intel 4004ベースで、4.096MHzの原振から512kHzを4004へ供給し、さらに分周した100HzとGOESからの100Hzを位相比較してバリキャップで水晶へフィードバックする。回路図や基板パターン、アセンブリ等、一通りの資料が入っている。

https://tf.nist.gov/general/pdf/450.pdf

　衛星の位置から伝搬遅延を補正するタイプの受信機。

　遅延量は計算機用の半導体(MOS Technology?の7529-103)を使って計算するらしい。さすがに4004で自分で三角関数を計算するのは大変なのかな。計算チップの機能の説明もあるけど、四則演算や三角関数のほか、1/x、x^0.5、x^2、x^y、10^x、e^x、N!、など、いろいろな機能があるらしい。

https://wdc-cloud.nict.go.jp/IONO/wdc/hsv/gallery/pdfs/RRL1955JP_1.pdf

　1955年。日本の短波標準電波の変調方式とかの説明。

　各周波数で秒や分の切れ込みの入ったパルス信号を出したり、定期的にモールス符号や音声信号で時刻を通知したり、伝搬異常の予報を出したり、という感じ。

https://jjy.nict.go.jp/QandA/reference/ShortWave/JJYformat_199604.pdf

　1996年。短波(5, 8, 10MHz)・長波(40kHz・実験局)の標準電波の説明。

　当時は短波・長波共にDUT1値が放送されていた。長波の変調方式では現在のパリティ・予備ビット・年・曜日・閏秒が割り当てられていなかった。あくまでも周波数標準と時刻の放送がメイン。電波時計みたいな用途で使おうとすると年や曜日があったほうが便利だから、変更されたんだろう。閏秒は官報で通知していたらしい。

　DUT1は0.1秒の分解能だけど、官報か何かを参照すればミリ秒くらいまで追い込める、みたいな話を何処かで読んだ気がする。天文みたいな用途だと電波でDUT1が得られるのは便利だろうけど、精度が欲しいなら別のソースが必要で、それならUTCから直接計算すればいい、ということでDUT1の放送は削除されたんだろうな。

https://www.nict.go.jp/publication/kiho/29/149/Kiho_Vol29_SI_No149_pp263-278.pdf

　1983年。標準電波の説明いろいろ。歴史とか、伝搬特性とか。

　時報を東京天文台から有線で伝送するために、三鷹からほど近い小金井に標準電波の送信所を作った。

　秒は元々地球の自転速度に従属していたから、年ごとに周波数標準も変化していた。そもそも標準電波を開始した目的は、様々な無線通信間での干渉を防ぐために統一した基準を与えることだから、年毎に周波数標準が変化したのでは、それぞれの機器を常に調整し続ける手間がある。ということで秒(周波数)を定義値として、閏秒で対応するようになった。

　小金井で宅地化が進んで電波障害が問題となったので、移設。

　その他色々。

　The most important part of every sports broadcast - YouTube

　ASUSのコンシューマ向けマザボでU.FLコネクタが乗っていて、外部クロックに同期できる製品があるらしい。

　メーカーWebサイトの製品写真にもコネクタは実装されているけど、ユーザーズマニュアルには一切記載がないし、そもそも製品イラストにはU.FLコネクタ自体が描かれていない。サポートされている機能なんだろうか? 将来的には、みたいなことなんだろうか。あるいはかつては使えていたが、なのか。

https://www.jstage.jst.go.jp/article/sicejl1962/17/5/17_5_395/_pdf

　1978年。4ビット1チップコントローラとか8ビット1チップコントローラに関して、チップ自体の説明とか、応用の話とか。応用はPOSやテレビ、電子レンジなど。

　やっぱりAirspy欲しいなーと思って下調べ中。Mini買いたいと思ってたけど、帯域幅広めのR2も魅力的なんだよなぁ。

　試しにDLLをdumpbin /exportで見てみるといくつかの関数が見えるし、ソースコードもあるから、C#で叩くのにも支障ないはず。ただ、airspy_rx.cを見てみると、コールバックの中で構造体を触る必要があるっぽいのがちょっと嫌な感じ。構造体の定義を見てみるとポインタが3個、intとuint64_tとenumが1個ずつだから、C#で定義するのも難しくはなさそうな気がするけど。

　あとは、R2やminiは製品としてはかなり古いのと、ファームウェア/ソフトウェアのアップデートが行われていないのがちょっとした懸念点。まあ、それだけ成熟していると考えることもできるが。

　今のところ、某代理店でminiが在庫なしになっているので、近いうちに買うのであればR2の一択。買うかどうかはさておき。そのうち衝動買いしそうな気はするけど。

　PRN122のPromptの相関値の自乗の平方根

　コード・キャリアともにドップラを手動で設定してフリーラン。キャリアの周波数がなぜかステップ状に変化している。他のPRNだとフリーランでも線形だから、この衛星だけの問題だと思う。

小ネタ

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

　西ノ島以降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サーバーが正しい値を返しているのかも不明。

小ネタ

「2泊してからラベンダー見に来い」

　……ラベンダーが有名なエリア付近の人かな???

　YouTube、デザイン変わった気がする。トップページのサムネがデカくなって1画面で見れる情報量が激減した。Googleが時々やる改悪。今回の場合は見づらくなるとかその程度でさほど大きな問題ではないとはいえ。。。

　でっかいテレビをリビングにおいて離れた場所からリモコンでポチポチする、みたいな使い方を考えると、サムネが大きいと便利そうではある? PCから見るなら不便すぎるけどな。

　米ミサイル防衛システム「ゴールデン・ドーム」、スペースＸが重要部分で最有力候補に | ロイター

　今更固体燃料に手を出すつもり? 既存の軍需企業が作る固体燃料より安く作れるかもしれないけど、とはいえベンチャー企業がアジャイル開発する製品をド正面の防衛装備品に使うのはちょっとなぁ…… 歴史のあるメーカーが作ってるミサイルの固体燃料だって場合によってはトラブってるのに、全く経験のない会社がいきなり信頼性の高いものを作ろうとしてそう簡単に作れるとも思えんが。

　それとも液体燃料を使うつもりなんだろうか? NCADE(弾道ミサイルのブーストフェーズを撃墜するAIM-120サイズの空対空ミサイル、キャンセル)では制御に1液グリーンプロペラントを採用する予定だったわけだが。とはいえ、それにしたって固体燃料で加速したあとの話だし。一応、SpaceXもドラゴン宇宙船(有人系)でヒドラジン系を扱っているし、常温系液体燃料のノウハウもそれなりにありそう。しかし、AAMならともかく、SAMで液体燃料を使うかなぁ。そういう固定観念を壊して安く作ろうぜ、って話になるのかもしれないけど。

　SpaceXってわりと燃料種類のバリエーション多いよな。ロケット用のケロシン/LOXやメタン/LOX、ロケット用RCSのLN2コールドガス、輸送船のハイパーゴリック、衛星の電気推進。いままで固体燃料を使わなかったのはやっぱり制御性の悪さとか? これを機にDoD予算で固体燃料の経験を得よう、みたいな腹づもりなのかしら。そんな「予算の浪費」が許されるかな?

　ルネサス製品ForgeFPGAの評価ボードを使ってロータリエンコーダを動かしてみた | 組込み技術ラボ

　Nucleoみたいに投げ売りして販促するボードじゃないから、開発ボードいい値段するね。パッケージ/ピン互換のチップを載せ替えて色々試せるように、とか、デバッグ用の機能も色々乗ってるんだろうけど。

　マイコンみたいに単体でいろいろ使えるようなものでもないし、評価ボードの売り方も難しいんだろうけど。

　せめてブレッドボードに載せられるような簡素な変換ボードが秋月あたりで販売されれば楽に遊べるようになるんだけどな。書き込み(USB-SPIブリッジとか)に一工夫必要だけど、Arduinoを使い回すとかすればいいわけだし。なんたって自社のMCUが乗ってるんだからな。

　ミニマルファブの時代がやってくる！：半導体工場を3000万ドルで構築（1/3 ページ） - EE Times Japan

　記事中では「ミニマルファブ」や「ミニファブ」が出てくるけど、産総研等が開発している固有名詞としての「ミニマルファブ」とは無関係っぽい。まぎらわしい…… 名は体を表すという意味ではミニマルファブという固有名詞はわかりやすいけど、とはいえ直交性が悪いよなぁ。

　MCUの「礎」的存在、Microchip「PIC16」：マイクロプロセッサ懐古録（3）（1/4 ページ） - EDN Japan

　Microchip設立の由来とか。

　Flash ROMの搭載で「(前略)だからといってProduct Definitionの期間が短くなるというのは理解しにくい」という話、後からFlushを書き換えて機能の変更ができるのであれば、最初の製品定義の段階で顧客の需要をキッチリ作り込む必要がなくて、後で必要な機能とか不要な機能が出てきたらそのときに対応すればいい、みたいなことなんじゃなかろうか。

　しかし、Microchipって社名の通り最初からマイクロコントローラーの会社なんだな。なんで原子時計扱ってるのか本当に不思議。

　Amazon.co.jp: All You Need Is Kill (集英社スーパーダッシュ文庫) 電子書籍: 桜坂洋: Kindleストア

　https://www.amazon.co.jp/dp/B00C7PU87G/

　そういえば読んだことないなー、と思って。2004年発売(映画は2014年)。

　原作と映画ではストーリーが全く違うな。原作はいかにもライトノベルという感じ。結末は映画のほうが好きだけど、映画では説明されていない部分も色々と書いてあるので、原作もオススメ。設定がだいぶ違うからそのまま流用できるわけではないけど。

　全く知らなかったけど、1ヶ月ほど前にアニメ化が発表されていたらしい。原作とも映画ともまた異なる内容だそう。自分としては原作と映画の中間くらいの感じで作ってくれると嬉しいなーといったところ。

***

https://www.jstage.jst.go.jp/article/zisin1948/44/Supplement/44_Supplement_15/_pdf

　1991年。地震計の波形の伝送に関する話。

　従来は無線回線、現在は専用回線や電話回線が主流で、衛星回線も出てきた。従来はアナログ波形の伝送が多かったが、計算機で信号処理する場合はどこかでA/D変換が必要になるから、地震計でデジタル化すれば信号を劣化させず、圧縮処理等も行いやすいから、これからはデジタル化が進むだろう。ただし伝送帯域を大幅に増やすことはできないから、非線形符号化等でダイナミックレンジを広げると大きな波形に乗った小さな波形が見えなくなったりとか、課題もある。

　衛星回線を使ったシステムでDCPの例もある。1MBのメモリと太陽電池・蓄電池を持ち、衛星経由のデータは基本的には磁気テープの形で得られるが、必要に応じて管制センターに問い合わせれば数分以内に取得できる。日本のひまわりを含めて4機の衛星が対応しているが、日本にはDCSを使った地震計は無いとのこと。

　衛星1機で数千台の地震計を中継できるそう。1日1440分でタイムスロット1.5分とすると最大限に詰め込んでチャンネルあたり1日に1000パケット弱、複数チャンネル(衛星1機あたり133ch中継できる)を割り当てればその数倍、需要さえあればまあ、割当はできるか。

　周回衛星を使った場合、1日に1KB程度しか伝送できないらしい。

　DCSは1パケットで600文字強(7ビットデータ+パリティ、バイナリデータ不可)を送れるから、16進で325バイト程度のバイナリを送れる。1キロバイトを送るには3パケットくらい必要。1パケットを送るのに1分、最大仰角の1パスで2,3パケット送って、場合によっては前後のパスで1パケット程度、と考えると、1日に1KB程度というのはそう遠くないか。DCSって転送レート結構低いんだな。

　データ転送を目的に周回衛星のDCPを使うのは難しそうだ。そもそも、低緯度地域なら静止衛星を使えばいいし、高緯度地域なら周回衛星のパスが多いから、場所によって相手を選べば問題ない、という設計思想だろうし、片方を選択して使うというものでもないんだろうけど。というかDCSってすべての衛星で(静止・周回問わず)共有のアップリンク周波数を使うはずだから、静止衛星相手に指向性アンテナを使うみたいなことをやらない限りは、ユーザーからは静止・周回の区別なく使えるはずなんだけど。

/* そういえば、1パケット最大650文字程度の制限は日本独自の仕様であって、海外仕様だとその制限はないはずだから、海外のDCS地震計は、リンクさえ成立すれば1パスで一気に1KBくらい送れるのかも */

　この当時はISDNはまだ都心部だけだが、64kbpsは現在より1桁増えるので、利用地域が広くなれば地震観測にも使いたい。

　地震計は市場規模が小さいので十分に開発リソースが投入されているとは言い難い。日本では優秀な技術スタッフを満足な待遇で雇用することも難しい。一方で、地震計は地震学の中で珍しい「ものを作る」という分野。

https://www.jstage.jst.go.jp/article/sicejl1962/16/9/16_9_714/_pdf

　1977年。地震観測技術に関する話。

　情報工学の専門家に地震計測の現状を話すと、必ずといっていいほどその情報量があまりにも多いことに驚く。さらに詳しく話すと、われわれが一生けん命集め保存してあるデータと、その収集方法にはたいへんなむだがあると指摘し始める。そこに地震学の現状が表されており、また自然科学の中での特殊性が見られる。

　とはいえ、「地震学者はほとんどの場合自分の研究のために必要十分なデータを手にしたことはない」とも書いてあるわけだが。

　短周期の地震のデータ量。50Hzまで見るために200Hzでサンプリング、1回の地震は10秒、3成分で、10箇所で観測して、1日10回、として、200*10*3*10*10=600kw/日。8bitで記録したとしても600KB/日、もう少しダイナミックレンジを広く取って16bitで記録すればその2倍。1週間で10MBあたりか。「こんな情報を交換することは不可能である」だそう。10MBなんて今の時代からすればスマホの写真2-4枚程度の容量だけど、半世紀前だもんなぁ。

　データの保存。「オンライン監視がなされていない場合、例えば無人観測点を置いたとき、われわれは欠測の恐怖に襲われることになる。目指す地震が発生し、その記録を回収に行ってみると、ちょうどその前から故障していたということによく出会う。やりなおしのきく屋内実験との差を最も痛切に感じるのである」 地震計のテレメータ化は研究者の精神的にはだいぶ良くなったんだろうなぁ。回線使用料を考えると予算取得の面で苦しそうではあるけど、。

　地震観測システムを設計するとき、多くのメーカの技術者と出会って感じたことは、どのような研究をどのような方向で進めようとしているのか、ということを理解してもらわない限り、良いシステムは完成しないということであった。細かい数字は具体的な問題にぶつかったとき改めて整理してみればよい。計測技術の発展の方向を理解した科学者と、その分野の研究の方向を感じとる技術者とが、出会うことが科学を一歩進めるために重要な意味を持っていると思う。

https://www.jstage.jst.go.jp/article/jscejseee/69/4/69_I_448/_pdf

　重力異常の調査を目的に、サーボ加速度計にデジタル制御を組み込んで、ダイナミックレンジを広げる提案。ダイナミックレンジが広ければ船舶や航空機に対して防振機構を経由せずに搭載できるから、観測が容易になる。

　レンジ200Galで分解能1uGalだから166dBくらい。地震計に比べると10-20dB広い程度? 新しい方式だし、今後もう少し広くなるんだろうけど。

　重力系の試験で観覧車を使うという話。高低差を容易に得られるから、とのこと。高低差がほしいだけならエレベーターに乗ればよくねって気もするけど、中層ビルだと重力変化が少なすぎて、超高層ビルだとエレベーターの加速度が高すぎる、みたいな話なのかな。

https://www.jstage.jst.go.jp/article/kokusaianzenhosho/41/2/41_116/_pdf/-char/ja

　2013年。CTBT(包括的核実験禁止条約)に関する説明とかいろいろ。どうやって核爆発を把握するか。

　CTBTが集めるデータは世界各地で得られたデータなので、地球規模の現象を把握するうえで効果的。本来想定していた用途以外にも使えるのではないか。例えば微気圧振動で火山噴火を把握することで航空機が噴煙に突っ込むことを防止できる。

　かつてはGPS衛星の使用すら軍事由来(米軍が構築したシステム)だからと嫌がってた民間航空機業界が、監視用とはいえ核兵器関連の技術まで使うとは、時代は変わるものだなぁ。まあ、「IMSデータの使用を認める」という書き方だから、彼らとしてはあくまでも自分たちが集めたデータに加えてCTBTデータも含める、みたいな扱いであって、軍事技術に依存しているわけではない、ということなのかもしれないけど。

「核実験が必ずしも頻繁に強行される現状にない今日において、CTBTの検証制度を高価な玩具にしないことも重要であり、近年IMSデータが多目的に活用され始めていることは理にかなったものである」

　註の13に、地震波形を周波数解析することで、核実験か否かの判定に利用できる、みたいな話が書いてある。ソースの論文は気象庁のものだけど、オンラインで読めるものではなさそう。

https://www.jma.go.jp/jma/kishou/books/kenshin/vol81_1.pdf

　2017年。地震計に記録されるいろいろな震源の種類。主に人口由来のものを文献から参照している。エネルギーとマグニチュードの関係とか。観測した振幅と距離からマグニチュードを推定してエネルギー変換効率を推定したり。

https://www.jstage.jst.go.jp/article/kaihatsukogaku1984/13/2/13_2_27/_pdf/-char/ja

　1994年。NHKの人が書いたもの?

　情報は大手メディアが選別したものを配信する一方通行の「垂直の流れ」から、送り手と受け手の区別のない、管理・選別されない情報が絨毯にこぼした水のように「水平の流れ」へと変わるだろう、というような話。その例として、1993年の核実験をNGOが探知した事例をあげて解説している。衛星画像を入手する方法や地震波形の解析とか。

　最後に情報の流れが変わったあとのメディアのあり方の話とか。

　30年前にこういう話がすでにあって、現在になってこういうグダグダになってるのか、というのでちょっとアレな感じもする。

　高速フーリエ変換のアルゴリズムを再発見した動機が核爆発の探知を目的とした地震波形の解析だそうだけど、日本語資料だといまいちこのあたりの話題が少ないのよなー。普通に地震計の資料とか読んで終わった感じ。日本語資料だと北朝鮮の核実験の話題が大半で、その他にCTBT関連の話題があって、解析とかの話はあまり見当たらないかな、という感じ。古い資料だと米ソの核実験のデータ解析とか中国の核実験の話題も出てくるけど、その当時はまだ日本の地震観測網もあまり発達していなかったっぽいし。

　地震計も地震計でダイナミックレンジめちゃくちゃ広いので計測システムとしても面白いし、地球物理学みたいな計測対象も面白いんだけどな。気圧変化によって重りの浮力が変わるから上下方向にノイズが出るとか、なかなかにすごいものを測っている(気圧変化のない気密容器に入れると差圧で歪んで水平方向に出てくる)。

　非理系大学の学生?が書いた論文で、核実験の直接的な検出を目的として、ニュートリノ検出器を使う話を見つけた。それらしいワードでググっても他に出てこないのであまり主流の話題では無いんだろうけど。

　原子炉をニュートリノで監視するみたいな研究は実験的に行われているようだけど、今のところは原子炉建屋のすぐ直近で炉のON/OFFの差が見える程度らしい(おそらく絶対値でON/OFFを見分けるところまでは行ってない)。原子炉(制御した臨界)と原爆(ほとんど暴走状態の臨界)では放出されるニュートリノの量も違うだろうけど、それにしても数十mとか数百mで差を見るのがギリギリとすると、1000kmとか離れた場所の核実験の検出は難しそうだ。検出器を大量に配置して同時にイベントが発生するのを探す、みたいな方法はありそうだけど。

　ただ、ニュートリノ検出器って、潰しが効かないのがちょっと大変そうよなぁ。原子炉監視用の検出器はトラックで運べる程度の規模とはいえ、核爆発検知用は一回り大きくする必要があるだろうし、それを世界中に数千台くらい設置したとして、核実験の検出にしか使えない。地震計とか微気圧変動は、普段の地震観測とか火山監視とか応用が効くけど、ニュートリノはそういうお題目が無い。天文へ応用しようにしても、数で感度を補えるとしても、角分解能が足りなさそう。

　カミオカンデみたいな大容量の検出器ならなにか見えそうな気もするけど、ググってもそういう話題は出てこない。少ない記述によると、帯域(エネルギーバンド)とか角分解能の問題らしい。

　ニュートリノ振動の説明だと1.5GeV以上と以下のグラフがあるから、このあたりが観測帯域の中央付近なのかな? 核分裂で発生するニュートリノがMeVあたりのはずだから、3桁くらい違うのか。それと、この図ではcosθを10分割してヒストグラムを取っているから、角分解能は20度程度しか無いらしい。1000km先で幅300kmの分解能だから、なにかイベントがあっても拘束がちょっと弱い。九州とか北海道あたりにもMeVレベルが見えるSKクラスの検出器を設置すれば北朝鮮の核実験をToFで絞れるかもしれないけど、いくらなんでもコスパが悪すぎる。

*

　地震計のデータ圧縮でフィボナッチ符号というのが書かれていたので、C#で実装して遊んでみた。

　0以上の自然数は隣接しないフィボナッチ数の和で表すことができるから、連続する1をデータの区切りとして使うことで、容易に復号できる(単純なビット演算で可変長ワードの区切りが見つかる)。符号化する際も比較的単純な演算で行える(先にフィボナッチ数テーブル(数百バイト程度)を用意しておけば、それと比較しながら減算とビット加算を行うだけ)。64bit処理系なら2^43.9(10^13.2)くらいまでを簡単に扱えるから、広ダイナミックレンジな信号を容易に圧縮できる。

　0以上の自然数しか符号化できないから、負数を扱うには工夫が必要になる。また、0を符号化するには余計に1,2bitが必要になるから、1以上の自然数に正規化するほうが有利なはず。正数しか扱わないなら1を足すとか、負数まで拡張したいなら、正数なら2倍して1を足す、負数なら-2倍する、みたいな感じで。

　符号化する数値の絶対値が大きいほど長いビット数が必要になる。何回か微分して書き出せば多少圧縮率を稼げる。綺麗な波形(Sincとか)であれば2回微分程度で比較的良い圧縮率が得られるけど、正規分布みたいなノイズを与えてやると急激に圧縮率が低下する。

　圧縮率はDeflateとほぼ同じ程度かな。Deflateが使えるなら、わざわざフィボナッチ符号を実装する理由はなさそう。ただしDeflateは過去のデータから一致位置を探したりハフマン木を作ったり、アルゴリズムが重いしメモリ空間もある程度広く必要な欠点がある。フィボナッチ符号は過去のデータ列が必要ないし、微分するにしても大して追加リソースは必要ないし、アルゴリズムも非常に軽い。

　観測対象が十分に精度良くモデル化できて(例えば2回微分すると単位時間あたりの絶対値の和が小さくなるとか)、かつSNRが十分に高い場合は、非常に低コストで圧縮できるフィボナッチ符号は良さそう。

　半世紀前の地震計だとデータ圧縮の動機はありそうだけど、昨今はどうなんだろうか。イザというときにDCPを使うことを考えると需要はあるのかな? とはいえたかだか数百バイト程度しか送れないなら50%まで圧縮できたところで地震波形を送るなんてことはできないだろうしなぁ。組み込みコンピュータの計算能力でゴリ押しして地震波のパラメータ(時刻や振幅)だけ送るような感じになってそうな気がするが。

　IoTみたいに計算リソースが少なくて帯域幅が狭いプローブに使うのにフィボナッチ符号は良さそうではある。まあ、8バイトのデータを6バイトに圧縮するくらいなら、生のまま飛ばすほうが楽だろうけど。

***

追伸

　私事ですが(というと仕事で書いてるみたいですが)、先日誕生日を迎えて30歳になりました(計算を間違っていなければ)。10進数では節目の年なのでなにか書こうかとか思ったりもしたんですが、ちょっと筆を執ってみると思ったより精神的にキツかったので、やめました。うーん、結構引きずってるなぁ……

　いくつかのSNSを転々としつつ、結局このブログが一番続いてます。昔のネットも(楽しかったけど)結構ギスギスしていて疲れたのに、最近のネットは本格的にPvPの殺し合いみたいな世界らしいしね。何事もなければしばらくはこのブログの週1更新は続ける予定です。書くネタなにも無いけど。

　最近何やったかなーと振り返ってみても、ここ10年くらいマジで何もやってないんだよなー。本格的にやばい気がする。とか思いつつ何もやらないあたり現状の因果関係がはっきりしていますが。

小ネタ

　スチームパンクスタイルのGPSナビゲーションデバイス。ダイヤルで緯度・経度を入力すると、方向と距離が表示される。

　紙テープとかパンチカードで目的地を設定できるような機能があると面白そうだな。パンチカードを裏面のポケットに入れておくとその場所まで案内してくれて、複数のウェイポイントを経由したい場合は都度カードを入れ替える、とか。パンチカードを面で認識しようとすると膨大な画素が必要なのが欠点。ポケットに入れるときにスキャンして抜かれるまでそれを記憶しておく、あたりが落としどころか。

　パンチカードとニキシー管だと、パンチカードのほうが早いかな。ニキシー管の使用が許されているスチームパンク世界観なら、パンチカードの使用も問題ないはず。/* そもそも、スチームパンク世界観でパンチカードはともかくとして、ニキシー管が許可されるかは怪しい気がするけど、そんな事言い始めたらGPSもな。。。 */

　野辺山でトランシーバー携帯必須はだめでは? いや、観測帯域周りを徹底的に切り落とした専用のトランシーバーの可能性も……

「税金で建てた研究施設だから無料で見学ができます」というスタンスは羨ましい。無料に限らず、科学技術系の展示施設は関東以南に多そうな印象。東北でも例えば岩手の水沢とかあるけど。こういう施設って水沢あたりが北限のイメージ。

　科学技術系の展示施設だと青森県六ケ所村とか北海道泊村とかにもあるけど、ちょっと内容が特殊というか。/* こういう施設ってどういう展示をしてるんだろう。大人が見て時間を潰せる(or見て面白い)ような内容はあるんだろうか? */

　やっぱり人口密度が低いと入場者数が見込めないから展示施設を作れないんだろうな。まあ、丸の内に作ってある程度人は集まったけど維持費が高いと言われて廃止された展示施設とかもあるわけだが。北海道とかどうですか! 土地代たぶんめちゃくちゃ安いし広い敷地を確保できるから展示施設をそのまま倉庫代わりにも使えますよ!! アクセス悪い地方にそういう系統(地元の産学とほとんど無関係な内容)の展示施設を作ってもらおうとすると、倉庫という建前で見学もできる施設、みたいな言い訳のほうが作りやすいかもなぁ。とはいえ、倉庫として使う前提だと入退室管理とか色々面倒になりそうだが。あと、アクセスが悪い場所に倉庫を作ると在庫の出し入れが面倒だし。

　eufyMake E1 UV Printer: Compact 3-in-1 UV Printing Solution - eufymake US

　旧AnkerMakeブランドの新製品。フルカラーで立体面(凹凸)も印刷できるUVプリンタ。今のところ発送先に日本は含まれていないが。

　Kickstarterのページがまだ無いっぽいので値段はわからないけど、$50払って$800+安くなるってことは、$3000-$5000位になるのかな? さすがにホビーユースとして売るには高すぎる気がするが。かといってクラファンで応援して半額とかになるかな? 半額だって$1600だが。/* 50ドル払えば750ドル分得するって結構ヤバそう */

　3Dテクスチャを印刷できるらしいけど、UVレジンの3Dプリンタをインクジェットで作ったみたいな感じなんだろうか。

　円筒や円錐台にも印刷できるらしい。5軸CNCみたいに2軸で回転する軸があって、いい感じに制御してくれるんだそうだ。マグカップやマイボトルのデザインをオリジナルで作れるよ、とのこと。LiDARで凹凸をスキャンしたりするわけじゃないだろうから、ちょっと複雑な形のタンブラーとかには対応で来なさそうな気もするけど、回しながら撮影すれば断面形状が得られるから、座標変換すればいいだけか。ソフトウェア次第でどうにでもなりそう。まあ、どうにもならなかった前例もあるわけだが。。。

　eufyMakeの製品ページ、新製品のUVプリンタ以外にはPLAフィラメントと3Dプリンタの交換部品しか残ってないから、3Dプリンタ本体は撤退したんだろうな。結局ホビー向けを含めたFFFプリンタはBambuLabが強いし、AMSでマルチカラー印刷とかもできるしな。AnkerはAMSの大量のゴミを削減できるという見込みで3Dプリンタに参入したけど、製品としては実現できなかったわけだし。ホビー向けの3Dプリンタとして何かアピールできる点があるかというと、無いだろうし。Anker製品の外形CADデータとか配布してくれたら面白かったんだろうけど、それにしたって結局Bambuで印刷すればいいじゃんって話になるし。

　Framework 12、すごく欲しいんだよなー。なんで日本向けに売ってくれないんだ。

　最小構成で550USD、色々オプション乗せて1500USD、あたり。わりといい値段するな。メモリくらいなら後で交換することもできるけど、さすがにメインボード丸ごと交換は部品代がヤバそう。ストレージは価格的にはそこまではいかないけど、データの移動とかの手間を考えると面倒そう。となると結局最初から余裕を見たスペックで注文するしかなさそう。でも、若干円高が進んだとはいえ、20万円台かぁ…… やっぱり最小構成で注文して足りない部分はあとから? いや、そもそも注文ができない問題が。。。

　ACS、とりあえず、ランチャー上で110時間くらいでエンドクレジット等。各章のバランス悪すぎんだろ……

　アサクリの竹の切断はメディア向けの先行プレイでも微妙に話題になってたけど、竹だけでなくて、いろいろなオブジェクトの切断が結構作り込んであってすごい気がする。

　竹を切った場合、生えている竹だけじゃなくて、切った先の竹も更に切れるし、それもまた更に切ることができる。

　籠を切ると、ちゃんと刀が通った面で切れるし、切ったあとの破片も同様に切ることができる。

　布を切ると、刀が通った場所が切れるし、完全に切ったときも、中途半端に切ったときも、ちゃんと物理演算が持続して切れたとおりに風にはためく。

　今まで銃を撃つゲームばっかり遊んでたから、こういうオブジェクトが切れたあとの挙動があるゲームを遊んだことがなかったのでだいぶ新鮮。

　奈緒江はスキルポイントを振れば敵の強攻撃もほとんどがパリイできるけど、弥助は敵の強攻撃は避けるしかできないし、反撃するにはジャスパするしかないけど、タイミングがかなり狭くて、その前に攻撃コマンドを入れていたらほとんど避けられない。攻撃しないで待ってると膠着する。あるいは、敵の攻撃を1回食らうと怯みで次のパリイが間に合わないから連続して食らう。

　クナイもスキルポイントを振ればほとんどの敵を接近せずにほぼオートエイム&追尾でヘッショのステルスキルができるけど、弓矢は当たり判定が狭いから敵の動きをしっかりと予想して偏差射撃しないと当たらない。クナイは低い確率でヘッショから外れて敵に気づかれるけど、それでも矢より遥かに使いやすい。

　イーグルビジョンとかが使える点も含めて、圧倒的に奈緒江が使いやすくて、バランス調整がちょっとびみょい感じがする。こういうゲーム(マウス押しっぱで銃連射すれば勝てる、みたいなやつじゃないゲーム)に慣れている人なら弥助もうまく使えるのかもしれないけど、自分には使いこなせん。

　とりあえず、メインストーリーは一区切りついたし、サイドミッションはいくつか残っているけど大半は終わったし、マップは未開放が結構あるけど大部分は道すらない山だし、全体的に区切りはいいかな。サブスク1ヶ月分が残り数日なので、最後の数日はしっかり遊んで、自動更新は停止かなー。遊びすぎて色々支障出てきてるし。25日で120時間遊んで4.8h/dくらい。そりゃ支障も出ますわ。。。AFOPは2ヶ月で70時間強だから、4倍以上のペースで遊んでる。ここまでガッツリ遊んだゲームはかなり久しぶり。

　Airspy Mini、サンプリングレートが10Msps、6Msps、3Msps、あたりの固定値しか使えないのかな。いや、そんなわけ無いだろ、と思ってたんだけど、本当にそうなの?

　R2だとクロックジェネレータ(Si5351C)が乗ってるから自由度高めらしい? メーカーの製品ページには「10Msps IQ Output」と、実験的な機能としてRasPi等で使うための2.5Msps出力機能が書いてある。ということは、任意のサンプリングレートを設定するのは不可能っぽい(可能なら実験的な2.5Mspsは不要で、適当な低いレートを設定すればいいだけ)。ファームウェアを書き換えればSi5351でサンプリングクロックを作れる、みたいな話なのかな。

　ISDB-Tとかを受信して遊ぶことを考えると、サンプリングレートを細かく設定できないのは結構ネックなのよなー。

　普通のR820+RTL2832でもサンプリングレートは0.2Hzくらいの誤差で1Hz単位で設定できるのに、Airspyにそういう機能がないのはちょっと不便な気がする。RTLはデシメーションでサンプリングレートを調整しているはずだから、元々そのサンプリングレートで取るのとはまた違うのかもしれないけど。

　個人でも買えるようなルートで売っているちゃんとした受信機だとUSRP B200とかがあるけど、さすがに25万は無理ですわ。。。秋月で取り扱いが始まったのは2020年からだけど、youtubeで探すと10年以上前の動画が出てくるから、結構古い製品なんだろう。そのわりに参考になりそうな動画がほとんど見当たらないのは値段故かな。6GHzとかいらんやろと思いつつ、まああれば5.8GHzとか覗けるし面白そう。

　結局、遊びのレベルでSDRに手を出そうとすると、RTL-SDR blogのドングル(v3 or v4)が最強なんだろうなー。

　C#のint.Minとかそういう系のメソッド、たまに引数を3個とか4個とか取るオーバーロードが欲しくなるんだよなー。いちいちint.Minとかネストさせるのメンドクセ。まあ、そういう話をすると、じゃあ何個あれば足りるんだよ、という話になるから最低限の2個だけしか実装していないんだろうけど。

小ネタ

　可動部めっちゃ多くて価格めっちゃ高そう。でもすごく面白そう。

　内燃バイクとかヘリコプターも可動部はそこそこ多いけど、基本的にパッシブな可動部に対して、関節の多いロボットは1個1個の可動部が能動的に動くからそれぞれにコストが掛かりそうだよなー。歩く程度に動く乗り物を作るのは難しくないだろうけど、快適に移動できる、移動手段として使える、アクティビティとして乗ること自体が目的にならないようなものを作るのはかなり大変そう。

　ホットケーキ。フライパン(テフロンの行平鍋)で、冷却無し(1枚)とそれ以外。見た目が全く違うな。冷やすと綺麗に焼けるけど、急冷すると熱応力で鍋がどんどん歪んでいく。

　カーナビが使っていたDGPSの補正情報、VICSで受信しているものだと思っていたけど、実際には別のシステムだったんだな。いくつかのナビゲーションシステムではVICS(交通情報)とDGPS(測位精度)が選択式らしい。VICSはNHK-FM、DGPSはJFNなので、1chの受信機では片方しか受信できないから、とのこと。オプションでFMチューナーを追加してVICSとDGPSを同時に受信できる機材もあったらしい。

　カーナビ各社のプレスリリースによると、（株）衛星測位情報センターが提供する情報をFM多重放送で送信していたらしい。’97年5月から’08年3月末まで。’00年5月にS/Aが解除されたのでDGPSは必要なくなった、ということで放送を終了したらしい。

***

　聞き慣れないジェット音がするなーと思ってFr24を見てみたらなんか変なのが飛んでた。変なの? 変かどうかもわからないやつ。まあ、ADS-Bで見えないジェット機はその時点で結構怪しかろう。

　北海道の西側の日本海海上とか、下手すると鳥取近くまで伸びてるけど、Fr24のMLATのアルゴリズムの問題だと思う。

　Fr24で監視しつつ、近くに戻ってきたタイミングがあったので窓の外に出て見てみた

　見づらいけど、中央に2つの明るい点が見える。千歳のF-15とかなのかな? 夕方から夜にかけて編隊飛行の練習をしつつ地理感覚を掴むためにあちこち飛び回って、とかなのかしら。

　ICAOアドレス000FFFはググると空自F-15で使用実績があるコードらしい。じゃあF-15で確定かな?

　1090MHzのログ

　たまにMode-Sのリプライもあるけど、大部分がMode-3/A/C。ただ、F-15から000FFFのコードが出ているということはMode-Sトランスポンダも積んであるわけで、このSリプライもF-15由来なのかもしれない。

　Mode-3/Aっぽいリプライはいくつか受信できていて、そのうちのいくつかはコヒーレントで綺麗な波形だし、別のいくつかはインコヒーレントで振幅もパルスによって違うからガブールっぽいとわかるやつもあるし。

　むしろ編隊飛行していて毎回ガブールにならないほうが不思議。戦闘機に積んであるトランスポンダって応答レートを適当に低く設定してガーブルを起こしづらいように、みたいな機能があったりするんだろうか? それとも民間用のトランスポンダでもそういう機能はあるんだろうか。輻輳空域でガーブルを起こさないように、ということで民間機にそういう機能があってもおかしくはない気がするが。

　それとも、応答数がわりあい低い気がするのは、ATCレーダからの質問じゃなくて、オンボードのトランスポンダからの質問に対する応答だから、相互に質問し合っている状態ってことなのかな。

　rtlドングルだとトランスポンダのリプライがあることは見えるけど、その中身を確実に復調するのは問題があるんだよなー。やっぱりもっと帯域幅の広い受信機が欲しい。Airspy miniあたり買うべきかなぁ。rtltcp.dllを叩いたことでDLLへの恐怖が薄れたので、AirpsyもDLL経由で使えばいいんじゃね、とは思い始めている今日このごろ。帯域幅が広くなったところで、Mode-3/A/C応答のデコードを維持したままMode-Sをデコードできる、くらいの違いでしかないし、Mode-Sのエンコードの複雑さを考えると自分でデコーダを書くのも面倒だし、結局持て余す気がするのよなー。

***

　球面調和関数で遊んでる…… 正確には遊ばれている。

　球面調和関数の何が難しいって、量子論とかそういう話じゃなくて、全く別の場所にある。

　参照する画像によって形や向き(符号)がバラバラで、そもそもどれを基準に確認すればいいのかすらわからない。

　1枚目はm=0で画像下側が常に正、2枚目と3枚目は画像上側が常に正。1枚目と2枚目は0<=mでcos、m<0でsinだけど、3枚目は常にcosを表示している。ただ、3枚目は明らかにほかと形が違う。

　元々はジオイドモデル(EGM2008とか)を計算したかったんだけど、うまく計算できなかった。計算方法をググっても出てこないし。

　ジオイドモデルって必要なときになって計算するものだから、計算はそれなりに軽いはず。それにNが2200くらいまであるとして、その階乗をどうやって計算するんだって問題もあるし。2200!が10進で6400桁位になるから、4倍精度浮動小数点数(4900桁程度)でも取り扱うことができない(8倍精度なら精度が圧倒的に足りないという問題を除けば取り扱い自体は可能)。そもそもそんな係数をどうやって求めるんだとか疑問は尽きないけど。

　とにかく、ジオイドが必要なときにいちいち任意精度演算とかやるのも大変だろうし、そもそも階乗が必要なのは係数のスケーリングであって、θ、λとは無関係だから、このあたりは事前に調整してあるはず。係数の説明にもfully-normalizedと書いてあるし。とすると基本的にはθ、λがpowとかcos/sinに含まれる項目だけ計算して総和を取ればいいはずなんだろうけど、そういうふうに処理してもいい感じの結果が得られない。

　なにかヒントないかなーと思ってjstageでEGM2008で探しても、使用例はいくつか出てくるけど、計算方法を詳しく説明するような資料は見当たらない。EGMを使っているような例でもグリッドデータを使っている風だったりとか。

　EGM2008のグリッドデータはバイナリ(F32LE)で配布されているけど、150MB(ZIPで130MB)くらい。球面調和関数の係数はテキストで同じくらいの容量だから、単純にデータファイルの大きさで比べればどちらを使っても大して違いはない(全データをメモリに読み込んでおく場合は係数表のほうが圧倒的に小さい)。ただ、任意の座標を非常に低コストな計算量で取得できる分、グリッドのほうが楽。周囲4点からの線形補間で地理院の24年β版とは1m未満の誤差。グリッドの線形補間と球面調和関数の計算で比較すればまた有利不利が出てくるのかもしれないけど、計算方法がわからないことには。。。

　いちおう、係数ファイルにはFortranのソースコードも付属しているけど、Fortranの文法なんて知らないよ。。。

https://www.jstage.jst.go.jp/article/enrihappyou/17/0/17_2/_pdf/-char/ja

　航空機の気圧高度の精度を確認する手法に関して。従来はMLATを使っていたが、機材の維持にコストがかかる(複数受信点での時刻同期とか)。ので、ADS-Bを使えないかという検討。

　ADS-Bは機材によって標高(HAG; Height Above Geoid)を出すものと楕円体高(HAE; Height Above Ellipsoid)を出すものがあるんだそうだ。ジオイド高は±100mくらいの範囲を取るから、同じ高度をレベルフライトしている2機がHAGとHAEで違う場合、双方で100mの高度差があると誤認する。逆に、100mの高度差があっても同高度であると誤認する場合(あるいは200mの高度差があると認識する場合)もある。

　TCASのシステムは850ft(260m)で警告(TA)、600ft(180m)で回避指示(RA)を出すらしい。双方のリファレンスが100mズレている場所で、レベルフライトのセパレーション1000ftで交差すると、気圧高度(Mode-C)では1000ft差があるのに、ADS-Bでは700ft未満差として誤認されて、TAの誤警告が出る、みたいなことはありそう。その逆(RAやTAを出すべき状況で出せない)もあるだろうし。

　ジオイドの低い方はIOGL(Indian Ocean Geoid Low)と呼ばれる場所で、en.wikipediaにも記事があるけど、高い方はそういう話が見当たらない。高い方は何箇所かあるけど、数値として一番高いのはパプアニューギニア・アルバート・エドワード山の西側の85.8mくらいだと思うんだけど、それっぽいワードでググっても関連しそうな話題は出てこない。

小ネタ

　4月1日の動画……じゃ、無い、だと!?

　本国のアカウントだと#aprilfoolのタグが付いてるんだけど、日本語アカウントだとそういうのが無くて、投稿日も含めてマジネタかと思ってしまう。日本時間だと4月2日0時の投稿だけど、欧州だと4月1日の午後だし、アメリカだと4月1日の午前なんだよな。英語圏のアカウントで4月1日中に投稿するようにして、他言語版はそれに歩調を合わせて、とするとタイムゾーンが早いエリアだとエイプリルーフルが終わったあとになっちゃうんだな。

　面白かった。ストーリーはあまり長くなくて、サクサク読めば1時間足らずで終わる。

　PV段階だとIDPAっぽい感じを想像していたけど、ちょっと違うベクトル。ゲームセンターのシューティングゲームっぽい感じなのかな?

　UIがシームレスでポップなのは結構好き。

　アーケードはかなり奥深い。レートが全然上がらない。手ブレはランダムっぽい感じがあるけど、マウスのコントロールである程度軽減できるような気もする。上手い人がやると上手そう。

　頑張ってもAAまでしか行けない。それもあまり好みじゃないプレイスタイルでようやく。Steamの実績によると20％位のプレイヤーがSまで行ってるらしい。SSSまで行っている人も結構いる。どうやったらそこまで行けるのか全く見えない。

　3Dプリント(PLA?)のヘルメット(自転車用)って、相当危険そうな気がするけどなぁ(某社のPV)。自転車のヘルメットが義務化されているわけじゃないだろうし、安全基準に則ったものを使わないと罰則がある、というわけでもないはずだから、安全性なんて気にせず好きなの使おうって話なんだろうけど。

　SETI的な文脈で、進んだ文明は強い電波を出している(文明の程度と電波強度が比例する)と想定している場合があるけど、どうなんだろうか。電波ってかなり限られた資源なので、人口が増えると一人あたりの電波強度は落とさざるを得ず、惑星全体での電波放射量はある程度のところでリミットするはず(少なくとも指数関数的な増加よりは対数関数的な増加になるはず)。

　技術レベルが発達すれば単位情報あたりの通信に必要なSNRはある程度下がるだろうし、人口密度が高くなったり、あるいは経済的に余裕がある場合は、通信網の基地局をより高密度にできるから、電波強度はさほど高い必要はないはず。ラジオとかテレビみたいな放送にしても、利便性を考えれば移動体通信にデータを乗せるほうが楽そうな気がする。地球だってラジオやテレビはradikoやTVerで配信するような時代になってきているし。SNRにはシャノン限界みたいな下限があるとしても、基地局を密にするとか色々な工夫次第で電波強度は下げられるはず。というか下げてセルを小さくしていかないと莫大な人口をカバーしきれないはず。

　レーダーみたいなものにしても、例えばアメリカではADS-Bを必須化して民間の空港ではPSRを削減するみたいな方向になっているし、軍用レーダーが必要だとしても、信号処理が発達すれば電波強度は低くていいわけだし、むしろ敵に攻撃されるのを防ぐためにLPIレーダーみたいなものが普及するだろうし。SETIで探す対象になるような進んだ文明が惑星内で戦争をするような状況かどうかは別にしても、民間用レーダーだって符号変調とかを使う利点はあるわけだから、巨大な尖頭電力を持ったレーダーに期待してSETIの探索条件を設定するのは厳しい気がする。

　光学SETI(OSETI)専門の人が書いた本で「緑色のレーザーを見たらそれはYAGレーザーだと思って間違いない」みたいな話が出てくるんだけど、高出力レーザーだけじゃなく、民生用のレーザーポインターとかも含めて説明しているのが怪しい気がする。レーザーポインターで使われているレーザーダイオードってYAGとは別物じゃね?

　OSETIでYAGの第2高調波をターゲットにする理由が、「肉眼で見えるから放射がわかりやすくて安全」という理由らしくて、うーん。スペクトルが太陽と同じ恒星系が相手ならその理論は成り立つけど、長波長側の恒星系のほうが宇宙での分布としては多いだろうしなぁ。もっとも、長波長側はエネルギーが低いから生命が誕生したとしても知的生命体(人類と交信できる程度の技術レベル)まで進化しないはずだ、という理由で除外しているわけだが。それとて自分が使える望遠鏡が可視光付近しか観測できないからそういう理論を作っているだけじゃないか、という気もするけど。

　25日22時55分頃に外を歩いていたら火球が見えた。東北からも見えたらしい。火球ってかなり広い範囲から見えるんだな。

　火球を専門的に取り扱っている研究組織とかないものかと思ってちょっとググってみたけど、なさそう。あくまでも有志が設置したカメラで写ったらラッキー、みたいな感じなのかな。これだけ広範囲で見えるなら、100kmくらいの間隔で全天観測していれば問題ないのかな。1箇所で天気が悪かったってこれだけ広範囲で見えるなら他の観測点からは見えるだろうし。あとはどうやって検出するかだけど、今は観測報告から録画を確認するみたいな感じなのかな。それにしたって今後はAIで自動的に怪しい現象をリストアップするとかの方向になるだろうし。

　国土交通省/気象庁とか、ウェザーニューズとか、全国的にカメラを配置している組織は色々あるだろうし、用途から感度とかもある程度高いはずだし、火球の観測とかに使おうって話はないんだろうか。個人が問い合わせたところで対応してくれるとも思えないけど、NAOJとかある程度権威のある組織から「何月何日何時何分頃、緯度xxx・経度yyyの方向を向いていた画像データありませんか」みたいに問い合わせたら対応してくれないのかな。NAOJも予算不足とか色々大変でわざわざ火球なんか関わってられねぇって話はありそうだけど。

　新しいマウス、3日くらい使ったところで充電インジケーターが赤く点滅を始めた。ユーティリティのアイコンだとまだ50％程度残ってそうなのだが。2日毎程度で充電したほうが良さげ。DODを低めに維持したいなら毎日充電でいい。

　充電ステータスLED、サイドボタンの手前側にあって、普通に右側に置いたときにLEDが顔に正対するからかなり見やすくて良い。マウスに内蔵したRGB LEDは設定した色を維持したまま、インジケータだけ小さく光る。このデザインはかなり好き。

　ただ、RGBで光るのって、手のひらで握り込むと見えなくなる場所のロゴだけなんだよな。ゲーム中はマウスを動かしているからロゴが光っているけど、このときは見えない。手を離すと見えるようになるけど、数分程度で消えてしまう。Razerのマウスは手のひら部のロゴとホイールがRGBで光るから、持っていてもホイールは光っているのが見える。とはいえ、これをやろうとすると結構複雑な光学系が必要になる(RazerはわざわざLED専用の基板をFPCで接続している)から、コスト的にかなり厳しいはず。エントリー価格帯のブランドとしてはロゴを光らせるのが精一杯、充電インジケータを別につけるだけかなり頑張ってそう。

　Type-Cコネクタは少し奥まった場所にあるけど、穴がテーパーになっていて挿しやすい。こういう使いやすさに直結する細かい作り込みはさすが日本の老舗メーカーって感じ。

　ACSを遊んでて、移動が結構楽なのが好きなポイント。山をまっすぐ突っ切ろうとすると木とか崖が邪魔だけど、ナビに従って道を走る分にはかなり楽。Zでオートランにしてマウスで方向だけ微調整するなら片手だけである程度の速度で移動できるから、移動中に軽く飲み物を飲んだりなにかつまんだりができる。たとえば某配送ゲームは移動がゲームのメインコンテンツなのに(だからこそ)移動の難易度が高くて、つねに両手操作が必要だったから、長時間の移動中にプレイヤーが飲み物を飲んだりすらできないのが不満だった(ゲームの中の主人公は好きなタイミングで飲食できるのに!)。

　ゲーム内に温泉(湯気が立ち上るちょっとした池)があるけど、温泉に入ってもなんのアクションも無い。が、フォトモードに入ると画面が真っ白になって何も撮影できなくなる。海外版だとなにかアクションがあって、それに応じてフォトモードにも光を入れているけど、日本版ではアクションだけ削ってフォトモードはそのまま、みたいなことなんだろうか? 疲労ゲージがあるわけでもないし、戦闘すると体力は削れるけど、敵から離れれば自動回復するし、温泉に入って回復するようなゲームシステムじゃないからな。

　ファストトラベルで季節が変わるのはいいとしても、キャラクター切替時にも季節が変わるのが結構面倒なんだよなー。ステルスキャラで敵の大型拠点をクリアリングしてからゴリ押しキャラに切り替えて倉庫の扉を壊す、みたいな遊びができない。攻略前に季節を切り替えてタイマーをリセットしてから爆速でクリアリングしてキャラ切り替え、ならいいのかもしれないけど。ちゃんとそれぞれのキャラで遊べよ、ってことなんだろうけど。

　ACS、ゲーム規模がクソでかいのにリリース後何日か経って安定性改善の1.0.1を配布しただけで、自分の環境では安定性は全く問題ないし、バグも全然無いし、すごく良くできていると思う(稀にステルスキルした敵がバネ仕掛けのごとく起き上がってくるから、KIAは確実に確認する必要があるけど)。

　遊んでいて体験が単調になりすぎるということもあまり無い。敵が少なすぎたらプレイ時間の大半が移動で占められてしまうし、敵が多すぎたら数十秒歩いてすぐ戦闘の繰り返しになる。敵の多い場所と少ない場所の調整がかなりちょうどいい。例えば敵の少ない市街地なら自由に動き回ってその場で戦闘をしても敵が集まってくることはないし、敵が多い市街地で戦闘を始めればあっという間に増援が集まってきて乱戦が始まる。戦闘に飽きたときは街を出ればすぐ敵の密度が減るから気ままに歩き回れる。それに敵の難易度調整もかなり良くて、うまく隠れながら進めばほとんど戦闘は起こらないけど、時々はしっかり負けるし、負けたときもほとんどの場合は1,2回やればしっかり勝てる(同じ敵に負け続けて萎えることがない)。

　強いて言うならマップ&クエストボードがでかすぎてどれだけプレイしても埋まらねぇって問題はあるけど、それは嬉しい悲鳴というやつだし。

　個人的には近接より遠距離のほうが好きだけど、とはいえSCAR-Hとか使うわけにもいかないしね。クナイを強化するとサプ付き1911くらいには便利だから、近接しか使えないというわけでもないし。クナイを持てる数はあまり多くないけど、銃弾と違って回収して再利用できるし。スキルを上手く組み合わせれば大人数も一気にステルスで殲滅できるっぽい雰囲気があるし。

　一部のゲームはUbiから分離するらしいけど、ゴーストリコンとかはUbiで開発を続けるらしいし、俄然ゴーストリコンの次回作も期待したい。

　先日、たまたま機会があったので札幌に行ってきた。いつぶりだろう? 最近札幌行ってないなーと言ってるあいだにコロナ禍に入ったから、10年ぶりとか? いや、そんなわけ……

　あんまり時間がなかったのでヨドバシをちょっと眺めて科学館に寄って帰ってきた。

　ヨドバシ狭くなった? 前はもっと広かったような気がするんだけど。あと、前はもっと活気があった気がする。今回は特に欲しいものがあるわけでもないので、軽く眺めて終了。最近のノートPCってすげー高いのな。MacBook Proの最小構成のほうが安いんじゃねって気がするんだが。自分の用途的にx86のWindowsが条件だからMacとかChromebookは選択肢外だけど。あとはDJIのジンバルが置いてあったから、ちょっと触ってみたり。NATOポートって本当にNATOなんだな、とか。

　科学館は正直ちょっと期待外れ。土地柄というか、自然科学系の簡単な展示しかない。宇宙論的な説明(ビッグバンや大規模構造)が少し、太陽系の説明がもう少し、北海道の地質に関する説明も少し、人体に関する説明が少し多め、残りの大部分は雪関連の説明、以上。という感じ。大部分はボタンを押して説明動画を見るだけの展示だし。もう少し色々あるとしても。地元に自然以外の題材が何も無い田舎の科学館って雰囲気。

　旭川の科学館のほうがもう少し展示内容が豊富だと思う(展示内容のベクトルはほとんど同じだけど)。スタッフの人数も旭川のほうが多い。札幌は展示スペースにスタッフが皆無で、警備員の制服を着た人が何人か歩いている程度。旭川はボランティアスタッフが多いから、気になったことがあったらすぐに聞ける。まあ、青少年科学館(「子供向けの施設」)に期待しすぎるなと言うことなのかもしれないけど。そもそも札幌は建物が狭いから展示を増やせないしスタッフが立つスペースもない、ということもあるのかな。旭川は広い分で展示もスタッフも増やせる。あとは来場者数の違いありそう。札幌も休憩スペースとかで結構場所食ってるから展示増やそうと思ったら増やせそうだけどなぁ。学校単位とかでまとめて団体を受け入れようとするとあれくらいの空間が無いとだめなんだろうか。それにしちゃ展示スペース狭くねえかって気がするが。

　rtlsdr.dllを直接叩くロガーアプリを作ってみた。いちいちrtl_tcpを起動したりIPアドレスやポート番号を管理するのも面倒でな。。。

　とりあえず周波数・サンプリングレートを固定して、固定時間でファイルを分割して、一定時間を過ぎたら自動的に削除して、というような処理(自動削除はON/OFF可能)。ついでにヒストグラムとスペクトルの表示も行っている。

　自動分割・削除機能を使うと、30分でファイルを区切って、サンプリング終了後2時間待って削除する、みたいな処理を裏で勝手にやってくれるので、事前に発生が予想できないイベント(通信・放送)を記録したいときに便利なはず。削除待ちを12時間とかに設定しておけば、寝ている間に起きたイベントも起きてから取り出せる。

　ただ、ウチのPCは全部SSDしか乗っていないから、総書き込み容量が怖いので、この使い方はできない。メインPCのデータドライブはHDDだけど、3本でRAID5を組んでいるので、連続書き込みはちょっとやりたくない(単に容量の問題もある)。当面は連続記録は使わず必要なときだけ単純な記録として運用かな。気が向いたら4TBくらいのHDDを買ってメインPCに増設しよう。2.4Mspsで24時間記録して420GB程度だから、2ch同時に記録しても1TB/day程度、24時間程度で自動削除なら埋まることはない。

　あとはキャリアスケルチでスケルチが開く前/閉じた後の適当な範囲も含めて、信号があるときだけ記録するような機能があると便利かな。アマチュアとかエアバンドとかMode-3/A/Cとかを受信するときに。

　欲を言えば追加のデコード機能(たとえばMode-3/A/Cとか)やその表示機能もあれば便利だけど、さすがに機能を増やしすぎると使いづらいからなぁ。

　rtlsdrのReadAsyncをTask.Runで包んでIAsyncEnumeratorで返すようなラッパーを作ってあるので、GUIスレッドからawaitで呼んでGUIスレッド内でファイルへ書き込んだりスペクトルを更新したりみたいな機能が一通り走る。最初設計思想を把握できなくて結構大きな手戻りが発生したけど、実装し直したらかなり信頼性の高い記録ソフトが作れた。前に作ったやつはISDB-T(フルセグ)用にドングル3本同時サンプリングが標準機能だったから(1chとか2chとか単独でも使えるけど)、1chだけ記録したいときにはちょっと機能が過剰だった。

　GNSSのオンボードクロック、10.23MHzに対してGPSが約-4.6mHz、QZSSが約-850mHz、くらいに調整しているらしい。軌道半径が1.6倍になるだけでこんなに違うのか。

　軌道が低いほうが速度が早くて特殊論での遅れが大きくなるし、重力が強いから一般論での遅れが大きくなる。地上と時間の進みが同じになるのは高度約3000kmの円軌道だから、それより高度が高いGPSは地上より時間の進みが早くなるし、さらに高いQZSはさらに早くなる。とはいえ、すごい効くんだな。

　GPS Block IIIF(2027年打上げ予定)、WikipediaによるとUSBに対応したよ、とのこと。むしろGPS衛星ってUSB使ってなかったんか。軍用衛星と民間衛星はアーキテクチャが違うみたいなことなのかな。通信衛星とか放送衛星はXとかK前後とか使うことも多いし、観測衛星とかでもXとかを使ってるはずなのに、今更USBに対応したところで、という感がなきにしもあらず。半世紀以上も前の通信プロトコルやぞ……

　C#でIEnumerable<T?>をOfType<T>でIEnumerable<T>に変換するやつ、IEnumerable<(int,T?)>をOfType<(int,T)>でIEnumerable<(int,T)>に変換しても、T?がnullの要素を除外できない。nullを除外するにはWhereを使わなきゃいけないし、その後でnullableのnullチェックを行わないと警告が出るから、OfTypeも呼ばなきゃいけない。結構面倒。

　C#のLibraryImport、ノーコストで使えると思ってたけど、Visual Studioが勝手にunsafeを許可してたんだな…… 自分のコードでunsafeを宣言しなければ問題ないんだけど。

　charポインタを受け取って文字列を書き込むタイプの関数をLibraryImportで呼ぶ方法がググっても出てこない。なんとなくそれっぽく実装してみて、いちおう動いているけど、本当に使えるのかはよくわからない。

　C# 8.0からローカル関数に属性を付けれるようになったけど、LibraryImportはpartial属性が必要だから、ローカル関数にできない。DllImportならローカル関数で宣言できるから、ラッパー関数の内側に隠すことで、外部に公開せずに済む。privateでクラス内に閉じ込めているとはいえ、クラス内の他の処理から必要ないならローカル関数内に隠せるほうが便利だけど、それができない。

　LibraryImport、いまいち便利な感じがしないな。マルチプラットフォーム云々とかも、そもそもDLL呼ぶ時点でWindows専用だろって感じだし。

　StringBuilderで固定長を確保した場合、GC.AllocateUninitializedArrayでpinned=falseな配列を確保するけど、これをDLLに渡してヌル終端文字列を書き込んでもらった場合、sb.ToString().TrimEnd('\0')と処理した場合に、最初に確保したバッファにゴミデータが書き込まれていた場合、それが読み出されてしまわないんだろうか? あと、確保した配列はピン留めされていないけど、直接DLLに渡して大丈夫なんだろうか? DLL呼び出しの例を探すとたいていこの書き方だし、うまいこと対応してくれてるんだろうけども。

　結局、そこら辺が心配なら自分でピン留めした配列を確保して(or小さい配列ならstackallocで確保して)、IndexOf<byte>(0)で最初のヌル文字を探して、みたいにしなきゃいけないのかな。それならDllImport/StringBuilderを使う利点はないから、LibraryImportでもいいのか(ローカル関数で宣言できないデメリットだけ残るけど)。

小ネタ

　オペアンプをコンパレーターとして使って見る：今岡通博の俺流！組み込み用語解説（12）（1/2 ページ） - MONOist

　直流用フォトカプラをAC100Vに繋いでた人。この人にこの手の記事書かせ続けて大丈夫? 個人運営ブログの学習メモとかじゃあるまいし、「モノづくりスペシャリストのための情報ポータル」を謳うサイトが組み込み(電子回路)をターゲットに解説記事を連載するなら、その分野である程度経験のある人に頼んだほうがいいと思うんだけど。

　今週は某ゲームを遊び込んでたので進捗だめでーす。

　YouTubeのアルゴリズムの問題なのか、某ゲーム、「殴ったり燃やしたりしても良いコンテンツ」として扱われているような印象になってて残念。大手ゲームメディアとかだとそこまで火をつけて遊んでるわけじゃないし、というか普通のゲームとそう変わらない扱いだし、一部のメディア(主にYouTubeとか個人運営サイトの「反応まとめ」的なコンテンツ)がそういう遊びをしてるんだろうけど。/* そういうコンテンツ1回も見たことないしなんなら時々チャンネル自体ブロックしてるのにそれでもなお執拗にクリックベイトをオススメしてくるYouTube君のアルゴリズムさぁ。。。 */

　プレイキャラの切り替えができるようになるまでプレイ時間24時間くらいかかった。あちこち寄り道したとはいえ、序盤だけでこのボリュームか……

　ゲーム内時間経過で一定時間が経つと次のファストトラベルで季節が入れ替わるシステムは面白いけど、それがゲーム性に反映されているかというと微妙な気がする。冬は走るのも遅いし、遮蔽になる植生もないし、植物に入るとカサカサ音がなったり屋根の上を歩いたら氷柱が落ちたり。冬はちょっと面倒。せめて積もった雪に隠れることができればよかったんだけどな。夏と冬でゲーム性結構変わる気がする。うまく季節に合わせた立ち回りを考えないと。

　エンジンが同じだからか、GRBPっぽさもある。GRBPは平面方向でしか動けなかったけど、ACSはパルクール的に建物の上とかに行けるのが楽しい。操作性に若干難ありという感じだけど。

　オープンワールドは移動が多くて、ACSは世界観的に車とか飛行機とかヘリコプターとかが使えないから、とにかく走るしかない(or馬に乗る)。GRBPと違って体力ゲージが無いから、走るときに体力管理が必要なのが嬉しい。あと崖を滑り降りるときにHPが削られないし。Zキーで自動で歩き/走りしてくれるるけど、それでも進行方向は自分で調整しなきゃいけないから、長距離を移動したいときにちょっと面倒。まっすぐ突っ切ろうとすると地形が厳しいし、道なりに行こうとすると遠回りだし。せめて馬に乗ってるときは目的地の近くまでは自動で歩いてほしいな。ゆっくり周りを見て移動するとかもできるし。

　ゲームの設定でキー入力のソースを1個しか設定できないのが地味に不便。例えば回避のデフォルトはAltだけど、これをマウスのサイドボタンに割り当てようとするとAltが削除されるから、クセでAltを押すと回避できない。せめてキーボードとマウスは区別して(重複して)設定できると便利なのだが。

　例によってサブスクで遊んでるけど、ゲーム自体は楽しめているし、ライセンス1本買おうかな、と思ったり。Ubi版で遊んだ履歴ってSteam版を買っても引き継げるんだろうか? 今までのUbiのゲーム、例えばThe DivisionとかGRBPはSteam版で買ってもUbiのランチャーで起動するからSteam版/Ubi版の区別なくセーブは共通だろうけど、ACSのSteam版はUbiランチャー不要だそうだから、セーブデータの引き継ぎに難がありそう。どうしてもSteam版を買わなきゃいけない理由もないので、Ubiで買ってもいいんだけど。

　安いゲーミングマウスを買ってみた。ちょっと前に買ったキーボードと同じブランド/デザインのやつ。

　FPSだとあまり気にならないけど、剣を振り回したりするゲームだととにかくクリックを連打するから、マウスの寿命が心配。/* ACSの場合、1段くらいのキュー経由っぽくて、連打するとパリィが間に合わなくなるから、本当は連打しちゃだめなんだろうけど */

　今まで使っていたやつと並べて使うと新しい方のカーソルがめっちゃ引っかかる。amazonのレビューも低評価ちょっと多かったしなぁ……と思いつつ有線で接続したら問題なく動く。試しに古い方のドングルを抜いてみたらヌルヌル動くようになった。USBハブにドングル2個並べていたから、古い方のドングルから出ている電波が新しい方のAGCをリミットさせているのかな。無線機器を並べて使う経験がほとんど無いので、目に見えて抑圧を受けたのは初めてのような気がする。

　古い方は海外のブランドなので結構大きいし重い。新しいやつは国内のメーカーだからかひと回り小さくて持ちやすいし軽い。ガッツリ肉抜きしてあるFPS用のマウスならもっと軽いんだろうけど。

　古い方は充電ドッグ(別売り)に乗せれば簡単に充電できるけど、新しい方はType-C専用なので充電するたびに挿抜しなきゃいけないのが面倒。ただ、古い方は1日で50％くらい電池を消耗するから毎日の充電が必須だけど、新しい方はそこまで極端に放電するわけじゃないから、数日毎に充電すれば良さそう。それはそれで忘れそうとか不安だけど。

　コネクタがもっと手前にあれば磁石で簡単に着脱できるアダプタを使えるのに、なぜかゲーミングマウスのUSBコネクタってかなり奥まった場所にある印象。新しい方は普通のType-Cケーブルが使えるだけまだ良心的。古いやつはコネクタこそMicro Bだけど、細い穴の奥にコネクタがあるせいで市販のUSBケーブルが使えない。テーパーみたいな構造もないからUSBを刺すのがかなり面倒だった(だからしょうがなくドックを買ったわけだが)。新しい方も、付属のケーブルは普通のType-Cより被覆が大きくて、スリットが入った構造になっている。もしかしたらマウスを振り回したときにType-Cコネクタじゃなくてその周りの樹脂パーツで負荷を受けるような意図なのかな? 古い方のマウスも同じ思想なのかも。専用ケーブルしか使えない古い方に比べて、市販のケーブルでも(コネクタにダイレクトに負荷がかかるとはいえ)使い回しができる新しいほうが親切感がある。

　ユーティリティでいろいろ設定できるけど、ボタンに割り当てられる機能が少なめなのがちょっと不満。例えばDPIはいくつかの種類を設定できて、ボタンで切り替えられるけど、DPI切り替えが1方向しかない。2個のボタンでDPI Up、DPI Downみたいな操作が作れない。不思議。ホイールの手前に2個のボタンが付いていて、普通のマウスはここにDPI Up/Downが割り当てられていたりするはず(デフォルトでは無割当)。

　左右クリックとサイドボタンはマイクロスイッチっぽい感触だけど、中クリックはタクタイルスイッチっぽい感触。あっという間に死にそうだなー。ホイール手前のボタンに中クリックを割り当てるという手もあるが。

　ホイールはクリック感強めで結構好み。

　最初は軽すぎる感触とかが不慣れで変な感じだったけど、慣れてしまえば結構快適。

　古い方のマウスはサイドパネルを交換すれば12ボタンにいろいろな機能を割り当てて、右手だけでほとんどのPC操作が完結するのが便利だったけど、マウスがスリープに入るとウェイクアップに時間がかかるのが不便だったんだよなー(立ち上がるはテンキーモードになっているから数字が連打されて、いちいち消さなきゃいけないのが面倒だし、YouTubeとか見てると不用意にシークしてしまう)。あと、FPSを遊ぶときにサイドボタンが邪魔で2パネルに交換していたから、サイドパネルのショートカットも使えていなかったし、普通のマウスに変えてもそんなに違和感無い。もう一つマウスを買ったんだから12ボタンパネルに戻してもいいんじゃね、とは思いつつ、抑圧の問題がなぁ。こっちのマウスは有線で接続すれば、抑圧もないし、スリープに入ることもないし、「右手デバイス」的に使うのであれば問題ないかな? マウスを2個も置くスペースが無いという大問題を除けば。

　世界の重要インフラを強くする！時刻同期は2周波GNSS受信の時代へ | 技術 | GPS/GNSSチップ&モジュール | フルノ製品情報

　あくまでも周波数ダイバーシティ的に使っているだけであって、L1/L5で電離層遅延を推定する、みたいな感じではないのかな。L1を妨害されてもL5を受信できていれば問題ないよ、L5を妨害されてもL1を受信できていれば問題ないよ、L1もL5も妨害されたらフリーランするけどそれでも短時間なら十分な精度を維持するよ、みたいな。

　衛星の打上げ、神社等で成功祈願を行っていない衛星はトラブルを起こしやすい、というジンクスがあるらしい(1990年前後の話)。祈願に行ける程度にスケジュールに余裕があるときは地上で対応できるトラブルは対応済みだが、祈願に行けないほど打上げ直前まで対応に追われていると不具合を潰しきれていないから、という相関関係らしい。まさに人事を尽くして天命を待つという感じの。天命を待てない場合は人事を尽くせていない。

　1980年代末頃にESAから提案されていた測位衛星NAVSAT、18機とか24機とか何種類か提案されていたけど、地上の原子時計をベースにベントパイプで測位信号を放送して、4機から信号を受信することで測位する。

　SBASは静止衛星でGPSの補正信号を送るシステムで、これはベントパイプで放送を行うが、オプションで測位信号を放送することもできる。

　ベントパイプで測位信号を放送する場合、衛星軌道に起因する相対論的効果は発生しない。全地球規模でベントパイプで放送するには地上局を満遍なくある程度の数(最低3箇所、できれば6箇所とか8箇所とか?)配置する必要があるから、今の地球のみたいに陸地の配置が非等方的な惑星の場合は地上局の配置に制約があるけど、それにしたって例えば衛星間中継を行うとか、どうにでもできるはず(衛星間通信みたいな方式だとアンテナゲインを稼がなきゃいけないから機械可動部が不可欠で、そのあたりの信頼性が、黎明期のオンボード原子時計と比較してどうかという問題はある)。

　多少なりとも相対性理論を解説しようとする文脈では「衛星測位を行うには相対性理論が必須」というような説明が判で押したように出てくるけど、本当にそうなのか怪しい気がするんだよなぁ。人間のスケールではほとんど効いてこない相対論の研究に無理やり理由をつけるために使っているだけのような気がする。

　結局、現在の衛星測位システムはすべて軌道上に原子時計を搭載しているから、なんだかんだ原子時計を軌道上に置くほうが色々と楽なんだろうけど。そのせいで飛行機とか高信頼性の用途で使おうとしたときに面倒なことになってるんだけどな。。。

　ベントパイプなら軌道上で時計が壊れたり計算をミスって誤った信号を放送する心配がほとんどない。中継機が壊れた場合は単に信号が中断する場合が多いから受信機はそれを無視するだけで済むし、そもそも全ての衛星が地上局から可視なのが前提だから、中継機の特性が悪化して測位精度が劣化するような場合でも地上局で検知して放送を中断すればいいだけだし。

　軌道上に原子時計を置くもう一つの利点として、地上局から独立して動作できるという利点がある。つまり地上局が壊れたり壊されたりしても、しばらくはシステムとして稼働できるから、軍用のシステムとして考えたときに便利(1箇所の地上設備が破壊されるだけでその周辺数千kmで軍事作戦が全部支障を受ける、みたいな脆弱性が無い)。NAVSATがベントパイプ方式で考えていたのは民間用の測位システムとして考えていたからだろう。

　なんとなく思い至ってrtlsdr.dllをC#から叩いてみた。

　非協調型のDLL(Visual Studioでメソッド一覧を取れないという意味で)をC#から叩くのってもっと大変だと思ってたけど、かなり簡単に叩けるんだな。リンカで公開されている関数の一覧を得て、ソースコードから引数とか戻り値がわかるから、それに従ってLibraryImportを書いていくだけ。

　rtlsdrライブラリはOpenに構造体のポインタのポインタを渡して、その他関数(Close含め)は構造体のポインタを渡す。構造体の中身に触らないのであれば、C#側からはIntPtr(Openはref IntPtr)を渡すだけ。基本的に全部静的メソッドとして定義するので、いちいちIntPtrを渡さなきゃいけない(or IntPtrを持つインスタンスとそれを使ったオーバーライドを作らなきゃいけない)のが面倒くさい。

　前にC#のRTLSDRラッパーのコードを見たときに、結構複雑そうなことをやっていた記憶があるけど、最低限必要な部分だけ書くなら、結構簡単。

　まだ複数ドングルの同時接続は試していないから、もしかしたらそのあたりは大変かもしれないけど。rtl_tcpだって実際はrtlsdr.dllを呼ぶような実装だろうし、多分問題ないと思うんだけど。

　試しにDLL直叩きで1575.42MHzを2.4Mspsでサンプリングしてみた。問題なくデコードできるけど、長時間サンプリングしても数分程度しかデコードできない。適当な時刻オフセットを与えてやれば別の場所をデコードできるけど。たぶんドロップしているんだろう。

　ドロップがrtl_tcp.exeとかの問題ではなくて、少なくともDLLレベル以下か、ハードウェアに起因するんだろう、というのがわかっただけでも収穫。まあ、DLLから配列を受け取ってファイルに書き込むなんて非常に簡単な処理だし、こんなところにバグの入り込む余地はほとんど無いだろうし。

　rtl_tcpとDLL直叩きを比較して、どちらに大きな優位点があるというのはあまりなさそう。DLLで叩ける機能はだいたいTCP経由でも叩けるし。

　DLL経由とrtl_tcp経由で一番違うのがゲインの設定かな。DLL経由の場合、R820T2(orその他のフロントエンドIC)が対応するゲインを正しく設定する必要があって、対応していない数値を与えた場合は単に無視される(近いゲインに設定されるわけじゃない)。対応していない値を設定した場合に無視されるのはrtl_tcpでも同じ(rtl_tcpも結局同じ関数を呼んでいるだけなので)。

　ただしrtl_tcpはゲインを番号で指定するコマンドがあって、この場合、範囲内の番号を指定すればゲインを設定できる。この番号は例えばR8xxの場合0以上28以下の範囲の自然数を指定する。ゲインを指定する場合は規則性のない数値(R8xxの場合0から496までの29種類)を指定する必要があるから、インデックスで指定するほうが簡単。

　しかし、このインデックスはフロントエンドICによって指定できる数は異なり、対応するインデックスより大きい値を設定した場合は単に無視されるから、結局、適当な巨大な数(例えば1000とか)を設定しても無視されるのはgainコマンドもgain by indexコマンドも同様。

　DLLを叩く場合、対応したゲインの数値の一覧を得ることができるから、適当な値(例えばR8xxでは対応していない40dB)を設定しようとしたときに、対応するゲインの一覧から一番近い数値を自動的に設定する機能を作ることができる。この場合、適当な巨大な数を設定すれば、それに一番近いゲイン、すなわちそのフロントエンドICで設定できる最大のゲインが設定されるから、フロントエンドICの種類とか使用できるゲインの数値とかを気にする必要がない。

　ただしこの一覧を得る関数はintポインタを引数に取って一覧を配列に書き込むから、呼び出し側でmalloc/freeで取得した配列(あるいはあまり多くないことを期待してスタック領域で宣言した配列)を渡す必要がある。こういう処理は普通のC#に比べるとちょっと手間がかかる。とはいえ、数行程度のメソッドを1個書けば隠せる程度の処理ではあるが。

　GPSの受信もちまちま実装中。

　C/Aコードのロックオフの検出をPLLで実装してみた。今までは航法メッセージのパーサで検出していたので、数秒程度の遅れがあって、その間の測位データが大きな誤差を持っていた。

　PLLがロックオンした状態ではフィードバックは±1rad程度に十分収まるが、ロックオフした状態ではフィードバック値が±πradにランダムに分布することを利用して、閾値(例えば±π/4rad)を超えたフィードバックが適当な割合(例えば25%)を超えた場合、ロックオフしたと判定し、相関器・受信機をリセットしてドップラスキャンを行う。閾値にもよるけど、数百ミリ秒程度で搬送波ロストを検出できるから、航法メッセージを見るより1桁早い。閾値を狭くすればもう1桁早くなるけど、ノイズに弱くなる。

　以前遠出したときにサンプリングした30分くらいのIQファイル(途中で何回かドロップしている)を解析して、結果全期間を復調できるようになった。観測値(GPS衛星時刻)を100Hzで出力して、そのまま測位演算してNMEA0183で出力しているから、GGAだけしか出していないのに12MB(17万行)を超えている。点数が多いせいかGoogle Earthで表示できない。高度ビューは見れるし、カーソルに合わせて三角形のマーカーが移動するから、正しそうな位置が得られているのはわかるんだけど。

　今のところ、IQファイルの復調は各GPS衛星が放送している時刻(普通のGPSで言うところの擬似距離に近い情報)をファイルに書き出して、その後で測位演算を行っているので、GPS衛星の捕捉に推定値を使うことができない(最後にロックオンしていたときのドップラを持っておくとかの方法はあるけど)。GPS衛星の受信と同時に測位演算を行っておけば、現在位置・速度・受信機クロックエラーから衛星のドップラや航法メッセージの位置(ビット内外の位相)を推定できるから、より早く再補足ができる。ただ、この場合は測位演算が継続していることが大前提であって、例えばRTL2832Uのサンプルドロップは全衛星が同時に断してその量もわからないから(数us程度のはずだけど)、相関器や復調器はリセットする必要がある。

　PLLの記事で、IC用のクロックとか無線機の修理とか、いろいろな文脈で「PLLのロックが外れる」みたいな表現が出てくるけど、ではそれをどうやって検出するか、という話はほとんど出てこない気がする。一部のPLL ICにロック検出回路を内蔵しているものがあるけど、とはいえその詳細な説明とかは見当たらない。

　クロック回路のエンジニアとしては安定して動作するPLLの設計が腕の見せ所(というか安定して初めてマトモな設計になる)だし、古い無線機の修理とかではPLLが外れる=正常に動作していないわけだから、いちいちPLLのロック状態を把握しなきゃいけない状況ってのは少なそう。どうしてもクロックの監視が必要なら、そのクロックでカウンタをインクリメントしたうえで、適当な高信頼のクロック(数十kHz程度)でカウンタをリードandクリアして、カウンタがゼロ(or適当な範囲外)の場合はクロックエラーとして割り込みをかける、みたいな機能でいいはずだし、PLLだけ見てもあんまり意味ないだろうし。

　通信分野だと相手の信号の有無を検出したいみたいな場合もあるけど、それにしたって例えば放送(デジタルテレビとか)ならOFDMのガードインターバルを探すとか、受信した情報の誤り率を見るとか、そもそも信号の判定をしない(SNRが悪ければ単にブロックノイズとしてユーザーに提供する)とかだし、通信(移動体通信とか)にしても上位プロトコルで判定することが多いだろうし、搬送波レベルで信号のロストを検知したいって用途は結構レアなのかもしれない。

　宇宙機の通信だと地上からCWをスイープしてオンボードのPLLでこれを検出・ロックして地上に折り返して、地上でもキャリアを検出してロック判定、みたいなことをやるけど、こういう手順の(搬送波レベルでハンドシェイクする)通信方式って宇宙通信の他にあるんだろうか。

　C#のメソッド(というかコンストラクタ)でトップのブロックを書かずに;で終端するような機能欲しいよなー。record Hoge(int Value){public Hoge(string str)this(int.Parse(str));}みたいな感じで、thisで別のコンストラクタを呼ぶだけで、中で何も処理しないときに空のブロックを書かなくて済むように。わざわざ専用の文法を用意するくらいなら空ブロック書くほうがマシ、ということなんだろうけど。

　C#のSpan<T>/ReadOnlySpan<T>と同じように使えるSpan<T1, T2>/ReadOnlySpan<T1, T2>みたいな構造が欲しいなーと思ったり。

　大量の複素数をComplex[]で持つのでなく、float[]real, imaginaryで分けて持ったりするときに、それぞれを一体として扱ったり、必要に応じてFirst, Secondで個別にSpan<T>を切り出したりできるようなやつ。

　既存のC#でも例えばArrayとかSpanのSort<TKey,TValue>(TKey[],TValue[])みたいに2種類の形(2個の配列)をあわせて使うような機能はあるわけだし、それを積極的に使うようなサポートがあっても良さそうな気がする。Arrayならともかく、Spanの場合は切り出して使うのが前提だろうし、それなら両方をまとめて切り出すような機能も欲しい(切り出しを2回書かなくていいから、ソースコードが半分で済む)。

　ついでにSpan<int,int>spanみたいなやつをvar(a,b)=span[0];とかforeach(var(a,b)in span)みたいな感じで一括で読めるような機能があるとなお嬉しい。