「卓上で半導体製造」実現を目指すミニマルファブ、研究開発や教育向けで導入加速：CEATEC 2024 - MONOist
展示会の様子だけ見ると機械の間隔がすごく広くてめちゃくちゃ場所を食うイメージだけど、実際はピッタリ並べられるんだな。
Discover DMQP Vol.3 圧入式ツーリングシステム「powRgrip」 - YouTube
2分32秒あたりでERコレットの作業の様子。トルクレンチも泣いてるよ。。。
袖とか手袋の感じが同じだから、DMGの社員が作業してる様子を撮ってるんだろうなぁ。技術スタッフじゃないから工具の使い方を知らないとしても、周りで見てる誰か、工具の使い方くらい教えてやれよ。メーカーのスタッフも近くで見てるだろうに。
デジイチを久しぶりに使用。SONYのデジイチはLIBを本体に入れてなくてもすぐに放電するな。ペンタは本体に入れっぱなしでも全然放電しない。
GPSモジュールを使おうと思って探しても見当たらなかったので、GPS無しで撮影。終わってから改めて探したら、前に棚回りを片付けたときに別の場所に移動していたことが判明。これだから片付けなんかするとどこに何があるかわからなくなるんだよ。。。
10月16日。60mm(@APS-C)くらいで撮影。ND代わりにつけっぱなしにしてたC-PLを忘れていた。外せばもっとSNR良く写ったのに。
最近、Chromeでリンクを新しいタブで開くときに、同じページが2回開かれていることがある。中クリックのチャタリングかな? Razer君さぁ。。。
左右クリックはRazerロゴのマイクロスイッチだけど、中クリックはTTCロゴのマイクロスイッチ。そういうところでケチろうとしてBOM増やすから製品の質にしわ寄せが。。。スルーホールだから取り外すのも面倒そうだ。どうしたものか……
Razerのマウス、信頼性低すぎてどうにかしたいんだけど、とはいえ側面12ボタンのワイヤレスマウスも種類がないからなぁ。Corsairの製品があるらしいけど、日本では正規ルートの販売は無いのかな?
***
久しぶりに大量のフレーミングパルス
およそ1時間半の間、数多く受信できた。F1とF2の角度はどれも同じなので、コヒーレントなトランスポンダから送信されたものと考えられる。ほぼ同じタイミングでコード1200とMode-Cも受信できている。ただし1200が出ていても0000が受信できていない時刻もある。0000や1200が受信できるときでもMode-Sは受信できないから、Mode-S(&ADS-B)非対応機らしい。
Xビットを含むリプライ
赤い点がXビットを含む応答で、3273X(3/A)がいくつか出ている。同じタイミングで2370(3/A)が大量に出ているのと、1524(FL340)が出ている。背景塗りつぶしの緑はデコードに失敗した応答(大部分はMode-S応答、いくつかはMode-3/A/C応答)。1524、2370、3273X、それとMode-S信号は振幅がほぼ同じで、時間変化で信号強度が変わっても、連動して変化する。
1524を拡大すると最初に連続的に変化しているから、Mode-Cの可能性が高い。最初に受信した応答はFL328だから、山の向こう側から現れたと考えるべきか。
距離が離れると信号強度が低下して、トリガされなくなると以降は記録されなくなる。それに先立ってMode-3/A/C信号が復調できなくなり、すべて復調失敗として保存される。復調に失敗した波形のうちいくつかはMode-3/A/Cの波形であり、手動で復調すれば先に受信できていたコードと同じ応答が得られる。
この時刻をFr24で再生してみると、ANAのB738が、スコーク2370、気圧高度34,000ftで飛行している。
つまり、少なくともMode-3/Aの2370応答、及びMode-CのFL340応答はこの機体から出たものであると考えて良いはず。Mode-3/Aの3273Xも、タイミングや信号強度が一致している点から、この機体から出力されたものと考えていいはず。
2370応答が受信できていた期間中、数は少ないが同じタイミングで3777(3/A)や、1個だけだが3171(3/A)も受信できていた。角速度(1bit毎の位相回転)や振幅から考えて、これも同じ機体からの応答と考えられる。
つまり、この機体のトランスポンダに何らかの不具合があり、数は少ないが、設定されたMode-3/AコードやMode-C高度と異なった応答が行われていた、という可能性がある。
別の機体
Mode-3/AとMode-Cの応答の途中でいくつかのコードがパラパラと出ている雰囲気。コード/高度からするとJALのB738らしい。
また別の機体
重なっているけど、直線状のMode-3/Aと傾斜しているMode-Cが出ていて、時々いくつかのコードが出ている。Mode-3/AからするとJALのB738らしい。このトランスポンダは7777が複数個出ていたり、Mode-3/A/Cとして壊れているリプライ(フレーミングパルスが足りない)だったり、変な応答がかなり多い。角速度が正常なMode-3/A/C/Sと同じだから、同じ機体からの応答。
翌日の同じ時間にも同様に7777等が出ていた。おそらく同じ機体で、同じトランスポンダのはず。再現性がある誤応答らしい。
ログを見ていると時々低頻度で出てくるMode-3/A/C応答、デコーダ側の誤デコードだろうと思ってたけど(実際、誤デコードも多いけど)、それなりの確率で明らかに異常な応答が出ているらしい。
飛行機のトランスポンダってものすごい高信頼性な物だと思ってたんだけど、実際はそうでもない? 受信側(ドングル)の安定動作範囲(2.4Mspsまで)を超えた範囲(約2.76Msps)で使っているからそれが原因という可能性もあるけど、とはいえコヒーレンシー(位相が直線状に乗る)とか同じ応答が複数観測できるとかを考えると、受信側の問題はあまり無いはず。
これだけ大量に誤応答が出てくるってことは、ENRIあたりの資料を漁れば出てきそうな気もする。気が向いたら探してみよう。
リプライのサンプリングはMode-3/A/C狙いで約2.76Msps(1.45us/bitの4倍)に設定しているから、Mode-S(マンチェスタ/BPPM、2Mbaud)のデコードには不適。Mode-Sのデコードを行うなら4Mspsくらいほしいところだけど、3Mspsとか、アルゴリズム次第では2Mspsでも可能らしい(かなり大変そうだけど)。せめてICAOコードだけでも取得できれば、誤応答を連発するトランスポンダでMode-S対応の場合は、誤応答を多く出す機体番号を自動で取得できるんだが。電波品質を見るような目的でやるなら10Mspsとか20Mspsとか、高いサンプリングレートが欲しいな。
まあ、それを取得したところでどうするんだという話ではあるけど。航空会社に「御社のICAOコードXXXXXXの機体のトランスポンダが調子悪いっぽいですよ～」とか言ったところで対応してくれるとも思えんしな(運用上の問題がないからそのトランスポンダを使い続けているわけで)。
途中でコードが変わった機体
Mode-3/AとMode-Cのリプライ。1200で飛んでいた機体が途中で1563になった。航空大の機体で、旭川空港でタッチアンドゴーを繰り返していた。旭川空港付近では1200で、ある程度離れたところで1563に変わった。Fr24で見ると、旭川空港と帯広空港でいえば旭川空港に近い側で、大雪山系-日高山脈のラインより東側。
パルス列はコヒーレントだけど、直線状ではなく、周波数変動がかなり大きい印象。とはいえたかだか20us程度でここまで大きく暴れるってこともそうそうありえないはずなんだけど。
PAの発熱が水晶に戻って発振周波数が変動する、みたいなメカニズムはあり得るけど、それでも熱移動で駆動する以上、ある程度大きな時定数が必要になる。マイクロ秒オーダーだとかなり厳しい気がする。小型機に乗せるような小さいトランスポンダなら基板のPAの裏に水晶が乗っていて熱的にほぼ直結、みたいな可能性もあるけど、それにしたって基板を貫通できるだけの時定数が必要だし。
あるいは、電源がヘタってる、という可能性もあるか。RF系は大電力のパルス放電なので、一旦キャパシタに溜めてPAに入れているはずだけど、TX電源が容量抜けすると送信中に上流から引っ張るから電圧低下が伝搬して、発振周波数が引きずられる、みたいな。この場合、熱容量で平滑されないから応答性が高くなる可能性がある。ただ、この場合はF1に比べててF2は送信出力が低くなるはずだけど、振幅を見る限り電力の変動はほとんど見られない。RF電力でほとんど影響のない範囲でも発振周波数である程度変動する可能性はあるけど。
F1側は20deg/1.45usくらい、F2側も同様に20deg/1.45us程度(ただし符号が逆)として、20deg/360deg/1.45us=38.3kHz程度。2倍で80kHz程度。1090MHzに対して75ppm弱程度の変動。結構でかい。
JALの機体。このあたりをこの高度で飛んでいるのは見たことがない気がする。この機体はもちろんADS-B out対応機なのでFr24でも見える。まっすぐ滑走路に進入していった。旭川空港に南東から進入するルートは、普段はもっと西寄りの経路を通るはず。FL40くらいのMode-Cが受信できていたので、AGL1km(未校正)程度か。
21日の午前中にかなり大きな音がした。回転翼機みたいなバタバタした音じゃなくて、ジェットエンジンみたいな音。自分は見れなかったけど、目撃者曰く「戦闘機が3機」だそう。まあ、その人はシルエットで機種を判断できるような知識のある人ではないから、本当に戦闘機なのかも怪しいけど。
当時のログを見ると、Mode-3/AとMode-Cがパラパラと受信できていて、ほぼ同じタイミングで3種類のMode-3/Aと、心の目で見ると3つのMode-Cがあるような気がする。2分半程度でMode-3/A/Cのみ(Mode-Sは無し)。
近くに飛行機がいるかどうかは1090MHzを見れば(運が良ければ)わかるけど、その飛行機がどの方向にいるとか、どういう機体か、みたいな情報はほとんど得られない(Mode-Sを受信できればICAOコードが取得できるし、ADS-Bを復調できれば位置情報も得られるけど、未実装&ICAOコードから機種への紐づけはまた別問題)。
どちらかというと、MGSのサラウンドインジケーターみたいなモノが欲しいんだよな。方向と音量を可視化するようなシステム。パワースペクトルが見えれば、ヘリコプターなのか、ターボプロップなのか、ターボファンなのか、みたいな情報もある程度得られるはず。ゲーム内のサラウンドインジケーターは周方向が方位、半径方向が音量だけど、半径方向にスペクトル、輝度で音量、みたいな表示にすれば、方位とパワースペクトルを表示できる。分解能の低い低周波側を内周に、分解能の高い高周波側を外周に、という感じで。問題はビームフォーミングだが…… 大量のマイクを並べなきゃいけないからオーディオインターフェースが大変そうだ。
音を視覚的に表示するインターフェースは例えば潜水艦のソナーが考えられるけど、こちらは方位と時間を2次元に表示して輝度で強度を表示している。スペクトルはカーソルで選択した信号源を別画面で表示する、みたいな感じだったはず。これはスペクトル情報の重要度が低いというわけではなく、単に歴史的な由来のような気がする。ソナーにCRTを組み合わせた頃は容易にスペクトル解析を行う方法がなくて、まずは方位と時間だけ表示して、その後で周波数解析ができるようになったら追加で画面を用意して、みたいな感じだったんじゃないかな。
とりあえず方向はわからなくてもいいから、パワースペクトルだけでも見れると便利なはず。周波数だけでも把握できれば、飛行機の機種もある程度判別できるはず。旅客機(ターボファンエンジン)は音が似てるとか、プロペラ機はスロットルレベルでピークが移動するから判断しづらいとしても、ヘリコプターは機種ごとに結構違うはず。さすがにUH-1とAH-1くらい似てるとパワースペクトルだけで判別できるかは微妙な気もするけど。パワースペクトルの表示だけならさほど面倒ではないはず。C#でやろうとするとマイク周りのインターフェースがちょっと厳しい気もするけど。最悪、オシロスコープをFFTモードで表示してPCから定期的にスクショするだけでもいいし。問題は屋外に設置するマイクの耐候性だが……
***
GPSの相関器のDLL(Delay-locked loop)について、なんとなく分かったような気になっているので、メモ。例のごとく素人考えなので間違ってるかもしれないけど。
Phase-locked loop(PLL)は位相(Phase)を固定するもの。Frequency-locked loop(FLL)は周波数(Frequency)を固定するもの。Delay-locked loop(DLL)も同様に遅延(Delay)を固定するもの。
例えばデジタルデータをデータとクロックの2本の配線で送る場合、周波数が高くなるとデータとクロックが同時に届かなくなってくる。このズレ(遅延・Delay)を調整するために使うのがDLL。この用途の場合、DLLは単なる移相器と考えればいい。
DLLをロジックで作る場合、シフトレジスタを大量に並べて、シフトレジスタ間からのタップをスイッチで切り替えることで遅延量を決める(最大の遅延量はクロック速度とシフトレジスタの数で決まる)。通常、外部から入る信号に対する遅延を固定する場合、DLLの最後のレジスタの後ろから出てくるデータはそのまま捨てることになる。
GPS(というかCDMAのコード)をDLLで再生する場合、ウロボロス的に後ろから出てきたデータ列を再度DLLに戻す(シフトレジスタでDLLを組めば劣化なしにループさせられる)。1クロックごとにシフトレジスタで1段ずれるから、N段のDLLであればNクロックで1周する信号列が得られる。
例えば10230段のシフトレジスタに10.23MHzのクロックを入力すれば(適当な初期値を設定しておけば)1kHzで回る信号列が得られる。このシフトレジスタ列からのタップに対してEarly/Lateの差をフィードバックすれば、0.1chip(30m)分解能でレプリカの位相を制御できる。スイッチは基本的に固定だから(E/L差のフィードバックがあるから多少の速度で回る)、ハードウェア内で高速に信号を振り回す必要がない(シフトレジスタをブン回す必要はあるけど、直線的に流すだけ)。
つまるところ、この手のDLLは発振周波数が固定のNCO(1bit・任意波形)と考えれば良い。そしてこのDLLへのフィードバックはNCOの位相に対する加算・減算指示と等価。NCOはレジスタ値をテーブルのアドレスとして使うから、パラレルバスを高速に駆動する必要がある。DLLであればシフトレジスタは高速だが、制御信号は低速でいい。
それと、NCOは初期値をテーブルに流し込む処理が必要になる(GPS32個なら4KiB程度なのでROMで持てないこともない気もするけど)。DLLも初期値を与える必要はあるが、DLLの頭にスイッチを置いて、自身をループさせるか外部から読み込むかを選択できるようにして、外部のGold符号発生機から読み込ませることができる。C/Aコードの場合は10bitのLFSRを2個並べて1.023MHzのクロックを与えるが、片方には1024回に1回クロックを遮断するスイッチを設ける(10bitのカウンタがオールクリアorオールセットでスイッチを切ればいい)。こうすると約1kHz周期(1クロック遅れるので約999.02Hz)で1個のPRNが出力される。1回毎にG1/G2の遅延が1段増えて、1.024秒毎に1023個のGold符号が出力されるから、適当なタイミングでDLLのスイッチを符号器側に設定してやれば、PRNをDLLに流し込むことができる。任意のPRNを取得するのに最悪で1秒以上かかるけど、当時の受信機はスキャンNch+トラッキング4chみたいな構成だろうから、衛星切替時はスキャン用相関器のDLLからトラッキング用相関器のDLLにコピーすれば、任意のタイミングで切り替えができる。
DLLをクロック再生に使う場合でも、DLLをループさせて使うような用途があるらしい? DLLの後ろからDLLに戻して適当な位置からタップすれば固定周波数・可変位相の発振器として使えるけど、適当な位置からタップしてDLLに戻してやれば可変周波数・固定位相の発振器として使える(ループ位置とタップ位置を変えれば可変周波数・可変位相にもできる)。送信側と受信側のクロックに多少のズレを許容しているシステムだと、フレームの先頭に同期用のビット列がついていて、この周期を保存するのにDLLを使うらしい。周波数がある程度固定であれば、入力側のシフトレジスタはシンプルに遅延させて、後ろ側の適当な位置でタップすれば、ある程度の範囲で周波数を可変できるクロックジェネレータが作れる。
QZSSのL1 C/Aって将来的に廃止されるのかな? 1RではC/Aを放送中だけど、5以降ではC/Aを放送せずC/Bを放送し、5を打上げたあとは1RもC/Aの放送を終了してC/Bを放送するらしい(いちおう、5以降もC/A送信能力は残っているらしい。サブキャリアのON/OFFで切り替えられるってことだろうけど)。
C/Bってどんな信号なんだろ。ぐぐってもわかりやすい解説はあんまり見かけない。GPSの文脈で探しても出てこないから、QZS用の信号なんだろうか? C/Bを使う理由もよくわからない。「よくわからない」とか「なんで変えるのかわからない(既存の別の信号との差別化ができない)」みたいな感想もいくつか見かける。
C/BがQZSだけの場合、アメリカからの政治的な圧力とかあったのかな、とか邪推してみたり。GalileoがL1 C/Aに互換性がないのは米国が管理できないGNSSで米軍への攻撃を誘導されるのが嫌だから(周波数で分離すればジャミングできる)みたいな理由だったらしいけど、準天頂衛星システムは対地同期軌道(日本やオーストラリア、東南アジアの東側)でサービスを提供するから、米軍への大規模攻撃に使用される状況は想定しておらず、L1 C/Aが許されていたが、昨今のこのあたりの情勢を考えるとQZSのカバレッジの中で米軍が大規模に展開する可能性が出てきて、嫌がられたのかも。
邪推に邪推を重ねると、そういう場合にL1のC/A以外を妨害したうえで、L1 C/Aはどうするんだろう。最近のGPS衛星にはS/A機能は乗っていないけど、米軍が本格的に参戦するようになったときに、C/A信号はどうするんだろう? そもそもC/AはCoarse/Acquisitionの略で、Pコード(10.23Mcps・7days)の非常に長い拡散符号を捕捉するためにC/Aコードで大まかな位置を掴むことが目的だったわけだけど、信号処理の発達でC/Aコードに頼らずにPコードを捕捉できるようになった現代では、軍内部でC/Aコードの重要性が相対的に低下しているわけで、S/Aが有効化できない以上はC/Aコードの放送を停止するみたいな方向になるのかな? あるいは、衛星にS/A機能がなくたって、地上セグメントからクロック補正に適当な誤差を投げてやれば同じような機能が作れるしな(C/AコードとPコードで異なる航法メッセージを放送できるのであれば。送信機は冗長系で切り替えられるだろうから、C/AとPで別の変調器に接続すればできそうな気がする)。S/Aが廃止されてDGPSインフラがどんどん廃止された現在、再びS/A的な機能が有効化されると社会的な影響も大きそうだ。とはいえ、その「社会」はアメリカではないし、戦争中のアメリカが他国の社会を気にするかというとな…… そういう諸々が嫌になったからQZSS単独で測位できるように数を増やそうみたいな話にもなったんだろうし、各国が独自の測位システムを作る理由でもあるだろうし。そうやって増えたGNSS衛星群は平時では測位精度の向上に直結しているけど。
いちおう、QZSSがL1 C/Bを使うのは、L1 C/Aを使う衛星(GPS衛星やSBAS衛星)が増えたために干渉レベルが上がったのでQZSが出ていく、みたいな理由もあるらしい。C/Bのほうが性能がいいというわけではなく、C/Aの性能を落とさないために、という消極的な理由らしい。SBASは航空機等で使うシステムだから今更変えるわけにもいかないんだろうけど、最初っから測位信号(航法メッセージ)と補助信号(SBAS)はスペクトルで分離しておけばこういうトラブルはなかったはずなんだよなぁ。SBASは航法メッセージと互換性がない(変調方式・変調レートが違う)から、元々C/AとSBASの互換性はさほど大きくないはずだし。当時は相関器のコストが高かったから、そこだけでも共通化すればだいぶ楽になる、みたいなことなのかもしれないけど。
***
C#の変数(特にタプル)の初期化で、(int i, int j, int k) a = default with { k = 123 };みたいな文法が使えたら便利なときがありそうな気がする。プリマリコンストラクタで初期化するときに、ほとんど全部は初期値(ゼロとか)でいいんだけど、一部だけ特定の初期値を設定したいというときに、他の全部にも初期値を与えるか、あるいはコンストラクタメソッドを作って一部を上書きする、みたいな行為が必要になる。
0 件のコメント:
コメントを投稿