GNURadio
整流回路とオペアンプ増幅回路でWi-Fi電波を可視化してみるなんてのを見て、フムフムと頷いているオイラーが居る。
電波の入り口のアンテナは、ハーフ・ラムダのダイポールアンテナ。どうせなら、八木アンテナにしてゲインを稼ぐのが良いかも。
次はダイオードを２個使った、倍電圧整流回路。ダイオードは順方向電圧が小さいショットキータイプの物がいいんだけど、既にディスコンらしい。オイラーが現役の頃は普通に手に入ったんだけどね。時代の趨勢か。
最後はオペアンプを非反転増幅回路にして、1000倍の増幅度を得ている。どんな微弱な電波も捉えてやるぞと言う、気構え十分な回路構成。
これで、見事にWifiルーターや、電子レンジ、（最近だとIHIの炊飯器とか、家の中に仕掛けてあるかも知れない盗聴器でもOKかな）から、出る電波を捉えて、LEDを光らせる事が出来るとの事。小学生向けの電子工作にちょうど良いだろう。
小学生じゃないオイラーは、ipadで実験。Wi-Fiミレルを、突っ込むだけの、お手軽実験。
こんなのが有ると、家の外に電波が漏れてないか、確認したくなるよね。電波が漏れてたら、ガムテープで塞いでしまいたい、今日この頃。
でも、屋外でipadを持ってウロウロしてたら、怪しい人と思われて通報されそう。どうするか？ 背中にのぼりを立てて、堂々と宣言するのさ。『安全確保の為、漏洩電波の調査中です。XX電波監理局・委託者』ああ、電監は余計だな。
本当に怪しい人はipadなんか使わないで、スマホをさりげなく持って、歩きスマホで済ませちゃいますよ。そう言えば5月の連休の時だったかに公園で、スマホを持った人（若い人からお年寄りまで）の軍団をみたけど、どういう集団？
ポケモンGoの集団かしら？ 人気が落ち目になったんで、こういう田舎の公園でもサービスしてんかな？何やってんですかって、職質すればよかったな。
Install GNUradio
rtl_tcpとVirtualBoxを使ってGNURadioからRTL-SDRを使う1つの方法
ぐだぐだとURLを並べていてもしょうがない && Debianを入れたDISKがいっぱい余っていて可哀そうという理由で、入れてみた。色々なサイトを見ていると、ソースから真面目にコンパイル して入れるってのが流行のようだけど、オイラーはそんな元気がない。さくっと、apt install gnuradioしちゃった。山のように関連品が来たのは、見なかった事にする。
Cフラフラ語で書かれた部品をPythonで配線するって方法。システム側が管理するPythonとオイラーが勝手に入れたanacondaが喧嘩しないか？ アナコンダの方が強そうだけど。
取り合えず起動してみる。
debian:tmp$ gnuradio-companion
<<< Welcome to GNU Radio Companion 3.7.10 >>>
Block paths:
/usr/share/gnuradio/grc/blocks
ほー、本拠地が出て来た。
debian:tmp$ cd /usr/share/gnuradio/ debian:gnuradio$ ls examples fec grc modtool themes debian:gnuradio$ ls examples/ analog channels fcd hf_radio noaa uhd atsc ctrlport fec metadata qt-gui vocoder audio digital filter mp-sched tags volk_benchmark blocks dtv hf_explorer network trellis zeromq
examplesが有るんで、簡単そうなオーディオを見てみる。
debian:gnuradio$ cd examples/audio/ debian:audio$ ls audio_copy.py dial_tone_daemon.py multi_tone.py audio_copy.pyc dial_tone_daemon.pyc multi_tone.pyc audio_fft.py dial_tone.grc noise.py audio_fft.pyc dial_tone.py noise.pyc audio_play.py dial_tone.pyc spectrum_inversion.py audio_play.pyc dial_tone_wav.py spectrum_inversion.pyc audio_to_file.py dial_tone_wav.pyc test_resampler.py audio_to_file.pyc mono_tone.py test_resampler.pyc cvsd_sweep.grc mono_tone.pyc
コンパニオンから、ここを開いてみたら、dial_tone.grcってのとcvsd_sweep.grcってのが 見えた。トーンの方を選ぶと、350と440Hzの発信器と弱いノイズ源が足されて、オーディオ出力に出ていってる。ピポパの電話機の音を作ってるんだな。 走らせると、xtermがなんたらかんたらって言って、警告が出て来た。
で、もう一方のcvsdの方を選んで走らせると、何やらFFTの窓が開いて、FFTしてた。
dial_tone.grcを開いて、正体を確かめてみる。
<?xml version='1.0' encoding='ASCII'?>
<flow_graph>
<timestamp>Sat Jul 12 14:32:31 2014</timestamp>
<block>
<key>options</key>
<param>
<key>id</key>
<value>dial_tone</value>
</param>
:
オイラーの大嫌いなXMLになってた。これが部品名かな。次は、pythonの例。どれでもいいんだけど、dial_tone.pyを見てみる。
sample_rate = int(options.sample_rate)
ampl = 0.1
src0 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, 350, ampl)
src1 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, 440, ampl)
dst = audio.sink(sample_rate, options.audio_output)
self.connect(src0, (dst, 0))
self.connect(src1, (dst, 1))
発信器が有って、それが出力に接続されるって事だな。 ああ、/tmpの下に、dial_tone.pyなんてのが出来ている。実行時に作成されたやつか。 どうでもいいけど、例に何の説明も無いとは、どういう事よ。それとも、じっと配線図を眺めて、機能を想像せいと言う事？
文句を言っていても進歩が無いので、もう少し詳細に観察。Runメニューから実行すると、下記のようなメッセージが左下の窓に出て来る。
Executing /usr/bin/python -u /tmp/dial_tone.py
-uオプションは、stdin/out/errをバッファリングしないで垂れ流せってオプション。それを除いても、普通に/tmpの下にあるスクリプトを実行せいって事だ。実行したら音が出てもよさそう。
と思っていたら、LXDEのメニューで音がしないようにミュートしてた。音が鳴るように解除したら、無事にトーンが聞こえた。雑音を大きくしても、トーンはちゃんと判別出来るな。まだ、オイラーの脳内フィルターはちゃんと機能してるな。
そして、もう一方のやつを実行すると、宇宙的な不思議なスィープ音が聞こえた。ブロックダイアグラムにVCOなんてのが見える。これって、与える電圧によって発振周波数が変わる発信器の事じゃない。と言う事は、与える電圧をランプ波にすれば、低音から高音まで連続的に聞こえるんだな。一種の周波数変調器か。納得しました。
このgnuradio-companionはやはり有名らしく、LXDEのPrograminngの項にGRCって名前で登録されてた。有名なアプリなのね。で、コンパニオンさんが居ないと、実行出来ないの？って言う、当然の疑問が出て来る。
/tmpの下に出来てるpythonスクリプトの冒頭を見ると
debian:tmp$ head dial_tone.py #!/usr/bin/env python2 # -*- coding: utf-8 -*- ################################################## # GNU Radio Python Flow Graph # Title: Dial Tone # Author: Example # Description: example flow graph # Generated: Tue May 22 16:06:18 2018 ##################################################
こんな風になってたぞ。注目は１行目。python2を探して、それを起動っていう事。今の所（DebianのPythonが古い為）、anacondaのpython3系とはちゃんと棲み分けできてる。 先走りしてるウブだと、喧嘩しちゃうんじゃなかろうか。ちゃんとフルパスでPythonを指定して欲しいと思うぞ。
で、このスクリプトを単独で走らせても、全く問題なく走る。コンパニオンさんて、研究者と言うか、実験者の事なのね。色々実験して、その結果が/tmpの下に残るって事だ。
doc gnuradio
マニュアル類は無いかと、探してみると
debian:gnuradio$ pwd /usr/share/doc/gnuradio debian:gnuradio$ ls README* README README.dtv README.gl README.signal_flow README.analog README.dvbs2 README.gsm README.txt README.audio README.dvbt README.howto README.TXT README.blocks README.dvbt2 README.karn README.uhd README.channels README.fcd README.md README.vocoder README.Debian README.fec README.modtool README.zeromq README.digital README.fft README.plot.gz README.doxyxml README.filter README.qtgui
README.xxxってのが、その入り口みたい。一つ例を挙げる。
debian:gnuradio$ cat README.fcd
This is the gr-fcd package. It contains a source block for the
FunCube Dongle hardware.
The Python namespace is in gnuradio.fcd, which would be normally
imported as:
from gnuradio import fcd
See the Doxygen documentation for details about the blocks available
in this package. A quick listing of the details can be found in Python
after importing by using:
help(fcd)
マニュアルの見方が出て来た。味方になってくれるかどうか？
debian:gnuradio$ python2.7
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import fcd
>>> help(fcd)
Help on package gnuradio.fcd in gnuradio:
NAME
gnuradio.fcd - Provides a source block for the FunCube Dongle hardware.
FILE
/usr/lib/python2.7/dist-packages/gnuradio/fcd/__init__.py
PACKAGE CONTENTS
_fcd_swig
fcd_swig
FUNCTIONS
source_c_sptr_swigregister(...)
source_c_swigregister(...)
とからしい。まどろこっいな。つらつらと見て行くと、uhdってのがハードとの橋渡しをしてくれるみたい。膨大な資料が出てくる。
で、コンパニオンさんのhelpで、色付きの端子の説明が出てくる。各モジュールのデータ形式は決まっているっぽい。
pd
過去に似たようなコンセプトのやつををやったと思い出したぞ。
Pure Data Japan こんな協会が設立されてた。
懐かしくなって、pdパッケージを入れちゃたぞ。
Pure Data（本家）を見ると、iOSにも入りそうな事が書いてあったので、行ってみたら、MACユーザー限定っぽい。残念。（そんなに間口を拡げてどうすると）
関連で、 SDRはどう作る？ なんてのが見つかった。Ch5ぐらいまで有ったので、見ておくと吉。
anacondaと喧嘩する？
GnuRadioの最終出力がpythonスクリプトって事は、pythonのdebug環境が有ったらいいな。 ああ、debug環境なんて言う大層なものじゃなくて、python2の貧弱なreplを補うだけでいい。 そうなるとipythonだな。
apt-cacheで探すと、
ipython - Enhanced interactive Python 2 shell ipython3 - Enhanced interactive Python 3 shell
こんなのが出て来る。当然、２系のやつを入れたよ。が、ipythonを起動すると、anacondaに入っているpython3が起動してくる。あれ？ ひょっとしてanaconda側のipythonを起動してるのかな？ そう思って、/usr/bin/ipythonと指定しても、やはり３系が上がってくる。
anacondaを入れた時、.bashrcに
# added by Anaconda3 installer export PATH="/home/sakae/anaconda3/bin:$PATH"
こんな痕跡を残していったんだ。この妖術に惑わされて、/usr/bin/ipythonを起動しても、３系が動いちゃうという現象になったんだな。
これはもう、破滅の第一段階だな。anacondaには冬眠してもらおう。PATHから外して、知らんふりを決め込む事にしたよ。どうしてもanacondaを起動する必要が出たら、絶対PATHで指定するなり、テンポラリィーでPATHを通せば済む話ですから。
begin GNURadio
Tutorials Write Python Applications
いきなり、上記から見始めたけど、いいのかな？ まあ、ページの中ほどにモジュールの簡易的な説明が有ったぞ。
uhd_cal_rx_iq_balance uhd_fft uhd_images_downloader uhd_siggen uhd_cal_tx_dc_offset uhd_find_devices uhd_rx_cfile uhd_siggen_gui uhd_cal_tx_iq_balance uhd_image_loader uhd_rx_nogui uhd_usrp_probe
それから、ドングルと言うか、ハードに対するユーティリティが、上記のように用意されてるのね。
<connection>
<source_block_id>analog_sig_source_x_0</source_block_id>
<sink_block_id>blocks_throttle_1</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>analog_sig_source_x_1</source_block_id>
<sink_block_id>blocks_throttle_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>blocks_multiply_xx_0</source_block_id>
<sink_block_id>qtgui_freq_sink_x_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>blocks_throttle_0</source_block_id>
<sink_block_id>blocks_multiply_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>1</sink_key>
</connection>
<connection>
<source_block_id>blocks_throttle_1</source_block_id>
<sink_block_id>blocks_multiply_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
4KHzと5KHzのCOS波をMIXする回路のネットリスト。足し算じゃなくて掛け算するとミキサーになる。(オーディオ界でミキサーと言うと、複数の音源を一つに足し合わせる意味だけど、無線界では、掛け算の意味で使う)酷試にも出て来るけど、ミキサーの出力はどうなりますか？ 和の9KHzと差の1KHzが出て来るのはいいんだけど、元の波形も出て来ると思ってたぞ。
それから、発信器とミキサーの間に、misc/throttleという絞り弁を入れておく事。こうしないと（多分）スペアナの演算が間に合わなくて正しい表示をしてくれない。それから、信号は全てfloat32にしてる。
発信器の一つをCOS波からノコギリ波にすると、色々な所にスプリアス(?)が出て来て、面白いぞ。
KIT数学ナビゲーション SDにも紹介されてた、なかなか良いページだな。
サンプリングがデフォで32000/sなんだけど、これってFFTする時に都合が悪くないか？2のべき乗のデータ数のはずなんだけどな。ああ、いいのか、32768個データが揃った所でFFTすれば何の問題も無いって事だな。
Gqrx SDR
GunRadioは実験基盤。普通の人は、製品になったラジオを使いたいはず。 定番は、 Gqrx SDR みたい。（Unix系だとね）FreeBSDにも、
Gqrx is an experimental software defined radio receiver implemented using GNU Radio and the Qt GUI toolkit. Currently it supports the following devices: - Funcube Dongle Pro and Pro+ - RTL2832U-based DVB-T dongles (rtlsdr via USB and TCP) - OsmoSDR - USRP - HackRF Jawbreaker - Nuand bladeRF - RFspace SDR-IQ, SDR-IP and NetSDR - Airspy - any other device supported by the gr-osmosdr library Gqrx can operate as a traditional AM/FM/SSB receiver with audio output or as an FFT-only instrument.
こんな紹介が有った。ラズパイ3でもぎりぎり使えるみたい。
何もドングルを刺していない状態で、取り合えず起動するかどうかだけ確かめてみた。
debian:~$ gqrx
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown
Controlport disabled
No user supplied config file. Using "default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
FM demod gain: 1.52789
IQ DCR alpha: 1.04166e-05
Using audio backend: auto
BookmarksFile is /home/sakae/.config/gqrx/bookmarks.csv
getDeviceList : Available input devices:
0 : "RFSPACE SDR-IQ Receiver"
1 : "RFSPACE SDR-IP Receiver"
2 : "RFSPACE NetSDR Receiver"
3 : "RFSPACE Cloud-IQ Receiver"
4 : "RTL-SDR Spectrum Server"
5 : "Red Pitaya Transceiver Server"
6 : "Complex Sampled (IQ) File"
Loading configuration from: "default.conf"
Configuration file: "/home/sakae/.config/gqrx/default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
/path/to/your/file: No such file or directory
同然の事ながら、エラーですよ。でも、それらしい受信機の形状は出てきたな。
etc
KG-ACARS HFDL VDL MCAに感謝 受信方法 受信記録のブログPlus RTL-SDR