違法無線を自作復調器に通すとノイズが多いの、おそらくSNRが悪いのが原因と思われ。あいつらの出力が低いわけじゃなく、八木アンテナの真上(エレメントの軸上)方向から受信しているのが原因。
FMなので当然周波数復調だけど、スケルチを作るために振幅復調も行う必要がある。スケルチはいくつか手法があるけど、IFを整流検波して適当なLPFに通してから大きさを見るのが一番楽なはず。
有意な変調が無ければ角速度は雑音になので、AFには高周波が出てくるから、AFをHPFに通してしきい値を超えていればAFを絞る、みたいな手法もある。
***
UHFあたりで時刻情報を放送してるヤツ、何かないかなーと探してるけど、いまいちいいのが見当たらない。
時間同期ソリューションとして地デジを使う機器があるらしいけど、カタログスペックは精度500msなので、あんまり精度のいい情報は出してないようだ。TCXOで何ヶ月も維持するよりはマシ、程度かな。通信ならともかく、放送ならそんなものか。GPSとか使わないので便利だよ、と言ってるけど、結局テレビの電波を受信する必要があるので、あんまり優位な気はしないなぁ。建物内にテレビ視聴用の同軸が引き回してあればそれを流用できるから、専用にGPSアンテナを追加するよりは楽に使える、ということだろうか。
地デジ(ワンセグ)、せっかく日本全国の広い範囲で受信できるし、周波数も低すぎず高すぎず、丁度いい高さだし、デジタル変調だからある程度自由にデータ載せれるはずだし、時刻情報とか載せてくれたら便利だったのになぁ。もったいない。まぁ、物陰で受信するには周波数高いし、アンテナ小型化するには周波数高いし、IoT機器のクロックソースみたいな使い方するには中途半端といえば、中途半端な周波数か。1kSy/s弱くらいだから精度もせいぜい10msくらいだろうしな。規格考えてた当時はこんな世の中になるなんて考えてなかっただろうし。「車(移動体)でもフルセグ受信できるじゃん」どころか、「携帯電話サイズでもフルセグ受信できるじゃん」という時代を経て、「携帯通信網で個別に放送を配信できるようにしようぜ」みたいな時代になったもんなぁ。IoTだって時々セルラーつないでデータ送るならその時に時刻合わせもできるし。
VHFだとNHKのFMラジオを受信して時刻同期する方法もあるらしい。正時の時報音を検出するんだそうだ。当然、1時間に1回しか使えない。時刻配信用のマスターとして使うならいいけど、任意のタイミングで時刻を取得するような用途には使えない。
***
とりあえず、試しに地デジの電波を受信してゴリゴリやってみた。
物理ch28(NHK G)の中心周波数(563.142857MHz)を1.015873Mspsで受信。
上が全体のスペクトル。
下段左が8シンボル分のガードインターバルの相関処理。190くらいの場所にピークが出ていて、-120度くらい回転している。1.008msで0.3revの回転だから3kHzくらいの周波数誤差に相当? 5ppmくらいだから、水晶(非TCXO)の受信機ということを考えると妥当性はりそう。ただ、計測できる範囲は-180 - +180度の範囲だから、-120度というのは結構ギリギリ。10ppmもずれていれば補正できなくなるはずなので、本来は別の方法で周波数をある程度修正するのかも。あるいはパイロット信号が見つからなかったら1サイクル分変えて試す、みたいなアルゴリズムとか? チップのメーカーサイトによるとチップにそのあたりの機能も組み込まれているようだから、順当にワンセグチューナとして使うならそのあたりはハードウェア任せでいいのかも。
下段中央が周波数を補正してFFTに通したあとの位相(横軸は周波数軸、縦軸は角度)。左右が雑音状なのはSeg1とSeg2の部分。Seg0の周波数高い側がちょっと回ってしまってる。
下段右がSeg0のシンボルのコンステ。概ねまとまってていい感じなんじゃないだろうか。高周波側のシンボルの影響でちょっと引き伸ばされた形になっている。QPSKの4箇所以外にも2箇所に集まってるのはTMCCとかSCかな?
とりあえず、ワンセグを受信してコンステ見るところまではわりとサクッと動いた。ここからが面倒なんだけど。日本の地上デジタル放送、ほとんど日本でしか使われてないガラパゴスのクセして仕様書の日本語版は有料販売、英語版は無料配布、という謎な扱い。ファイル自体は結構長いけど、後半はガイドラインなので、前半だけザーッと眺めれば良さそう。まぁ、えてしてガイドラインに重要なことがしれっと書いてあったりするのだけど。
***
調べてみると、地デジを使って周波数を補正する(地デジをクロックソースに使う)という提案は結構あちこちであるらしい。フルセグの高周波側のキャリアは固定値BPSKなので、アマチュア無線とかの用途だとこれを受信するのが一番簡単なんだそうだ。ただ、やはり精度良く調整するにはフルセグをデコードするのが一番、とも。
ところで、地デジの精度はどれくらいかというと、規格(STD-B31)としては1Hz以内と定められている。一方、フルノによると0.2Hzと定められているらしい。規格としては1Hz、運用としては0.2Hz、ということかな?
ただし、STD-B31の中に、「影響がないと認められれば500Hzまで可」というようなことが書いてある。田舎だと結構微妙そうだなー。まぁ、「SFNの運用の影響がなければ500Hzまで許可するよ。SFN必要ないような僻地じゃ半年ごとにルビジウム調整するの面倒だよね」みたいな理由だと思うので、GPSベースなら年に何回も調整する苦労とかもないだろうから、概ね1Hzで運用されてるはず。500Hz運用には大臣の許可が必要らしいし、いちいち申請するよりGPS使うほうが楽そう。
あるいは、「0.05W以下なら20kHzまで可」とも書いてある(送信出力ごとにいくつか規定されてる)。フルセグのエリア放送だと130mW以下、エリアワンセグエリア放送だと10mW以下、だそうだから、その際の機器を想定しているんであろう。40ppmくらいだから、TCXOとか、場合によっては水晶だけでも達成できそう。
送信出力を更に下げて、例えば放送範囲が直線距離で50cmくらいであれば微弱無線局扱いで行けるようだし、FPGAでワンセグ放送できそうな気がする。所謂MakeみたいなイベントとかでFPGAボードに接続したUSBカメラをワンセグで放送して50cmくらいの範囲に入るとケータイで視聴できる、みたいな展示やったら面白そう。今の時代ワンセグを受信できるデバイスがどれだけ残ってるかという問題が。。。「ワンセグを放送するFPGAボード」を展示する人と「ワンセグを受信するFPGAボード」を展示する人がいればいいのか。受信ボードの様子を撮影して放送ボードで放送して、それを受信ボードで表示する。錯視やってる人が通りかかってドロステ効果の説明が延々始まるんだ。知ってる。
受信側(フルセグの場合)の周波数は0.3ppmが指定されてるけど、おそらく、送信側に0.3ppmで同期できればいい、という意味であって、受信側にその精度が要求されているわけではないはず(じゃないとTCXOでも厳しい)。送信側で20kHzずれてもいいわけだから、受信側は40kHzくらいなら引き込めるんであろう。とすると、やはりガードインターバルの相関よりも荒い同期方法があるんだろうな。
***
久しぶりにRtlSdrManager(.NETのラッパー)を試してる。思ってた以上に使いづらいなぁ。PCにドングル2本刺さってて、別のプログラム(e.g. rtl_sdr.exe)が1本使っていて、別のドングルをManager経由で使いたい、というときに、かなり困る。一つは、別のプログラムが動いているとデバイスの一覧が取れない、デバイスの一覧がなければデバイスIDが取れないので一意に選択できない。もう一つは、一意に確定しなくてもいいからとにかく開きたい、という場合でも、開くのに失敗する時がある。あとはデバイス閉じるときにメモリの不正アクセスを起こしがちとか。GitHubにソースあるし、プロジェクトにソースまるごと突っ込んでいくつか自分で機能追加する、みたいな感じで使えば良さそう(いや、それならOSSに貢献しろよ、という話だけど)。
RtlSdrManagerを使うと受信中にダイレクトサンプリングに切り替えができるらしい。たぶんちゃんと動いてる。つまり、ダイレクトサンプリングにGPSからの1PPSとかUARTを(レベルをわせて)突っ込んでやれば、コヒーレントに記録できる。最初と最後に受信しておけば、1PPSの位相差と時間差から周波数誤差をかなり細かく追い込めるはず。RtlSdrManagerはlibrtlsdr.dllのラッパーなので、Managerでダイレクトサンプリングに切り替えられるなら、DLL叩いても同じことができるはず。
librtlsdr.cを読むとI2Cで読み書きする関数が定義されてるけど、rtl-sdr.hには定義されていない。librtlsdr.dllからI2C読み書きできたりしないかな? 好きなデータをI2Cに通せるのであれば、外付けのマイコンとの通信ができるようになる。もちろんセンサ等に直接つなぐことも。外部にデバイスを置けるようになれば、例えば衛星追尾のジンバルの制御だったりを、UARTやHIDを使わず、RTL単体で行えるようになる。
しかし、I2C直接読み書きは難しい気がするなぁ。逃げ道がないこともない気がするけど。EEPROM(I2C接続)は自由に読み書きできるんだから、マイコンをEEPROMに偽装するとかすれば良さそう。ただ、EEPROM読み書きの中でちゃんと位置チェック(offset+length<romSize)が入ってるので、EEPROMの範囲外に読み書きしてマイコンで受け取る、みたいなことはできない。例えばデバイス名みたいなUSB接続時だけ読まれそうな場所に何らかのシーケンスを書き込む(e.g. 1秒以内に一連のバイト列を分割して送りつける)みたいなことをやってモードを切り替える、みたいな工夫が必要になる。
rtlsdrブログのドングルだとヘッダにI2C出てるし、rtlsdrブログのブランチならI2C強化されてないかな?と思ったけど、そんなことはなかった。というか、このブランチ、ほとんど更新されてないやんけ。本家のほうがよほど更新されてるんじゃないか。。。
***
最近は進捗無いなぁ。
0 件のコメント:
コメントを投稿