VIDEO
めちゃくちゃ真面目に遊んでて良きかな。
歌詞に出てくる色々なキーワード、「コレ」っていう写真だけスライドショーにしたバージョンも欲しいな。そのうち誰か作りそうではあるけど。
リアクション&解説動画とかあっても面白そう。CNESとかJPLあたりにホロヲタいないかな。欧米の宇宙機関ならプロジェクト進行とか日本と似てるから色々面白い話ができそう。真面目に全部説明してたら5時間くらいかかりそうだけど。
VIDEO
DMGのスピンドル。ひずみゲージを内蔵して3軸の力覚センサみたいな計測値が得られる。今のところは手動で記録開始/停止を行って、後で解析するみたいな使い方かな? おそらく適当なテストピースをカットして発生する負荷を計測して切削条件を最適化する、みたいな使い方を考えているんだろう。
機械自身がセンサで状況把握できるようになるなら、従来のCAMでツールパスを作ってポストプロセスで座標変換して、みたいな感じじゃなくて、CADから「このボリュームを除去して」みたいな指示だけ出して、機械が自分で持っている工具情報(刃の位置や許容負荷範囲)からそれに合わせたツールパスをある程度決めて、切削速度(切り込み量)とかはトルク等を見ながら自動で調整して、みたいな機能があっても良さそうだけどな。ワークピースの形状は機内のカメラなり、DMGならニコンのスキャナなり、機械自身で把握できるわけだし、機内の障害物も知っているから、工具をどういう向きで突っ込むとクラッシュするとかの情報は一通り持っているわけで、CADデータ(STLとか)で最終的に欲しい形だけ教えておいて、あとは先に除去したい範囲とかを教えておけば、機械が勝手に削ってくれる、みたいなのが理想的な工作機械だろうけど。付加造形はわりとそういう感じになってきているし、切削加工もあまりピーキーな製品でないなら勝手に削ってくれる方が良さそうだが。あるいは、最終的な形に1mmくらい膨らませた形(荒削りの範囲)までは機械が自動的にゴリゴリ削っていって、最後の仕上げのツールパスは人間が細かくプログラミングして削る、みたいな感じとか。
まあ、そのあたりは、とりあえずセンサだけ先に売っておいて、あとからライセンスで追加する、みたいなことを考えているんだろうけど。
Introducing the S-70UAS™ U-Hawk™ - YouTube
UH-60を無人化してコックピット部分を観音開きになるようにして長い貨物を積み込めるように。MLRSのコンテナ1個を運んだり、UAVを上空から吐き出したり、いろいろ運べるし、無人だから(機材のコストを無視すれば)撃墜されるような任務に投入しやすくなる。
各国の軍で採用されているUH-60を改造するのであれば、保守部品の調達や整備の教育コストも圧縮できるし、色々便利そうだろうなぁ。シミュレータ用の機材をそのままリモートコントロールステーションに流用すればUH-60のパイロットがU-Hawkを遠隔操縦できるようにもなるだろうし。
米海兵隊はMLRSフォームファクタのランチャーを前線付近で移動させて生存性を高めながら使おうとしてるし、運用コストの低いヘリで必要なところに運ぶシステムが有ると便利そうよね。スリングで吊るのでなく機内に格納できるから運用性も高そうだし。
前線で物資輸送とかUAVランチャーに使うならある程度のステルス性もほしそうだけど、外観を見る感じそのあたりはあまり考えてなさそう。ステルス型のUH-60系は15年くらい前にちょろっと漏れたことがあるから開発自体はやってるだろうし、前線で飛んでたってことは一通り評価も済んでるはずだけど。むしろ一通り情報は持ってるから必要になったときに改造すればいい、みたいな判断なのかもしれないけど。あるいは逆に高コスト過ぎてUH-60のステルス化は諦めたのか。ヘリのステルス化は一定の繰り返し周期が発生するローターからの反射が大変そうだが。
たぶん無人の輸送ヘリを最初から設計して作ればもっと効率の良い機体を作れるんだろうけど、運用コストを考えると既存機の改造がベストなんだろう。「新規設計じゃないですよ。飛行実績のある機体のバリエーションですよ」といえば色々な手間を省けるし。MLRSコンテナ流用の無人ランチャーといい、既存システム流用の機材が増える昨今。
20年でCPUコアの巨人にのし上がった「Cortex-M」：EE Times Japan 20周年特別寄稿（1/3 ページ） - EE Times Japan
自分は仕事として(直接的に金銭的な報酬を受け取って)組み込み開発に関わったことはないけど、ちょうどこの移行期あたりにマイコンで遊んでいた(&若干の試作の下請け的な事をやっていた)気がするな。PICのアセンブリで電子工作を始めて、Arduinoで試作してPICに移植したりして、mbedを一時期触って、その後はSTM32(Cortex-M3)に移行してある程度複雑なものも作ったりして(PICを最後に使っていたのが2011年頃、STM32を使い始めたのが’12年頃、のはず)。試作みたいなやつはPIC, Arduino, STM32, mbed、あたりを一通り使っていた気もする。PICとかSTM32や周辺のセンサを使うときはどうしても英語のデータシートを拾うしかなかった。STMは日本語訳も用意してくれてたり、PICはそこそこシンプルなのでそもそもあまりデータシートを読み込まなくてもある程度は使えたけど(それでハマることも多かったけど)。
H8Tinyも本当に触りだけ(Lチカ程度は)使ったことがあるけど、開発環境の構築とかが結構面倒で結局全く使わなかった気がする。でも電子工作を本格的に始める切っ掛けはH8系に特殊な開発環境を付属させたキットだったかな。
海外のマイコン(PICやAVR)が普及して以降は、学生の間にマイコンとかを触り始めたようなエンジニアは英語のデータシートを読むしかないから、その人達が仕事として組み込み機器を作るようになると英語があまり敬遠されなくなった、という効果もありそうな気がする。そういう人たちが就職したタイミングでCortex-Mが出てきた、みたいな。
ルネサスも一時期電子工作向けにマイコンを普及させようとしていた気がするし、比較的新しいArduinoにも乗ってるけど、でも日本語データシートのメリットを活かせるほど日本で普及したかというとな。そもそもArduinoは巧妙に隠蔽(抽象化)されているから、これでマイコンに触ったからと言ってデータシートを積極的に読むかというとそうはならん気もするし。チップを普及させたいならSTMのNucleoみたいにそれっぽいボードを用意する程度でも十分な気がする。まあ、ルネサスはそれをやって失敗したわけだけど。
QualcommがArduino買収でエッジAI強化へ：新ボードも発表 - EE Times Japan
Qualcommは「Arduinoは独立したブランドやツール、ミッションを維持しながら、複数の半導体サプライヤーの幅広いマイクロコントローラーとマイクロプロセッサを引き続きサポートする」と述べている。
じゃあ何のために買収したんだよ、という話だしなぁ。そのうちRasPiと競合の層しか出さず結局売れず、みたいな感じになりそうな気もするが。Intel Edisonとかみたいに。
Nvidia Jetsonは10年経った今でも製品の発売が続いてるけど、これは計算能力がちょっと高めの用途で使いたいみたいな部分で人気があるのかな。UNO QもQualcommのある程度計算能力の高いチップを積むんだろうけど。とはいえ例えばハイエンドのSnapdragonを積んでAndroidが走ります、とか言われたって、そんなもん何に使うんだよ、って話だし。
気象衛星ひまわり9号の観測障害 8号での観測に切り替え 気象庁 | NHKニュース | 気象、台風
「今回は衛星のカメラと衛星本体との間の通信に何らかの不具合が起きたとみられていますが、詳しい原因はまだ分かっておらず」
前回は熱管理の問題だったけど、それとはまた別の原因なのかな?
ひまわりっていまいち衛星の詳細がわからないんだよなー。AHIは外国製だから日本語資料も少ないし、そもそもここ10年とか20年の衛星はほとんど情報が出てこないってのもあるけど。
DS2000の資料でAHIの接続にSpWを使っているみたいな感じのことは書いてあるけど。データレートは平均60Mbpsくらいだから、SpWでちょうど良さそうな程度。ほとんど固定レートだから汎用バスを使う利点はあまりないだろうけど、だからといって専用のインターフェースを作るよりはな。
しかしまあ、ミッション機器と通信ができないと言っても原因として考えられる範囲は端から端まで幅広いからなぁ。
ひまわりとGOESって少なくともセンサ(AHI/ABI)のメーカーは同じだし、観測帯域もいくつかは共通だったり、多少の互換性はあるわけだけど、例えばひまわりが予備も含めて全損した場合って、軌道上予備のGOESを借りてくる、みたいなことは可能なんだろうか? アメリカは国土が広いというのもあるので、観測衛星は東西のペアでかつそれぞれにバックアップがいるので、軌道上には予備が2機ある。事務仕事(スロットの管理とか)さえクリアできれば西側の1機をもう少し西に寄せてもらうとかはできそうだが……
ひまわりは日本だけで使っているシステムじゃないし、影響力も非常に大きいから、理想的には軌道上に3機以上を置いて、同時に2機は観測してステレオ視や高頻度観測を実施して、片方が止まっても観測は中断を挟まずに継続して、トラブルが長期化しそうであれば予備機を立ち上げて、みたいに運用するほうがいいんだろうけどな。ひまわり11号以降で純国産化するなら「いよいよやばくなったら最悪GOESを借りて解析に突っ込む」的な運用も難しくなるし、オーストラリアあたりにも呼びかけて軌道上に常時3機おいておくような運用にできないものか。
日本の気象(weather)衛星はひまわりだけだけど、気候(climate)観測を目的としたものとか、あるいは海外のLEO気象衛星も含めれば断続的とはいえ日本周辺を観測できる衛星は色々と飛んでいるし、静止気象衛星が使えなくなったとしても、直ちに気象予報が許容できないほどに劣化するというわけではないんだろうけれども。少なくとも、いくつかの周回衛星は気象庁のモデルに組み込まれているはずだし。だから9号機の設計寿命を超えて10号機の打上げを遅らせようみたいな話も出てくるんだろうし。
GOES-17 - Wikipedia #Malfunctions
GOES搭載ABIでも熱管理のトラブルがあったらしい。推定される原因はループヒートパイプの流れがFODで阻害されたのではないか、とか。ただ、これは純粋に放熱量が減るものだから、ひまわり9号みたいに単発で発生するものとは種類が違うけど。
YouTube、スマホのYTMで音楽聴きながらデスク外で作業して、机に戻ってきてからPCのYouTubeでBGVを再生しようとすると「別の場所でアカウントが使用されています」的なエラーが出てきて再読込しないと駄目なの結構不便。最近のYouTubeは再生位置が残るとはいえ、時々滅茶苦茶な場所に飛ばされることもあるし。何が面倒って再生画面を再読込しなきゃいけないのが面倒。なんで再開できないんだよ。
アカウントを複数人で共有してるわけじゃないんだから、「別の場所で再生してる? うっせぇ！そっちを止めろ！！」的な運用でいいはずなんだけどな。
https://www.jstage.jst.go.jp/article/jie1922/37/5/37_5_280/_pdf
「ガスタービンに関する最近の諸問題」(1958年)
この表題で講演を引き受けたが、問題点が特に思いつかない、とのこと。強いて言えば使用実績が少ないところかな?とか。この頃の実用ガスタービンの例が色々と書いてある。発電用とか、コンプレッサー用とか。
ガスタービンはそれらの要素を作動流体の通路であるダクトと動力伝達を行う軸とで、色々に組み合わせ、結合したものであり、それらの組み合わせ方で色々のサイクルもできまた同一サイクルでも部分負荷性能、回転数特性などきわめて広範囲にかわった性能を持つことを作ることができる。その変化の範囲の広いことは非常なもので、真空管、抵抗、コンデンサ、コイルの組み合わせで全く異なった特性を持った回路を作ることのできる弱電回路とよく対比される。この点はガスタービンの一大特色で、他の原動機がたとえばピストン式内燃機関、蒸気タービンといえばそれぞれかなりはっきりと性能が決まってしまうのと全く異なるところである。
弱電回路は同じ部品をシリーズやパラレルに使って色々組めるのでさすがにそこまで自由度が高い熱サイクルは実用的な意味は無いとしても、まあ、そういうふうに作れないこともないか。
ガスタービンを航空機に使う場合、出力あたりの重さが軽いことと、高高度では空気温度が下がるから圧縮比を高くできる(断熱圧縮でより大きな圧縮比(=温度差)を設定できる)ことから地上用よりも効率が高くなる。
「このように弾道兵器の原動機やごく小型の軽飛行機などを除けば、ほとんどの航空原動機界は内燃タービンの仲間で占めてしまったといってよい。しかし航空用以外にはこのように圧倒的に使用されるというような分野はない」
その他の用途についてもいくつか。冷却水が不要なので砂漠等での発電で使っているとか。
圧縮機やタービンの効率はほとんど限界に達していて、あとはタービン入口温度をいかに高くできるかにかかっている。
ターボプロップとかターボファンとか、エンジンの前にプロペラ(ファン)がついているトラクター式が多くて、プッシャー式ってあんまり見かけない気がする。特にターボファンの場合、コアの中央に低圧シャフトを貫通させなきゃいけないから、構造的にデメリットが大きそうな気がするのだが。
ターボファンの場合、周囲にカウリングがあるから、トラクター式では流れ(特にファンの後ろ)を時間をかけて整流しやすい、という利点があるのかな? 流れをきれいにすればその分効率化や低騒音化が可能になる。
ターボプロップの場合は、コアの中を貫通させているわけではなくて、平行軸にオフセットして、その間で減速させたりするから、コアを貫通するような構造上のデメリットは少なそう。
そういう諸々のバランスを考えると、トラクター式のほうがいいよね、みたいな結論になるんだろうか。
古い資料(80年代中頃)だと中型機の後方(与圧区域より後ろ、ペラ等が飛散しても与圧区画を貫通しない)にプロペラを配置したプッシャー型ターボプロップ機のイラストがあるけど、普及していないところを見るとトータルで大した利点はなかったんだろうな。飛行機の大型化・高速化でターボプロップ機では厳しいというのもあるだろうし(実際には思ったより小型機のレンジが広がらなかった、という感じか)、他にも、より効率を求めるのであれば胴体の後ろに小径のプロペラをつけるより、主翼の上とかに大径のプロペラを付けたほうが燃費がいいだろうし。
特殊な例として、P&W PT6がある。普通は前から吸い込んだ空気を後ろに流しながら圧縮・燃焼・膨張を行って高圧タービン(圧縮機用)や低圧タービン(出力用)を駆動するわけだけど、PT6は後方で空気を吸い込んで前に向かってサイクルを進めて、前方から後ろ向きに排気を出す。この場合、低圧タービンが一番前につくから、最短距離の出力シャフトで伝達できるし、コアを貫通させたり長いシャフトで引き出す必要がない。気流を大きく曲げるからFOD対策にも良さそう(質量の大きな粒子は曲がりきれずにトラップできる)。遠心式圧縮機とかタービンの周りに燃焼器がついているとか、大型化するのは厳しそうなデザインだけど、小型機で使うなら問題ないだろうし、売れてるってことはやはりメリットが大きいんだろうな。
船舶の電動化と同じように航空機でもガスタービンで発電してモーターでプロペラを回そうみたいなシステムもあるし、絶賛開発中だろうから成立する見込みはあるんだろうけど、途中でエネルギー変換を重ねるから効率が悪そうな気はする。小型機で大径ペラをギヤで減速して高効率で回そうとすると機構部の質量が増えるけど、電気を経由すれば比較的簡単に回転数を制御(減速)できるみたいな利点はあるのかな。
航空機だと運動エネルギーが大きいし軽量化の要求が大きいけど、船舶は逆に運動エネルギー(位置エネルギー含め)が大したことなくて、軽量化の要求も小さいわけだから、ガスタービンより原子力のほうが合いそうな領域ではありそう。それこそ小型モジュール炉で発電してモーターで駆動して、とか。アクティブに動く場所が少ないSMRなら故障の可能性も低いから予備電源もかなり小さくていいだろうし。ただ、船舶の場合は遠洋で沈没したりする可能性を考えると、大きな水圧で圧壊しないような構造(適当な差圧を超えると海水を引き込むとか)が必要になるから、陸上用と設計の共通化ができなくて、単価が厳しそうではある。
***
L1Cの相関のテスト
相関値は非正規化なので、高さはあまり意味はない(CPとCDは相対的に比較できるはず)。
C/Aに比べて狭いスペクトルのCP/CDが得られている。
L1CはL1 C/Bと同じように1.023MHzの正弦波を重ね合わせてあるけど、CPは1.023MHzと6.138MHzが適当な割合(1MHzが多い)で乗っている。ただ、今回は1.92Mspsだから、単に1.023MHz100%で近似している。送信出力が同じならCPのほうが相関値が低くなるはずだけど、実際にはCPの方が高い。送信出力の違いかな?
とりあえず、C/Aと同じドップラと思える場所にピークが出ているから、QZSS L1Cの拡散符号は正しく生成できているはず。
拡散符号の生成はソフトウェアで実装すると結構シンプルだけど、これをハードウェアで実装しようとするとかなり面倒くさい気がする。送信側もどうやって変調しているのか気になるな。C/Aみたいにシフトレジスタで作れる符号列じゃないから、ハードウェアでやろうとしたらROMに持っておくくらいしか考えられない。あるいは初期化に100秒以上かけていいなら比較的シンプルに作れそうな気もするけど。
ドップラスキャンで出るスペクトル幅が狭いからスキャンは大変そうだ。どうやって取得するのがいいんだろうか。先にC/Aで受信機の位置・時刻・速度を決めておくとか? なんか本末転倒な気もするけど。
L1Cのスペクトル。縦軸は任意の値。横軸は周波数(MHz)。左右対称なので片側だけ。1.023McpsをNCOでサンプリングレート変換(25Msps)してFFTに通した形。L1C/Aも同じ形のはず。
自己相関のピーク。縦軸は任意の値。横軸はミリ秒。
同様に、L1C BOC(1,1)のスペクトルと自己相関。L1CもL1C/Bもスペクトルや自己相関の形は大して変わらないはず。自己相関は周期が違うけど、チップレートは同じだから、メインローブのエンベロープは似ているはず。
BOC(1,1)はメインローブの±0.5us(±150m)の場所にサイドローブがあるから、綺麗な形のメインローブを期待したアルゴリズムを組んでいると、正常に処理できない。
あと、DLLのEarly/Lateを±0.5chipsに設定していると、相関値のちょうど切れ込みの部分を見ることになるから、特性が悪くなりそう。それに、Sカーブの形も多分想定と違った形になる。BOC(1,1)をDLLでロックしたい場合、±0.25chipsとかの場所を見ないとダメそう。
スキャンしてロックするときも、FFTで探して見つけたピークから±1chips程度の範囲を0.1chips間隔くらいで全部相関値を取って、一番高いピークを探す(サイドローブを棄却する)ような処理も必要になるはず。
簡易的にL1C/Bを受信するならC/Aコードのチップレートを2倍にすれば良いけど、正常に受信したいならかなり大変そうだ。L1CもQZSSから受信したいなら同様。
実際の信号から、FFTで見つけたピーク値の±6chips位の範囲を、適当な間隔で位相をずらしながら相関
なんか変な形。3個連なった高いピークが2つのサイドローブとメインローブだろうけど、サイドローブの高さが結構違う。あと、サイドローブの前にもう一つ山がある。
試しにPRN 4(GPS 3-1)でドップラスキャン
L1C/AもL1Cpも同様にピークが出る(縦軸は任意の値)。
ただ、PRN 4はBOC(1,1)は無いけど、時間軸のデータを見ても、妥当性(納得感)のある結果が得られていない。
デバッグ用に簡単なコードを書いてみたら、全く動かね。。。CDMAの復調ってこんなに大変だったっけェ??
***
C#のRichTextBox、Textを書き換えても字面が似ていればスクロール位置は概ね維持されるんだな。ちょっとずれる時があるけど。元々TextBoxで作っていて、TextBoxはTextを書き換えると一番上までスクロールされるので、それを防ぐのに色々ググってたんだけどやり方が分からず、RichTextBoxならそれっぽい挙動が作れるらしいのでRichTextBoxに変えたら、そもそも何もやらなくてもスクロールを維持できるじゃん、という発見。これだけで丸一日無駄にしたような気がする。。。
ただ、RichTextBoxでも字面が大きく変わるとスクロールが少しずれることがある。それが嫌な場合は、
static Point GetScrollPos (RichTextBox richTextBox )
{
const int EM_GETSCROLLPOS = 0x4DD ;
SendMessage (richTextBox . Handle , EM_GETSCROLLPOS , 0 , out var b );
return b ;
[DllImport ("user32.dll" , CharSet = CharSet . Auto )]
static extern long SendMessage (nint hwnd , int msg , int wp , out Point lp );
}
static void SetScrollPos (RichTextBox richTextBox , Point b )
{
const int EM_SETSCROLLPOS = 0x4DE ;
SendMessage (richTextBox . Handle , EM_SETSCROLLPOS , 0 , ref b );
[DllImport ("user32.dll" , CharSet = CharSet . Auto )]
static extern long SendMessage (nint hwnd , int msg , int wp , ref Point lp );
}
みたいなメソッドを用意して、GetScrollPosで取ったスクロール位置を、Textを書き換えたあとでSetScrollPosに投げれば、スクロール位置をかなり忠実に維持してくれる。ただし描画範囲の前の部分でテキストが書き換えられた場合は、もちろん表示内容自体がズレる。
TextBoxの場合、SendMessageでEM_GETSCROLLPOSを呼んでも正しい結果が得られない。EM_SETSCROLLPOSも期待したとおりに動かない(反応がない)。おそらくRichTextBoxでしか対応していないと思う。ただ、TextBoxに対してもEM_GETRECTみたいな呼び出しは動いているみたいだから、TextBox自体がSendMessage系コマンドに非対応、というわけではないらしい。いまいちよくわからない。
SendMessageみたいに色々な型のポインタを渡すような場合は、DllImportでメソッド内に定義するやつのほうが便利そう。LibraryImportだとメソッド内に定義することができないから同じ名前が大量に出てきて面倒なことになりそう。LibraryImportはunsafe前提だから、むしろポインタで宣言してゴリ押しするという手も……
C#のパターンマッチングのvalue is >= 10 and <= 20みたいな範囲指定の構文、もう少しわかりやすい構文無いものかなー。良い書き方は全く思いつかないけど。value is 10..20とかvalue is not 12.34..56.78みたいな感じとか? そういう書き方がC#的に実装できるかどうかは別として。<や<=は境界値を明示できるのが良さそう。Rangeみたいな書き方は境界値がうまく表現できない。
宇宙船演算子 - Wikipedia
「.NET FrameworkではCompareToメソッド[9]が同じ働きをする」
.NETのCompareToって結果はあくまでも「負数」「ゼロ」「正数」としか規定していないから、宇宙船演算子みたいに例えばswitchでcase -1: break; case 0: break; case 1: break;みたいに分岐できなくて、「同じ働き」とは言えない気がする。最近のC#のswitchだとパターンマッチングで負数、ゼロ、正数にマッチできるから似たような使い方ができないわけじゃないけど。
基本的には-1,0,1を返すことが多いだろうけど、とはいえ例えばintの比較ならreturn value1 - value2;を返してもいいわけだし(キワでバグるけど)、文字列の比較ならC言語のstring.hのstrcmpみたいな結果をそのまま返したっていいわけで、このあたりはライブラリとか実行環境に依存しているから、呼び出す側はあくまでも符号だけ(&ゼロかどうかも)を見るしかない。
実際のところ、機械語レベルまで行けば-1,0,1を比較するのと負数、ゼロ、正数を比較するのでは、後者のほうが楽そうな気もする。厳密に-1,0,1で分岐するには1を足してゼロなら-1、1を引いてゼロなら1、どちらでもなければゼロ、みたいなロジックのはずだけど、負ゼ正で分岐するならゼロに対する比較を行って、ゼロフラグが立っていればゼロ、マイナスフラグが立っていれば負数、そうでなければ正数、みたいに分岐できるはず。CPU依存なので実際どういう処理になるのかはわからないけど。
プログラムで変数を非表示(触るとコンパイルエラー)にするような機能が欲しくなるときがたまにある。例えばint i = 123; Console.WriteLine(i); delete i; Console.WriteLine(i); double i = 123.456;みたいな感じで、適当な構文で変数名を削除すると、その後に読んだり、新しく作ったりするとコンパイルエラーになる(IDE上でもIntelliSenseで見えなくなる)。ちょっと長いメソッド内の最初の方でしか使わない変数が後ろの方で見えるのがウザいときに使ったりとか。そういう場合はメソッドを切り分けろよということで必要ないんだろうけど。
***
2018年頃に俄に話題になっていたような気がする、USB-VGAアダプタを使った送信機、そういえばそんなのあったなぁ、と思ってamazonで探したらドングルが売ってたので、試しに購入してみた。
使っているチップがFL2000という型番なので、これを使ったトランスミッタはfl2kと呼ばれるテクニック。
Windowsからはうまく動かなかった。zadigでドライバを入れ替えるとエラーメッセージが変わるけど、正常動作ではない。
試しにUSBメモリにUbuntuを焼いて、ライブUSBで起動して、ソースコードからビルドしてみると、実行時にUSB周りのエラーが出た。それと一緒にusbfs_memory_mbを書き換えろみたいなメッセージも出たので、それに従って設定を変えたら、ちゃんと動くようになった(メッセージではechoで書き換えろと表示されていたけど、sudo echoではうまく書けなくて、sudo viで書き換えた)。本当に動いているのかはわからないけど、少なくともfl2k_testで50MHzの正弦波が出て、Ctrl-Cで止めれば止まる。
100Mspsで50MHzを出して、イメージが-30dBあたり、というような感じ。
バイアスが0.7Vあたりなのがちょっと謎い。VGAってもう少し低いはずなんだけど(1MΩで受けてるから2倍になったと考えれば、正常かも)。
ということで、Windowsで動かすには工夫が必要そう(or現状動かない)、Ubuntuで動かすなら割と簡単、という結果が得られた。USB 3.0接続で10Msps～150Mspsくらいで出力できるDACとして使えそう。
しかし、Ubuntuかぁ…… Windows側もzadigの設定とかいじる余地はあるから、もしかしたら動くのかもしれないけど。
今回買ったドングルはamazon.co.jpでレビューも多くて、結構数売れてそう。順当に在庫があるなら当面は入手できるかな? はんだ付けは綺麗だけど、底面パッドがスカスカだったり、Dsub mini15の補強端子がはんだ付けされていなかったり、値段なりではある。
今回は手持ちのUSB 2.0のメモリにUbuntuを入れてたけど、結構使いやすかったし、SDカードに入れて持っておくのも良さそう。ノートPCはUSB 3.0対応だけど、USB端子は2個しかなくて余裕がないから、これは開けておきたい。充電対応のType-Cもあるけど、これは電源として使っているから、USBメモリを差すのには不適。バレルジャック経由でも給電できるけど、ACアダプタ使うのメンドクセ……
そういえば、夏頃に中古のノートPCを買ったけど、一通り動作確認してから……とか考えてる間に失念して書いてなかった気がするな。こういうことやろうとするとソフト的に多少壊れても問題ないパソコンが有ると便利。その目的で買ったNUCはSDR用のアダプタに使っちゃってるしな。。。あと、キーボードとかディスプレイとか色々考えずに気軽に使えるノートPCはやっぱり気軽に使える。キーボードやトラックバッドのクセが今まで使っていたものと異なるので使いづらくはあるけど、とはいえ北海道じゃ現物を確認して買うってのも難しい御時世だからねぇ。運試しと思って買うしかない。
ライブUSBって保存領域を設定しない場合は設定やデータが保存されないらしいけど、これって逆に言えば電源ブチ切りとかあるいは起動中にストレージを抜いても問題ない、みたいな使い方ができたりするんだろうか? そういうふうにググってもいまいち情報が出てこない。スピーカーからブチブチ音がする、とかそういう記事ばっかり。ライブCDとかライブDVDなら書き込みができないから明らかに問題ないけど、リムーバブルディスクだとどうなるんだろうか。
UbuntuってSDカードにインストール(ライブUSB的な動作でなく)はできるんだろうか。その状態でSDカードの優先度を上げておいて、カードが入っていればUbuntuが起動、それがなければWindowsが起動、みたいな。
WindowsとUbuntuのデュアルブートに関する記事で、Windowsが入っているドライブを物理的に外してからUbuntuをインストールしたあとでWindowsも接続してBIOSで選択する、みたいな解説もあるから、SDカードの有無で起動OSの選択はできそうな気がする(BIOSからSDカードが見える必要があるけど)。デスクトップPCのHDDならSATAコネクタを抜くだけで切断できるけど、NVMeは着脱がちょっと面倒。ノートPCだと底面パネルを開く手間も増える。
NVMeをカートリッジみたいに気軽に交換できるラップトップとか無いものかな。FrameworkのStorage Expansion Cardが「高速だからOSの起動にも良いよ」(意訳)みたいなことを書いてあるから、これを使って追加のOSをインストールするとか、あるいはカードを交換していろいろなOS環境を交換したりとかもできるんだろうか。Framework Desktopも正面にスロットが2個あるからこれにOSを入れておけばOSを交換できそうだけど、Desktopの拡張スロットは交換が難しそうだ。
あるいはそもそもSDカードとかUSBメモリなら、ISOを焼くときに保存領域を設定しておけばインストール作業不要でそのままOSとして使えるのかな?
