パン屋じゃなくて。
FHSSはヘディ・ラマー(Hedy Lamarr)。イニシャルは「HoppingすればLambdaが変わる」と覚えれば良さそう。
工学系大学生に質問! 尊敬する人!!
「そうですね、マリリン・モンローとか、ヘディ・ラマーとかが好きです」
往年のハリウッド女優が好きなだけの可能性が……
***
***
しくじった。。。前回の往路で磁気テープに著作物入れて持っていく話、「私のテープ上書きしたの誰!?」を思いつけなかった。。。「このドラマの次のエピーソド、楽しみにしてたのに!!」
LTOって最近はドライブはIBMだけ、テープは富士通とソニーしか作っていないらしい。オープン化して複数企業で製造して価格競争させるために作った規格なのに。
人類を初めて月へ送り届けたIBMは、磁気コアメモリに変わって磁気テープを火星に送り込むのだ…… さ、さすがに無いよね?
磁気コアメモリは情報を「無期限(indefinitely)」に保持できるそうだ。スペースシャトル チャレンジャーでは海から回収されたコアメモリから記録を読み取ることができたとか。ただし磁力や熱には弱い。
磁気コアメモリは大きな質量を持っているので、衝撃によって影響を受けることもあるらしい。「調子が悪いときは叩くと治ることがある」というのも、衝撃によってワイヤの位置関係が変化して信号処理が改善するから、とか。
C言語とかで遊んでる人がよく遭遇するセグフォったときのコアダンプは、「メモリのコア(重要)な部分を吐き出す」というような意味ではなく、物理的にコア(磁気コアメモリ)に記録されていたものを吐き出すことに由来するらしい。「メモリに記録されてるデータ全部印刷するぜ」みたいな。
***
キーボードがちょっと調子悪い。Bluetooth接続のやつ。いくつかのキーが認識されづらいことはよくあるけど、最近完全に入力できないことがたまに起きる。電池切れかと思って交換しても改善しない。電池抜いたり電源入れ直したりガチャガチャやってると復活するんだけど。
USBキーボードはいくつか手持ちがあるので最悪でも何も入力できないという事態は回避できるけど、なんで使ってないかといえば手が慣れてないからであって、やはり困る。とはいえ、メインで使ってるやつはキーピッチ19mmの普通のやつなので、物理的に似てるやつを買ってしまえばいいんだけど。同じような機能のキーボードがいまいち見当たらない。
amazonのレビュとかを見る限り、安いBluetoothキーボードでストレスなく使えるものは少なそうだな。省電力化でペアリング切ってスリープに入って復帰に時間がかかる、とか。
***
加湿器を物色中。流石に気が早いが。
今まで使っていた超音波方式は掃除が面倒なので、次シーズンはスチーム式を使いたいな、と思っている所存。象印の加湿器を期待してみてみたけど、まぁ、当たり前というか、加湿機能しか無い。
電気ポットと加湿器が一緒になった家電があれば便利だと思うんだけどなぁ。うまいこと構造作らないと衛生的にやばいから、そこまでしてコストかけるくらいならコンセント2個使って加湿器とポット別に置いてくれ、ということだろうか。
***
六角のドライバー、ボールポイントじゃないやつで軸が短いやつがほしいんだけど、探してもいまいち出てこない。グリップを握ったままで軸の先端に指が届くくらい短いやつがほしい。
プラスネジとかマイナスネジのドライバーは暗器かってくらいに小さいやつが大量に市販されているのに、六角ではそういうのが見当たらない不思議。個人的にボールポイントじゃないタイプが好きなので、どうしても真っ直ぐ入れられない場所以外は切り落としっぱなしの軸のタイプを使っている。ただ、このタイプはキャップボルトを外した際に、軸に残って外しづらい。組み立てるときに脱落しないのが利点なのだけど、分解時に適度に脱落してくれないのは地味に不便。ということで、指が届くタイプがほしいという次第。
無いものは作るしか…… と思いつつ、長いドライバーを切るのと、短いアレンキーに3Dプリンタとかでグリップを作るの、どっちが楽だろうか。手持ちのドライバー(長いやつ)は先端部を残して表面処理がしてあって、絶縁の樹脂ほどじゃないにしろ、明らかに厚さがあるから、途中で切ると六角レンチとして使えなくなる気がする。研いで被膜を剥がせばいいのかもしれないけど。アレンキーにグリップを付けるほうが楽かな?
もっとも、分解時にネジが脱落しなくて困っているだけなら、分解時にはボールポイントタイプを使えばいいのでは、という気もする。
あるいは、電動ドライバー用の六角ビットに1/4ホルダを組み合わせて使っても良さそう。一体型工具を使わないとはケシカランみたいな思想を持ち合わせているわけでもないし。一体型のほうがスリムで好きではあるけど、電動工具用ビット+ホルダにそういう性能は求めてないし。
***
気分転換に、チャチャッとFusionでモデリングして造形
外径25mmに制限するとBB弾が入る穴は6個が限界。回転式拳銃みたいな様相を呈している。
とりあえず昔買ったスプリングでエネルギーを貯めてBB弾を飛ばしてみた。どーせ大して飛ばんやろ、と思ってナメてかかったら、想像以上に吹き飛んで非常に楽しいことになった。そうじがたいへん…… 数は大したことないけど、広い範囲に飛び散る。
今回は何も考えずに(フィラメントの消費量を減らすことだけを考えて)高さを設定したので、合計12発しか入らないけど、18発とか24発入るようにしたらもっと高密度に飛ばせる。6方向にしか飛ばないけど、弾体をスピンさせて飛ばせば1発ずつ違う角度に飛んでいくから、ある程度広い範囲に放出できるはず。
ただ、モスカートみたいに軸上に飛ばすのと違って、径方向に広がるから、放出点から離れると急速に密度が低下してしまう。サバゲで使うのは難しいだろうなぁ。本物の近接信管も指向性破片とかコネクティングロッドとか、いろいろ工夫しているようだし。
思ったより良さそうな感触なので、細部を変えて造形。
BB弾の脱落防止の輪ゴムを追加して、全長を伸ばしたタイプ。4x6=24発入る。バネを圧縮すると全長60mm(突起含む)くらいになる。これに保持/開放機構とか電装系が追加されるのでもう一回り長くなる。
軽く画像検索した感じ、実物の25mm低速弾も結構気持ち悪い長さなので、当たらずとも遠からずかな、という感じ。実弾は全長100mmくらい(ケース含む)かな? 今回の場合だと発射は発射機側のスプリングとかを使うことになるはずなので、発射薬等が不要な分で弾体全体をフルに活用できる。小型のLiPoや8pinマイコンくらいなら十分入りそう。薬莢(みたいな形のパーツ)は分離して発射機側から放出されるとそれはそれで楽しそうだが。回収するものが1個から2個に増えても大して変わらんやろ……
/* XM25等で使う25x40mm低速弾の他に、XM109等で使うことを想定した25x59mm高速弾もある。M203で使う40x46mm低速弾とMk.19で使う40x53mm高速弾の違いと似たような構成。25x59もオートマチックランチャーで使う構想もあったらしい。 */
***
だいぶまえに単色液晶で作ったやつ
テトリス(R)ミニのあまりのクソゲーっぷりにムカついて作ったやつ。
当時のエントリを読み直すと、11日に「遊びづらい」と書いて、13日にC#でテトリスを作って、15日にマイコンで実装しようかな、と書いて、21日にこの写真を撮影してるのか。よほどムカついてたんだろうな。
テトリス、市販のゲーム(ハードorソフト)で遊ぶより作るほうが楽しい説まである。
この液晶は色深度が1bitしかないので形ごとに色を変えるみたいな表現はできないけど、それでも3色(白、黒、灰)くらいは表現できるから、テトリスのゴーストブロックくらいなら問題なく表現できる。解像度もテトリスを作るのにちょうどよくて、横10マス縦20.5マスを表示して、右に次のブロック、左にホールド、上にスコアを表示してピッタリ収まる。フレームレートも20Hz出るのでテトリスくらいなら問題ないし、SPI1本で制御できるので楽。
このときはSTM32F303K8でで制御してたはず。液晶の単価が秋月で3000円するのでコスト的に厳しいけど、正直、公式ライセンスのテトリス(R)ミニよりはるかに遊んでて楽しいゲーム機が作れたと自負している。チャタらないし、同じブロックが4個連続で落ちてくるみたいなアホみたいな実装にもなっていないし、デファクトスタンダードの10x20マスをフルに使えるし。
昔、iPod touchでテトリスをかなりやり込んでいたので、久しぶりにマトモなテトリスで遊びたいと思って、このあいだXbox OneでTetris Effect Connectedを買ってみたんだけど、思ったより楽しくないんだよな。なんでだろう? 操作性の問題かな? いろいろ設定弄り回して自分に合わせればいいのかもしれないけど。どこに違和感があるのかよくわからないので手当たりしだいに設定を変えるしかない。面倒くさい。
iPodで遊んでたときは隙間の時間に軽く遊べたのが楽しかったのかな。コンソールで遊ぶとなるとしっかり気合を入れてゲーム機を起動しないといけないので、精神的にハードルが高い。Xboxで買うとWinでも遊べるので必ずしもXboxを起動する必要はないとはいえ。
パックマンみたいにテトリスをモチーフにした映画化もあるのかな?と思ってググったら、Apple TV+で製作中とのこと。2020年12月から2021年3月まで撮影していて、近日公開らしい。もっとも、映画『ピクセル』みたいなピコピコ楽しい映画とは違う感じらしいけど。きっと西側諸国の生産性を下げるためにソ連が暗躍するスパイ・アクション大作であろう(んなわけない
***
STM32G4のSPIでハマった点
左側2オクテットがソフトウェアによる送信(HAL_SPI_Transmit)、右側3オクテットがDMAによる送信(HAL_SPI_Transmit_DMA)。一番下の黄色がHighの場合はコアがフリーな状態(RTOSのIdleタスクが回っている状態)で、DMA転送開始後にコアがフリーになっているので、DMAで転送されていることがわかる。
ソフトウェア転送でもDMA転送でも、1バイト(バイト:4-16bitの範囲)を送ったあとに、2クロック分の隙間が発生してしまう。
これは、STM32G4のNSSパルス機能によるもの。STM32CubeMXではデフォルトでEnableに設定されているので、不要な場合(最大限のスループットを得たい場合)はDisableに設定する必要がある。
CubeMXは新しく追加された機能に関しては互換性が失われるような設定がデフォルトになっていることが多いので、ちゃんとリファレンスマニュアルを読んで理解して設定しないとハマりがち。それが当たり前なんだけど、電子工作の遊びレベルだと面倒。。。
NSSPをDisableに設定すると、適切に隙間なく転送してくれる
パケット表示に隙間があるのはロジアナソフトの描画によるもの。クロック信号はキッチリ詰まってる。
SPIの謎挙動
最後のデータを送ったあとに、MOSIがトグルする。常にそうなるわけではなく、場合によって異なる。特に困るわけではないが、いまいち理解し難い、気持ち悪い動き。
4バイト前のデータが漏れ出てる、みたいな挙動なのかな? いくつかパケット見るとそんな感じの動きをしている気がする。FIFO周りのリングバッファみたいな実装の関係かな。
データが多いのでウチのLAP-Cだとメモリが足りなくてつらい。LAP-C Proほしい。。。
/* ST公式のG4 SPIの日本語プレゼン資料、パリティと書いてあるのはポラリティ(polarity)の間違いかな? */
***
CMSIS-RTOSv2のスレッドフラグのタイムアウトの実装がおかしい。
ぐぐったらちゃんと出てきた
去年7月にフィックスされたらしい。STM32CubeMXで入るライブラリには反映されていないが。
CubMXが少し前のバージョンなのが駄目なのかと思って最新版にしてみたけど、CMSISのアップデートは来なかった。が、HAL周りは全部入れ替わってる。といっても実装の変更はごくわずかで、大部分はコメントのインデント変えたとかその程度だけど。CubeMXの起動めちゃくちゃ遅くなったな。。。
CMSISの更新は手動でやるしかないのかな?
***
1回転600パルスは10進数とは相性が悪い、ということで、1回転1000パルスのエンコーダをポチってみた。うーん、動かんぞ???
安定化電源で試してみたところ、電源が5.5V程度ないと起動しないことが判明。公称値は5-24Vなので、USBの5Vで使えるだろ、と思っていたんだけど、あてが外れた。
試しに分解してみたら、中身は磁気式エンコーダだった。商品名には光学式って書いてあるのに。
中国製の安物は信用しちゃいけない(戒め(今更
STM32G4ってA相のRisだけをカウント、みたいなモードもあるんだな。F4とかだとRis/Fal両方でカウントしてしまうので、クリック付きエンコーダだと2倍カウントしてしまう問題があった。G4だと1クリックで1カウントに設定できるので、クリック付きのエンコーダを使ったときの気持ち悪さがなくなってる。フィードバック制御ならA/BのRis/Falで4倍の分解能が使えるので(ジッタとかが無ければ)問題ないんだけど、ユーザーインターフェースに使うにはG4のほうが便利。
***
受信の処理、FIR前段にヒルベルト変換を挟めるようにしてみた。LSB/USBと、ヒルベルトを飛ばしてDSBの3種類。LSB/USBではCPU使用率98.5%くらいまで行く(スペクトル表示512pts8Hz時)。今の所、FIRもソフトウェア処理なので、これをFMACに投げればもう少し楽になる。ソフトウェアが複雑になる以上の利点が見えてこないけれど。
複素数の処理、今までは全部多次元配列で処理していたんだけど、[0]とか[1]を.reや.imでアクセスしたり、積をオーバーロードできるように、構造体に書き換えてみた。そしたら、目に見えて遅くなった。コマッタ。。。
順不同の処理を構造体での計算と同様な(と考えられる)ように並べ替えると、同程度に遅くなるので、構造体が遅いというよりは、レジスタに乗るか溢れるかみたいな部分が大きそう。そういう細かい調整をやろうとすると構造体では対応できないので、結局配列で処理しなきゃいけない。順不同な計算は勝手に入れ替えてくれたりすると便利だけど、低レベル(メモリマップドIOとか)を叩くようなことを想定すると、そういう実装にもできないんだろうな。スタック内に収まる計算は順番を入れ替える、みたいな処理もできそうだけども。
***
ビットマップフォントを作っていて気がついたこと。
ASCII文字セット(7bit)の範囲を2段で組んで、00hから1Fhまでを未使用とした場合、大きさが半分のフォントをマトリョーシカ的に組み込むことができる。まさかこのために制御コードが32文字確保されてるんじゃないだろうな??
.png){kind=small}
(源ノ角ゴシック Code JP M)
文字の大きさごとに画像データを用意しなくていいし、空きスペースに埋め込んでいるのでデータ効率がいい。ただし計算がめんどい。あとシーケンシャルアクセスができない。
***
gcc/newlibで使う-u_printf_floatというオプション、nano.spaceでもfloatを使うためのオプションだけど、同じような感じでlong longを使えるようにするオプションってないんだろうか? lluとかlldを指定すると正常に動作しない。nano.spaceを消せば使えるけど、バイナリが肥大化するので書き込みに時間がかかる。hexなら32bitに分割して表示してもいいけど、10進で欲しいときに困る。
***
AN/PRC-152みたいなポータブルラジオとか、AN/PRC-117みたいな可搬型ラジオでも、キーパッドにはピリオドを入力するボタンって無いんだな。F-16やF/A-18の無線関係でも、周波数はピリオドを含めずに入力していた気がする。西側軍用通信機器、ピリオドなしのインターフェースを使いがち? おそらく左寄せゼロ埋めで入力しているんだろうけど、不便じゃないんだろうか? そんなにレンジ広くないからゼロ1個入れるか入れないかの違いであって、それならピリオド使うよりゼロ使うほうがキーが少なくて済む、という判断だろうか。あるいは、普段使う設定はプリセットに入れるから、通常の運用では周波数を直接入力することはない、みたいなことなのかな。
米海兵隊の資料(B191716)にいくつかの軍用無線機器の使い方が書いてあるけど、結構面倒くさそうだな。
この資料、AnnexにJulian Date Calendarというのがついていて、1月0日からの経過日数の一覧が書いてある(平年と閏年の2ページ)。いったい何に使うんだろう? まさか自前で通信衛星の軌道計算とかやるわけでもあるまいし。
機器の時刻設定の手順で「insert the last two days of the current julian date and press ENT.」みたいなステップが出てくる。あるいはDTD(Data Transfer Device)の設定でも、同様の手順が出てくる。最上位1桁を省略できる理由はなんだろう?
月日の入力とユリウス日の入力だと、ソフト的にはそう大きく違うわけでもないはずで、そりゃテスト項目が増えるのはコストに響くけど、いちいち月日と通日を変換するほうがコストが大きいはず。いったいどんな理由で通日を使わなきゃいけないんだろうか。
周波数ホッピングの設定でも、ユリウス日の指定が必要らしい。こっちは許容範囲が狭いのでGMT(Zulu Time)も設定する必要があって、許容範囲は±4秒だそうだ。100cycle/secのFHSSでトレラント4秒ってどういうことだろうか。±400chipsまでは相関できる、ってことかな?
AN/PRC-117のFHSSの設定でも、通日は2桁で良いらしい。日2桁+時分秒でPRN作ってるのかな?Bluetoothが2.4GHzで毎秒1600回だから、VHF(100MHz前後)で毎秒100回というのは1.5倍くらいか。拡散率としてはBluetoothと同程度。DSSSみたいにピークを下げるのが目的ではなく、あくまでも線スペクトルの妨害波を回避する、程度の目的かな? 十分にPRNが長ければ盗聴対策としても使えるだろうけど、昨今の電子戦装備に対してFHSSがどの程度役に立つかはちょっと微妙な気がするな。
***
ラジオの現状
受信部周りがすごいシンプルなのに、エンコーダやら液晶やら、挙げ句にキーマトリクスなんぞ追加して、どんどん複雑になっていく。解せぬ。まぁ、無線周りをどれだけシンプルに作れるか、という疑問から始まったプロジェクトだから、周辺回路のほうが複雑になるのは、ある意味では勝ちだ。
液晶は2kHz/div, 6dB/divでドットを表示している。左右の端から端までで約24kHzの範囲を表示していて、隣(9kHz)のキャリアも目視できるような範囲。特にそれを狙っていたわけではなく、単に31.25kSPSを512ptsのFFTに通して幅400pxの液晶に表示したらそうなった、というだけだが。現状ではFFTの最大値を0dBとして固定しているので、キャリアのフェージングがそのままノイズフロアの上下として見える。
マトリクスから周波数を直接入力したり、エンコーダで微調整したり、あるいはエンコーダで一気に周波数を変えたり、いくつかの操作モードが有る。
基本操作としてはENTを押して周波数入力モードに入って、1MHzから順番にキーを押して、最後にENTで決定する。周波数入力モードでCLRを押すと入力をキャンセルできる。周波数レンジが狭い場合、上位桁からゼロ埋めで入力していくのは、予想以上に快適。ピリオドのスイッチ1個を省く以上にメリットが有る。
トップ画面では数字の1個が反転して表示されて(上の写真で6の位置)、左右キーで移動できる。これはエンコーダ1回転で数字が1変化する桁を示している。今回は100パルス/revのエンコーダなので、1クリックで100Hz変化し、1回転で10kHz変化する。今のところは0.01Hzまで表示しているので、最小0.01Hzまで調整できる。1回転で1変化するのでなく、1回転で10変化するほうが直感的かな? そのあたりの操作は追々。
あと、3スイッチ(PRCでは"3GHI/mode"キー)を押すと、受信モードをDSB→USB→LSB→DSB→で切り替えて、長押しでDSBに戻るようにしてある。3種類だと長押し操作は特に必要はないけど、今後CW受信モードとかが増えると、役に立つのであろう。本当に実装されるかはさておき。。。本物の無線機だと、CW(wide)とCW(narrow)の2種類があるらしい。その代わりにLSBが無いけど。
とりあえず、AMラジオとしてはAGCが無い以外はある程度マトモに動くようになってきた。RFスペクトラムモニタもあるし、そこいらのBCLラジオに引けを取らない。まぁ、受信周波数はせいぜい1.6MHzが限界だし感度も低いけど。
民生用ならともかくとして、AGCは必ずしも必要というわけでもないし。不便ではあるけど。
もう少し機能を実装しつつ、ちゃんとケースを作ればAMラジオとして最低限使えるようにはなりそう。外部アンテナ必須なのが辛いけれども。あとはプリセット機能とかもつけておきたい。よく聞く周波数/モードを+/-ボタンで呼び出せるような機能。
0 件のコメント:
コメントを投稿