Computer Radio RF Tech

GRCとはgnuradio-companionのことです。グラフィカルなパッチプログラミングにより、お手軽にSDR信号処理の実験や実装が可能です。

GNU Radioについては、こちらでも少し紹介しています。ただ、日本語によるまとまった解説が、Webや雑誌を含め存在しないことを残念に思っていました。どこかで紹介や解説を書かせていただければなー、と思っていました。そんなところに、あのRFワールド誌からお声がけをいただき、O編集長のご尽力により、このような形で記事にしていただくことができました。

SDRのフロントエンドも安価なものが入手しやすくなっています。今回はいろいろ比較した結果、HackRF Oneを使うことにしました。性能のバランスもよく、秋月で購入可能で入手性も良く、オススメです。

特集記事の内容はGNU Radio入門ということで、アマチュア無線にお馴染みのアナログ方式についての変復調をメインに取り上げました。それから、ちょっとだけデジタルもということで、ワンセグの受信とデコードをGNU RadioとRTLドングルで行う方法を紹介しています。GNU Radioはソフトウェアフレームワークなので、ちょっとだけPythonコードの雰囲気や、ブロックの開発についても紹介しています。

あのカンガルー先輩の挿絵も入っていますよ! 

電波の扱いにはくれぐれもご留意ください。

発売は2018/10/29です。ぜひお手にとってご高覧いただければ幸いです。

コメントは是非Amazonレビューにお願いします。

RFワールド No.44 http://www.rf-world.jp/bn/RFW44/RFW44A.shtml

CQ出版社販売ページ https://shop.cqpub.co.jp/hanbai/books/MTR/MTRZ201811.html

当初から使用していたのは、2.2’’と小型のパネルでした。小型ゆえにピクセルの密度が高く少し小さめでした。安価に入手可能なので標準的に使用しています。

CentSDRキットの製作レポートを拝見していると、2.8’’のパネルを使用したモジュールがそのまま使えているとの報告がありました。2.2’’は9ピン、2.8’’は14ピンとピン数は違うのですが、9ピン部分は同じ配列になっているので、そのまま使うことができるということでした。さっそく入手してみると、なかなか良さそうです。基板の縦サイズもほぼ一致していてちょうど良い感じです。

液晶モジュールは横にはみ出ます。

こんな感じでピンが余ります。無接続で問題はありません。

この液晶パネルは安価ながら、タッチパネルとコントローラチップが搭載されていて、上記の余ったピンからSPIで制御することができるようです。これを機能するようにするのも試してみたいと思いました。

もう一つ良いと思ったのが、ノイズレベルの低さです。AM放送の中波帯では液晶パネルを原因とするノイズが少し目立っていたのですが、この液晶ではそれが見当たらないのです。写真下が現在入手可能な2.2’’のタイプですが、無信号で最大ゲインの状態だと、こんな感じでゆらゆらとゆれるスイッチングノイズが見えています。右上の2.2’'は以前入手したものですが、こちらはノイズは見えません。品種が違うようで最近は入手できないようです。

それに対して、左上の2.8'’ではノイズが見当たりません。もしかすると他の周波数帯をよく探せば見つかるかもしれませんが、さっと見た限りでは見当たりません。というわけで、ノイズの点でも2.8’'タイプは現時点でオススメと思います。

続いてもう一つ、2.4’’の液晶を基板裏面に取り付けるバージョンです。今回頒布した2nd lot版の基板の裏面にはこんなパターンを用意してありました。

これは液晶パネルのフレキケーブルを接続するためのパターンです。NanoVNAで使用したのと同じ、2.4''タイプの基板無しパネルのみの液晶用です。まだ試していなかったのですが、今回ようやく取り付けてみました。

基板が無いタイプのモジュールですので、とても薄く仕上がります。10mm程度で納まります。

このパネルには抵抗膜タイプのタッチパネルが付いています。回路側には、このタッチパネルをADCで制御するための用意がしてあります。ですのでやろうと思えばタッチ操作を実装しようと思えば可能です。ただ、操作体系を変更するのは、それなりにソフトウェアの実装に気合が必要なので、実装は時間がかかりそうです。なので現在は操作はできず、USBからコマンドを送っての制御のみです。

タッチ操作を実装できればロータリエンコーダは不要になります。基板をカットできるようにレイアウトしてあります。うまくいけばカードサイズの薄型超小型受信機が作れると思っています。

というわけで、2.2’’, 2.4’’, 2.8’’と3種の液晶をCentSDRで試してみました。実際に動かしてみると、単にサイズだけではなく、いろいろと違いが見えてきます。今後の設計の参考にしたいと思います。

参考

CentSDRのかんたんな紹介です。

ワンボードでシンプル

マイクロコントローラ(STM32F3)によるSDR実装

液晶表示にスペクトラムやウォーターフォール、波形表示が可能

CW,SSB,AM,FMステレオ復調

広帯域でアーキテクチャ

ファームウェアソースはgithubで公開

2回目の頒布にあたり基板を改訂しました。右が旧版、左が新版の基板です。

基板サイズを縮小

拡張コネクタを2列から1列にスピーカ用端子の追加

アルミ電解への変更

取り付け穴のサイズをわずかに拡大し、GNDを出した

USBコネクタの取り付けパタン改善

ロータリエンコーダの論理をActive Lowに変更(LED駆動のため)

配線最適化のためミキサーからADCへQ+/Q-をひっくり返した

裏面は、前回同様ブロック図と、各インターフェースの信号パッドを用意してあります。

その他、実験用にこんな変更、追加もあります。(実際の動作は未対応。お問い合わせ無用です)

I2Sの全二重動作を別クロックで行うための配線追加

別形式のLCD用パターン

あくまで実験用の素材ですのでご了承ください。

前回の頒布は半年前でしたが、参加していただいた方には丁寧なレポートを作成していただいて、とてもありがたかったです。

今回の頒布も、前回同様レポートしてくださる方を対象にしています。前回はブログ記事作成などWebでのレポートを必須としていましたが、今回はツイッターなどのSNSや展示に使っていただける方も対象に広げました。

キットは、フルキットではなく、LCDやロータリエンコーダなど、いくつか追加で部品を用意する必要があります(Si5351Aはキットに含まれています)。案内をよくお読みになってください。

是非チャレンジしていただければと思います。

それから、8/4~5のMakerFaireTokyoで展示出展予定です。こちらもよろしければ是非。

参考

最近のHomebrewでは、GNURadioのformulaが用意されています。しかもバイナリでインストール可能となっているのですぐに使えます。ところが残念ながら、バイナリインストールされるGNURadioは、GUIをサポートしていません。そして残念なことに、gnuradio-companionがディセーブルされていて使えないという問題があります。gnuradio-companionはGNURadioの主要な操作系ですので、これが使えないのは致命的とも言えます。オプションを追加して、gnuradio-companionを使えるよう試みたのですが、ビルドは成功するものの動作させることができませんでした。

以前にもGNURadioをHomebrewでビルドした手順を解説しましたがすでに内容が古くなっていますので、今回また改めてGNURadioの構築手順を整備することにしました。以下その解説です。

GNURadioのインストールには落とし穴が多く、なかなか成功しません。主な理由として、構築に必要なツールの選択肢がいくつもあり、それらを一貫性を持って合わせていく必要があるためです。大きく言語の問題と、GUIツールキットの問題があります。

GNURadioは、C++とPythonを使用しているのですが、まずはC++についてです。

C++コンパイラに、gcc、またはclangという選択肢があります。後者はxcodeの一部として提供されているものです。

C++には言語のバージョンがいくつもあり、一部のモジュールは特定のバージョンを要求します。C++11 を選びます。

標準ライブラリに、newlib, stdlibという選択肢があり、これの不一致はリンク失敗の原因となる。

一方Pythonについても、バージョン問題に加えて、どの実装を使うか問題があります。

Python2とPython3があり、現行バージョンのGNURadioではPython2を使用する必要がある。

Homebrewの場合には、Pythonバイナリを直接リンクするのではなく、dynamic lookupを指定をする。直接リンクしてしまうと、マイナーバージョンの変化にも追従できなくなるためと思われます。

OSXの場合、PythonはOSにもともとインストールされています。しかし、通常の利用ではHomebrewやpyenv、virtualenvなどの方法で後からインストールで追加したPythonを使うことが一般的です。GNURadioの構築でこれらのPythonを混ぜて使うと、実行時にエラーとなってしまいます。そのため、構築の途中で、どのPythonが使われるか留意が必要です。特にOSXにもともと入っているPythonが使用されることがないよう慎重に排除する必要があります。cmakeのモジュール、もしくはPATH変数など、Formulaや各モジュールに数多くのpythonの依存解決の場所があり、これらを一貫させる必要があります。

言語の他にも、GUIについても配慮する必要があります。

WXとQTの2種類のGUIツールキットをサポートしている

QTの現行バージョンは5だが、gnuradioが要求するのは4

QT4は、デフォルトのHomebrewではサポートされていませんが、有志がTapとして提供してくれているので、これを使います。

これらをえいやっと解決して、パッチをまとめてHomebrewのFormulaとして用意しました。https://github.com/ttrftech/homebrew-gnuradio に置いてありますので、tapとして利用することができます。

$ brew tap cartr/qt4 $ brew tap ttrftech/gnuradio $ brew install ttrftech/gnuradio/gnuradio --with-qt

RTL-SDRなど多くのSDRフロントエンドで使うためには、gr-osmosdrが必要となります。同じtapの中に、いくつかのフロントエンドを追加したものを作成しました。

$ brew install ttrftech/gnuradio/gr-osmosdr

バージョンが少し古い(3.7.10.1、最新は3.7.11.2)のと、実行時にいくつかウォーニングが出るのがちょっと気になります。が使えてはいるようです。

今回Homebrewは、Formulaが正しいかチェック(audit)するコマンドがコマンドが用意されています。当初コンパイル成功して動くようになった後、brew auditしてみるとこんな感じでいくつか不具合を指摘されました。以下はpythonのリンクが正しくされていないという指摘の例です。

$ brew audit ttrftech/gnuradio/gnuradio ttrftech/gnuradio/gnuradio: * python modules have explicit framework links These python extension modules were linked directly to a Python framework binary. They should be linked with -undefined dynamic_lookup instead of -lpython or -framework Python. /usr/local/opt/gnuradio/lib/python2.7/site-packages/gnuradio/qtgui/_qtgui_swig.so Error: 1 problem in 1 formula

これをログやソースから調べて問題を解消していきました。何も問題がなければ何も文句を言われなくなります。

$ brew audit ttrftech/gnuradio/gnuradio $

とりあえずGNURadioがGUI付きで使えるようになりました。インストール手順はREADME.mdにも記載しています。もし間違いや動作しないなどの不具合があれば詳しくお知らせください。

いくつかフロントエンドを入手して、GNURadioで使えるよう整備していますので、引き続きこちらも紹介したいと思います。

参考

作成したFormula https://github.com/ttrftech/homebrew-gnuradio

元にしたFormula https://github.com/rixon/homebrew-gnuradio/

以前解説した手順 「 gnuradio 3.7をHomebrewでMac OSXにインストールする」https://ttrftech.tumblr.com/post/72672888223/

計測ですが、SGをPCから制御、CentSDRも同様にPCから制御して、主にチューニング周波数を設定し、計測した電力値を読み取ります。これをスイープしながら自動計測しました。

まずは直線性の結果からです。SGから、-130dBm〜-20dBmの信号を2dBステップで設定しました。周波数は7.5MHzと47.5MHzの二箇所です。CentSDRの周波数応答0Hzの穴を避けるために、1kHzずらしてチューニングしています。

結果をグラフにすると下記のようになりました。周波数の違いで少しずれがありますが、いずれも-120dBm弱から応答があり、およそ-110dB〜-30dBの範囲で直線性が得られています。周波数による偏差はありますが、補正の範囲内です。

直線性は良さそうですので、それでは周波数応答はどうでしょうか。こちらもグラフにしてみました。今度は入力電力を一定として、周波数をスイープさせてプロットします。

入力電力を-80dBmとして500kHzから60MHzまで1MHzステップで、測定値を読み取ります。60MHz は、チューニング可能範囲を超えていますが、どこまでいけるか確認のため上限を超えて振ってみます。結果のプロットが下記です。

低い周波数で少しずれが生じるようです。20MHz以上は、おおむね平坦です。偏差の幅は5dB程度となりました。この程度なら補正が十分可能です。

一方周波数の上限は54MHz程度となり、それ以上では一気に感度がゼロとなります。これは2相クロックを生成している74LVC74が動作しなくなるためです。このときのD-FFへの入力は220MHz程度です。

一方、無入力の場合を確認してみます。-120dBm程度の計測値が得られますが、5MHz以下の部分では、少し持ち上がってます。

10MHz以下について、無入力の場合の応答をみてみます。5MHz以上では-120dBmがフロアですが、5MHz以下では-110dBmから-90dB付近までフロアが上がってきています。このあたりの周波数帯は、おそらくコーデックの動作周波数に近いので、ノイズを拾ってしまうようです。I2Sの接続方法にもうひと工夫が必要かもしれません。

広帯域な種は数特性は確認できましたので、今度は帯域付近の特性を確認してみます。48kHzのサンプリング周波数により、±24kHzの帯域がありますが、その前後を含めてもうすこし広く±40kHzの範囲をプロットしてみます。入力は-50dBmで、CentSDRのチューニングは一定のまま、入力の周波数をスイープします。

そうするとこんな形になりました。デシメーションフィルタの特性が両側の肩の形として見えています。けっこう急峻な特性を持っていることが確認できます。そして注目すべきは中央です。残念な0Hzの穴があります。

帯域内の拡大です。±20kHzで3dB程度下がっているようです。

逆にもっと広い帯域でみてみます。±200kHzだと、すこし離れたところ±100kHzの付近に跳ね返りがあるのがわかります。その内側では-125dBm程度と、減衰極になっているのか、まわりより低いレベルにまで下がっています。

今度は中央0Hzの穴の拡大です。±100Hzの拡大です。ふらつきが大きいので何度か計測して重ねてプロットしています。±40Hzの範囲では10dB以上減衰があることがわかります。

水色のトレースは、条件を変えてあります。キットでは100nFとしていたカップリングキャパシタを1uFに交換して測定したものです。時定数が10倍なので、穴も1/10になっています。特に不都合はみられないので、このくらいの定数とするのが良いかもしれません。

ついでに実験として、192kHzサンプリングの場合の帯域内特性を計測してみました。外側で振幅が下がるのがわかっていましたが、測定してみたら一発です。肩のあたりまで10dB程度も減衰しているのがわかります。グレーのプロットは、48k-spsのトレースを4倍に拡大して対応するように重ねたものです。仕様外の使い方をしているので仕方のないことなのですが、せっかく使えることがわかったので、なんとか活用したいところです。

ちなみに今回の計測は、Pythonでスクリプトを書いて、SGとCentSDRはシリアル経由で制御、ならびに測定値の読み取りを行いました。また、測定結果は、matplotlibでグラフ化しています。すべての作業はJupyter notebookで行っています。Jupyter notebookは作業とメモが同時に行えるのは大変便利です。

FM放送は150kHz程度の帯域幅があるので、もともとfs=48kHzで動作させているCentSDRでは、FM放送は当初は対象外と考えていました。

一方、TLV320AIC3204のチップそのものは192kHz動作をサポートしており、いつかは実験してみたいと思っていました。そのときの想定ではADCは192kHzで動作させて広い帯域幅を利用し、他方オーディオの再生では高いサンプリング周波数は無駄なので、DACは48kHzで動作させることを考えていました。すなわち信号処理において復調処理の過程でダウンサンプリングも行う、すなわちマルチレート処理とするのが、まっとうなプランと考えていました。そのためには若干回路側に改良が必要で、次の版で実験する想定でした。

ところが、いろいろと実験をしていると、HF帯域の中に、邪魔な幅広いノイズが散見されます。その原因がFM放送でした。というのもアナログスイッチをミキサーとして使用している原理上、奇数倍の周波数に感度を持ちます。たとえば、82.5MHzの放送であれば、その1/3である27.5MHzにチューニングすることで信号が入ります。FMモードの復調は実装済みだったので、チューニングしてみると、ほとんどノイズですが、たまに音声がわかるという感じでした。

このノイズだらけの音を聞いていたら、マルチレートの実装にしなくても、全体をえいやっと192kHzで動作させてしまえばイケるかも、と思いついてしばらく試行錯誤してみました。

その過程でわかったのは、TLV320AIC3204はADCを192kHz動作させたとしても、チップの想定する仕様では、デシメーションフィルタの特性で帯域が制限されてしまうということでした。デシメーションフィルタはA,B,Cの3種類用意されており、192Hz動作ではCを選択することが想定されているようです。Cのフィルタは下記のように0.2 x fsの通過帯域しかなく、192kHzで動作させたとしても帯域は±38kHzが上限となってしまいます。

音声アプリケーションであればこれは望ましい特性かもしれませんが、SDRとしてはせっかく192kHzで動作させている意味がありません。

こちらは48kHz、96kHzのときに選べるタイプA、タイプBのフィルタ特性です。理論いっぱいの0.5 x fsまで応答があるのがわかります。

これがわかって、FM放送受信は半ばあきらめかけたのですが、往生際悪くしばらく、オーバーサンプリングの分周比や、DAC側のデシメーションの負荷を下げるための設定パターンなど、いろいろと試行錯誤してみたところ、なんと192kHz動作で広帯域の応答が得られる設定を見つけることができました。使えるフィルタはBタイプです。

これで動かしてみたところ、ちゃんとFM放送がそれなりに受信することができるようになりました。下の動画ではちゃんと音になっているのがわかります。(まだデエンファシスは入っていないため高音がかなり強調された状態です)

192kHzサンプリング動くようになった pic.twitter.com/NYS5LZ1HV3

— TT@北海道 (@edy555)

2018年1月29日

その後、実装の調整をいろいろしており、かなり改善できたと思います。スペクトラムの表示は30fps近く出ており、音楽に合わせてダイナミックにスペクトラムが飛び跳ねるのは、飽きずいくらでも眺めていられます。

ステレオの再生にもチャレンジしています。実装はLPC-Link2でやったFM受信機からの流用です。すこし調整が必要でしたが、パイロット信号のPLLを動作させることができ、一応ステレオにはなりました。が、ノイズが著しく増えてしまいます。原因ですが、おそらく受信帯域の特性がフラットではなく、両側が丸くなだらかに下がっていることがわかっており。このあたりに含まれる副搬送波38kHz付近の成分が劣化しているのだと予想しています。この肩の減衰を補償する処理を追加することを考えています。なんとか、まともなステレオ再生を実現したいと思っています。

もう一つ問題があります。動作中にサンプリングレートを切り替えると、I2SとDMAの関係か、どこかでデータがずれるらしく、IQがひっくり返ったり(症状としては、逆サイドが対称に出たり左右逆になったりする)、バイトがずれるのか全く音にならなくなったりします。何度か切り替えると正常になったりします。これもうまい制御がないか、方法をさぐっているのですが、まだ解が見つかっていません。

もうひとつ本質的な限界は、0Hzの穴です。受信帯域の中央に十数Hz幅の穴が空いており、これがノイズや歪みの原因になります。なので決して高音質にはなりませんので、あくまで実験としてご理解ください。

ところで本日は関西ハムフェスティバルが開催されたそうで、今回キットにチャレンジしていただいたPUPさん、北神電子サービスさん、JL1VNQさんがCentSDRを展示してくださったとのことです。来場者の方で興味を持ってくださった方がいらっしゃったとのことで、ありがたい限りです。貴重な機会をCentSDRに割いていただいたことに御礼申し上げます。

リンク

TLV320AIC3204 Application Reference Guide - Texas Instruments http://www.ti.com/lit/ml/slaa557/slaa557.pdf

Interface 2015年7月号 オール・ソフトウェア無線http://www.kumikomi.net/interface/contents/201507.php

CentSDR関連記事 http://ttrftech.tumblr.com/tagged/CentSDR

CentSDR頒布ページ http://ttrftech.tumblr.com/kit/centsdr

CentSDRキット組み立てレポートまとめ https://togetter.com/li/1191867

関西ハムシンポジウム　２０１８

PUPさんのレポート http://pup.doorblog.jp/archives/51496704.html

JL1VNQさんのレポート http://jl1vnq.blogspot.jp/2018/02/2018_5.html

背景として、CentSDRにSメータを付けていないことが無いことが気になっていました。どうせならと、代わりにパワーメータとしてみたわけです。値付をしたのでちゃんと電力の表示となっています。測定の種類としては、全電力ではなく、帯域内の電力、すなわち選択レベル計となっているわけです。

測定原理ですが、1フレーム1ms分のサンプル列の波形からRMS (Root Mean Square)を計算しており、これが電力に相当します。ADCで取得したサンプルから計算しますので、対象となるのは帯域内の成分だけです。48kHzでサンプリングしていますので、中心周波数から前後24kHzの内側にある成分のみが測定対象です。帯域外の成分は、ADC内のフィルタで除去されています。

ADCの前にPGAでアンプされているのですが、このゲインはAGCで制御されており、そのゲインはチップから取得することができます。フロントエンドにもアンプが入っていますがこれはゲイン24dB固定です。

計算で得たRMSは真数(リニア)なので、対数(ログ)を取ってdBに変換します。そこから、手前のゲイン分だけ差し引けば受信機に入力された電力となるわけです。

実際には校正として、レベルがわかっているSGの信号を入れて値付をしています。あとは直線性の範囲内で、それなりに正確な計測値が得られているようです(今度グラフを出してみます)。試した範囲だと、-110dBmから-30dBmを超えるところまで直線性が得られているようです。

計測値は、ディスプレイの2段目にdBm単位で計測値を表示するようにしてみました。フォントを用意していないので、画面ではmの無いdBの表示ですが、実際にはdBmです。AGCを有効とした場合だけ、入力電力を表示するようにしています。AGCが無効の場合はゲインをマニュアル設定しますので、ゲイン表示を優先し、電力表示されません。

さきほどの写真と同じシチュエーションで、NHK第二 747kHzを受信してみます。こちらは-32dBm程度となっています。なんと1µWもの入力電力があります。

現在地から北東方向11キロほどに、NHKの中波送信所があって、NHK第一は100kW、そしてNHK第二は500kWの出力(東日本をカバーする中波放送で最大出力の送信所)です。第一と第二では、5倍すなわち7dBの差がありますので、数値の差とだいたいあっています。

7MHzでアンテナをつないだ状態だとこんな感じです。-80dBm前後を示します。なにも聞こえている局が無い状態でほとんどが外来ノイズです。

アンテナを外してみると、ノイズが減り、AGCが効いてフルゲインになります。この状態で-120dBm前後を示します。フロントのアンプBGA2817は、NF=3.9dBなので、HF帯には必要十分です。

測定値は画面だけではなく、USB経由で得られます。USB CDC=シリアルとして見えますので、各種コマンドを使うことができます。

ch> power -88.8dBm

AGCをオフにすると、受信電力の表示の代わりに、マニュアルゲインの設定のための欄になります(アンテナマークが付いて、色が黄色になります)。

このパワーメータには欠点もありまして、第一には受信帯域内で特性がフラットではないことです。±24kHzの両端近くでは-5dB程度下がっており、また中央付近には数10Hz幅の穴があり、中心は無応答です。両端の低下はΣΔADCの弟子メーションフィルタの肩の特性が出ています。中心の穴は、ADC手前でDCカットされていることが原因です。これらのことから、正確な値付をしようとする場合には、目的の信号を、中央からのオフセット数kHzの付近にくるようチューニングする必要があります。実用上は、信号はスペクトラムでいつでも見えていますので、チューニングは容易に可能です。

ダイナミックレンジについてですが、SGからの入力レベルを上げて-20dB付近になると、だんだん測定値が小さめに表示されるようになります。これはおそらくフロントの固定ゲインアンプの飽和などが原因かもしれません。測定範囲を拡大するには、ここも可変ゲインにするか、切り替えでアッテネータを入れるかですが、現時点ではシンプルさを選びたいと考えています。

さて、キットの頒布を開始しましたが、ファームウェアにはもう少し手を入れようと思っています。すくなくとも、チャネルの設定と、フラッシュメモリへの保存ができるようにしようと考えています。これが一段落したら、バイナリファイルでの頒布を行う予定です。もう少々お待ちください。ソースはgithubに常時pushしていますので、こちらを利用することも可能です。

リンク

CentSDR頒布ページ

CentSDR関連ページ

このブログで試作の様子を紹介してきたスタンドアロンSDR受信機CentSDRのキットです。主要な半導体、基板、CRとコネクタをセットにしたセミキットです。完成には、LCDやロータリエンコーダなどいくつか追加で部品を用意する必要があります(通販で購入可能です)。そして、ファームウェアの書き込みのためのアダプタの用意が必要です。詳細は掲載の資料をご覧ください。

改めて少し解説です。

特徴

手のひらサイズ、スタンドアロンのソフトウェア受信機(SDR)です。

小型液晶(2.2インチ)に、周波数やモード、スペクトラムや波形などを表示します

すべての操作をロータリーエンコーダ一つで行います

PLLシンセサイザにより≈1Hzの周波数解像度で設定可能です

広帯域構成により特性がフラットで回路がシンプルです

USB(CDC=シリアル)経由でコントロールが可能です

仕様

基板：57.8mm x 87.3mm (コネクタ、スイッチを含まず)

周波数：0.1 〜 50MHz

ディスプレイ：320x240ピクセル

電源：USB 5V 100mA

対応モード: LSB, USB, AM, (NFM)

USBインターフェース：CDC(シリアル)

構成

動作原理

クロックジェネレータチップSi5351AをI2Cで制御し、受信周波数の4倍のローカル信号を生成します

74LVC74によるJohnson Counterで2相クロックを得ます

アナログスイッチSPDT二つを2相クロックで切り替え、I/QのIF信号を得ます

一次LPFでフィルタ後、TLV320AIC3204に入力します

ΣΔ方式によるA/D変換で48kHzで16bit 2chのデジタル信号とします

I2SでMCUに入力します

信号処理により復調を行います

復調されたオーディオ信号をI2SでTLV320AIC3204に出力します(全二重動作)

TLV320AIC3204はD/A変換を行いアナログ信号を出力します(2ch)

ポイント

アナログスイッチをミキサに使うことで歪みが小さい

サンプリング周波数は48kHzですが、ΣΔ方式のADCであるため折り返し歪みが256fs=12.576MHz離れるため一次のLPFで十分に低減可能です

クリスタルは26MHzのVCTCXOを使用し温度補償タイプのため安定です。周波数微調整をMCUのDACで行いますのでHz以下の精度です

シングルクリスタルです。Si5351AでADC、MCU用のクロックも生成しています(8MHz)

アナログスイッチによるミキサのためLoの奇数倍の周波数にも感度があります。これが妨害となる場合には、入力にLPFが必要です(例えばFM放送など) 一方これを積極的に利用してBPFを挿入しVHF帯の受信機として利用することも可能です

小型MCUの処理能力のおかげで、この程度のハードウェアでSDR受信機が構成できてしまうのは面白いことではないかと考えています。ソフトウェアは少々荒削りですが、改良の余地があるともいえますので、ぜひパッチを送って(またはgithubでpull requestして)ください。

キット頒布の準備を始めたのは数ヶ月も前なのですが、諸事情からご案内ができるようになるまで時間がかかってしまいました。

今回の頒布はWebでレポートを公開してくださる方を対象にしたいと思います(qiitaでもnoteでもgistでもなんでも結構です)。頒布のページからリンクさせていただたいと考えておりますので、ご理解ください。

それと若手を優待すべく学割も用意いたしました。

それではチャレンジをお待ちしております。

リンク

CentSDR頒布ページ

CentSDR関連ページ

深圳市で開催されるMaker Faireとしては4回目。主催はSeeedStudio、そして柴火創客というハッカースペースです。今年は深圳職業技術学院の学校敷地内で催されました。屋外にテントを張っての開放的な展示です。日本からの展示も多く来ていました。

学校での開催ということもあってか、訪れる見学客は若い方、しかも女の子が多い印象です。日本からの出展はおじさんが多いことと対照的でした。

今回は金沢大学の秋田先生のMakeLSIが出展されるということで、前にMakeLSIに参加して作ったリングオシレータも一緒に展示ということで混ぜてもらいました。メンバーは学生4人と一緒です。

リングオシレータの出力(35MHz前後)を、自作受信機(CentSDR)でスペクトラム表示している様子です。FM復調できるように受信機を改造していったのですがその説明は無し。

会場で見かけた、RF的におっと思った展示がこちら。

キャビティのBPFを、ロボットでネジを回して調整するという展示です。

初日は稼働していなかったのですが、翌日からは機材が設置されて動作していました。横にネットアナが置いてあります(wktk)。

ネットワークアナライザ(Keysight E5061B)でBPFを自動測定して、

その結果から、自作のソフトウェアのAIでロボットを稼働して調整という展示です。見にくいですが画面下にネジの位置が表示されています。

展示の趣旨は、製造現場に必要な熟練作業を機械に置き換えるということでした。その例として、キャビティBPFを使ったということのようです。この選択は、なかなかやるなって感じでした。たしかに、BPFの調整は科学ではなく職人技能の世界と言われるくらいですし、調整のフィードバックループを回しやすいので面白い題材です。

展示されていたのはRFエンジニアの方で、お話を伺うと日本の某部品メーカーで働いていたことがあるそうです。MakerFaireでVNAを見かけるとは思いませんでした。展示はしていなかったのですが、NanoVNAを持参していたのでその場で見せて自慢してきました。

別のブースに、無線モジュールをメインの展示がありました。

そのアンテナ。

話を聞くことができませんでしたが、IR-Boxというおそらくは赤外線リモコンの展示がありました。SIMと一緒に置いてあるので、ちゃんと通信回線も統合されているのかもしれません。

あとは、ワイヤレス給電の展示。大きなコイルでワイヤレス電力伝送して、電球やLEDを光らせたり、

磁気浮上(Magnetic Levitation)と組み合わせて、浮いたオブジェを光らせたりしていました。

今回は日程の都合もあり、深圳の見学ツアーには参加できませんでした。その代わり、会期中にあった日本からの見学者のパーティーには参加。100人以上が集まったそうです。現場はカオスでした。

こちらはネコミミで有名な高須さんに、ElecrowのJarvanとDavid。

Elecrowのツイッター@Elecrow1はJarvanがやっているみたいです。

@edy555 It is great to see you in the Japanese maker party.😀😀😀 pic.twitter.com/mjrVN7VZTm

— Elecrow (@Elecrow1) 2017年11月11日

ちょっとだけ華強北(ファーチャンベイ)の電子城も見てきました。店のブースの中で手工業生産が行われ、その場で世界中から注文を受け、出荷作業をし、

同時にその場で子育ても行われていました。ある意味英才教育なわけです。

あともう一点、今回のMFSZ2017では、MakeLSIがブルーリボンを受賞しました。面白い取り組みとして評価していただけたようです。Congrats!

今回は移動に香港エクスプレスを使ってみました。成田香港往復で1.8万円ちょいでした。気軽に出かけられるお値段ですね。(私の場合はさらに北海道往復があるのですが)

上は受信モードをLSBにして、SGから7.099MHz -80dBmの信号を入れ、7.100MHzを受信した様子です。90度位相のずれた正弦波が表示されているのがわかります。波形の横軸は1ms/divです。復調信号は1kHzなので、正弦波の周期がちゃんと1msになっています。スペクトラムでシングルトーンなので、当然ながら波形も正弦波なわけです。チューニングをずらすと波形も変わります。IQ信号なので、たとえば7.101MHzにすると、正と負の周波数で位相の関係が入れ替わるのがわかります。

ちなみにスペクトラムの縦軸は1ピクセル1dBで64ピクセル分、10dB/divにしてあります。狭いですが64dB分のレンジがあります。計算なので相対強度は正確です。

さて、実際のAM放送の信号処理過程を見てみます。制約としてコーデックチップのAD変換でDC成分を取り込むことができないため、AM放送の受信では周波数をずらしてサンプリングをおこなっています。もしぴったりに合わせてしまうと、キャリアが0Hz=DCになって成分が消えてしまい復調に不都合が生じるのです。そのため、AM放送の8kHz程度の帯域をカバーすることを想定して10kHzずらしてサンプリングを行ったあと、数値的に周波数シフト(回転演算)しています。この過程を、波形とスペクトラムでみてみます。

まず576kHz NHK第一を受信した様子です。スペクトラムで赤いマーカーがチューンした周波数で、中心からかなり右にずれています。

波形は、周波数が高めの信号を含むので、塗りつぶされたような感じになっています。このへんはデジタルオシロと同じです。

試しにすこし周波数をずらしてキャリアの周波数を下げてみると、ちゃんと波になっているのがわかります。IQの位相がずれているのもわかります。

さて、サンプリングされた信号を、信号処理により10kHz下げるとこのようになります。

キャリアが中央に位置、すなわちDCとなります。波形でみると、大きくゆっくりと波打ちます。DCとはいえ1Hz程度の周波数ずれがあるので、その成分が波形のゆらぎとして見えているわけです。

次は、LPFに通します。fc=8kHz Biquadのチェビシェフ6次IIR LPFです。0Hzを中心として両方の外側の成分を削ぎ落とすのですが、スペクトラムだとその様子が一目でわかります。波形も、ギザついていたのが滑らかになっています。

最後にオーディオ信号です。振幅を計算しているだけです。実信号なので、スペクトラムの0Hzは中央ではなく左側です。波形も片側だけです。

このように並べて表示することで、波形とスペクトラムの対応関係、そして各段の信号を観察できることで、信号処理の過程が感覚的にわかるようになるのではないでしょうか。

最後に動画です。

リアルタイムで復調した音を聴きながら、波形とスペクトラムを眺められるのが実に面白いと思います。それがこんな簡単なハードウェア構成＋ソフトウェアで実現できています。

波形表示では、ウォーターフォールに比べて表示更新レートが下がっています。半分程度の10FPS弱程度となり、ちょっと表示のダイナミックさが減ってしまっています。表示更新しなければならないピクセル数が増えるので仕方ないところです。(ウォーターフォールでは1ライン分の更新で済むが、波形は全部更新することが必要。88倍に増加)

上の写真はアンテナを接続せず無信号の状態でサンプリングした信号のスペクトラムを表示したものです。無信号にもかかわらず、中央に信号が見えています。内部のSSB復調信号処理の都合上、1.3kHzずれた位置に見えているのですが、ADCから取り込んだ時点では0HzすなわちDC成分です。サンプル値に常に0からのずれが残っている状態となっているわけです。

復調後のオーディオ信号のスペクトラムが下記です。こちらでも0Hzに応答が見えています。

このDCオフセットはADC由来です。本来無信号であればゼロとなってほしいのはずですが、どうしてもさまざまな要因からオフセットが生じてしまいます。無用な成分ですので消してしまうことが望ましい。対策は、DC=0Hzを通さないフィルタ、すなわちHPFを入れることになります。カットオフ周波数は、数Hz程度となるようにします。

HPFを実装する具体的方法ですが、使用しているCodecチップTLV320AIC3204にはDSPブロックが含まれていますので、かなりの自由度でデジタルフィルタを入れることができます。Codec内部のDSPを使うことで、MPUのサイクルを消費せずに済むわけです。下記に基本構成の場合のブロック図を示します。この構成の他にもFIRやIIRなど、さまざまなパターンが用意されています。詳しくはリファレンスガイドをご覧ください。

この図中の”1st Order IIR”が、ADCのDCオフセットを削除するために設けられたフィルタブロックです。DCオフセット削減程度の処理であれば緩い特性でOKですので、1次のIIRで十分というわけです。ここに適切な係数を与えてやればお望みのフィルタ特性が得られます。

このHPF用の係数を設計します。いつものJupyter notebookでやってみます。まずは準備として下記をインポートしておきます。

%matplotlib inline import pylab as pl import numpy as np from scipy import signal

scipy.signalのiirfilter関数を使って、1次のIIRフィルタを、High Pass Filterとして設計します。カットオフ周波数は適当に0.0001と指定していますが、これはナイキスト周波数に対して0.0001、すなわちサンプリング周波数48kHzの場合、ナイキスト周波数は24kHzなので、カットオフは2.4Hzということです。

この周波数特性を確認してみます。両対数グラフにプロットを示します。ちゃんとHPFの形になっていることがわかります。対数なので見えていませんが、0Hzの応答は0となっています。

さて、係数を、DSPに組み込むためには、24ビットの符号付き固定小数点に変換する必要があります。ごにょごにょして、それぞれバイト列に変換します。

b[0] = 0x7f, 0xfa, 0xda b[1] = 0x80, 0x5, 0x26 -a[1] = 0x7f, 0xf5, 0xb5

これをI2C経由でチップに書き込みます。コードを下記に示します。2つのチャネルでレジスタが違いますので、それぞれ同じデータを書き込みます。係数を書き込んだあと、係数バッファを切り替えることでフィルタの動作に反映されます。ADCを動作させながら切り替える場合はこの一手間が必要です。動作開始前に係数を設定するのであればバッファ切り替えは不要です。

const uint8_t adc_iir_filter_dcreject[] = { /* len, page, reg, data.... */ /* left channel C4 - C6 */ 12, 8, 24, /* Pg8 Reg24-35 */ 0x7f, 0xfa, 0xda, 0x00, 0x80, 0x05, 0x26, 0x00, 0x7f, 0xf5, 0xb5, 0x00, /* right channel C36 - C38 */ 12, 9, 32, /* Pg9 Reg 32-43 */ 0x7f, 0xfa, 0xda, 0x00, 0x80, 0x05, 0x26, 0x00, 0x7f, 0xf5, 0xb5, 0x00, 0 /* sentinel */ }; void tlv320aic3204_config_adc_filter() { const uint8_t *p = adc_iir_filter_dcreject; while (*p != 0) { uint8_t len = *p++; uint8_t page = *p++; uint8_t reg = *p++; I2CWrite(AIC3204_ADDR, 0x00, page); while (len-- > 0) I2CWrite(AIC3204_ADDR, reg++, *p++); } I2CWrite(AIC3204_ADDR, 0x00, 0x08); /* Select Page 8 */ I2CWrite(AIC3204_ADDR, 0x01, 0x05); /* ADC Coefficient Buffers will be switched at next frame boundary */ I2CWrite(AIC3204_ADDR, 0x00, 0x00); /* Back to page 0 */ }

これを組み込みます。さきほどと同様に無信号時のスペクトラムを見てみると、DCの信号が消えてちゃんとフラットになっています。

オーディオのスペクトラムを見てみると、0Hzの成分は消えたのですが、別の小さな信号が残っていることがわかります。

信号処理過程の中間の信号を見てみると、またもや0Hzに不要信号が生じていることがわかります。

SSB復調の信号処理ブロック図を示します。ADCで取り込んだ信号をまず最初に1.3kHz周波数シフト、次いでfc=1.3kHzのLPFを通します。最後に、また1.3kHz逆向きに周波数シフトしています。こうして2.6kHz幅の復調帯域幅を得ています。LPFにCMSIS DSPライブラリを使って、6次のBiquad IIRフィルタを実装しています。この内部でDC成分が生じているようです。最後にまた周波数シフトしているので結果として1.3kHz付近の不要信号となっているわけです。

CMSIS DSPライブラリのソースコードを調べてみます。ファイル

CMSIS/DSP_Lib/Source/FilteringFunctions/arm_biquad_cascade_df1_q15.c

にある

arm_biquad_cascade_df1_q15() 関数です(141行目付近)。

固定小数点のシフトを使った計算をしているのですが、適切でない箇所があるようです。2べきの割り算をシフトで行うことはよくやることなのですが、符号の扱いには注意が必要です。たとえば、正の数に対して右シフトを繰り返すと8→4→2→1→0とどんな数も最後には0になります。ところが負の数を右シフトする場合は、-7→-3→-1→-1→-1→-1 と、-1すなわち全ビットが1になったあとは変化しなくなります。このように右シフトによる割り算は、正と負で結果が非対称になっていますので、適切に扱われていないと期待しない結果が生じます。CMSIS DSPライブラリで生じているDCオフセットはこれが原因のようです。

これを回避するため下記の修正(FIXコメントの行)を追加します。0と-1のギャップを埋めるために0.5を足しておくのです。

/* acc += a1 * y[n-1] + a2 * y[n-2] */ acc = __SMLALD(a1, state_out, acc); /* FIX: compensate dc offset caused from bit shift operation */ acc += 1 << lShift; /* The result is converted from 3.29 to 1.31 if postShift = 1, and then saturation is applied */ /* Calc lower part of acc */ acc_l = acc & 0xffffffff; /* Calc upper part of acc */ acc_h = (acc >> 32) & 0xffffffff;

この対策を施すと、無事DC成分が消えました。無信号でオーディオフラットです。やったね!

公式にARMから提供されているCMSIS DSPライブラリといえども、注意して使用する必要があるようです。今回の対策は、LPFを実装する目的には効果がありましたが、一般に適用するには注意が必要かもしれません。

というわけで、同じくDCオフセットに関するトピックでしたが、ハードウェアからソフトウェアまで、いろいろな原因があり得ます。その対策2題でした。

それにしてもスペクトラムが実機で表示できるのはとても便利です。前はデータを取り出してグラフを描いたりしていたのですが、画面を見れば一目で効果がわかります。

おまけでCentSDRのハードウェアブロック図です。若干数のキット頒布の準備をしていますが、なかなか進捗しません。アナウンスをお待ちください。

参考

CentSDRを組み立ててみました http://ttrftech.tumblr.com/post/164219455216/

TLV320AIC3204 Application Reference Guide http://www.ti.com/lit/ml/slaa557/slaa557.pdf

CMSIS DSPライブラリ https://github.com/ARM-software/CMSIS

機材のセットアップですが、受信機にはいつものRTL2832UドングルをノートPC(Mac Book Pro)に接続しています。受信用ソフトウェアはdump1090をコマンドラインから使います。dump1090は受信したADS-Bメッセージをデコードした結果をTCPのポート30003で出力する機能があります。これを活用してロギングしてみることにします。 UNIX系のOSでは、nc(NetCat)というコマンドで、任意のホスト、ポートにTCP接続をし、受け取ったデータをそのまま標準出力に出すことができます。これをリダイレクトすることでファイルに記録できます。この出力フォーマットはCSVのテキスト形式ですので、データの処理は難しくありません。

MacOSの場合、dump1090コマンドはソースからビルドする必要があります。準備として、RTL2832U用のライブラリを用意しておく必要があります。ライブラリはbrewでインストールしておくのが簡単です。あとはdump1090のソースコードをgithubから落としてきて、makeするだけでOKです。Linux(Raspberry Piなど)の場合もbrewの代わりにapt-get等を使うことで同様にビルドできます。

$ brew install rtl-sdr $ git clone https://github.com/MalcolmRobb/dump1090 $ cd dump1090 $ make

RTL-SDRドングルをPCに接続し、dump1090コマンドを起動します。アンテナは付属のものをつかいます。受信に成功したらログメッセージが流れていきます。次にやるTCPでデータを取れるように--netオプションを付けて起動しておきます。

$ ./dump1090 --net

この状態で別のターミナルを開いて、ローカルホスト(127.0.0.1)、ポート30003からデータを読むため、下記のコマンドを入力します。

$ nc 127.0.0.1 30003

そうすると、テキストでCSV形式のデータが表示されるはずです。デコードできたメッセージが、1メッセージ=1行で出力されます。あとは、これをリダイレクトでファイルに落とせば記録できることになります。

$ nc 127.0.0.1 30003 > adsb.csv

ところでdump1090には、いくかバリエーションがあります。検索で最初に引っかかる https://github.com/antirez/dump1090 で公開されているバージョンでは、30003ポートから下記のような出力が得られます。

MSG,8,,,84BB74,,,,,,,,,,,,,,,,, MSG,8,,,84B79C,,,,,,,,,,,,,,,,, MSG,3,,,D9E098,,,,,,,40325,,,,,,,0,0,0,0 MSG,5,,,84B79C,,,,,,,2400,,,,,,,,,, MSG,8,,,84BB74,,,,,,,,,,,,,,,,, MSG,5,,,84B79C,,,,,,,2450,,,,,,,,,, MSG,5,,,84B79C,,,,,,,2475,,,,,,,,,, MSG,5,,,84B79C,,,,,,,2500,,,,,,,,,, MSG,6,,,84B79C,,,,,,,,,,,,,7301,0,0,0,0 MSG,5,,,84B79C,,,,,,,2525,,,,,,,,,, MSG,8,,,84B79C,,,,,,,,,,,,,,,,,

カンマの連続が目立ちます。空のフィールド多いようです。

このバージョンの他に、https://github.com/MalcolmRobb/dump1090 にも公開されています。こちらは種々の改良が加えられており、CSV出力の形式形式が違っています。こんな出力が得られます。

MSG,7,111,11111,8675BC,111111,2017/06/04,10:18:14.261,2017/06/04,10:18:14.252,,7375,,,,,,,,,,0 MSG,4,111,11111,8675BC,111111,2017/06/04,10:18:14.316,2017/06/04,10:18:14.254,,,271,217,,,3968,,,,,0 MSG,7,111,11111,86752C,111111,2017/06/04,10:18:14.356,2017/06/04,10:18:14.318,,11025,,,,,,,,,,0 MSG,7,111,11111,862248,111111,2017/06/04,10:18:14.530,2017/06/04,10:18:14.514,,22525,,,,,,,,,,0 MSG,5,111,11111,86752C,111111,2017/06/04,10:18:14.538,2017/06/04,10:18:14.515,,11025,,,,,,,0,,0,0 MSG,8,111,11111,8675BC,111111,2017/06/04,10:18:15.106,2017/06/04,10:18:15.104,,,,,,,,,,,,0 MSG,8,111,11111,8675BC,111111,2017/06/04,10:18:15.115,2017/06/04,10:18:15.104,,,,,,,,,,,,0 MSG,8,111,11111,8675BC,111111,2017/06/04,10:18:15.124,2017/06/04,10:18:15.105,,,,,,,,,,,,0 MSG,7,111,11111,85D7C0,111111,2017/06/04,10:18:15.195,2017/06/04,10:18:15.170,,2550,,,,,,,,,,0 MSG,8,111,11111,8675BC,111111,2017/06/04,10:18:15.195,2017/06/04,10:18:15.170,,,,,,,,,,,,0 MSG,3,111,11111,8675BC,111111,2017/06/04,10:18:15.226,2017/06/04,10:18:15.172,,7425,,,35.44315,139.86805,,,,,,0

こちらは埋められたフィールドが増えています(一部のフィールドはダミーのようです)。重要なのは日時についての情報が入っていることです。航跡を時系列データとして記録するためには、MalcolmRobb版を使った方が良さそうです。

以上のような準備をしたえうえで、当日現地で、屋外でノートPC(MBP)を広げて、データを記録しました。日差しが強く、ノートPCの画面が見えにくく少し難儀しました。

さて、得られたデータを観察してみると、行によって内容が違っています。データフォーマットはこちらに解説がありました。2 番目のフィールド2=Transmission Typeでメッセージの種別が区別されているようです。フィールド5にAircraftIDがあり、機体(メッセージの発信者)を識別するようです。

緯度経度はTransmission Typeすなわちタイプ3メッセージのカラム15,16に記録されています。また、 高度はタイプ2,3,5,6,7のいずれか、カラム12のようです。これらを取り出せば軌跡が得られるはずです。

さてこの手順でデータを処理して、プロットすることが目標です。何かツールがあるかもしれませんが、テキストファイルですので、自力で処理してみます。時系列データですので、PythonとPandasを使ってみます。最終的にGeoJSONに変換することで、Google Mapをはじめ、いろんなツールで取り扱えるはずです。

まずはpandasをimportし、CSVファイルを読み込みます。

import pandas as pd dat = pd.read_csv('20170604-1252.csv', header=None, index_col=9)

フィールド9にある時刻をインデックスに指定しています。こうすることで取り扱い易く易くなります。

読み込んだデータはJupyter notebookのうえではこんなふうに表示されます。

NaNが多く、意外とスカスカであることがわかります。

メッセージタイプ=3のレコードから、AirCraft IDと、時間、高度、緯度、経度を取り出してみます。

メッセージタイプ5を取り出します。Aircraft ID,時刻,コールサイン,高度(FT)のフィールドだけを表示しています。これでコールサイン=便名とAircraft IDの対応がわかります。

高い高度で飛んでいるのは商用機です。羽田の近くなので飛行機はたくさん飛んでいます。

エアレース機は低空を飛んでいますので、1000FT以下のメッセージだけを取り出してみます。NaNになっているレコードが多いのでそれも取り除きます。

エアレース機らしいコールサインが見つかります。このうち、N31YMというのがFalken室屋機です。Aircraft IDが A346AA ということがわかります。

Aircraft ID(フィールド4)が’A346AA’のレコードを取り出します。

結構たくさん出てきます。930行ありました。これならプロットできそうです。

matplotlibでグラフ化してみます。jupyter notebookの中で%matplotlibディレクティブでinlineを指定します。

見事グラフになりました。上下に大きく変化しているのがわかります。

プロットがブツ切れになっているのは、NaNが混じっているせいです。dropna関数を使って取り除きます。

いい感じになりました。途中怪しげなジャンプがありますが、何かあるのかもしれません。

さて次は緯度と経度です。メッセージタイプ3の、フィールド14,15に入っています。

こちらは186個取れてました。軌跡は描けそうです。

さて、このデータをgeojsonに変化してみます。まずはpandasから緯度経度を普通のデータに直します。イテレータとリスト包括表記で、経度緯度のタプルの配列に変換します。

うまくいったら、今度はgeojsonというモジュールを使ってgeojson形式に変換します。緯度経度の配列からLineStringを生成、それをFeatureとしてgeojsonに追加します。geojsonのデータができたら、こんどはjsonモジュールを使って、jsonファイルを生成します。

ファイルの冒頭を見ると、それらしいデータが入っています。

このgeojsonファイルを地図の上にプロットしてみます。今回は簡単のためgeojson.io というWebサイトを利用します。ブラウザで http://geojson.io/ を開き、geojsonファイルをアップロードするだけで表示させることができます。

稲毛海岸で待機旋回している様子や、会場前で競技の折り重なった飛跡、そして終わった後、浦安方面を戻る様子が記録できていました。

手順は省略しますが、他機や商用機もすべて含めたgeojsonを作ってみました。geojson.ioは、GITHub/Gistに置いたデータを開くことができます。置いておきましたので興味があればご覧ください。こちらのgeojsonには高度情報も含めています。

本来であれば、Jupyterの上で表示させると良かったのですが、ごにょごにょと面倒なので、ここではGeoJsonファイルを作ってWebサイトで表示させてみました。コードの断片をスクリプトファイルにまとめることも可能です。是非お試しください。

ちなみにGeoPandasという地理情報用のPandasパッケージもあります。geojsonファイルを直接扱うことができ、簡単なプロットも可能です。shapelyというモジュールで、いきなりセルの上でプロットされてしまいます。こちらも便利そうです。

補足

Jupyterを使える環境にある場合は問題ないと思いますが、pandasやgeojsonはモジュールとして追加が必要です。pipでインストールすることが可能です。

pip install pandas pip install geojson

参考

使用したdump1090(ADS-Bデコーダ)  https://github.com/MalcolmRobb/dump1090

ADS-Bメッセージの解説 http://woodair.net/sbs/Article/Barebones42_Socket_Data.htm

Jupyter http://jupyter.org/

Pandas http://pandas.pydata.org/

GeoPandas http://geopandas.org/

geojson.io  http://geojson.io/

今回の基板には、裏面にシルクでブロック図を描いてみました。ブロックを結ぶ各信号線に合わせて、その信号にアクセスするためのスルーホールランドを設けてあります。基板裏面を見るだけで構成が理解でき、信号をオシロを当てて実際に観測したり、実験のために信号を注入したりできることを狙っています。

I/Q信号はそれぞれ差動信号なので2本づつ。Loも2相信号なので2箇所あります。Loは50MHz以下。4xLoは〜200MHz。MCLKは8MHzの固定です。そのほかVCTCXOの制御電圧(Vadj)や、I2S, I2Cの信号です。SPIは、LCDのコネクタでアクセスできますので、ランドは設けていません。

組み立ては、段階を踏んで、以下の順序で行います。

USBコネクタ 電源供給用のUSBコネクタを取り付け、VBUS=5Vが来ることを確認します。

電源周り LiPoバッテリ用の制御回路を用意しているのですがそれは後回しにして、先にレギューレータとMOS FET、電源スイッチを付けて、3.3Vの電圧が正常に出ることを確認します。

MCUとその周辺 電源がOKであればMCUとしてSTM32F303CBT6を付けてしまいます。書き込みにはST-Link2を使います。(DFUは外付けクリスタルが必要なので、今回の構成では最初の書き込みには使えません) LEDがあるのでまずはLチカを確認するのがオススメです。今回はFriskSDRとほとんど同じ構成なので、そのファームをそのまま使って動作確認をしました。 ファームウェアはCDC (USB Serial)に対応しているので、正常ならばUSB経由での接続と、コマンド操作が行えるようになります。

VCTCXOを付けて26MHzの出力をオシロで確認。Si5351aを付けて、ファームからの制御でMCLK 8MHzの出力が出ることを確認。そして4xLoの信号が出て、周波数チューニングができることを確認。

TLV320AIC3204、そしてスピーカ用ミニジャック、周辺のコンデンサを付けます。

74LVC74を付けて、分周動作と2相信号が生成されていることをオシロで確認。

アナログスイッチTS5A23157、そしてRCフィルタを付ける。ファームウェアが正常に動いていれば、スピーカを付けて、ミキサの入力端に適当にアンテナ線を繋げばAM放送を聞くことができます。

RFアンプとSMAコネクタを付ける。

ファームウェアを流用できたこともあり、ここまではスムースに動作確認をすることができました。

最後にLCDとロータリエンコーダを取り付けます。

FriskSDRと新旧比較してみます。LCDを除けば同じアーキテクチャ、同じ部品で、基板サイズがかなり大きくなりましたのでレイアウトはスカスカです。FriskSDRは、よくあのサイズに入っていたなと我ながら驚きます。

ファームウェアですが、LCD描画のために、コードを修正していかねばなりません。NanoVNAでSPI LCDのコードがあるのと、雑誌でやったLPC-Link2受信機の画面描画のコードがあるので、これらの合わせ技で作っていきます。とはいえMCUが多少違うので調整が必要です。詳細は省きますが、I2C(DMA)との干渉で半日ハマりましたが、無事に動かすことができました。I2Sの全二重動作(DMA)と、LCDのSPI(DMA)もうまく動いています。あとは、ロータリエンコーダがスムーズに動かせるよう外部割り込みで動作するよう作り直して、各種操作ができるようコードを手直ししています。作業にはお盆の二日間を要しました。

基本的な画面構成と操作体系は、LPC-Link2で作った受信機とほとんど同じです。あちらはマルチコア、こちらはシングルコアですが、動作を見てみると、FFTの画面更新レートは結構な速さが得られているようです。音声に合わせて躍動する感じが良いです。負荷を見てみると、DSP処理には15%程度しか要しておらず、残りはFFTと描画処理に使っています。

いろいろと動作確認をしてみました。

上限の周波数は52MHz程度まで受信できるようです。この限界は74LVC74の動作速度のようで、分周動作の上限が200MHz程度(データシート上は225MHz)であることによります。

無入力でもぴょこっと0Hzの飛び出しが見えます。ADCのDCオフセットがあるようで、リジェクトするようコードを入れたいところです。

IQバランスは比較的良いようですが、チューニング周波数を上げていくと少し逆サイドの漏れが出てきます。こちらも係数補償でキャンセルできるはずです。

スプリアス。Si5351aのチューニングをダイアルでスキャンしてみると、ところどころにSpurが出てきます。スペクトラムが見えてしまうと、どうしても気になります。

クロックの妨害。アンテナを基板に近づけると24MHz, 48MHz付近で、スペクトラムが広がったノイズが観測できます。MCUからクロックの放射があるようです。一方、アンテナ無しでは微弱で済んでいるので、基板内の分離は良いようです。

USB CDCを接続状態にすると、中波帯に広くノイズが出る。配線の引き回しが長いので影響が出やすいようだ。

動画です。

操作もできるようになった pic.twitter.com/mHNs6XoTyl

— TT@北海道 (@edy555)

2017年8月15日

コードは、もう少し整理して公開したいと思っています。できればmbedあたりにしたいと思っていたのですが、既存のコードがあると、どうしてもそちらに流れてしまいます。

受信機としての基本的なアーキテクチャはFriskSDRとまったく同じです。ローカル発振器としてSi5351aを使い、ジョンソンカウンタで2相信号を作成、アナログマルチプレクサをミキサとして使います。

もともと53x27mmの基板サイズに詰め込んでいたものを、大きな基板(といっても58x88mm)にゆったりと再配置した感じです。使っている主要な部品はSMDの同じものです。

ディスプレイはカラーグラフィックLCDを採用することにしました。LPC-Link2やNanoVNAで使ったSPI LCD(ILI9431)が実績があるので、またこれを使ってみることにします。操作はロータリーエンコーダのワンノブスタイルです。

MCUは、FriskSDRと同じくSTM32F303の予定です。実時間処理しながらグラフィック描画をするにはMCUが非力ですが、全く不可能というわけではないはずです。

FriskSDRではCodec TLV320AIC3204のADCの前段にあるVGAのみをアンプとして使っていました。シンプルな構成で、たしかに受信機として動作させることはできていたのですが、正直ゲイン不足であることは否めませんでした。そこで今回は、ゲインブロックを追加で一段置いてみることにしました。さらに、RF入力部にはプラグインモジュールを挿せるようにしておいて、アンプを入れたり、フィルタやミキサを置いたりなど、いろいろ実験できることを目論んでいます。

基板の裏面にはシルクでブロック図を描いてみました。表側には対応する部品が載っています。絵に描いたような実装で、眺めるだけで原理がわかると良いなと思っています(ただ、図として見ると、信号の流れが右→左と少し違和感があります)。実験をしやすいよう各信号にアクセスするパッドを各所に設けてみました。パッドとブロック図がちゃんと対応しています。

ソフトウェアはこれからですが、まずは実績のあるChibiOSベースのものを移植することになると思います。

基板はすでに発注して、製造は完了したようです。試作が進んだらまたご報告したいと思います。

実は明日からのMakerFaireTokyoに出展予定です。今回のプロジェクトも展示したいと思っていたのですが、残念ながら輸送が間に合いませんでした。なので今回は新作の実物は展示が無いのですが、資料や、これまで作ったFriskSDRやNanoVNAご覧いただけます。もしお時間ありましたら、是非、東京ビッグサイトへ。ブースの場所はE08-06です。

参考

HMC472はHittite社のマイクロ波帯まで使えるワンチップのステップアッテネータです。0〜31dBまで1dBステップで5ビット分をパラレルでデジタル設定可能です。近頃はGaAsによる特性の良いチップが入手しやすくなりとても有り難い限りです。本来はマイクロ波帯向けですが、データシートを見ると低い周波数まで使えそうです。注意点としてHMC472はVddが5Vなことです。

試すにあたって、QFNパッケージのRFチップなので基板を起こします。このチップの試験だけではなんなので、ついでに抵抗アッテネータも付けて特性を比べてみることにしました。AS169-73LFというこれもGaAsなSPDT RFスイッチを前後に付けてパスを切り替えて、抵抗アッテネータ/スルーを切り替えるようにしています。HMC472が31dB分あるので、調整範囲が連続するよう抵抗アッテネータは30dBとしています。1段で-30dBの減衰を得るのは少し無理がありそうなので、-10dB＆-20dBの2段構えにしています。切り替え前後の分離には一応気を使っているのでCやFBが多くなっています。

アッテネータ部分の評価なので、コネクタとケーブルを取り付けます。制御には基板に載せたSTM32F072を使っています。STM32はIOピンのほとんどが5Vトレラントなので、HMC472を制御するため、オープンドレイン＋5Vへのプルアップで制御しています。

測定はNanoVNAで行います。データはPCで収集しますので、USBで接続します。

計測するための小さなコードをこんな感じで用意します。それぞれの計測を辞書(dict)に保存しています。

%matplotlib inline import numpy as np import pylab as pl from nanovna2 import NanoVNA nv = NanoVNA('/dev/cu.usbmodem401') s11 = dict() s21 = dict() def measure(label): s11[label] = nv.data(0) s21[label] = nv.data(1) nv.logmag(s11[label]) nv.logmag(s21[label])

ステップアッテネータはMCU経由でUSBシリアルで制御できるようにしておき、ターミナルから手作業で設定を変えながら、特性を計測しました。

まずはHMC472の通過特性をプロットしてみます。減衰段のビットを増やしながらグラフに重ねます。

ちゃんとステップ特性が得られています。デジタル設定なので0.5dB掛ける2のベキ(0,5,1,2,4,8..)の間隔になっています。スルーでも2dB程度の減衰があるのは全体の挿入損失です。ステップアッテネータやRF Switchなど素子をいくつも経由しているのでこれは致し方ありません。いちばん下のトレースの低域が持ち上がっていますが、残念ながら-16dBの段は特性がフラットにならないようです。-8dBの段も少しうねっていますが、他はおおよそフラットなようです。

続いて抵抗アッテネータです。ON/OFFでの差ですが、ほぼ-30dBの減衰がフラットに得られているようです。この周波数範囲では抵抗アッテネータでも十分な特性が得られています。こちらは文句ありません。

最後に全部をプロットしたものです。最大減衰では60dB前後が得られていますがノイズっぽいのは、NanoVNAのダイナミックレンジ不足の影響です。もうすこし駆動レベルを上げたいところです。

抵抗アッテネータは大変素直で良い結果でした。一方、HMC472は少々不満が残りました。実はデータシートでは330pFを4つ付けるよう指定されているのですが、この指定の通りだとさらに低域が悪化していました。このキャパシタを10nFに増やすと改善しました(上の結果がそれです)。残念ながら満足いくまでは改善されませんでした。低域が持ち上がった結果、全体で-31dBの減衰は得られず-28dBに留まります。もともとがマイクロ波帯のチップですから致し方ありません。

もともとこの実験は受信機作りに使える手軽な信号源として、Si5351Aを使って簡易SGにしてみようとの目論見でした。充分にレベルを落とした信号が得らるならば受信機に与えるトーン信号の代わりに使えます。一方、出力は方形波なので、奇数次が多いので当然ながらひずみの計測には使えません。しかし、目的を絞れば役に立つだろうとの想定です。ちなみにこの基板はミンティアのケースに入れられるようにしています。

というわけで、少し不満は残りますが、特性の雰囲気はつかめました。SGにするには少なくとも抵抗アッテネータの段数を増やす必要があります。しかし全体の減衰量をもっと増やすには、シールド無しでは厳しいかもしれません。簡易SGとしてまとめられるよう引き続き検討したいと思います。

リファレンス

HMC472 http://www.analog.com/en/products/rf-microwave/attenuators/digital-step-attenuators/hmc472a.html