航空大のCirrus SR22。
久しぶりにK-5を使ったらメインスクリーンのバックライトにフリッカーが出てるし、カードのアクセスも調子悪い(カードのアクセスが悪いのは前からの気もするけど)。2012年の3月かそのあたりに買ったカメラなので、13年以上使ってるのか。ここ数年はほとんど使ってないけど、それまではだいぶ酷使してたからなぁ。防水なのをいいことに土砂降りの中で使って水道水で丸洗いしたこともあったし。およそ精密光学機器とは思えぬ取り扱いをしてきた。
ミラーレスも1台持っていて、軽いので持ち歩くには便利だけど、起動が遅いし、待機電力も大きいので、持ち歩いて楽しいかというとちょっと微妙なんだよなー。K-5は電源OFFでもファインダーを覗けば被写体が見えるし、電源ONで起動待ち無しに直ちに撮影できるし、そもそも電源ONで放置したって待機電力は全く問題ないし、持ち歩いてて楽しいカメラだった。
ここ数年はカメラを持って出歩くこともほとんど無くなっちゃったなぁ。
VIDEO
SR Series G7+ featuring Safe Return™ Emergency Autoland - Explainer - YouTube
緊急(パイロットの急病とか)の際に自動着陸するシステム。
アクティベートした際にはMFDに乗客向けの情報が各種言語で表示されるけど、その中には日本語も含まれているから、メーカー(Cirrus or GARMIN)としては日本にも売り込む気はあるんだろう。日本で使えるかどうかはさておき。まあ、FAAが認可してるならそのうち日本でも使えるやろ…… あるいは、単に米国とか特定の地域で、観光で来た各国の乗客を想定しているだけかもしれないけど。
パイロットや乗客が手動(ボタン操作)で起動する以外にも、複数回の安定性アシスト(空間識失調等を想定)や、高すぎる飛行高度(低酸素症で判断能力を失った状態を想定)で自動的にONになる機能もあるらしい。
もう少し発展させればAuto-GCAS的な機能も載せられそうだけど、少なくともSafe Return機能には入っていなさそう。とはいえ、もちろんSafe Returnによる自動操縦では地形を回避する機能は入っているけど。
着陸進入では上空待機のトラフィックパターンっぽい表示もあるから、7700を出して脇目も振らず滑走路に突っ込んでいくわけじゃなく、ちゃんとATCに従って許可を得たうえで進入するんだろう。ということは何らかのデータリンクでATCと通信できるんだろうな。データリンクがあるなら航空機が自動で選んだ滑走路以外にも、外部のATCから指示された滑走路へ進入するとかもできるんだろうか。それとも、データリンクなんぞ全く整備されていないような場末の空港にも進入できるように、あまり外部には依存しないようになっているのか。
空飛ぶクルマが実用化されれば自動操縦は巡航だけでなく離着陸も含めてフルタイム・フルオーソリティで動作するし、ATCだってデータリンクを使うだろうし、自動着陸というのはそのうち実用化される機能なんだろうな。Cirrusが一歩早く売り始めたというだけであって。やっぱり既存の機体を持っているCirrusや既存のアビオ系があるGARMINが一歩先を行っている。
日本でも空飛ぶクルマはそれなりに力を入れて導入しようとしているはずだし、データリンクを始めとして航空機(数人乗りの小型機含め)の高機能化は避けて通れないし、そのうち日本でもSafe Return付きの機体も飛ぶようになるんだろう。
あるいは、電子フライトバッグみたいに各種情報がデータ化されたり、航空機が自身のステータスを把握できるようにセンサが統合されていくと、人間のポカミスを防ぐようなシステムも作れるだろうし。脚やフラップの出し忘れ、燃料管理のミス、といったことで発生する事故は、完全自動化した飛行機以外にも、小型の固定翼機みたいな分野でも利点は大きいんだろうな。ただ、そういうシステムは概して導入コストが高いから、個人オーナーへ普及するには半世紀くらいかかるんだろうけど。飛行時間が短い個人オーナーほど知能化した航空機でポカミスを防ぐべきなんだけど、運用時間が短いせいでコスパが悪いから高額な機器にリプレイスできないというアレ。
旅客機で自動着陸は実用化されているのに自動離陸が禁止されている理由を、乗客数などによって条件が毎回異なるから、と説明している記事があるけど、それって嘘じゃね? じゃあ何かね、自動着陸するときは一定以上の乗客や荷物は上空で捨てるとか、乗客が足りないときは着陸前に空中で補給するとでも言うのかね? そんなわけ無いだろう。離陸するときだって乗客数や荷物の重さはFMSに入力して離陸速度を決めてるんだから、システムがそれを知らないわけがない。
あるいは、離陸するときは周りの航空機に注意をする必要があるから、みたいなことも書いてあるけど、じゃあ着陸時は周りを見ずに着陸していいのか、という話だし。
自動着陸はILSに従って進入できるけど、離陸時はILS信号が受信できないから信頼できる位置情報が得られないし、オンボードの位置推定(INS)は信頼性が悪いから、みたいなことなんじゃないかな? SBASやGBASで離着陸時にGPSが使えるようになれば、自動離陸もそれで対応できそう。
「はやぶさ2」異常原因は姿勢制御装置の停止。姿勢立て直しエンジン再稼働へ | TECH+（テックプラス）
JAXAの情報公開はX(旧Twitter)でしかされないし、それを報道するニュースサイトは最初の1行以外は会員しか読めないし。情報化社会が進むと情報を得るのが難しくなるなぁ。アカウントの2,3個くらい四の五の言わず作れって話だけど。
TECH+は広告を超えてスクロールすると外部リンクがあるのが救いではあるが。
INET2001 Paper: Advanced NTP Synchronization Device
2001年。CRL等で試作したCs原子時計ベースのLinux PC。マザボの水晶(4fsc)を外して、HP5070Aから供給した10MHzをPLL経由で入力して、PCで高い時刻精度を得る。
https://jjy.nict.go.jp/tsp/research/labo3/xoreplace.html
2007年。マザボの4fscの代わりに外部10MHzを供給するためのボード、とのこと。PCIカードに電源がFD用コネクタってあたりが時代よなぁ。ボード上にトリマ付きの10MHzTCXOも乗っているから、外部クロックが切れてもPCは動き続けるんだろう。もちろんCsに比べられるような精度ではないとはいえ。
ボード上に高周波を通せるようなコネクタが見当たらないのが謎い。PCIバス経由でクロックを供給できるわけではないと思うんだが。それともピンヘッダで15MHzを出してるんだろうか?
三技協サービスサイト | 光無線｜三技協｜The Optimization Company
光無線通信の歴史から最近の高速通信の説明までいろいろ書いてある。所々誤字ったりしてるけど、企業の技術記事だし、御愛嬌ということで。
この会社の製品ではLEDをOFDM変調して、300mで200Mbps弱、50mで600Mbps超を通せるんだそうだ。8P8Cを挿してEthernet(100M, 1G)を光で中継するので、自由空間で通信できるメディアコンバータみたいな感じで使えるらしい。
https://www.jstage.jst.go.jp/article/ieejeiss/133/2/133_268/_pdf
2013年。照明用のLED素子を受信素子としても使用して双方向で通信できるような方式の提案。高演色性を得るためにRGBを個別に制御できる照明を想定していて、起電力の大きな赤色LEDを受光素子として使用する。また、受光時は応答速度を得るために逆バイアスを与える。チラツキを抑えるためにフレーム長は4.5ms秒(逆バイアス用の回路切替で追加0.5ms)で、1フレームはプリアンブル10bit+ペイロード32bitで構成。フレームを最大限並べれば6.4kbpsだけど、その間に少なくとも60Hz程度で照明としての発光区間を与える必要があるし、誤り訂正とかを含めると、実際のデータレートはせいぜい100byte/sec程度かな。
基本的には照明側から大容量のデータを送るのがメインで、逆方向の回線は欲しいデータのリクエストに使う程度だろうから、あまり速度は必要ないだろうけど、とはいえあまりにも遅いとレイテンシが悪すぎるし。
しかし、送信側も受信側もほとんど全く新しいシステムになるから、普及させるのは大変だろうな。BluetoothとかWiFiでブロードキャストするようなシステムのほうが作りやすそう。光でなければだめ、というような用途が無いと。光はカーテンで遮断できるから秘匿性が高い、とか言ったって、美術館の案内音声とかに秘匿する必要性なんて皆無だし。
IMES(屋内測位)でL1 C/Aを使いWiFi/Bluetoothを使わない理由は、測位したいユーザーに測位システムの有効化を要求するのは良いが、WiFiやBluetoothを要求するのは手間が大きすぎる、みたいな理由があったはず。とはいえ、実際には既存のシステムを使うWiFi/Bluetoothベースの測位システムが普及したし、専用の受信チップ(少なくともファームウェア更新で対応した受信チップ)が必要なIMESは全く普及しなかった。
全く新しい技術というのは、開発にも普及にもめちゃくちゃなコストがかかる。普及しないとメーカーは採用に踏み切らないし、メーカーが採用しないとユーザーは利便性を感じない。Appleみたいな巨大企業がゴリ押しする技術ならともかく、大学や研究機関が開発する全く新しい技術を普及させるのは現実的ではないような気がする。
まあ、「普及する見込みがある技術しか研究しない」とか言い始めたら、それはその研究機関の寿命だろうという気もするけど。小規模な民間企業はともかくとして、研究機関とか大学とかの研究開発はモンテカルロ的にやるのが仕事だろうしな。あるいは、ビッグテックのアホみたいに巨大な研究機関のほうが「数撃ちゃ当たる」をはるかに大規模にやっている気もするけど。
デジタルミラーデバイスを光通信に応用するみたいなことってできないのかな、という空想。
例えばLEDパネルから空間多重化した光通信を出力して、DMDで特定のLEDからの光を選択的に受光素子へ反射する。単純なジンバル追尾と違って複数箇所から同時に導光できるから、ランダムな複数個のLEDの光を加算してSNRを稼げる。同じ信号を出力するLEDの組み合わせは高速に(DMDの応答速度程度で)変化させられるから、一つの信号を空間的・時間的に分散させて、複数の情報を多重化することで、LEDパネルは均一な発光に見える。
一つの開口で空間的に大きく離れた複数箇所からの信号を受信できるのは利点か。例えばある程度の高度を飛行するドローンで同時に複数箇所からの信号を受信できる。もっとも、受信素子は単素子だから送信側で時分割制御が必要になるし、送信利得も相当必要だろうけど。
空間的に分解するならカメラでもいいけど、カメラは素子数が莫大なために時間分解能が極めて悪い(せいぜい数百Hz、シンボルレートはその数分の一)という欠点がある。DMDなら受光素子の応答性は極めて高いものが使えるから、シンボルレートもある程度高くできる。
受光素子を単素子ではなくて、分割型の(例えば2x2=4分割の)フォトダイオードを使用すれば、空間的に分離した複数の信号を同時に受信することもできるか。
DMDって光をコリメート化してからDMDに当ててそのまま放射しているから、これを逆向きにすると受光面積がめちゃくちゃ小さくなって、受信用デバイスとしては極めてSNRが悪くなる欠点がある。DMDの前に対物レンズを置けるなら受光デバイスとして使えるけど、空間分解との相性はあまりよくなさそうな気もする。
***
NTPのログ
RTT
特にどうということもなく。
NTPとPCの時差
w32tmが止まっていたときよりは少ない差で安定しているけど、誤差が数十msより小さくならない。8日から9日(UTC)で大きく下向きになっているけど、原因は不明。温度特性? システムクロック用の水晶くらいはせめてTCXOくらいのやつを積んでほしいなぁ。あと数年も経てばMEMS発振器が乗るようになるのかもしれないけど。
***
C#でテキストファイルを圧縮しながら追記したりするやつ。非アーカイブ形式であるgzipを使えれば便利なんだけど、C#のGZipStreamはシークをサポートしていないから、追記はできないはず。gzの元になるストリームレベルでシークしてやれば追記はできるけど、もちろんエンコーダの連続性はないので、あくまでも追記した分でしか圧縮しない。1度に大量に書き込むなら(追記分だけで十分な冗長度があるなら)、GZipStreamのBaseStreamレベルでシークするのも効果がある。
最近のWindowsはhoge.txt.gzとか作ればダブルクリックでhoge.txtを開いたりhoge/hoge.txtに展開してくれるから、gzipで作れれば便利だと思ったんだけど。
今のところ、ZipArchiveで頑張るほうが現実的かな? 追記してもちゃんとシームレスに圧縮してくれるから、ちまちま書き込んでもちゃんと圧縮率が稼げる。
ZIPファイルの形式的に、複数ファイルを突っ込むと容量効率が下がるはずだから、そのあたりは要注意だけど、ファイルが1個しか入っていないなら問題ないはず。
ただ、この追記がどういう処理になっているのかわからないのが怖い。もしかしたら既存のエントリを一旦全部読み込んで、それに追記したうえで、再度ZIP圧縮して書き込んでいるのかもしれない。
1回あたり1024バイト(ASCII1022文字+\r\n)を書き込んでそれを1024回繰り返す、という処理(1回毎にファイルを開き直す)が、1回目で24秒、2回目で51秒、3回目で78秒、くらいかかる。かなり遅いし、処理時間がどんどん長くなる。ASCIIで表現できる範囲とはいえ乱数でピックしているので、圧縮用のデータとしてはかなり特性が悪いと思うけど、それでも17%くらいは小さくなる(3回目で3MiBが2600kBくらい)。
試しに0123456789の数字だけを同様に書き込むと、圧縮率は50%を超える。ただ、1回目でも51秒くらいかかる。SmallestではなくFastestだと18秒くらいで書き込めるけど、圧縮率は25%くらいまで低下する。
同じように、ASCII文字範囲全体をFastestで圧縮すると、1回目で19秒、2回目で32秒、3回目で44秒、くらいになる。Smallestよりは早いけど、圧縮率はほぼ0％まで悪化するから、ZIPを使う意味がない。テキストファイルに追記するほうが圧倒的に早いし、ファイルサイズも大差ない。
同様の処理をgzipで試してみると、1回あたり0.25秒前後で書き込める(もちろん劣化しない)。ただし圧縮率はかなり悪い。
出現文字セットを0-9までの数字だけにすると圧縮率は高くなるけど、今度はWindows側から開けなくなる(0x8096002Aが出る)。C#のgzipエンコーダとWindowsのgzipデコーダで解釈が違うのかも。文字セットの問題じゃなくて木の作り方とかの問題だろうから、普通のテキストファイルなら確実に問題ないというわけでもないだろうし。
そもそもgzipってバイナリレベルで連結していいものなんだろうか?
結局、大容量のテキストファイルは、平文で書き出して適時人間が適当に圧縮するなり、大容量のメディアに移動するなりするのが一番確実な気がする。
*
class ClsA{public event EventHandler HogeEvent;} class ClsB{ClsA _clsA;} みたいな構造があって、アプリからはClsBを見ているときに、ClsA.HogeEventを受け取るのって、どうやるのがいいんだろう? _clsAをプロパティで公開してclsB.ClsA.HogeEvent+=みたいな感じで登録しているけど、これだとsenderがClsAだから、どのClsBが管理しているClsAなのかがわからない。それを逆引きするためにDictionary<ClsA, ClsB>みたいなのを作るのも面倒くさいし。
ClsBの中にevent EventHandlerを追加して、受け取ったイベントをsenderだけ付け替えて投げるみたいな挙動にするしかないのかな。
*
C#の愚痴等。
Spanの添字にuintが使えないの地味に謎いんだけど、どういう理由なんだろう。Spanで管理できる長さがuint.MaxValue未満(int.MaxValue程度)だからみたいなこと? どうせintで添字取ったところで負数ならIndexOutOfRangeExceptionを投げるんだから、uintで範囲外をIndexOutOfRange投げたっていいはずなのに。
System.Numerics.Complexって、インスタンスを作るor積がかなり遅い? (double,double)にキャストして自分で複素数の積を計算して書き戻すとだいぶ早い気がする。SourceLinkをざっと見た感じ、単なるreadonly record structだし、operator*(Complex,Complex)も普通の実装だし、変な感じはないんだけど。ちゃんと確認したわけじゃないので、別の場所がボトルネックかもしれないけど。
DictionaryのTryGetValueでkeyにnullを渡すとArgumentNullExceptionが出る仕様、ちょっと使いづらい気がする。クラスのインスタンスから何らかの値を逆引きするような用途で辞書を持っていて、クラスのイベントから送られてくるobject senderをkeyとしてTryGetValueで逆引きする、みたいなときに、sender as Class hoge && dict.TryGetValue(hoge,out var value)みたいに2段階で判断しなきゃいけないのがちょっとめんどい。直接dict.TryGetVakue(sender as Class,out var value)みたいにできたらいいのに。
lockが代入で透過的だと嬉しいな、という気がする。例えばvar value=lock(lockObj) dict[index];的な感じで。今のC#だとint value;lock{value=dict[index];}みたいに変数の宣言と代入を別に書く必要がある。int valueくらいだと書くのも手間ではないけど、型名が長いとvarで書きたい。
List<T>に相当するスレッドセーフなヤツって何を使えばいいんだろう? AddとRemoveができるのが最低条件。今回の用途ではアイテムが重複する必要はないから、ConcurrentDictionaryのKeyで代用することもできそうだけど、なんかアホっぽいよな。
EventHandler<T>と合わせて使うようなやつで、class EventArgs<T>(T item) { public T Item => item; }的なやつがあれば便利そうなのに、なんで無いんだろう。
***
Windowsのfindstrコマンドが結構便利。findstr /s /n HogeFuga *.csみたいな感じで呼ぶと、サブディレクトリを含む拡張子csのファイルからHogeFugaの文字列を含む行を、ファイルパスと行番号付きの一覧で出力する。この文字列はデフォルトで正規表現として認識し、大文字小文字を区別する。findstr /?で呼ぶとヘルプを表示する。
昔書いたコードで使った機能のはずなんだけど、みたいなときに、直交性の高い文字列を覚えていればそれで検索できて便利。
***
GPSのドップラスキャン、本物のGPSだと1msとか、かなり短時間のサンプルで信号の有無を判定するらしいんだけど、SDRでサンプリングした波形だと、4msとかでもSNRが足りなくて判断が難しい。少なくとも相関強度で信号の有無は判定できなくて、場合によっては信号が入っていても相関強度がノイズレベルを下回る。ノイズ以下の信号は更に長いコヒーレント長、例えば20msとかでスキャンすれば浮いてくる。本物のGPS受信機が1msとかで判定できるのが信じられないんだけど、ワンセグチューナーの熱雑音が高すぎるってことなのかな。広帯域のミキサが乗ってたり多ビットADCでサンプリングしたらノイズも増えるだろうけども。
*
試しにrtl_tcp経由でL1をサンプリングして、全PRNをスキャンしつつNAV/SBASメッセージを自動判定して受信するプログラムを書いてみた。単にメッセージのビット列と、適当な頻度で衛星のタイムスタンプ・ドップラ・ドップラレートをテキストファイルに出力するだけ。生データ(IQファイル)を保存するよりマシとはいえ、テキストファイルだと容量がすごいことになるねぇ。
PRN142からSBASメッセージが出てるっぽいんだけど、L1 C/A PRN CODE ASSIGNMENTS April 2023を見てみると、PRN142はUnallocatedになっている。謎い。
メッセージの内容はMT0,1,2,3,4,9あたりが出ているから、SBAS衛星で間違いなさそう。ただし時々フレームエラーが出る(メッセージ健全性はプリアンブルとCRCで確認)。
エフェメリスをデコードしてみると、東経116度0分、緯度0度が出ている。位置のZや速度・加速度はすべてゼロ埋めで、X/Yも極座標の116度を直交座標に換算しただけのもので、リアルタイムに軌道決定して(or推定して)放送しているわけではなさそう。
Celestrakのactive geosynchronousをプロットしてみると、この場所にはKOREASAT 6A(61910, 24206A)がいる。
KOREASAT 6A to embark a satellite-based augmentation system payload built by Thales Alenia Space | Thales Alenia Space
KOREASAT 6Aは116度のスロットに打上げて、SBASペイロードを搭載とのこと。PRN142のSBASメッセージを放送しているのはこれで確定かな?
ちなみに、メッセージエラーが出るSBASメッセージは142の他に134がある。この2衛星は比較的高い頻度(毎秒～1分に1回程度)でエラーが出る。134も韓国のSBAS衛星。他の衛星からは全く問題なくメッセージが受信できて、韓国の2衛星からはエラーが出るということは、なにか特殊なメッセージを放送しているんだろうか? (134と142は別のメッセージが放送されていて、エラーのタイミングも各々独立している) あいにく復調に成功したメッセージのビット列しか保存していないので、プリアンブルエラーなのかCRCエラーなのか、あるいはそもそも信号強度が弱いのか、とかの判断はできていないんだが。
しかし、なんでPRN ASSIGNMENTSに記載がないコードが放送されているんだろう?
gps.gov、「NOTE: The contents of this website have not been updated since February 2025 due to staffing shortages. Please bear with us as we work on a solution.」(Google翻訳 / 注：人員不足のため、このウェブサイトの内容は2025年2月以降更新されていません。現在、問題解決に向けて作業を進めておりますので、今しばらくお待ちください。)だそうで。
PRN142も本当は正式に割り当てられているけど公開資料が更新されていない、みたいなことなのかな? トランプやイーロンのせいでゴタってるって噂は聞いてたけど、本当にいろいろ支障出てるんだろうなぁ。そうやって国内で揉めて信頼性落とすから他の国が優位になるんだよ。。。
*
試しにL1帯のQFHをモデル化
直径30mm、高さ60mmくらいだからかなり小さい。そりゃまあAPT用に比べれば1桁以上小さいのは当たり前とはいえ。
導体だけで自立しそうだし、治具さえ作れば作れそう。しかし、結構ウネウネした形だし、治具のデータを作るのも大変そうだ。
NOAAの旧衛星も最終19号機の打上から16年以上が経って、正式運用の終了も発表されたらしいし、APTの運用が続いている間に受信しておきたいんだけど、いかんせんAPT(VHF)のQFHはデカすぎてなぁ。。。
