星のパイロット、続きを書いてるだって!? 海賊は? 転校生は!?
ブループラネットすごく好きなので続き読みたい。
***
井の中の蛙、しかし彼は昼間でも星を見つめることはできるのだ、みたいな作り話を考えてみたり。
井戸とか煙突を通して見上げると昼間でも星が見える、という話、昔調べたときは肯定的な説明が出てきてた気がするけど、改めて調べ直してみると否定的な説明が多い。たぶん見えないんであろう。ブラウン運動で振動する花粉みたいな話だ。昼間でも天体望遠鏡を使えば明るい星は見えるらしいから、うまいこと条件を設定できれば昼間でも星は見えるのかもしれないけど、まぁ普通の煙突や井戸では無理なのであろう。
煙突の先端にマイクロブラックホールを配置したら重力レンズ効果で見えるようになったりしないかな? 焦点距離長そうだなー。普通の重力レンズでも焦点距離数億光年とかだもんな。
***
DJI Action 2、すごいなー。GoProみたいな物理的寸法の互換性とか全く気にししてない感じ。
つい2週間ほど前のエントリで「GoProでかいよね」とか書いてたのに、ウェアラブルカメラが急に小さくなった。もっとも、大きさだけで言えばinsta360 GO 2みたいな製品もあったわけだが。/* GO 2の公式サイトどうしてこんなに見づらいんだ。。。 */
高解像度でここまで小さくなると色々遊びがいがありそう。例えば背面ディスプレイに小さな光学系を組み合わせれば(文字通り)目の前にカメラを設置できるようになる。そしてじゃまにならない大きさで構成できるし、必要であれば左右に2個置いてステレオ撮影もできる。サバゲとか撮影すると、プレイヤーが見ている視界そのままに記録できるようになる。ヘルメットカメラみたいにオフセットしなくて済む。昔はビームスプリッタで光軸を分離しなければ作れなかったようなものが、コンパクトに作れるようになる。
Action 2に電子ビューファインダーみたいな目の直前にカメラを置くようなオプションが出てくると、面白い映像が撮れそうな気がする。カメラが壊れると視界が失われるけど、左右2個配置したカメラが同時に壊れることは稀だろうから、ステレオ撮影でも一応視界の冗長性は確保できている。あとは「安全に気をつけて撮影してください」みたいな注釈つけておけば良いだろう。
もっとも、本当の同軸で撮影する必要がある映像って、実はあんまりないんだろうな。サバゲとかタクトレであればEOTech始め同軸で覗かないと見えない物が多いけど、それ以外では、それほどシビアじゃない。逆に言えば、この手の産業界ではウケるわけで、どっかのメーカーが作りそうではある。既存製品で言うと、例えばTNVCが昔PVS-14/GoPro用にビームスプリッタとマウントのセットを売ってた(ITAR規制されている製品で450USD弱くらい)。Action 2用のマウント/光学系のオプションは、そのうちSurefireとかWilcoxあたりが作りそうな気がする。
***
GRPBのなかでアウロア各地に設置されている、浮いているバルーンライトの妄想。前に考えたときは水素で浮かせつつ、水素と酸素で電気を作って、みたいな感じだったけど、ライムライト復権させればいいんじゃね?と考え中。浮力は水素でなく熱によるもの。中に水素を溜めないので爆発の危険性がかなり減る。
しかしまぁ、発熱を伴う発光ならアークライトとか使えば水素を経由するムダもないし、そんな事言い始めたらLEDで光って電熱線で加熱してもいいんだよな。しかし、そう考えるとアホみたいな発熱量が必要そうな気がするし、とすると水素燃焼でも同程度に発光効率は悪そうだ。/* 電熱線を内蔵したバルーンでググると、20年以上前の技術情報が出てくる。曰くスカイスポーツのリカバリー用として考えていたらしい。いったいどんなエネルギー源を考えていたんだろうか。 */
ドラえもんの道具で、百円ライター1個で飛べる熱気球みたいなのがあったはずだけど、エネルギー保存どうなってるんだろうか。と思ったけど、あれは断熱性があれば(外との熱交換を減らせば)保存則は問題ないのかな。ものすごく断熱性能が高くて軽い材料か。すごく便利そうだ。冷蔵庫や冷暖房機器みたいな、熱を維持するのに消費されるエネルギー使用量が極端に減ることになる。使用温度範囲が広ければ超電導の維持とかも楽になるので、医療関係(MRI等)やエネルギー伝送(超伝導送電)も楽になる。たぶんそういう特殊用途(多少高価でも使用しやすい)で実用化されて、大量生産されて安くなって、スカイスポーツみたいな遊びや趣味の領域でも使われるようになったんだろうな。クオリティチェックで弾かれたやつ(超伝導維持には熱流量が高すぎる等)を遊び用として放出している可能性もあるか。もっとも、熱流束が極めて小さいとして、だからといって最初の加熱がライター1本で足りるかという問題は残るわけだが。家庭用のガスコンロの何倍みたいなオーダーであれだけ加熱しなきゃいけないんだから、足りないだろうなぁ。/* 「MRI 超伝導」でググったら三菱総研(Mitsubishi Research Institute)が出てきた。ここ最近行く先々で三菱に遭遇してる気がする。 */
そういえば、『ふわふわの泉』のふわふわって、断熱性の話題とかって出てたっけ? 記憶にないけど、建材として使っているんだからそれなりの断熱性はありそうだが。序盤で「腕が短いから熱伝導が高い」みたいな話をしていたと思うけど、もう少し大きなスケールでは薄膜の立体構造なわけで、熱伝導はだいぶ悪化してそう。例えば潜水艇の浮力材に使われるような中空ガラスビーズは断熱性もあるわけだが、ふわふわも同じように断熱性はあるんだろうか? もっとも、ふわふわ自体は空気に対する比重が1未満だからそれ単体で浮力を持つわけで、内部に熱風をためて浮力を得る(=断熱効果があると嬉しい)という使い方ではないけれども。
JAXAの高高度気球とか、加熱して浮力稼ぐような方向は行かないのかな? その分のエネルギーをどうやって持っていくんだ、という問題か。宇宙太陽光発電が使えるようになれば外部からエネルギー供給できるし、受ける側は電力としてほしいわけじゃないから、金属線で軽い金網作っておけば電波を受け取ったら勝手に発熱してくれるから、SSPSで高高度気球のペイロード増やしたりとかはできそうだ。宇宙に荷物持っていくのが大変だから気球で頑張りたいのに、それのペイロードを増やすのに宇宙に出なきゃいけないとは。。。
気球を加熱するだけならカーボン練り込んだフィルム使えばいいのか。大気による減衰を受けない強烈な太陽光が加熱してくれる。昼間しか使えないけど、短時間のミッションなら早朝に放球すればいいし、長期間飛ばしたいなら南極付近とかで飛ばせばいいし。フィルムを着色して吸熱を大きくして浮力を増すみたいな方向性はすでにあっても良さそうだけど、少なくともJAXAが運用しているフィルムはほぼ透明だよな。なにかそれができない理由があるんだろうか? それともあの色でも遠赤外線ならガッツリ吸収するから問題ない、みたいなことなんだろうか。あるいは多少温めたところで上空の冷たい環境では無意味だからコスト増になる着色は行わない、という可能性もあるか。
とりあえず熱気球の方向で考えてみようと思って、ためしにヒートガンでゴミ袋に熱風を送ってみた。袋の中が100℃くらい、室温が17℃くらい(共にK熱電対で測定)で、ギリギリ浮力が足りないかな、くらい。勢いをつけてやれば慣性で多少は上昇するけど、あきらかに浮力ではない。中途半端な大きさのゴミ袋使ったからうまく行かないんだろうけど、かなり大変そうだ。風量下げて継続的に500℃近い熱風を送って袋の中が100℃なんだから、熱損失も大きそう。実現したとしても、省エネに真っ向から反する照明器具になりそうだ。
***
en.wikipediaでバルーンライトを調べたら「実質的に日本の行灯を工業化したもの」と説明してあって妙に納得してしまった。最初の特許は1924年のドイツらしいが。本格的に使われたのは1994年にフランスのAirstarという会社が作ったもので、これはヘリウム気球で吊ってたらしい。30年近くも周回遅れで空想してたのか…… 大敗した気分だ。
2000年シドニー五輪の開会式でも使われたらしい。
File:2000 Summer Olympics opening ceremony 1.JPEG - Wikipedia
観客席においてあるやつがそれかな。
画像検索してみると、まさにアウロアに置いてあるやつと同じ。アウロアにあるやつは上半分に反射膜がついているタイプで、より照明器具としての性能を求めたタイプ。Airstar Lunixは一般的にはデザイン的な側面が強そう。それでも高さ7mで直下は155lx、20m離れて6lx、高さ15mで直下34lx、30m離れて3lx、くらいの明るさはあるらしい。
パイレーツ・オブ・カリビアンの撮影風景
アウロアにあるやつそのまま。っていかこれをアセットとして作ったんだろうけども。
***
SIMDゴリゴリ、パフォーマンスの測り方がわからなくてどこに手を加えるべきか判断に迷う。
ループは小さい方がいいんだろうか? ループのブロックが大きくなると命令キャッシュから溢れて遅くなりそう。とはいえマイコンじゃあるまいし、昨今のx86システムじゃ目に見える程度の大きさのブロックなら全部キャッシュに入ってそうな気もする。それよりもデータのキャッシュミスを防ぐほうが有効なんだろうけど、どうしたものか。
整数演算のソフトウェア無線、ビット数の管理が難しい。結構簡単にあふれる。16bit狭すぎ。。。
入力が1+7bit(符号1bit+データ7bit)、続いて利得256倍(8bit)のFIR LPFを通して/3デシメしつつ1+15bitの中間IFになり、1+15bitのローカルでヘテロダイン変換、この際に上位16bit(1+14bit)を取ってきて、32bit幅でCIC処理、CICがR8N5でゲインが15bitなのでCICの出力が1+30bit、これをfloat32でFIRに通して/2デシメ、最初のサンプリングレートが1152kSa/sなので1152/3/8/2=24kSa/sとなり、それが32本分の最終IF信号として得られる(32本は内部処理の都合。実際に使うのは20本分)。最終IFを位相復調して、スケルチ処理を行えば、各chの音声データが得られる。
ヘテロダイン・CIC・FIR・AF復調は1個のスレッドで処理している。CPU使用率5%程度とかなり効率的に実装できた。実際のアプリケーションとしてはグラフィック周りでリソース食ってる感じ。このあたりはGPGPU(というかグラフィックライブラリ)使うとかなり改善しそう。
ヘテロダインへの入力は384kSa/sで、今の所4096ポイント/ブロックで処理している(最終IFは256ポイント/ブロックで出てくる)。384kSa/s / 4096 = 93.75Hzでデータが流れる。ローカル信号は4096x32の大きさで配列を確保し、fLOを93.75Hzの整数倍にすることで、ローカル信号の生成を起動時の1回で済ませている。特小トランシーバは12.5kHz間隔で並んでいるので、周波数精度50Hz程度でも十分足りるはず。422MHzに対して50Hzは0.1PPM程度。受信機(SDRドングル)の精度が1PPM程度だから全く問題ない。特小トランシーバ程度の価格帯なら本体側の誤差も数PPM程度はあるだろうし。
実際には、FMモード・CWモードでの復調を行うために、モード切替時にローカル信号を生成し直している。CWモードではチャンネルを変えると明らかに音程が変わる。数chで周期的に音程が変わるので、送信側ではなく受信側のLOの影響の可能性が高い。
途中、SIMDで実装したし早くなっただろう、と思って走らせてみたら、1コア丸々全部使ってやがる。シングルスレッドじゃ足りないか?と思ってマルチスレッドで走らせても、突っ込んだだけリソース全部喰う。さすがにそんなに遅いわけ無いだろう、と思って、よく考えたら、データがないときはThread.Yield()を通してたんだけど、Yieldって単にコンテキストスイッチ投げるだけなので、他に処理がなければ直ちに戻ってくる。なので使える範囲のリソースを全部使い切ることになる。Thread.Sleep(0)もYieldと似たような感じ。Sleep(1)だとちゃんとCPU使用率が下がる。
遅くて使い物にならないと思っていた別のアルゴリズムも、結局Thread.Yieldが原因だった、というオチ。
教訓：データ待ちはThread.Sleep(1)を使ったほうが良さそう
SIMD、いまいちよくわからん動作をする。var a = func1(v1, v2); var b = func2(a, v3);みたいなコードをvar b = func2(func1(v1, v2), v3);みたいに書き換えると急に2倍位遅くなったりする。順不同の処理の順番を入れ替えても実行速度が数割変わったりとか。おそらくキャッシュヒット率が悪くなったりしてるんだと思うんだけど。賢いコンパイラはそのあたりをうまく処理してくれるんだろう。C#だとJITが担当してるんだろうけど、数値計算に特化したJITとかあるんだろうか? そういう用途ならC++とかFortranを使うべきか。Avx-512対応とか便利機能はC#には無いし。Win10標準の環境で使うなら人間が手を変え品を変え切った張ったで最適化していくしかないのかな。ある程度経験があれば方向性は見えてくるんだろうけども。中間コード見たりすべきなんだろうか? キャッシュヒットとかの話になってくるとIL見ても意味なさそうな気がする。スタックをシーケンシャルに使うかどうかはILでなくC#のレベルで決まるだろうし。
C#のデータ処理ってどんな流れでやるのが良いんだろう? マルチコアとかマルチスレッドとかで探しても、いまいちいい感じの方法が見つからない。同じ処理をパラレルでやったり、個別の処理を別々にやるのではなくて、連続した違う処理をシリアルにやりたい。
今のところは、メモリプールみたいなクラスを作って、それ経由で投げている。具体的には、ConcurrentQueue<T>を2本持って、Alloc, Free, Enqueue, Dequeueを実装している。最初にFreeで確保したメモリを投げ込んでおいて、データを受け渡す際はAllocで確保してEnqueueでキューに突っ込み、別のスレッドはDequeueで受け取ってFreeで返す。Allocで確保できない場合はDequeueで一番古い領域を取ってきてそれを返し、それにも失敗した場合は例外を投げる。DequeueはConcurrentQueue<T>.TryDequeueのラッパーなので、挿入済みのデータがない場合はタスクで適当に待って(Thread.Sleep(1)等)、再びDequeueを呼び出す。
とりあえず、今のところはこの方法で問題なく動いてる。と思う。FreeRTOSのキュー/メモリプールと同じような処理だな。待ち時間とかが無いだけで。
***
新しく作り直している受信ソフト。
見た目がカラフルになった。
一番上の大きいのがIF全体(384kHz幅)のスペクトル、下は左側がそのチャンネルのIF(24kHz)のスペクトル、右がAFのスペクトル。AFの上に出ているdBはデバッグ用のヤツ。
とりあえず簡単にCWモードも実装してみた。といってもローカル周波数を800HzずらしてIFをAFに直結しているだけだけど。まぁ、CWを聞き取る程度には問題ない。FMトランスミッタなのでCWとしては周波数安定度は低く、なんとも変なモールス音が聞こえてくる。ピーという鋭いスペクトルでなく、ポーという感じの音。でも昔の通信機は今みたいな周波数確度はないだろうし、こんな音で聞こえるのが普通だったんだろうな。ローカルが800Hzずれているので、IFのスペクトルもずれて表示される。
今回は描画処理とかはちゃんとUIスレッドでやっているので、安定して動作している。特小20chを全部ワッチする程度に使うのであれば全く問題ない。ただ、rtl-sdrの挙動の問題なのか、それを受け取る処理の問題なのか、過大な信号が入力されると複素信号が壊れるような挙動を示すバグがある。1バイトずれて上下が入れ替わるような感じではなく、上下にスペクトルが2本出ているので、複素信号でなく実数信号として入ってきている感じ。既存のSDRソフトでは過大な信号を入れても、それを除けば直ちに正常な状態に復帰できるから、ドングル(ハードウェアレベル)の問題ではないのだが。今回はrtl_sdr.exeのstdout経由でIQを受け取っているので、そのあたりに問題がありそうな気もする。SIMDを使うなら.NET Coreとか.NET 5が必要になるから、NuGetのSDRライブラリを使ってもいいんだけど、あのライブラリは微妙に使いづらいところがあったような気がする(同時に複数のドングルを使えないとか、終了処理で例外出るとか)。ということで、今回はrtl_sdr.exeを使っている次第。
次はトーンスケルチのデコードかな? あとは録音機能とかもあると嬉しいか。ウチの古いノートPCでも表示できるようにウインドウの大きさが制限されているので、あんまり多機能にすると表示が大変になる。とりあえず右上がだいぶ開いてるのでちょっとした機能を追加するくらいはできるだろうけども。トーンスケルチをデコードしてどれが入っているかの表示くらいなら問題ないはず。ただ、スケルチを指定して開かせるみたいな機能をつけるには場所が足りない気もする。/* ところでウチのノートってAvx-2対応してるんだろうか? 近いうちに確認しておこう。 */
***
ソフトウェア無線、IF以降は数値計算でやるから周波数精度が高いわけだが、例えば12kSa/sを8192ptsでFFTに通すと周波数分解能は1.4Hzくらいになる。で、特小トランシーバの422MHzでは、1m/sで動かすと1.4Hzくらいのドップラーシフトになる。つまり、手で持ってトランシーバと受信機の距離を変えると、電波のドップラーシフトが見えるようになる。計算上はそんな感じの結論になるんだけど、本当にそうなんだろうか? 光速に対するドップラーシフトがそんな簡単に見えるものなんだろうか?
ソフトウェアとしてはかなり簡単な部類(少なくとも同時20chとかは処理しなくていい)だから、実際に試して見る価値はありそうか。まぁ、送受信側の周波数制度足りなくて距離変えなくてもギュインギュイン動き回る、みたいな結論になりそうな気はするけど。
デジタルテレビ放送とか移動体通信に対して「あの規格は高速鉄道では通信できない」とか言われているのを見る限りでは、300km/hくらい(80m/s程度)でもドップラーシフトの影響はかなり大きいわけで、それより1桁低い程度の移動速度でも観測可能な影響は出そうな気もする。
***
ちょっと最近書き溜めすぎてる気がするので今回は早めに放流。なんか今回はコンテンツが薄い気がするなぁ。大丈夫? もっと書き溜めたほうが良くない??
GRBPのメジャーアップデートがきたので次は遅くなるかも。/* アップデートパッチが50GBだって? ふざけるな!! */
1500円くらいでmicroSDにアップデートパッチ入れてハガキで送ってくれるサービスとか無いものか。。。
kindle fire用にPrime Videoのドラマ1シーズンとかをmicroSDで郵送してくれるサービスは面白そうな気がする。700円くらいのmicroSDカード1枚で容量的にはドラマ1シーズン分くらいにちょうど良さそうだし、機械的にデータ突っ込んでハガキや封筒に埋め込んで発送するようなシステムは作れそうだし、パントリーみたいに自分で見たいコンテンツを選んで物理メディアを送ってもらうってシステムは、成立しそうな気はする。ライセンス管理は通信量少ないからオンラインでやればいいし、見終わったらSDカードは自分で使えばいいし、データが入ったままでカードを転売されてもライセンス管理がオンラインだからコンテンツが流出することもないし。オンラインで認証しないと見れないんだから、やろうと思えば未公開分も先に送っておいて、公開したら直ちに認証して見れる、みたいなサービスもできそうだし。やがては「数量限定生産版」とか言ってBlu-rayが付属したり……
まぁ、現実的に考えればKuiperとかになるんだろうけども。
0 件のコメント:
コメントを投稿