地上-衛星間光通信における大気ゆらぎの影響を克服する次世代誤り訂正符号の伝送に世界で初めて成功｜2025年｜NICT-情報通信研究機構
5G NR LDPCとDVB-S2の組み合わせでフェージングの誤りを訂正。組み合わせるってことは、どちらか片方だけじゃ駄目なんだろうな。S2だってBCHとLDPCの連接符号を使っているわけだし、G5 NR LDPCを使う理由って何なんだろうか。DVBのインターリーブと5Gの誤り訂正、とか?
最近の車のヘッドライトって歩行者を重点的に照らして反対車線の車には強い光を照らさないようなビームパターンになっているけど、比較的狭い場所とか起伏の激しい場所で使う車だと、ブロードなビームパターンが欲しい場合って無いんだろうか。汎用の車両とヘッドライトAssyを交換してブロードなやつをつけるオプションがあっても良さそうだけど、そういうのをつけると公道を走れないとか理由があるのかな?
人間用のヘッドライトを1本欲しいなーと思って物色してるんだけどいまいち良いのが見当たらない。
今まで使っていたPetzlのタクティカがわりあい良かったのでそういう系統のが欲しいけど、Petzlの現行製品はタクティカ(80g級)に比べて100g級と一回り重くなっているし、外観もゴツくなっている。
BlackDiamondのアストロ300は80g級で値段も比較的手頃だけど、白色灯しかないので、いざというときに赤色が欲しくなると困りそうな気がする。これに赤色をつけるとコズモ350という名前になって、値段が2倍になる。
GENTOSはデザインが好きじゃないからなぁ…… あとはPetzlとかBlackDiamondは人間の生死に近い場所で使うブランドだから、低価格帯の製品でもそれなりに品質も高かろう、という期待感があるけど(自分はそんな環境で使うわけではないとはいえ)、GENTOSはあくまでも安価なLEDライトのブランドというイメージ。とはいえ、GENTOSってまともに使ったことはない気がするな。一応日本メーカーだからそこまでひどい品質でもないだろうけど。/* amazonの履歴によるとGENTOS製品は10年くらい前に何個か買ってるらしいけど印象にない */
Petzlのヘッドライトは取扱説明書に変調周波数が明記してあるのが面白い。この周期で動く機械は動いていても動きが見えなくなるから使うときは注意しろよ、という注意書き。PetzlやBlackDiamondは取扱説明書が日本代理店からPDFでダウンロードできて、動作温度範囲がちゃんと明記してあるのが嬉しい。冬の北海道だと場合によっては温度範囲キワで使うことも考えられる。Petzlは欧州(仏)らしく-20℃(-4℉)から+40℃(+104℉)まで、BlackDiamondはアメリカの会社らしく-17℃(0℉)から+43℃(+110℉)まで。Petzlのほうがわずかに寒いところまで耐えて、BlackDiamondのほうが僅かに高い温度まで耐えるが、あくまでも丸めの範囲でしかない。
Energizerのヤツが70g級で白色と赤色が独立したボタンで使いやすそう。デザインもわりかし好み。ただ、あくまでもコンシューマー向けのメーカーな気がするし、信頼性はそこそこかな。普段使いで問題になるようなものじゃないだろうけど。Amazonの商品画像には緑色もあるらしいけど、商品パッケージとかには記載がないのが謎い。外観を見る感じ補助灯がLED2個分ありそうだからR/Gを積んでいそうな気もするが…… /* 購入履歴によるとEnergizerのライトも買ったことあるらしいんだけど、記憶が。。。 */
PetzlのARIA 1 RGBは白色の他にRGB LEDが乗っていて、3色を照射できるらしい。ただ、OFF状態からRedを起動するモードは無くて、WhiteをつけてからRedに切り替える、みたいな操作しかできないはず。常識的に考えて、以前のモードにかかわらず赤で起動する、という機能が無いわけないだろ?と思うんだけど、説明書に明記してないのがなぁ。他の機種でも同様。古い機種の説明書(PDF)にはswitching on & choosing colorという項目でoff or whiteから長押しでredを起動するというモードがあるけど、新しい機種にはwhiteから2秒長押しでredに切り替える、みたいな説明しかないから、OFFからredを起動は難しそう。あるいは、「white」というのはwhite onとwhite offの両方を含んでいる、という意味なのかもしれないけど。
BlackDiamondのコズモ350も、取扱説明書の図を見る限り、OFF状態から確実にredで起動するコマンドはなさそうな気がする。
昔使ってた安物のヘッドランプが1ボタンなのに白/赤の操作性がすごく良くて使いやすかったんだが、なんで安物のヘッドランプでできる操作がブランド物のヘッドライトでできないのか謎い。安物のやつはハードウェアの品質は値段なりだったけど。
Google曰く、うちの周り(田舎の距離感)にもスポーツ用品店は結構数があるらしい。とはいえ、このあたりはスキー場に来る観光客の相手がメインの店だろうから、PetzlとかBlackDiamondとかを一通り在庫している店が一体どれくらいあるだろうか…… 昼間(orナイター)のスキー客相手なら光り物は不要だし、自分で計画して山に入るようなガチのキャンパーなら装備を現地で買うなんて馬鹿なことはやらないだろうし。
YouTubeのレビューとか探せば操作中の動画くらいあるだろ、と思って探しても全然出てこねーし、検索ワードに全く無関係な"YouTuber"が馬鹿騒ぎしてるような動画は大量に「おすすめ」されて出てくるし。YouTubeの"アルゴリズム"ってほんと馬鹿だよなー。せっかく大量の動画コンテンツがあるはずなのに検索システムがクソなせいで死蔵してる。箱開封ASMR風モタモタ雑音Shortsとか誰が見るんだよ。なんでそんな動画しか検索結果に出てこないんだよ。YouTubeは暇つぶしのコンテンツを探すにはいいんだろうけど、特定の情報を探すには向かない感じだなー。YouTubeに限らず、最近のインターネットはそういう傾向なのかもしれないけど。商品名でググって出てくるレビューサイトでも表面的なことは書いてあっても、突っ込んだレビューをやってるところはあまり多くない。結局田舎住みは自分で買って試すしかないのか。。。
Nitecore UT27 MCTは白色2灯で色温度を3段階から選ぶことができて、赤色も搭載。重さも74gとかなり軽量。操作性はちょっと独特だけど、少なくともOFFから赤色を起動できることは明記されている。ただ、比較的高価格帯(9千円弱)なのがネック。
HA11は単3電池1本で38gとかなり軽量で値段も3.2千円と、輝度が低め&ランタイムが短い以外は良さそう。赤色もOFFから起動可能。バンドのNITECOREのロゴがうるさい以外は選択肢として良さそうだが……
Nitecoreはオンラインの取扱説明書のURLがわかりやすくていいな。一つのディレクトリに製品名が小文字でファイル名になっているから、気になる製品があったらとりあえず取説を開いて操作方法を見る、とかができる。試しに10年以上前に買った製品の名前を入れたらちゃんと説明書が見れた。テキストのコピーができないのが不便ではある。メーカー純正の充電池をamazonで探そうとか思ったときに手入力しなきゃいけない。あと、雪山とかは想定していないのか、温度範囲が書かれていない。
https://flashlight.nitecore.com/Uploads/FLASHLIGHTS/download/ha11.pdf
***
とある日の1090MHz
左側のグループは6種類の応答が出ている。右側は4種類。左と右ではドップラが若干違うので、おそらく別の機体。どちらの時間帯もFr24に機影無し。Mode-S応答無し。
左のグループは6個とも同じドップラ特性だから同一のトランスポンダっぽいけど、なかなか謎い。Mode-1,2,3/A,Cの4種類じゃないとすると、Mode-1,2,3/A,B,C,Dとか? そんなアホな……
***
C#からfl2kのDLLを叩いて波形を出せるようになった。構造体の授受とか配列のピン留めあたりでミスってたっぽい。
1280KiB/chのバッファを10Mspsで出力するので、ブロックを7.63Hzで出力、ここに1000サイクルや1100サイクルの正弦波を入れているので、7.63kHzとか8.39kHzの波形が出ている。8bitに対して±64ppの波形なので1/2フルスイング、VGAの信号レベルが0.7Vppで、終端抵抗をつけていないので1.4Vpp、その半分なので0.7V、といったあたりで、実測値もそのあたり。
2chオシロなのでRedとGreenしか見てないけど、おそらくBlueも出せるはず。ということで、3chパラレルの数十Mspsの高速DACとして使える目処は得られた。
手元の環境だと40Mspsあたりまでしか出ない(運が良いと75Mspsあたりまで行けるときもある)。デスクトップPCのフロントパネルの3.0端子なので、なにかボトルネックがあるのかも。underflow_cntに1が入るから何らかのアンダーフローが発生しているんだろうけど、start_txのbuf_numを増やしても改善しないので、別の場所っぽい。
FL2000のI2C読み書きコマンド
オシロはバグで後続パケットがあるとストップコンディションの場所が正しく表示されない。ロジアナだいぶ久しぶりに使った気がする。3月にソフトウェアアップデートが出てた。といっても後続モデルが出ているのでバグフィックス程度だけど。
プログラム上はレジスタアドレス0x12を指定しているが、実際には0x10からの4バイトが読み書きされている。下位2bitはFL2000の中で無視しているっぽい。
ターゲットデバイスはArduino Nano Everyで作ってみた。細かい制御をやろうとすると大変そうだけど、手軽に数バイトを読み書きできるダミーのI2C RAMっぽく作る程度なら結構楽に作れる。
しかしまあ、FL2000のI2C、どういう使い方を想定しているんだろうか。このシーケンスだと24LCxxxの読み書きには使えないはずだが。EDIDとかを想定すると24LCとは別のプロトコルでいいんだろうか? それともFL2000には別のI2Cモードも乗ってるんだろうか。
fl2kで設定できるサンプリングレート
青色(左軸)が設定できるサンプリングレート、橙色(右軸)が設定できる間隔。
数値的には7.777777Mspsから555Mspsまでを設定できる。実質的にはUSB 3.0(内部バス含め)の帯域幅で制限されて、150Mspsあたりが上限らしい。
間隔は狭いところでは1Hzステップで設定できる場所もあるし、場所によっては数MHzくらい空くこともある。
サンプリングレートの自由度があまり高くないので、用途によってはある程度妥協する必要もがある。例えば44.1kspsの整数倍を作ろうとすると、407倍で約17.95Msps(サンプリングレートエラー16Hz)、429倍で18.92Msps(17Hz)、481倍で21.21Msps(19Hz)、1069倍で47.14Msps(-45Hz)、1221倍で53.85Msps(49Hz)、1443倍で63.64Msps(58Hz)、といった選択肢が考えられる。大雑把に1ppm程度のクロックエラーが有る。日本のFMラジオの帯域を想定すると75-100MHzあたりになるので、53.85Mspsならzone3とzone4で全域をカバーできて(zone3/4の折り返し部分は抜ける)、63.64Mspsならzone3で両端を除いた範囲をカバーできる、という感じか。端はカバーできずとも奇数ゾーンだけである程度の範囲をカバーできる1443倍が便利かな? いずれも1280x1024との整数比にはならないから、そのあたりは気にせず。
試しにウイークリービルドの最新版(osmo-fl2k-64bit-20251026)を使ってみたら、fl2k_test.exeを起動すると"libusb: error [winusbx_set_interface_altsetting] SetCurrentAlternateSetting failed: [31] システムに接続されたデバイスが機能していません。"と"Failed to switch interface 0 to altsetting 1, trying to use interface 1"というエラーメッセージが表示されるけど、とはいえ信号はちゃんと出ているっぽい。
付属のDLLを使った場合も同じエラーメッセージが出力されるけど、信号の出力自体は行われている。
DLLは3個付属していて、本体がlibosmo-fl2k.dllで、他にlibusb-1.0.dllとlibwinpthread-1.dllがついている。libwinpthreadのプロパティではバージョンは1.0.0.0固定だがファイルサイズが若干違うのでバイナリは別っぽい。libusbはプロパティで表示されるバージョンも違うし、容量も違う。ただ、libwinpthreadとlibusbは最新版に付属しているものを使って、libosmo-fl2k.dllだけ切り替えた場合、最新版ではエラーメッセージが出るが古いバージョンではエラーメッセージが出ないから、libosmo-fl2k.dll側の問題だと思う。とりあえず、[31]エラーの場合、見かけ以上は波形やI2Cのやり取りには問題なさそう。エラーメッセージが出るのが気持ち悪いなら古いバージョンを使えばいい。
さて、ということでC#からDLLを叩いて複数ch(少なくとも2ch)の波形を出したりI2Cで読み書きしたりが動くようになった。安定して動かそうとするとサンプリングレートを高く設定できないのがネック。このあたりはPCとの相性問題なので定量的な評価は難しそう。せいぜいPCIe拡張カードを使えばUSBチップは比較的自由に設定できるかな、程度か。それにしたってPCIeバスコントローラーの機嫌もあるだろうしなぁ。
fl2kで3chをコヒーレントに数十Mspsで出せるとして、何に使えるかな。
法的な面を考えなきゃいけないから、実際に電波を放射するような用途には使いづらい。なので、例えば3素子のビームフォーミングみたいな使い方はできない。超音波あたりなら出せないことはないとしても。
外付け回路が面倒になる点を許容できるのであれば、GPSのL1, L2, L5を出してマルチバンドGNSSシミュレータとかは作れそうだ。高調波を使うのであればアップコンバージョンも不要だけど、低周波がかなり強く出るからせめて何らかのフィルタ程度は必要になる。先に数十dBのATTを挟んだうえでSAWとかを入れる感じかな? 3バンドを適切に配置できるサンプリングレートがあるかは未確認だけど、1個2000円未満のUSB DACでマルチバンドGNSSのシミュレータが作れたら面白そうだ。ぐぐったら18年頃(fl2kが出た当初)にちらほら記事があるけど、継続的に使っている人はいなさそう。その場合もL1だけで、マルチバンドのシミュレータとして使っている例はなさそう。マルチバンドにしろシングルバンドにしろ、わざわざGNSS信号を生成するような人はちゃんとしたデバイスを使うだろうしな。
ゾーン2とかゾーン3でNTSCやFMを出せばアナログテレビ信号を放送できるけど、今の時代にアナログテレビを復調する機材は入手性が悪そうだ(AirSpy R2で自作するとかも可能ではあるだろうけど)。レトロ家電とかで古いテレビを稼働状態で展示したい人とかは、自由にアナログテレビ信号を出せるfl2kはいいかもしれないけど、そんな人が日本にいったい何人いるか……
もうちょっと高い場所を使うなら地デジ放送(ISDB-T)とかも出せるだろうけど、このあたりまで来るとMPEG-2 TSの構造のほうが難しくなりそう。受信だけならRTL2836系でワンセグ放送は受信できるから、fl2kで出してrtlで受信して、最低限の映像信号だけ飛ばすならわりあい簡単にできそう。市販のテレビで受信できる一番シンプルなMPEG-2 TSってどれくらいのものが必要なんだろうか。さすがにH.264の映像信号にヌルパケットを入れて固定ビットレートで送る、程度で見れることはないだろうから、色々と必要なはずなんだけど。確か"ウルグアイの大学生"がフルスペックのISDB-Tの送受信をやっていたはずだが。
外付け回路で頑張るならIQ信号を出すということも考えられるか。3chのDACが一つのダイに乗っているということは、アナログ特性はかなり近いはずだから、3ch目はバイアス基準のDCを出しておくということもできる。例えば50MspsでIQを出せば100MHz幅近い信号を出して、外付けのアップコンバータで高周波へ移動できるから、帯域幅が非常に広い変調信号を出力できる。アップコンバータを用意するのが手間だけど。
試しにFMステレオ信号を作ってみようと思って、いろいろググりながら、とりあえずゼロIFでIQファイルに書き出してSDR#に入れてみたんだけど、うまくステレオとして認識できない。モノラルだけの信号でも、NFMで復調すれば一応聞こえるけど、WFMだと音量がかなり低くなる。
たぶん主搬送波とパイロットの信号レベルとかいろいろ合わせないと駄目だろうし、一部予想外の挙動をしている部分もあるので、しっかり本腰入れて作業しないとダメぽ。ということで、今回はfl2kがI2C周り含め3chDACとして動くことが確認できたということで良しとして、実際に使う辺りはまた気が向いたら、ということで。
といいつつ、なんかモヤモヤするのでWikipediaを物色
FM broadcasting - Wikipedia #Stereo_FM
それっぽい計算式が書いてあったのでC#でベタ書き。ちゃんとSDR#でFMステレオとして再生できるゼロIF IQファイルが作れた。やっぱWikipediaしか勝たんのよな。
処理の流れとしてはL/R channelをFIRでBPF(含エンファシス・CIC補償)に通したうえで、CIC(N5)で13倍し、NCOでステレオFMへ変調、Re/ImをCIC(N5)で111倍してキャリアを掛けて、IQファイルとして出力。低周波部ではなんだかんだ処理しても、結局は最終段のCICと複素積が一番重い。
CICは積分が入るから無限インパルス応答となって、厳密に言えばウインドウを区切って並列に処理することはできないから、ここの高速化は諦めるしかない。複素積は適当な領域に区切って並列で処理できるから、ここはマルチスレッド化できる。とはいえ、CICが重いことに違いはないので、CICは実軸と虚軸を並列に処理、最後にLoとかける処理は1ブロックずつ並列処理で、結局CICで律速されて、3ブロック同時処理、くらい。で、リリースビルドでは4分30秒くらいのWAVをIQファイルに変換するのに1分10秒くらいかかる。デバッグビルドでも早ければ3分30秒くらいだけど、遅いと4分20秒くらいかかって、確実に等倍速で走ることを期待するのはちょっと難しそう。ちなみに、4分30秒のWAVを約63.64Mspsの2ch8bitで吐き出すと33GB近くになる。SDR#だと最初の30秒程度しか読めない(SDR#は4GiB制限があるので)。
floatで保存すればさすがにスプリアスがゴリゴリに出るけど、u8で保存すれば分解能未満になるので、綺麗なFMステレオのスペクトルになる。
今回は特に理由もなくIQ信号で出しているけど、fl2kで出すなら実軸だけでもいい。虚軸を省いてもCICの計算は両軸が必要だけど、複素積の計算量が半分になるので、計算量が4分の1くらい省略できる。結局CICが一番重い。
IQファイルをC#でlibosmo-fl2k.dll経由でFL2000に与えてみた
FL2000から出したRed信号を同軸ケーブルでオシロまで引っ張って、75Ωの炭素皮膜抵抗で終端しつつ1MΩで受けてる。前に75ΩのBNCの終端抵抗を買った気がするんだけど、どこにしまったっけなぁ…… たぶんRCA-BNCケーブルにつけっぱなしのはずなんだけど、そのケーブルも見当たらないし。
オシロのMeasure、矩形波的な信号を突っ込むとFreqが正しく計測できないらしい。トリガのf=16.3666MHzのほうが正しい値に近い。約63.64Mspsでf16.3MHzを出してゾーン3で80MHzのFM信号を得ている。
試しに広帯域受信機を近づけたら、さすがに離れるとノイズだらけになるけど、同軸線にアンテナをピッタリ添わせたら受信できた。同軸線といってもさすがに真横に這わせたら漏洩する。/* スケルチ全閉にしてもノイズを受信する。この部屋の電波環境どうなってんだ */
試しにCICで高周波段(積分器)を1段ごとにバッファに書き出して、それぞれをスレッドで処理するようなやつを作ってみた。
4分30秒のファイルをデバッグビルドで処理して5分50秒、リリースビルドで2分50秒、くらい。元々の実装では1分10秒だったのが2分50秒になったわけだから、かなり遅くなった。積分器N個+微分器1個のN+1スレッドで動作するし、実軸/虚軸を同時に処理すれば、例えばN3なら6+2スレッドが走ることになる。ただ、実軸/虚軸を直列にしても、並列にしても、処理時間は全く同じだった(デバッグビルドだと誤差程度には早くなる)。つまり計算リソースではなくメモリ帯域幅等で制限されていると考えられる。ウチのPCだとシングルスレッドでCPUのキャッシュで頑張ったほうが良さそう。
そういう事を言い始めると最初から最後までバッファを介さずに全部一気に処理したらだいぶ早くなるんじゃ?という気もするんだけど、さすがに面倒すぎるなぁ。。。
/* そういえば、このときは最終段Loをシングルスレッドで回していたから、ここを変えればもう少し早くなるかも */
***
SDR#のWFMでスペクトル画面の左上に表示される文字列の意味。曰くRDS(Radio Data System)で放送されているコールサインや曲名みたいなテキスト情報をデコードして表示しているとのこと。ランダムな文字列が表示されるから信号レベルとかのステータスかと思ったら、ちゃんとしたテキスト情報なのかな? じゃあRDSって誤り訂正やら誤り検出やら積んでないのかよ、という話だけど。Wikipedia曰くエラー訂正機能があるとのことだから、RDSデータのない信号を突っ込んだ場合はノイズ的なものを受信して非表示になるはずなんだけどな。誤り訂正はおろか誤り検出自体通さずに表示しているのかな?
https://www.jstage.jst.go.jp/article/iteac/2016/0/2016_31C-4/_pdf
2016年。FMラジオ同期放送用のデジタルFM変調器の話。
OCXO校正用に「GPS/QZS/地デジCP信号校正」とのこと。地デジCPって、日本だと最上端の1本しか無いから、校正の精度としてはさほど高くなさそうな気がする。SPを使ったほうが精度が出るはずだけど、CPでいいってことはその程度の精度でいいってことか。
そもそも地デジ信号ってGPSに従属してるわけだから結局GPSを受信するのと大差ないのでは?という気もするが。GPSが止まってもCPで高精度なクロックを供給できるよ、みたいなことなんだろうけど、広域でGPSが止まってるならCPの精度だって悪くなってるだろうし。FMラジオ用のOCXOに比べれば地デジのクロックはさらに精度が高いことを期待しているのかもしれないけど。地デジがRbを使っているならOCXOよりは安定性が高いかな?
0 件のコメント:
コメントを投稿