最近、Chromeで大きくスクロールしようとしてホイールをグルーっと回しても、少ししかスクロールしなかったり、意図した方向と逆に一瞬スクロールしたりする。明らかにロータリーエンコーダの時間分解能が足りていないような挙動。Razer君さぁ。。。
設計思想としては、ゲーミングマウスだから、アイテム切り替え等で1パルスとかせいぜい5パルス程度しか回さないはずだから、ロータリーエンコーダの時間分解能はそれほど高くなくていい、みたいなことなんだろうな。だから普段遣いでWebブラウジングとかに使うとうまく動かなくなる。いや、ゲームで使うならクリック感弱すぎて1パルス正確に回せないじゃねーか、みたいな問題はあるんだけど。
このマウス、設計思想が理解できない。バグだらけだし、値段は高いし。側面に12ボタン付いている無線マウスという点だけが唯一の利点。側面ボタンが少なくていいなら安いマウスがあるし、有線でいいなら安いマウスでいい。無線で多ボタンとはいえ、バグの影響で動作が安定しないとか、接点が酸化しやすいから時々手入れしなきゃいけないとか、消費電力ヤバいとか、いろいろ。
二酸化炭素消火器でアイスクリームを作れるから、消火器は調理器具。
LEDウォールを使用したフライトシミューレーター。正方形のパネルを並べて多面体を作る謎技術。
https://www.mhi.co.jp/technology/review/pdf/601/601100.pdf
金属AMで通風ダクトのEMPシールドを試作した例。
機械加工で作るには複雑すぎるからAMで作っているけど、とはいえドーム状の形状を造形するためにサポートがかなり必要らしいので、量産品としては厳しそうだなー。AMはせいぜい試作段階で使って、量産する場合はダイキャストみたいな射出成形で作れるようにする感じになるんだろうか。
しかし、ダクトを這い回るスパイたちも大変な時代だな。「クソっ! EMP対策に金属製のグリッドがあちこちに入ってやがる!! これじゃダクトを移動できないじゃないか!」 EMP攻撃から逃げるためにダクトに入るという作戦もできるけど、まあ、ダクトをシールドしてある建物なら部屋の中で十分シールドされてるわな。
空調ダクトの開口部を全部電波的に閉鎖しているわけだから、空調ダクトを電波伝搬経路として使ったりってできないのかな? 取り出す部分はダクトにアンテナを挿入するとかして。10GHz程度まで塞いでるから、例えば5.8GHz帯でパケットをやり取りするような用途で。全反射だから伝搬特性は厳しそうだけど、最近はMIMOみたいにマルチパスを積極的に使うような用途もあるし。反射特性をモニタリングすればダクトの変形やシールドの着脱も見えるはずだから、セキュリティ(耐タンパー性)的な使い方もできるはずだし。
部屋の中の電波がダクトを通って他の部屋に行くこともなくなるから、ドアとかもちゃんとシールドしておけば部屋の中で独立したWiFiやらBluetoothやらを使えるようになるし。LiFiみたいに「目で見て」通信範囲を確認できるわけではないとしても。
だいぶ前から作ろうと思って部品だけ買って放置してるガジェット的なやつ、全く別の方向からビッグテックが似たような用途に使えるガジェットを出してきて、思い立ったが吉日とはよく言ったものだなあと。面白そうなネタは思いついたときにやらないと時代遅れになる。ビッグテックの予算力でゴリ押しされたらオマケ機能でも勝てませんわ。
ある特定の領域だけ見れば用途外使用の向こうは使い勝手悪そうだからこっちのほうが有利かな。中途半端なところまでは試作して、おおよそ実現性の目処が立ったところで飽きて止まってる。好奇心駆動開発はエタりがち。
大きめの氷の中に気泡が入っていると水に入れたときに破裂することがあるけど、あれってもっとド派手にできないのかな? 例えば金属で密封できる形の製氷皿を作って、0.9MPaくらいで中央に気泡を入れて製氷するとか。気泡を中央に寄せるのが面倒そうではあるけど、まあ、どうにかなるはず。
破裂する氷、用途はいまいち思いつかないけど、エンターテイメント分野で使うと楽しそうな気がする。例えば夏のお化け屋敷で入る人に「ドリンクサービス」とかで持たせて、中を歩いている間に手元で破裂するとか。結構面白そうだけど、飲んでる途中で破裂すると危険なのがなあ。キャップで顔に破片等が衝突しないようにしつつ、とはいえ手元で大きな音がしてびっくり、くらいにうまく調整できれば……
ワンセグチューナー3本で取得したフルセグのコンスタレーション(時間方向1フレーム分)
0番から3番までそれぞれ、ドングル1で取得した中央付近、ドングル2で取得した低周波側、ドングル3で取得した高周波側、それぞれで取得したキャリアを合成したフルセグメント、という感じ。
ドングル1とドングル3に比べてドングル2のコンスタレーションはすごく綺麗。
背景を違う色で塗りつぶすと顕著で、ドングル1やドングル3はかなり広い範囲に散らばっているが、ドングル2は64QAMの枠の中でもかなり狭い範囲に固まっている。
おそらくドングル(に乗っているTCXO)の個体差が原因で、sampling clock offsetの影響だと思う。周波数エラーを適切にフィードバックすれば綺麗なコンスタレーションが得られるんだろうけど、今回はSDRで取り込んだIQファイルに対して処理しているので、このあたりで不利になる。
で、前回の「畳み込み符号(ビタビ復調)で訂正できない量のエラー」というのは、なんのことはない、ただのバグだった。まあ、そうだろうよ。だって同じデータを使って前に復調できてるんだもんな。
3本のドングルでフレームの同期が取れていなかったのが直接の原因。その事象の原因は、デバッグ用に作ったサンプルデータが原因。デバッグ用(処理の高速化を目的として前半と後半で処理を分けている)に中間データを保存するときに、フレーム同期前のデータを保存して、それを読み込んで直接使っていたのが原因。
TMCCは1フレーム毎に同期信号が反転されるから、最長1フレーム期間(モード3で約0.23秒)以内の時間ズレは容易に補正できる。適切にフレームを同期して復調させたところ、RS誤り訂正前後で差がゼロ、つまり畳み込み符号ですべての誤りを訂正できた。
ガードインターバルの相関処理とかも全部Complex32でベタ書きしているのでめちゃくちゃ遅い。3フレーム(約0.7秒)分のフルセグを復調するのに50秒くらいかかる。実速度の1/70倍くらい。めちゃくちゃ遅い。処理速度とか何も考えずに書いたコードだとしてもよ。
プロファイラで調べてみると、後処理(デマッピングからエネルギー拡散まで)の、部分受信が0.45%、固定受信が18%で、合わせて18.5%が後処理に要する時間。この内、ビタビ復調で18%を使用している。ただしビタビ復調は1632ビット単位で処理できるから、マルチスレッドでブン回せば数倍くらいは早くなる。前処理(IQファイルの読み込みからデータキャリアの取り出しまで)のうち、大部分の処理は非常に軽量で、前処理の中で2番目に重いTime de-interleavingでも0.16%しか使用していない。一番重い処理はガードインターバルの相関処理で、3本合わせて73%のCPUリソースを使用している。その中でもComplex32の積和周りが非常に重い。バッファリングせず愚直に毎回計算しているから、そりゃ重いのは当たり前なんだけど。
試しにガードインターバルの相関処理を整数演算(総和が楽)でバッファリングできる場所はそうするように書き換えたところ、全体の73%→7.18%へ激減したことを報告しておきます。アルゴリズムの変更つよい……ッ!!! 処理時間も50秒→14秒へ大幅に減った。それに合わせてビタビ復調が18%→68%へ激増している。次はここの改良が必要なんだけど、ビタビは純粋にハミング距離を計算して条件分岐を大量にゴリ押しするコードだから大幅な速度向上が難しい。SIMD化も難しいしなー。マルチコアでゴリ押して多少早くなる、程度しか想像できない。簡単な和差と条件分岐を大量(最大数千程度まで並列化できる)に行う処理だから、GPUとかで回せばめちゃくちゃ早そう。
ガードインターバル相関処理は14秒*0.072=1秒で、これは3本並列で処理できるから、1本あたり0.35秒程度で処理できる。0.7秒より十分に短いから、ガードインターバル処理はリアルタイムで処理できていることになる。フレームの同期やイコライズは処理としてはさほど重い処理ではないから、ワンセグチューナーで受信した約4セグメントのコンスタレーションはリアルタイムで表示が行えるはず。
コンスタレーションの取り出しができれば、コンスタレーションの回転速度をワンセグチューナーにリアルタイムにフィードバックするような処理もできるはず。それができればワンセグチューナーのクロックをTV送信所のクロックに同期できるから、ドングルから28.8MHzを引き出せば長周期で非常に高安定なリファレンスクロックが得られる。
TMCCの変調モードの情報が謎い。モード3の場合はセグメントあたり12bitの多数決でCoherentとDifferentialの情報を送っている。しかし、Cohe/DiffはTMCCの変調方式(DQPSK、QPSK、16QAM、64QAM)とセグメント数を見れば変調モードも決定できるはず。なんでわざわざCohe/Diffを3bit/キャリアも使って送っているんだろう?
本来TMCC informationってフレーム同期後にセグメント形式を識別して等価処理したあとで取り出す想定なんだろうか? Cohe/DiffでTMCCの本数が違うから、そういう可能性もありそう。でもそうすると計算負荷が結構高そう。とはいえ、例えば緊急警報放送を起動するために低消費電力でTMCCを受信するようなシステムならTMCC周りだけ見て等価するとかでもいいのか。そのあたりの受信装置の資料を探すのも手か。
あと、ISDB-Tはセグメント12の上にCPが出ているけど、これも謎い。Cohe/Diffを組み合わせて使う場合、Coheは内側に入るから、周波数軸で一番上のセグメントは外側のCPを使用できなくなる。セグ12だけ外側にCPを置いて特別扱いする必要ってあるんだろうか? あるから置いているんだろうけど。
クレーン等の操作のリモコン。東西南北と上下や緊急停止などいくつかの操作。オプションで誤り訂正機能があって(誤り訂正が有効だと応答速度が少し悪くなるから、安定した環境なら訂正無し(検出だけ)のモードもある)、誤り訂正は差集合巡回符号(202,120)（273,191）とのこと。このリモコンのメーカーはアンリツ系列だったそうで(売却して譲渡)。
差集合巡回符号、古くはアナログテレビの文字放送から、FMラジオのDARCやISDB-TのTMCC/ACまで、あるいはリモコン機器等々、色々な場所で使われている割にググってもほとんど出てこないのが謎い。Design Waveの2002年の記事に関連した話題がちらほら、といった程度。ただ、これはコンテスト用に条件を設定しているし、細かく解説してくれている感もあまりない。少なくとも、畳み込み符号を調べたときよりもはるかに情報量が少ない印象。
https://www.jstage.jst.go.jp/article/itej1978/45/8/45_8_970/_pdf
いくつかの誤り訂正方式の解説。差集合巡回符号の変調器のロジックの図(図5)とかがある。これを参考に(21,11)符号化のプログラムを書いたらなんとなくそれっぽく動いているような感じがある。ただ、図とか本文とかであちこち間違いがありそうな気がする。ちゃんと理解して読んでいるわけじゃないので自分が間違っている可能性も高そうだけど。
https://www.cqpub.co.jp/dwm/contest/2002/dwm48154.pdf
Design Wave 2002の資料。HTMLでも同じ物があるけど、こっちのほうが書籍として形になっている分で読みやすい気がする。
(21,11)の訂正回路(45_8_970ではブラックボックスになっている)を参考にすれば、(21,11)の符号化回路・復号回路(のソフトウェア実装)は作れる。
Cyclic Code - an overview | ScienceDirect Topics
ここにも(273,191)(272,190)のシンドロームの多項式があるけど、45_8_970と数カ所異なる。これもなんか間違ってる可能性がありそうな気が……
とりあえず(21,11)のLFSRを使った符号化・復号と、(273,191)のLFSRを使った符号化、(273,191)のビットシフトでXORを取る復号は動くようになった。ただ、(273,191)のLFSRを使った復号は動いていない。
ARIB STD-B31には(273,191)(184,102)ということと生成多項式しか書かれていないから、本来は生成多項式だけで訂正用のビット列(差集合)とかシンドロームのビット列も作れるはずなんだけど、方法がわからない。B31は放送側の規格だから受信に必要なパラメータは書いてないという可能性もあるけど。
だいぶ脱線してTMCCの誤り訂正とかに手を出してみたものの、とりあえず最低限動くような雰囲気は掴めてきた。パフォーマンスは良くないけど、せいぜい1秒に10回程度しか使わないから、気にするほどでもないはずだし。
しかし、差集合巡回符号、わりと色々なところで使われてるはずなのに、ほとんど情報が出てこないのが謎い。軽くググった感じだと日本語圏のごく一部でしか使われてないんじゃないだろうか。ごく一部というか、アナログTVもFMラジオもデジタルTVも全部NHKが開発したシステムだから、実質NHKしか使っていないという可能性が。。。アンリツは放送機器の機材とかで触ってるだろうから、そこでの経験を元にして流用したって感じだろうし。
ISDB-Tはフルセグをデコードしようとするとワンセグチューナーが3本必要になるからちょっと面倒だけど、ドキュメントは公開されているし、日本全国たいていの場所で受信できるし適当にビットレートが高いし、デジタル変調のデコーダを作って遊ぶにはだいぶオススメ。いちおうFFmpegに突っ込めば(ワンセグ画質とはいえ)ちゃんと映像・音声まで復調できるから、遊びがいがあるし。ドキュメントはARIBからは英語版しか無料配布されていないけど、最近総務省が地デジ高度化の関係でISDB-Tの日本語資料を公開してたし(ちゃんと読んでないけど、おそらくISDB-Tのデコーダを作る上で必要なことは大部分書いてあると思う。参考にするだけでもだいぶ便利そう)。
高度化に移行するとLDPC,BCHとかまたややこしいことになるから、遊びたい人はISDB-Tの放送が終わる前に遊んでおくのがオススメ。ビタビ復号はあんまり最適化しなくてもソフトウェア実装でゴリ押しできるし、RS符号はライブラリを使うなり、興味がある人は自前で書いてもいいし。ISDB-Tは素人でも頑張って頭をひねれば手が届く範囲にある。なんたって規格を作ったのは四半世紀も前だから、現代のパソコンで処理すればリアルタイムは無理でもわりと現実的な速度で処理できる。
C#でbyte[]をint[]とかに変換するやつ、byte[8]をint[2]みたいにするわけじゃなく、byte[2]をint[2]みたいに変換したいんだけど、なにかいい方法ないのかな。結局手軽にやるならforでブン回すとか、パフォーマンス求めるならunsafeとかAvx系を使わなきゃみたいな話になるんだろうか。
https://www.jstage.jst.go.jp/article/sicejl1962/30/11/30_11_989/_pdf
1991年。光カードというデバイス。クレジットカードサイズのプラスチック板にレーザーで情報を書き込み、光学的に読み出す。コンパクトディスクを小さく切り出した感じのデバイス。カード1枚で数MB(フロッピーディスク2枚分前後)を書き込みでき、追記型なので改ざんに強く、磁場や静電気で破壊されない。
現在のICカードがおおよそ数十KB程度までだから、それに比べて2桁くらい容量が大きい。ただし電子的な手法で読み書きができないから、リーダ・ライタがかなり大型。光学的に読み書きするから傷や汚れに弱いという欠点もある。まあ、電気的に読み書きができるカードが出てきたら廃れるよな、みたいな雰囲気はある。半導体が一気に微細化する直前に頑張っていた時代の雰囲気かな。あとは、ネットワークが未発達という時代背景もあるか。
Foretrex 401、寒い場所だとビープ音が鳴らない? -12℃くらいのときに1時間くらい散歩してたら操作時にビープ音が鳴らなくなってた。このくらいの温度だとさすがに液晶もかなり遅くなる。とはいえ使うのに支障がある程度ではない。コントラストも十分。設定画面でコントラストを変更できるけど、デフォルトで支障なし。温度補償回路とか入ってるのかな。
https://www.jstage.jst.go.jp/article/jrsj/36/3/36_36_195/_pdf
特殊環境での圧電アクチュエータの使用について。特に強磁場(5-7T)とか極低温(5K)での動作とか。圧電アクチュエータは物によっては常温用をLN2くらいの温度でも使えるそうだ。ただ、LHeくらいの温度になると圧電素子の温度特性とか、あるいは金属部品との熱膨張の差でうまく動かなかったりするからうまく作らなきゃいけない、と。
サーキュレーターがガタガタうるさいので寝る前に止めたら、翌朝回らなくなってた。寿命かなーと思いつつ、ドライバーを突っ込んで惰性をつければ回り始めた。とはいえやはりガタガタうるさいので、分解。1箇所硬い場所があったけど、モーター部も綺麗に解体できたので、メタル軸受を軽く洗浄してグリスを塗り直して組み立て。スムーズに回るようになった。
'18年7月に買ったやつで、ほぼ5年間、かなりの期間で回しっぱなしだったので、潤滑が飛んでいたんだろう。それで寒い時期に一晩止めたものだから、残った油が固まって回らなくなったと思われ。回していればある程度発熱するから、強制空冷されるとはいえ油が潤滑する程度の熱は残されていたはず。それを一晩冷やしたものだから、とどめになった。
ローターのシャフト側にゴムブッシュみたいなのが入っているのが謎い。なんのために入っているんだろう? 本来、このサーキュレーターは水平から上向き垂直までがエレベーションの範囲。それを下向きにしてシーリングファンみたいに使っているので、ゴムブッシュと軸受が接触して大きな抵抗になっているのは可能性としてありそう。とすると潤滑が飛んだらまたゴムが接触しそうだな。アキシャル方向には結構余裕があるから、金属ワッシャでも入れておいたほうがいいかも?
0 件のコメント:
コメントを投稿