蛍光検出 --- デバイス編

光関係では「微弱な光を検出する。」、「蛍光を捉える。」という
テーマがあります。

浜ホト製PMT、I-Vアンプ

幸いにも日本にはノーベル賞を支えていると言っても過言ではない浜松ホトニクスという光デバイスメーカがあります。これは光関係者にとっては強力なインフラと言っても良いくらいにありがたい存在です。

日亜製LED(365nm、400mW)を使用した励起光源

次に蛍光検出の為には励起光が必要ですが、可視域で
あればあらゆる発光デバイスが入手できます。
しかし、励起用途ではスペクトルの広がりは慎重に検討しなければなりません。
紫外領域であればなんといっても青色LEDで有名に
なった日亜化学の製品が安心です。（スペクトルは
確認しなければなりませんが。）

更にLEDでは細かなリクエストに応じて頂ける株式会社エピテックスも貴重な存在です。

今や国産CPUは影を潜め、機能ICも元気のない日本ですが、私達のような用途で使用する光関連デバイスは良い物があり恵まれています。しかし、O/E、E/O部分以外はMADE IN JAPANの文字がないのはさびしい限りです。

Voyager of the Seas 入港

4/27に東京港に世界最大級の豪華客船Voyager of the Seasが入港しました。
高さの制約からレインボーブリッジを通過できないので大井埠頭に着岸だそうです。
写真は青海南ふ頭公園から撮影。

大井埠頭から出港

こういう出港風景をみていると、モールスの入圏、出圏通知が聴こえてきそうです。

そんな郷愁のあるモールスが廃止されてから10年以上が経ち、今では自動船舶識別装置のお陰でネット上で誰でも船の位置や動向を知ることができます。

http://www.marinetraffic.com/ais/

職場は海から近いので気になる船がいれば、
AISデータからすぐに調べられます。

AISは国際VHFの161.975MHz、162.025MHzでFM/GMSK、9.6Kbpsという仕様のようですから、SDRで十分に復調できそうです。

GNU Radioとは

最近、GNU Radioと呼ばれているソフトウェアに注目しています。

これはソフトウェアで無線信号処理をおこなってしまおうというもので、SDR (Software Defined Radio)と呼ばれています。その起源は米国の軍事的なニーズにあります。
現代戦はNCW（Network Centric Warfare）、ネットワーク中心の戦いと呼ばれているようにあらゆるシステムをネットーワーク化し、統合運用する必要があります。これが統合戦術無線システム、JTRS (Joint Tactical Radio System)として具体化されているわけです。

このように軍事的ニーズに端を発したSDRですが、私たちの周りには強力な使い切れない程の計算能力をもつPCがあり、ソフトウェアも容易に入手できることから身近になりつつあります。

このソフトウェアの中身は信号処理アルゴリズムの宝庫であって無線信号処理だけでなく他の信号処理にも使えそうです。（実際に使えます。）おまけにリアルタイム性があるので実用的です。

これらSDRのプラットフォームはGNU Radioの他にもOSSIE 、Ｉｒｉｓがあり、それぞれ特徴をもっています。組込み用途ではOSSIEやIrisも検討対象です。

私達は信号処理理論をバックグラウンドとして、GNU Radioをなどオープンソース・ソフトウェアの応用を考えています。

RFワールド --- CQ出版

RFワールドという雑誌がCQ出版から出版されています。
この雑誌のコンセプトは”ブラックボックス化された無線技術を理解する。”ということ・・・だと思いますが、今の無線技術は驚くほど存在を意識させないようになっています。

ここで言うブラックボックス化はふたつの意味があると考えています。

ひとつは、

高周波回路がIC化されて、個別機能部品が見えなくなり回路を追うことができなくなった。

そして、もうひとつは、

無線LAN内蔵PCのように無線機能が装置に内蔵され無線装置どころかアンテナまでもが目に見える存在ではなくなった。

この雑誌が創刊されるとの情報を知った時は楽しみでしたが、ひょんな事から記事を書かせて頂く機会を得ました。

タイトルは”写真で見る軍用艦船のアンテナ”。本当はアンテナではなく”空中線”がよっかたかもしれませんね。

昔ながらの無線屋さんは”アンテナ”ではなく”空中線”という響きが好きなはずですよね。
特に大空に開口していれば。。。

測距原理（２） --- TOF (Time Of Flight)

測距技術の基本方式がTOFと呼ばれているものです。飛行時間ですから、文字通りに目標までの光の往復時間を計測して光の速度をかければ求められます。原理だけは小学生でも分かります。

2.2m先からの反射パルス

しかし、光の速度は秒速３０万Ｋｍ、１秒間に地球を７周半、月まで約１．３秒という表現されように測距技術から考えると本当に困るほどの超高速です。仮に１０ｍ先のターゲットからから反射してくる時間は１億分の６．７秒（６７ｎｓｅｃ）。１ｃｍ単位の距離が知りたければ１０００億分の６．７秒（６７ｐｓｅｃ）という短い時間を計測しなければなりません。

 

汎用測距実験装置（社内用）

確かに研究室レベルであればダイレクトに計れる測定器はあります。しかし、フィールドにそんな測定器を持ち出すことは現実的ではありませんし、価格まで考えるとますます現実離れでしょう。

実際に単純なTOFの方式の場合、数十ｃｍの分解能と考えてよいでしょう。これは現実的に製作できるカウンタ回路は数１００MHｚで、時間分解能は数ｎｓｅｃ程度という数値を想定しています。

 ゴルフの用途に使われている距離計はこの方式が主に採用されています。精度も１ヤード程度あれば十分ということもありますが、レーザの目に対する安全性などもこの方式が採用される理由となっています。

ImageJ

今では有名になってきた画像処理ソフトウェアで、開発はアメリカ国立衛生研究所（NIH)でおこなわれ、オープンソース＆パブリックドメインの画像処理ソフトウェアです。
税金で開発されたものは公開を基本とするということなのでしょうが、米国外の私達も自由に使えるのはありがたいです。起動すると一瞬、はっ？と思ってしまうほど地味なユーザI/Fではありますが、実は硬派な実力の持ち主です。
ここからダウンロードできます。

ImageJとサンプル画像

NIHということで、バイオ関係と思われがちですが、バイオ関連画像であろうがリモートセンシング画像であろうが、自分の目的に応じて自由に画像処理や画像解析ができます。

ありがたいのは、plugin次第で沢山の画像フォーマットに対応できること。例えば、Carl Zeiss Microscopyの顕微鏡画像はzvi形式で保存されますが、pluginを導入すると開くことができます。

"imagej plugin"で検索をおこなうと沢山のPluginが見つかります。これらの中から必要なものを取り込めば益々、便利になっていきます。

私達は画像処理関連の開発を行う際に、このImageJで前処理やアルゴリズムの確認を行っています。

測距原理（１）---幾何学的方式とレーダー方式

ここでの測距原理はレーザやLEDを使用したいわゆる光波によるものを前提としています。
もちろん、レーダー方式であれば電波、音波にも適用できます。

幾何学的方式は三角測量の原理を利用したもので、通常、LEDとPSDデバイスを組合せてPSD上に結像した光スポット位置に応じた光電流値から距離を求める方式です。

この方式で重要な点は以下のとおりです。

　・スポットの明るさに影響されないよう２系統の電流値で正規化すること。
　・光源（LED）とPSD間の距離によって性能が左右される。

 この方式は原理的に遠距離かつ高分解能を要求する用途には対応できませんが、身近に多数使用されています。

これから解説する測距技術は測定距離は数ｍ以上、分解能がｍｍを実現するものですので、この方式は対象となりませんが、広く利用されているためふれておきました。

通信、レーダーの要素技術を他分野に。

通信やレーダーの技術をベースに他分野の開発に携わると、あの技術が適用できるとか、逆に、こうすれば通信のあの技術が使えて解決できそうと思えることがあります。

米艦艇に装備されたFURUNO（日本）製のレーダ
※ある国ではレーダのことを”フルノ”と呼ぶらしい。

例えば、吸光度（光の透過率）を計測する場合、普通は透過光をPDで受けてI-V変換してADCに取り込んで・・・。

これをデジタル通信の考え方を取り入れるとどうでしょう。

誤り率の計測でレベルが逆に推定できるのでは・・・。

となると、吸光度計測が電圧の計測ではなくカウントでいけるのでは？

こう考えると、”光量 vs 電圧”だったものが、
”光量 vs カウント数”となり、全く物理量の違う計測でできる
のではと想像されます。

2波長吸光度計測実験

 
もう一つ、計測対象のS/Nが悪い場合、信号源のパワーを上げたり、低ノイズOPアンプを探してノイズフロアを低下させたり等、真っ当なアナログアプローチを考えます。

ここで通信の誤り訂正符号の考え方を導入するとどうでしょう。
符号化利得が得られのでS/Nが改善するのでは？と想像できます。

しかし、いくら通信やレーダ技術を！と言っても、そのものずばりのハードウェアを用意するには大変です。

幸いなことに、今では有り余るPCの計算能力が身近にあり、一昔前までは困難であった信号のリアルタイム処理がソフトウェアで処理できる計算パワーがあります。また、ソフトウェアもLinuxで代表されるようにいろいろなOSS(Open Source Software)が自由に入手でき、目の前の課題に対して適度な粒度で考えることができるようになってきています。

この適度な粒度という部分が大切で、例えば、FFT を使おうとする人の誰もがFFTアルゴリズムを書く必要はないと思うのです。検証されている部品を有効に使って課題解決の効率をあげることの方が重要です。

ネジ止めをするのにネジやドライバから作る人は誰もいませんよね。