安芯航という中華メーカーのTLC SSDを購入しました。
個人的には全く知らないメーカーですが、単に安かった(120GBで約3000円)ので試してみました。
NanoPi NEOの放熱と動作クロック
負荷と温度と動作クロックの一般論
PC、サーバー、スマートフォン等を高負荷状態で運用していると、CPU(というかSoC)の温度が上昇します。
こういった場面で一般的なPCやサーバーであれば、ファンの回転数が上昇するなどして、放熱効率を上げ温度上昇を抑える動きをします。が、NanoPi NEOを含めシングルボードコンピュータの多くや、スマートフォン等はファンレスであるために、高負荷状態が継続すれば温度は上昇する一方で、基本的には下がりません。
ですが、温度上昇が続けば最悪は周囲の可燃性の基盤やパーツを巻き込んで発火、そこまで至らずともデータシート上で担保された動作温度範囲外ではプロセッサが壊れる可能性が有ります。
そのような事態は製造業者もユーザもだれも望まないので、実際には動作クロックを低下させて発熱を抑えるという制御がかかることがほとんどです。
長時間使用でスマートフォンが過熱されてくると、動きが鈍くなる挙動を示しますが、これはCPUクロック、或いはGPUクロックを低下させて(さらにマルチコアプロセッサの場合は動作コア数を制限する場合もある)発熱を抑えているのです。
NanoPi NEOの場合
NanoPi NEOをARMBIANで運用している場合も、高温状態を検知するとプロセッサの動作クロックが落ちるようになっているようです。
デフォルトではガバナーにondemand(高負荷状況であれば動作クロックも速くし、低負荷なら動作クロックを下げる)が選択されていますが、一定温度以上になると動作クロック上限が制限されたような振る舞いを示します。
ですので、よほどの異常事態が起きない限りは高負荷状態を継続させても、発火するような事態には陥らないと考えられます(あくまでも個人的見解で、何らかの保証を確約するものではありません)。
パフォーマンス観点から要約すると、「熱いと最高動作クロックが制限(低下)されるため、本来の演算処理性能を発揮しない」ということになります。逆に、「適切に放熱すれば最高動作クロックの制限が発生しないため、本来の演算処理性能を発揮し続ける」と言えます。
実例
上記グラフは、日次で実行される夜間バッチ処理を実行している際、下記3パターンの放熱条件の場合の動作クロック(点線)とコア温度(実線)の関係をプロットしたものです。
プロット色 | 放熱条件 |
---|---|
水色(2018/07/03) | プラスチック板の上にNanoPi NEOを置いた状態(CPU表面がプラスチック板に接触しているか、プラスチック板との間隔が約1mm程度しかない状態)で運用 |
オレンジ色(2018/07/10) | LANケーブルでNanoPi NEOを吊るした状態で運用 |
紫色(2018/07/17) | LANケーブルでNanoPi NEOを吊るしつつ、CPUに汎用ヒートシンクを貼り付けた状態で運用 |
処理データボリュームの変動による影響を抑えるため、いずれの放熱パターンも火曜日早朝からの時間帯をプロットしています。
このグラフからは以下の事が読み取れます。
- 単にプラスチック板の上に置いただけの状態が、最も高温状態(最高80度程度)となり、多くの時間帯で816MHzまで動作クロックが低下してしまう
- その結果、バッチ処理の終了時間が最も遅い
- LANケーブルで吊るした場合、CPU表面が外気に触れやすくなるためか、5度程度の温度低下が確認でき、CPUクロックの低下頻度も抑えられている
- その結果、バッチ処理が1時間程度短縮
- さらにヒートシンクを貼り付けた場合、外気接触面積が拡大するためか、さらに5度程度の温度低下が確認でき、CPUクロックもほぼ安定して960MHzを維持している
- その結果、さらにバッチ処理時間が短縮
※紫色の点線がバッチ処理終了後に急上昇しているのは、処理後にSCPによるアーカイブ処理を自動実行するように変更したため。
RTLSDRを使ったdump1090でADS-B受信
ADS-Bとは
航空機自らが自機の各種情報(緯度・経度・高度・対地速度・進行方向等)を送信するADS-B(Automatic Dependent Surveillance-Broadcast)という情報があります。
本来は航空機の管制や衝突防止のために用いられる信号ですが、航空機のほぼリアルタイムな位置情報を表示できるアプリ・サイトとして有名なFlightRader24を含め、同様のサービスはADS-B情報をデータソースとしています。
個人でADS-Bを受信する高価な専用装置も市販されている(た?)ようですが、現在ではSDRを利用して安価なチューナーを用いて受信機を構築する事例が多いようです。
受信できるチューナー
SDRについては以前に下記投稿で触れていますが、ADS-B受信の場合にはUSBインタフェース搭載復調ICとしてRealtek RTL2832Uを採用してさえいればよいわけではありません。
wave.hatenablog.com
ADS-Bの周波数は1090MHzのため、ワンセグチューナーとして市販されている製品の多くは、搭載するチューナーの周波数レンジ外となり受信することができません。
例えば手持ちのワンセグチューナーの場合、Fitipower FC0012をチューナーICとして搭載しており、これは周波数レンジが22~948.6MHzのためADS-Bを受信することはできません。
最近では概ね500円程度からワンセグチューナーが市販されていますが、これらの多くはFitipower製のチューナーICを搭載しているようで、前述のFC0012やFC0013が実装されているようです。FC0013の場合はスペック上22~1100MHzが周波数レンジとなっているようで、ギリギリADS-Bが受信できそうにも思えますが、実際に受信できたという情報は見かけたことがありません。
故に、日本国内のワンセグテレビ放送の受信を目的として製品化されたUSB接続のチューナーはADS-B受信には使えないと考えた方が良いでしょう。
逆に、ADS-Bが受信可能なチューナーICはRafael Micro R820T、R820T2となるようです。これは国外のテレビ放送受信用DVB-Tチューナーとして市販されていることが確認されています。但し、製品名にR820Tと書かれていても実際にはFC0012が実装されていたりと、なかなかカオスなよ状況のようですので購入時はレビューなどをよく確認した方が良いと思います。
私は以下の製品を購入し、ソフトウェア上からも"Rafael Micro R820T tuner"として認識されていることを確認しています*1。また、後述の通りADS-Bが受信できていることも確認しています。
dump1090
dump1090はRTL-SDRを使用してADS-Bをデコードするソフトウェアです。
日本語でdump1090の情報を調べると、殆どの人はFlightRader24に情報をFeed(提供)するために導入しているようですが、そのためにしか使わないのは勿体ないです。
単にADS-Bの生データを数値・文字情報としてデコードしてくれるだけではなく、航空機の位置情報などをリアルタイムにJSON出力できるので、WEBサーバと組み合わせて自家製FlightRaderっぽいものを運用することなども可能です。
なお、dump1090のオリジナルは以下になりますが、dump1090 mutabilityというfork版の方が高機能です。ざっくりと、デコード可能な情報が多い、内蔵Webサーバを(デフォルトのビルドオプションでは)廃止、付属WEBアプリがGoogleMapベース*2ではなくOpenStreetMapベースに変わっておりきちんと動作するといった違いがありますので、mutability版の方をお勧めします(以降、文中でdump1090と表記した場合には基本的にはmutability版を指します)。
GitHub - antirez/dump1090: Dump1090 is a simple Mode S decoder for RTLSDR devices
GitHub - mutability/dump1090: Dump1090 is a simple Mode S decoder for RTLSDR devices
インストール
(ARCH LinuxやOpenWRTなど)パッケージマネージャからインストールできる場合*3はそれを使うのが簡単(lighttpdやuhttpdの設定もしてくれます)です。
gitからソースを入手して自分でmakeする場合も基本的にはgitに書いてある説明の通りですが、dump1090 mutabilityをインストールする場合のコマンド例は以下。
# RTL-SDRを導入 sudo apt-get install rtl-sdr librtlsdr0 librtlsdr-dev # dump1090 mutabilityをソースからビルド cd ~ git clone --depth 1 https://github.com/mutability/dump1090.git ./dump1090_mutability cd ~/dump1090_mutability make #ビルトインWEBサーバーを無効化しない場合は以下のようにフラグを指定してmake (非推奨※後述) #make CFLAGS=-DENABLE_WEBSERVER
動作確認
何もオプション指定せずに起動した場合、以下のようにコンソールの5行目にチューナ名が出力されているはずです。
ここでRafael Micro R820シリーズではなくFitipower FC00xxシリーズが表示されている場合、前述の通りそのUSBチューナーではADS-Bは受信できませんので買い替えましょう。
$ ./dump1090 | head Wed Jul 18 10:30:19 2018 JST dump1090-mutability fb5942d starting up. Using sample converter: UC8, integer/table path Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected) Found Rafael Micro R820T tuner Max available gain is: 49.60 dB Setting gain to: 49.60 dB Gain reported by device: 49.60 dB
インタラクティブモード
--interactiveオプションを指定して起動すると、付近の航空機からADS-Bデータが受信できていれば以下のように表示されます。
左から順に、以下の項目が並んでいます。説明は私の理解で記述していますので、厳密には間違っていたりすることがあるかもしれませんが悪しからず。
- Hex
- 所謂ICAO 24bit codeの16進数表現値。ネットワーク機器で言うMACアドレスや、スマートフォンのIMEI番号のようなものの航空機版と考えると解りやすく、この値が同じ航空機は存在しない。
ちなみに日本の割り当て範囲(上位6ビットが100001)の都合もあってか国交省や日本の航空当局は8進数表現してることが多い(即ち8進数表現で41000000~41777777と表現できるため8進数表現で上位2桁が41なら日本籍機と解りやすい。一方、16進数表現だと840000~87FFFFの範囲となる)。 - Mode
- ADS-BのみをデコードさせていればMode Sのみ。--modeacオプションを付与して、SSR Mode 3/Aや3/Cもデコードさせれば該当するデータの場合にはそれらの表示が出力される。
- Sqwk
- スコーク(Squawk)コードの8進数表現値(というか恐らく他の進数では表現しない)。7500でハイジャック、7600で無線機故障、7700で緊急事態を意味することがICAOで規定されている。このような異常時にパイロット側の意思で設定することができるが、平常時は管制から指示された値を設定するのが普通。
- Flight
- コールサイン。事実上、航空会社が飛ばしている航空機の場合はフライト名(便名)であることがほとんどで、個人所有機の場合はレジ(登録番号)であることがほとんど。
- Alt
- 高度[ft]。25ft刻みで変化する(ADS-Bの高度の分解能は25ftで、生データの単位がft)。
- Spd
- 対地速度[NM/h]--metricオプションを指定するとkm/hに換算される
- Hdg
- ヘディング(航空機が向いている方向)[度]
- Lat
- 緯度
- Long
- 経度
- RSSI
- 信号強度
- Msgs
- 当該航空機から受信したADS-Bメッセージ数
- Ti
- 当該航空機から最後に受信したメッセージからの経過時間[秒]
Web UI
所謂FlightRaderっぽいものです。--write-jsonオプションで指定したディレクトリに順次リアルタイムな航空機の情報が記録されますので、それを静的なHTML/JSから順次読み込ませることでWeb画面上の(ほぼ)リアルタイム更新を実現しています。
以下のスクリーンショットのように、画面右側にインタラクティブモードと同等以上の情報と、左側に航空機の緯度経度を地図上にプロットした情報が表示されます。ICAO 24bit codeから割り出した国籍に基づく国旗マークと、機体種別による飛行機アイコンの描き分けが為されている辺りが、コンソールのインタラクティブモードでは得られない情報です*4。
なお、外部Webサーバの設定が面倒だからという理由で、CFLAGS=-DENABLE_WEBSERVERを付与して内部Webサーバを有効化してmakeするのはお勧めしません。Google Chromeからアクセスすると、ERR_CONTENT_LENGTH_MISMATCHが発生し、正常に画面ロードされませんでした。内蔵Webサーバがデフォルトで無効化されていることから察するに、恐らくメンテが行き届いていないのだと思われます。公式にも外部Webサーバの利用が推奨されていることから、安定性やセキュリティの観点からも外部Webサーバを使うべきでしょう。
さくっとuhttpdやlighttpdなど外部のWebサーバを使えばERR_CONTENT_LENGTH_MISMATCHは発生しません。
負荷
受信しているデータ量によっても変化しますが、それ以前にdump1090には多様なデコードオプションがあり、それらによって負荷は変動します。
貧弱なRaspberryPi ZERO WH(シングルコアARMv6 1GHz)の場合、オプション指定によって概ね以下のような負荷変動が確認できました。
- --aggressive --enable-agc
- CPU負荷約40%前後
- --aggressive --dcfilter
- CPU負荷約80%前後
- --aggressive --dcfilter --enable-agc
- CPU負荷85%前後
なお、aggressive有り無しを試してみたところ変化が見られないと思ったら、
"warning: --aggressive not supported in this build, option ignored."
と出力されていましたので、このビルドではaggressiveオプションの指定は無効なようです(パッケージマネージャから導入したバージョンなどではaggressiveが使えることもあると思います)。
負荷100%付近で張り付くことはありませんでしたので、SDR用にシングルボードコンピュータを選定するなら、現行製品なら何使っても性能不足ということは無さそうですね(データ量が多いことが推測される空港の至近距離などで運用する場合は判りませんが)。
以上。