2024年2月28日水曜日

小ネタ




 前方オーバーヘッドパネルの左上。見づらいけど、右側の赤いスイッチカバーと下段の黒の2個のカバーにシアワイヤがついている。赤がフラップの代替制御、黒がスポイラー格納。


 017 | Boeing 737. overhead panel. | liveview86 | Flickr

 中段左寄りの赤いスイッチ2個(バッテリ切り離し)にもシアワイヤがついている。

 赤いスイッチカバーは見える範囲で4個、すべてシアワイヤ付き。黒いスイッチカバーは見える範囲で7個、シアワイヤ付きなのはその内2個。シアワイヤがついていないカバーにもシアワイヤ用の穴が空いているけど、1個(一番左上のやつ)だけ穴が見えない。穴のあるカバーもパーティングラインとか穴の位置で微妙に違いがある。いろんなサプライヤが供給してるんだろうな。穴がないやつが混ざってると在庫管理が面倒そう。


***


 Google検索、バグなのか仕様変更なのか、"filetype:pdf"の効きが弱くなっているのがすっげー不便。ちょっと特殊なキーワードとかはPDFで探せばたいてい見つかる場合が多かった気がするけど、filetypeの強制がなくなって通常のHTMLも検索対象になった結果、似たような語感で全く無関係のページが大量に出てくる。


 製品紹介 Products|セイフティSBU|株式会社ダイセル

 火工品を扱っているメーカーの製品情報。いろいろと面白そうなデバイスが。

 パイロスイッチなんてあるんだな。火工品でピストンを動かしてバスバーを切断し、切り抜いた導体で次のバスバーを接続させる。大電流を扱えるし、一瞬(200us未満)で回路を切り替えられる。遮断だけまたは導通だけの製品もある。


 ren | Microsoft Learn

注意 このコマンドは rmdir コマンドと同じです。

 ……そんなわけないやろ??? 英語版だと「This command is the same as the rename command.」という表記。(rmdirはディレクトリ削除コマンド)


 8.126MHzあたりのオシレータって普通に売ってるものだと思ってたけど、全然売ってないんだな。DigiKeyでも1種類しか取り扱いがない。ルネサスのPLLオシレータだそう。もうちょっと普及してるものだと思ってた。PLLオシレータがアリならSiTimeのMEMSとかも選択肢に入ってくるだろうから、これらを含めていいならもう少し多いけど。


 STM32、使うの久しぶりすぎて開発環境整えるのもだいぶ苦労してる。CubeMXでコード生成してmakefileでビルドしてるけど、今どきのSTM32開発環境って何を使うべきなんだろうか。CubeMXで選べるライブラリが長らく保守されてないっぽいし、別の方法を使うべきっぽい気がするけど。それともF4とかG4とかのあたりは保守する気がないだけで、新しいマイコン使えってことなんだろうか?


 makeでビルドするとものすごい時間がかかる。クリーンビルドで10分以上かかる。遅いと1ファイルのコンパイル(ソース→オブジェクト)に数十秒とか数分とかかかる。試しに-ftime-reportをつけてみたら、G++の自己申告だとwallで1秒未満しかかかっていない。で、-ftime-reportを出力してから次のg++の呼び出しがかかるまでに相当長い時間がかかっている。ということは、g++の問題じゃなくて、makeの問題ってことか。


 WSLでホットリロード効かない or コンパイル遅すぎ問題 #webpack - Qiita

 WSL(WSL2)でビルドが遅くて重くてホットリロードが効かないとき #React - Qiita

 このあたりが原因っぽいなー。しかし、前にやったときは遅いとか全然感じなかったんだけど。ここ1年あたりでファイル処理周り変わったのか?


 どうしたものかなーと思いつつ、試しにcygwinをインストール。12分とかかかってたクリーンビルドが20秒ですって。めっちゃ早いじゃん。-j19で並列化すれば8.5秒程度で終わる。もちろん通常のビルドならさらに早い(3秒弱)。

 WSLを使っていたのってMicrosoft製のツールでmake使いたいだけだったしな。STM32の開発ならどうせCubeMXとかarm-none-eabi-gccとか外部ツールが必要だし、今更cygwinが増えたところで。

 Make for Windowsという方法もあるんだろうけど、もう20年近く更新されてないっぽいし、さすがに。

 あと、最近のVSCodeのIntelliSense用にWindows用GCCバイナリが必要だから、WSLから呼ぶLinux用バイナリと両方用意するのが面倒。cygwinならWindows用GCCバイナリを使うから、VSCodeと共有できる。


 STM32G4のADCで3.4Mspsでサンプリングして、フーリエ変換。

  HSI↑ ↓HSE

 64倍のPGA(GBW13MHz.typ)を2段で4096倍に増幅しているから、右肩下がりのスペクトル。

 HSIとHSEでスペクトルがちょっと変わる。HSEのほうがノイズが多い。HSIは周波数精度がだいぶ悪い(1900ppmくらい早い)。HSEは周波数精度がそこそこ高い(11ppmくらい遅い)。個体差とか温度特性とか色々あるだろうけど。

 外付け水晶は24MHzだから、数百kHzオーダーのノイズは問題ない程度だろうと思っていたんだけど、予想よりだいぶ影響がある。イメージ雑音なのかな?

 イメージ雑音を除去したいのであれば、例えばADCを駆動するTIMからDMAを蹴ってARRを書き換えてやればサンプリングレートをスイープ(リニアor離散)できるから、イメージのスペクトルを拡散できそう。ただ、目的のスペクトルは第1ゾーンに入っているとはいえ、LOもTIMに同期して動かさなきゃいけないのが面倒ではあるけど。1stLOはテーブルだろうし、ARRの周期とテーブルの長さを合わせればいいんだけど、色々面倒なことになりそう。

 ただ、ゾーン2以上のイメージを除去できるなら、逆に使えば任意のゾーンのスペクトル以外を拡散することもできるはずなんだよな。例えばゾーン2に同期してLOを振動させてやればゾーン1やゾーン3以上を除去できるから、ソフト的にアンダーサンプリング用のフィルタが作れる。しかし、計算量がなぁ。。。

 アンダーサンプリングなソフトウェア無線で、受信可能な帯域幅よりADCのサンプリングレートが低い場合に、ADCのサンプリングクロックを振動させてソフト的にイメージを除去する、みたいなソリューションってあるんだろうか? 素直に実装するならBPF通過帯域幅よりサンプリングレートを高くするべきだし、普通はそうするんだろうけど。

 1stLOが周期性として、その周期で位相が戻るような拡散パターンが必要になるのかな。パターンを作るのが大変そうだ。

 試しにアンテナを外してサンプリングしたら、HSEでもノイズがきれいに消えた。ってことは、基板内で入ったノイズじゃないのか…… 基板から放射されたノイズが2mくらい飛んでアンテナから入ったってこと? であるならダイカストのケースに入れれば十分シールドできそう。/* もしかしたらアンテナではなく、PGAの途中にオシロのプローブを当てていたのが原因かも */


 ADCの生データをオンチップでダウンコンバートしてCICに通してみた(間欠処理)

 567kHz(NHK R1、札幌、100kW)にピークが出てる。その隣の594KHzは東京のNHK R1(300kW)、その次は旭川のNHK R1(3kW)の621kHz。大阪のNHK R1(100kW)の666kHzのピークもある。まあ、周波数を見てるだけなので、本当にそこから送信された電波かどうかはわからないけど。

 とりあえずミキサとCIC(R16, N4)合わせてサンプリング時間の2倍程度の計算時間。全部forでループさせてるとはいえ、だいぶ遅い。これを最適化して3倍程度まで早くしなきゃいけない…… アセンブリ…… ウッ。。。


 前回DSP型AMラジオを作ったの、去年だと思ってたけど、一昨年だったか…… 前回は復調周りはある程度受信できるところまで作って、あとは液晶とかつないでスペクトルの表示とか作り始めて、結局中途半端なところで飽きてしまったので、今回はもう少し真面目に受信周りを作り込みたいな……


 STM32G474RE、アナログ回路いろいろ入ってて面白いのに、Nucleo G474REはピンアサインが厳しいのがつらい。G474REでアナログ電源周りちょっと気をつけたりして、特にアナログ回路の自由度高めのピンアサインのボードとかあると面白そうだが。さすがにQFP変換基板で使うのは面倒だし、とはいえ自分で基板を作るというのも……

 STBee F4miniみたいな感じでSTBee G4mini(STM32G474RE)とかあると便利なんだけど。最近ストリナはセンサ類も含めてあんまり新製品出してないしなぁ。


***


https://www.jstage.jst.go.jp/article/itej/69/3/69_185/_pdf

 NHKの中波ラジオの送信機の話。1本の空中線で2ch(R1とR2)を給電するための整合回路の例とかも。


https://www.jstage.jst.go.jp/article/itej1978/33/3/33_3_162/_pdf/-char/ja

 1978年。周波数拡散の方式の例とか。DS, FH, TH, TFH, pulse FM, FH/DS, TH/DS。

 TH(時間ホッピング)は装置が簡単に構成できる利点があるが、CW妨害に弱い。妨害対策ではなく多元接続が目的。FHと組み合わせてTFHとして使用される。

 pulse FMは情報通信で使う場合はチャープ方向(上り・下り)で情報を変調する。干渉やマルチパスフェージングに強い。情報通信に使われることは多くなく、レーダーで使うことが多い。

 FHやTHとDSを組み合わせたFH/DSやTH/DS方式。収容能力が高い。


 北海道の中波放送(AMラジオ)の周波数一覧

 横軸に周波数を、各線グラフで放送局を示し、データラベルには出力、所在地、コールサイン、周波数(一番下の行)を表示している。100kW以上のNHK(R1, R2)および在京3局は北海道外についても記載した。

 北海道の民放局(HBC, STV)はFMへの移行は表明しておらず、当面はこの周波数で放送が続けられるはず。この図中では在京3局がFMへ移行しAMを停止したいらしく、またNHKラジオ第2は2年後(2025年度末)に放送終了の予定らしい。アナログモードがどんどん減っていくなぁ……

 そのうちFMラジオも終了するんじゃね? とか思いつつ、まあ、これだけ大々的にFMへの移行を宣言してるんだから、「FMアナログ放送を終了します」とは少なくともあと15年は言えないだろうけど。想定としてはFM放送はISDB-Tsbでデジタル化したかったんだろうけどな。しかしワンセグでも430kHz、mmの3セグなら1.23MHzの帯域幅だから、FM放送の2倍に広がってしまう。電波仕様の効率化の面から見てもISDB-Tsbは厳しそう(ガードバンドが要らないから同一中継局からは6MHzあたり13ch詰め込んだり、SFNで中継したりで、トータルでは効率化できるだろうけども)。

 そういえば十勝NDBも廃止されたらしいしな。ググると2020年頃に受信報告があるけど、最新のエンルートチャートには乗ってない。北海道は十勝が最後の1個だったはず。近くに航空大学校の分校があるから、ナビゲーション機器の練習用にNDBが残ってたのかもしれないけど、とはいえ今の時代新しく練習するようなものでもないだろうし。他のエリアのチャートを合わせても、ナビゲーションの周波数の一覧にはNDBっぽいものは見当たらないから、国内のNDBは全部廃止されたのかな?


https://www.nhk.or.jp/bunken/book/regular/nenkan/pdf14/14_672_675.pdf

 NHKの主要な中継局の周波数、出力、コールサインの一覧。なあ、FMラジオの周波数、MHzとkHz間違えてんぞ。。。


0 件のコメント:

コメントを投稿