IM920sとGPS受信機で作る「なんちゃって追跡装置」

はじめに

秋の夜長の季節となりましたので、全国一千万人の電子工作ファンの皆様も何か作り始めている頃合かと思います。電子工作ファンの風下のずっと彼方のシヴァルツシルト半径の一歩手前位のところでぐーたらやってた私にも「汝IM920sで何かを作り給え」と新横浜方面から「天の声」が聞こえた来た訳です。

そんな訳でIM920sで何か作れとの事なので、さっそくIM920sについて調べてみました。 IM920sはインタープラン株式会社様が販売しているマルチホップ対応の920Mhz無線モジュールです。

https://www.interplan.co.jp/solution/wireless/im920s/im920s.php

主に組み込み機器向けの無線通信モジュールで、以下のような特徴をがあります。

  1. 携帯電話やWiFiのような既存通信インフラに依存しない。つまり通信費が無料。
  2. 920Mhz帯(Sub-Ghz)で免許不要
  3. 省電力でも長距離での通信が可能
  4. 動的メッシュネットワークの構築が可能
  5. シリアルプロトコルでマイコンでも容易に扱える

単に個別のデバイスから情報を取得するだけであれば携帯電話ネットワークとスマホで大抵の事が出来てしまう時代です。ソラコムのような携帯電話ネットワークを前提としたIoT向け通信サービスまである時代です。

逆に言えば、IM920sの強みは通信インフラに存在しなくとも独自ネットワークが構築出来、尚且つ通信事業者に通信使用料を払う必要がないとも言えます。

WiFiでも独自ネットワークを構築する事は出来なくもないですが、消費電力と長距離性能の面ではIM920sの方が圧倒的に有利です。

大雑把ですが、それぞれの通信システムの特徴を比べてみると、以下のような「傾向」があると思います。(あくまで大雑把な傾向なので突っ込みはご勘弁を・・・)

IM920sWiFi携帯電話
通信速度✖(100kbps)〇(数百Mbps)△(数十Mbps~百Mbps)
通信距離△(最大1.6km)✖(数十m)○(数百m~数km)
通信料金〇(無料)〇(無料)✖(有料)
通信インフラ〇(安価)△(比較的安価)✖(高額な基地局)

比較してみると、通信速度こそ桁違いに遅いという弱点はありますが、WiFiや携帯電話ネットワークと比較してIM920sが実は魅力的な通信システムである事がわかります。

この特徴が生きるアプリケーションは何かと色々思案したのですが、ふと子供時代に憧れた「あのガジェット」が出来るのではないかと思いつきました。

「追跡装置」を作る

硝煙弾雨の中、タイヤを鳴らして全速力で逃げる敵国のスパイ。皆が悔しさに唇を噛みしめ、絶望の表情で面を下げてうな垂れる。その重苦しい空気を払うように、ゆっくりと主人公が立ち上がる。その顔にはしてやったりの表情が浮かんでいた。「こんな事もあろうかと発信機を仕込んどいて良かったぜ」。懐からシガーケース程の機械を取り出して開いて見せる。緑色の円形スクリーンが姿を現すと、赤い光点がビートを刻みながら画面中央から離れていくのが見える。間違いない、敵国のスパイの位置を示している。「まだ間に合うぜ」。相棒を助手席に載せると主人公はアクセルを全開で踏みしめる。夜露に濡れる石畳にタイヤのスピンを響かせて、赤い光点を行く先を目指す・・・

以上ポエム終わり。

やっぱり昔のスパイ映画の類って良かったですよねぇ。こういうシーンよくありましたよね。実際なんの映画のどのシーンだとか言われると曖昧なんですが・・・細かい事は置いておいて、ある種の人には「追跡装置」って割とグッと来る定番ガジェットじゃないかと思うんですよ。大抵緑色の丸い画面のレーダースクリーンに、追跡相手の位置がピコンピコンと光る奴ですね。ルパン三世とか映画ジェームスボンドシリーズとか。あ、漫画「ドラゴンボール」でブルマが持っていたドラゴンレーダもその類ですね。

この手の「追跡装置」。子供心に「どうやって位置がわかるの?」と思ってた訳です。今でこそ、スマートホン+GPSがあれば出来て当然の技術ですが、当時はまだGPSも無ければ(実用化は1990年代)、携帯電話ネットワークもろくに普及してない時代です(1960年代はあることはあった)。小学生の自分でも何となく発信機の電波の強さと方向から追跡できるんだろうなぁとは思っていたものの、「ほんまかいな」と思ってはいたのですが「仕組みはともかくかっこいー」というガジェット感に鼻たれ小僧だった頃の自分は憧れた訳です。

IM920sは携帯電話ネットワーク等のインフラに依存せず、長距離通信も可能な点を考えるとこの「追跡装置」が作れるのではないかと思った訳です。

radar_denpa.png

システム案

前置きが長くなりましたが、今回はIM920sを使って「追跡装置」を作ってみたいと思います。実際にはどのようなシステムにするのか?大雑把に以下のようなシステムを考えて見ました。

GPS_SYSTEM.PNG

フィクションの追跡装置は発信機からの電波強度で距離や方向を推定するシステムだと妄想しますが、「事実は小説より奇なり」。現代はそんなフィクションの世界を飛び越えて、GPSが当たり前の時代となりました。難しい事など考えなくても、追跡装置にGPSを内蔵させ、その座標を送信すれば良い訳です。(現代っ子にしてみれば、それで当然なんでしょうが)

GPSも登場当初は米軍の最先端技術だった訳で、民生用途でも使えるようになった1990年代の印象は「高価、複雑、デカい」と言うものでした。未だにその印象が拭えなかったのですが、今回の追跡装置の件で調べて見てびっくりしました。今は500円玉程度のサイズのアンテナ内蔵GPSモジュールが数千円もあれば買えてしまいます。

GPS受信機キット 1PPS出力付き 「みちびき」3機受信対応 http://akizukidenshi.com/catalog/g/gK-09991/

秋月電子の有名キットです。

しかも衛星からの信号処理・座標情報変換などは全てGPSモジュールに搭載されたマイコンが処理するので、使う側はUARTで座標情報を読み込むだけの簡単さ。今回紹介した秋月電子のGPS受信機キットは更に日本独自の準頂点衛星「みちびき」の電波にも対応しています。

これならば複雑なシステムは全く不要という事がわかりました。GPSモジュールからシリアル通信で読み出した座標情報をIM920sのパケットとして送信するだけです。

その程度の処理であれば高性能マイコンは必要ありません。今回は「追跡装置」らしく小型化したかったのでArduino Nanoを採用する事にしました。

Arduino Nano http://akizukidenshi.com/catalog/g/gM-09059/

Arduinoは電子工作に興味のある人であれば説明不要の超定番マイコンボードです。C言語に似たプログラミング言語が使える上に、専用IDEからパソコンのシリアルポート経由でプログラムの書き込みを行う事が可能です。自分がマイコンを使い始めた頃はハンドアセンブルして、EPROMを紫外線消去装置で消して、専用ROMライターで描き込んで・・・と色々と面倒だったもんですが、いい時代になったものです・・・(秋月のROMライトお世話になりました。)

Arudino nanoはこのArduinoの開発環境が利用でき、さらにDIPサイズに小型化した製品です。今回のような簡単な内容であれば、Arudino Nanoで十分です。

IM920sについて

IM920sですが920Mhz帯(Sub-Ghz)の電波を使って情報を送受信できる通信モジュールになります。920Mhz帯は特定小電力無線局という扱いになっており、通信速度こそ100kbps程度ですが、到達距離は最大1.6キロメートルにも及びます(製品説明より。見通しのよい空間の場合)。通常、それ程の飛距離があれば免許登録などが必要となりそうですが、BluetoothやWiFiと同じ扱いでエンドユーザは免許が不要で使えます。

IM920sのスタータキット「IM920s-SK」はアマゾンで購入可能です。 https://www.amazon.co.jp/dp/B07F3VRGS7/ref=cm_sw_em_r_mt_dp_U_NRrJDb254KQG5

IM920S_PACKAGE.jpg

IM920s-SKの内容物です。4つのIM920s通信モジュールが同梱され、IM920sの様々な通信機能を手軽に試す事ができます。

IM920S_MODULE.JPG

IM920sのモジュール本体です。通信モジュール自体は上の基板です。下のUSBケーブルが刺さっている方はPCとの接続インターフェースで組込みで使う場合には上の通信モジュール単体で利用可能です。

IM920sは親機と子機との一対一の通信だけではなく、親機と複数の子機との通信も可能です。その際、マルチホップネットワーク(子機の間でバケツリレーのように情報を親機とやり取りする)の構築も可能です。

単純マルチホップ親機と全ての子機が一つのルートで接続
ツリーモード一つのルートで接続された子機グループが複数集まり、それが親機と接続
フルメッシュモード親機と子機がグループ化せずに複数のルートで接続

今回の「追跡装置」では一対一でも良いのですが、通信インフラがない環境でも通信できる事を実現したいので「フルメッシュモード」にもチャレンジしてみたいと思います。

IM920sの動作の確認

実際にシステムを作る前に、IM920sの初期設定と動作について確認してみます。

IM920sモジュールはPCと直接USB接続が可能です。今回購入したIM920s-SK スタータキットには4つの通信モジュールと3つのUSBインターフェースボードが含まれています。

IM920s単体では2.0V~3.6Vの三線式のUART端子(TxD, RxD, GND)を使って通信を行いますが、USBインターフェースボードを間に挟む事でUART-USB変換を通じてPCと直接通信する事が可能となります。

それでは実際に親機と子機をPCに接続して動作を確認してみたいと思います。

IM920sとの接続設定

IM920sとはUSBインターフェースを介してPCと接続します。PCからはシリアル通信デバイスとして認識されます。
今回はWindows10 PCから定番ターミナルソフトのTeraTermを使って接続してみます。
デフォルトの通信条件は以下の通りです。

TERATERM_SETTING.JPG

IM920sの設定概要

親機と子機が通信出来るようにするためには、同一ネットワークである事を認識する為の「グループID」と各モジュールを個別に認識する為の「ノードID」を設定します。

GROUP.JPG

親機の設定

複数のIM920sのモジュールから親機を決めます。IM920sのモジュール自体は物理的に親機、子機の違いはありません。 親機のシリアル番号をグループIDとしてネットワークを構成する全ノードに設定してあげる事でネットワークが機能します。 親機となるモジュールを決めたら、最低限度以下の設定を行います。

親機のIDの確認

ターミナルからRDIDと入力すると親機のIDが8桁の16進数で表示されます。
SERIAL.JPG
IM920sモジュールの表面にS/Nが印刷されていますが、これは10進数表記です。この印刷されているS/Nを16進数化すればRDIDコマンドの出力と一致するはずです。 私の手元にある親機はS/N 00002250なので、これを16進数化すると”8CA”になるので画面の出力と一致します。
(コマンド)
RDID
TERMINAL1.JPG
ターミナルでコマンドを入力する際、キーボード入力は画面に表示されない点、ご注意ください。正しいコマンドが入力されれば出力が戻って来ます。

ノード番号の設定

ノード番号とは同一のグループIDのネットワークに接続された個々のIM920sモジュールを区別する為の背番号だと思ってください。このノード番号を指定する事で、データ通信時の送り元、送り先を指定します。
(コマンド)
ENWR
STNN 0001
RDNN
TERMINAL2.PNG
“ENWR”コマンドはIM920sに搭載されているFlashメモリを書き込み可能にするコマンドです。ENWRコマンドを発行することSTNNで設定されるノード番号を永続的に記録します。 “STNN 0001”はノード番号を0001に設定するコマンドです。ノード番号0001は親機という決まりになっていますので、これで設定中のモジュールが親機だと確定されます。 “RDNN”は設定されたノード番号を読み出すコマンドです。ノード番号は0001に設定された事が確認できます。

グループ番号の設定(送信)

ノード番号を0001と設定した事で親機である事が確定されました。グループ番号は親機のシリアル番号という決まりなので、グループ番号を親機から周囲の子機へ送信する事で親機・子機の間のグループ番号設定が確定します。
(コマンド)
STGN
TERMINAL3.PNG
COM10は親機、COM7は子機に該当します。
親機(COM10)でSTGNコマンドを実行すると自動的にグループ番号が周囲へブロードキャスト送信されます。子機(COM7)でもSTGNコマンドを実行する事で親機のグループ番号を受信後、自動的にグループ番号が設定されます。(詳細は子機の設定で説明)

子機の設定

親機のノード番号、グループ番号が確定したところで、子機を親機のネットワークへと参加させます。

ノード番号の設定

親機のノード番号は0001ですので、この番号を避け、他の子機と重複しない番号を設定します。ここでは0002を設定します。
(コマンド)
ENWR
STNN 0002
RDNN
TERMINAL4.PNG

グループ番号の設定

親機の設定のところでも説明しましたが、グループ番号は親機からブロードキャスト送信されますので、それを受信する事で設定されます。
(コマンド)
STGN
“GRNOREGD"と表示されればグループ番号が設定された事になります。
TERMINAL5.PNG

ブロードキャスト通信実験

実際に親機から子機へ通信データを送ってみます。もっとも簡単なブロードキャスト送受信を試してます。
ブロードキャスト送信は文字通り特定の受信機を指定せず、すべての同一グループIDのIM920sへ通信データ一気に送信します。受信機からUARTで読み取りするデータの形式に2種類の方法が選べます。

DCIO非キャラクタ入出力モード
ECIOキャラクタ入出モード

非キャラクタ入出力モードはデータをHEX値として表現するモードです。それに対し、キャラクタ入出力モードはデータをASCIIキャラクタで表現するモードです。具体例を見ていきましょう。

DCIO mode

(親機側コマンド)
TXDA AB,CD
(子機側受信文字列)
TERMINAL6.PNG
[00hはダミー],[0001hは送信元ノード番号],[DFhは電波強度(RSSI)],[AB(データ1)],[CD(データ2)]
TXDAに続く文字列はカンマで区切られた16進数のHEX値としてやり取りされます。

ECIO mode

(親機側コマンド)
TXDA ABCD
(子機側受信文字列)
TERMINAL7.PNG
TXDAに続く文字列はASCII文字列としてやり取りされます。

ユニキャスト通信実験

ユニキャスト通信は送り先ノード番号を指定して、特定のノード間で通信する為の通信方法です。ここではデータ形式はECIO modeに固定します。

親機から子機へ

(親機側コマンド)
TXDU 0002,ABCD
(子機側受信文字列)
TERMINAL8.PNG

子機から親機へ

(子機側コマンド)
TXDU 0001,ABCD
(親機側受信文字列)
TERMINAL9.PNG
以上のように、非常に簡単な設定でUART経由でブロードキャスト通信、ユニキャスト通信が簡単に出来る事がわかって頂けたかと思います。

ハードウェア実装

IM920sの通信モジュールの最低限度の使い方がわかったところで、実際に追跡装置の実装に取り掛かります。とは言っても前述の通りGPSから読み出した座標情報をIM920sを通じて親機へ送信するだけなので簡単です。
システム構成をみて下さい。単純にArudinoとIM920sとGPSモジュールをUARTで接続するだけの構成となっています。注意点としてはGPSモジュールが5V電源ですが、TXD,RXDのピンが3.3V仕様になっている点です。IM920sは2.0Vから3.6V電源が必要ですが、幸いArudino Nanoは5V出力、3.3V出力両方ありますので別途システム上にレギュレータは不要です。
USB端子はプログラムの書き込み時やデバッグ時に使います。追跡装置としてスタンドアロン動作する際は電源入力端子として使います。

IM920S_SYSTEM_DG.PNG
システム構成
GPS_BOARD.PNG
実体写真
IM920S_PIN.jpg
ちなみに、IM920sをUSBインターフェースボードから外した後、上図のような足の長いピンヘッダを実装する事でブレッドボードにもUSBインターフェースボードにも接続できるのでお勧めです。

写真では画面表示用のOLEDが映っていますが、今回は間に合いませんでした。もしも反響が大きければ、続編では活用したいところです。

ソフトウェア実装

処理フロー

ソフトウェアはArduinoの標準IDEにて開発をしました。
前述の通り、基本フローは非常に単純です。

  1. 初期設定
  2. GPSからの出力をUARTで読み込む
  3. 読み込んだUARTの文字列から座標情報のみを抜き出す
  4. 座標情報をIM920Sのパケット情報へ変換する
  5. IM920SへUART経由で送信する
  6. 送信完了を待ち
  7. (2)へ戻る

Arduino Nanoですが、ハードウェアでサポートしてるUARTは1つしかありません。このUARTはUSBと接続され、普段はプログラムの書き込みやデバッグに用います。
今回、IM920sとGPSモジュール向けに最低2つのUARTが必要となりますがArduinoには汎用ピンを使ったSoftwareSerialというライブラリがあり、今回はこれを用いました。通信速度が限られる、半二重通信、複数のUARTを同時に動かせないなどの欠点もありますが、今回はこれらの制限を避ける形で実装しました。

これらの制限を前提とするとでソフトウェアを簡略化しています。(手抜きとも言う)

GPSデータの処理

GPSモジュールから出力される文字列は規格で決まっています。NMEAフォーマットという米国海洋電子機器協会が策定したNMEA 0183規格で定義したASCII文字列が出力されます。 今回利用したGPSモジュールの出力の一例を示します。
GPSからはUARTを通じて以下のような文字列が送出されます。

GPS_LOCATION.PNG
(自宅の場所がばれるので一部隠しています(^^; )
ヘッダ協定世界時(UTC)ステータス緯度北緯/南緯経度東経/西経移動速度方位協定世界時日付磁北の差磁北の方位動作モードチェックサム
$GPRMC230838.000A34AA.BBBBN139CC.DDDDE0.24291.84021019A


フォーマットの詳細はNMEAについてネット検索してもらえば有益なサイトが多数見つかると思うので触れませんが、今回の追跡装置では「緯度/経度」情報のみを使います。今回は手抜き工作なのでチェックサムも使いません(汗)

このGPSからの文字列を抜き出してしてIM920sのパケット情報へ変換します。

コマンド送信先ノードID緯度経度送信パケット番号
TXDU000134AA.BBBBN139CC.DDDDE2(デバッグ用)

(例:送信側) TXDU 0001,34AA.BBBB,N,139CC.DDDD,E,2

(例:受信側) 00,0002,34AA.BBBB,N,139CC.DDDD,E,2

受信側である親機はこの緯度/経度情報を画面に表示すれば良い訳です。

実験結果

それでは実際に動作を確認してみます。今回は自宅を中心に発信機を持って周回し、位置が検出できるかどうかを確認しました。

条件

作業環境の都合もあるのです、今回親機は自宅2階の作業用PCに接続しました。北側の部屋の窓から3m程奥まったところですので、見通しも悪く、あまり場所としては良いコンディションではありません。
今回はGPSを搭載した子機を私が手でもったまま自宅周辺を周回して、部屋の中の親機がGPS座標を取れるか確認してみました。

受信データの処理

本来であれば、リアルタイムで受信したデータを画面上にピコンピコンとリアルタイム表示するのが夢だったんですが、今回は時間の都合もあり、不本意ではありますがオフライン処理の形で位置情報をプロットしてみます。(リベンジ課題ですね)
GPS_RECEIVED.PNG
受信したデータは親機のターミナル上に上記のように表示されますので、これをログとして保存、Excelでフォーマット変換してこちらのサイトを利用してプロットさせて頂きました。
KTGIS.NET

フォーマット変換ですが、少々コツが要ります。GPSモジュールからの出力ですが例えば緯度の場合、「北緯AA度BB分CC秒」となりBBとCCが60進法表記となっています。
ところが、GoogleMapを代表するインターネット上の地図サービスはBBとCCが10進表記となっているので変換が必要となります。
(例)

緯度情報(GPS出力60進)35BB.CCCC
緯度情報(Web用10進)35.0+(((BB.CCCC)/100)/60)

ターミナルのログデータをエクセルに取り込み、緯度/経度情報を上記の変換式に当てはめ、その結果をKTGIS.NETに入力する事で位置情報をプロットしてみました。

親1対子1の場合

親1対子1の場合です。設定上はメッシュネットワークになっていますが、親機と子機2台しか動かさない場合です。
今回使ったIM920sは10cm程度のワイヤアンテナしか装備していませんので元々屋内から屋外への通信は条件が悪い訳ですが、それでも最大で85mの地点のデータは受信できました。この一番遠い地点でのRSSI値は0xA1でしたので、まだ余裕はあったかと思います。

HOME_LOCATION.PNG
親機から一番遠い箇所で85m程度です。
GPS_P2P.PNG
実際の測定結果です。

親機が置いてある南側に面している自宅前は良く取れてますが、部屋の反対側となる北側は流石に受信出来ていませんでした。今回、RSSIの受信閾値を0x80で設定していた為、もしかすると0x80以下に設定すれば受信出来ていた可能性はあります。
それでも家屋の内側に置いた10cm程度のワイヤーアンテナでここまで受信出来てるのは個人的には関心しました。

親1対子2のメッシュネットワークの場合

親1対子1の場合、家の周囲で受信が難しい理由は、親機が部屋の奥まったところに設置されているからだと推測し、中継用子機を部屋の窓辺に設置する事でホッピングさせてみる事にしました。
この場合、単純ホッピングでも良いのですが、動的ネットワーク設定のまま実験してみました。

GPS_MESH.PNG

明らかに受信箇所が増えています。前述の通り、北側は家屋の反対側になるのではやり受信が難しいようですが、西側や東側の受信点数が明らかに増えています。これは中継器がしっかりと機能した事を示しています。特別な設定をしなくてもマルチホッピングが機能したことが確認できました。

考察

今回はIM920sの通信性能の実験だった訳ですが、密かにGPSモジュールの優秀さにびっくりしてしまいました。地図との誤差は1m前後で2mはずれていません。これならば、人の移動のトラッキングを十分な精度で行えることが確認できました。 また、メッシュネットワーク用に子機を1台追加することで明らかに受信性能が向上する事が示せました。適切な地点に中継器を置けば、より遠くまで電波が届く事が確信出来ました。

将来への展望

今回は時間の都合もあり、1台の子機からの信号をPCで受信する場合とさらに1台追加した3台体制での動的メッシュネットワークしか実験できませんでした。しかし、4台すべてを使った動的メッシュネットワークを使えば複数の子機の位置情報を集める事も出来る筈です。 例えば、携帯ネットワークが存在しない山奥での登山やハイキングでのメンバー間の位置情報のやり取り、見通しのよい海でのボート間での位置情報の確認など、有益な応用例が考えられます。 また、今回は親機がPCではありましたが、親機をスマートフォンに接続する事でモバイルシステム化もそれ程難しくはない筈ですし、行く行くは完全なスタンドアロンな携帯システムにして、漫画に出てくる追跡装置の見た目まで作り込みたいですね。

まとめ

夢は映画や漫画に出てくるような追跡装置だった訳ですが、今回は時間の都合もあり、ここまでとなりました。ただ、今回試作した機材で「夢の追跡装置」は技術的に可能な見通しは立ったので、機会をみて作成してみようと思います。 世間では4Gから5Gへの移行が叫ばれるご時世ではありますが、個人レベルで広域ネットワークシステムが構築できるというのは非常に魅力的な事だと思います。

今回の記事を通じてlow bit rateなシリアル通信でもWANとの組み合わせで非常に面白いアプリケーションが実現出来る事が示せたと思っています。

正直、私も最初は「920Mhzのマルチホップモジュールってどうやって使うんだろう?なんか難しそう・・・」と思っておりましたが、蓋を開けてみれば非常に単純なシリアル通信で逆に拍子抜けした位です。UART通信という枯れた技術故に今回利用したArduinoのような単純なマイコンとの親和性が高く、既存のライブラリも色々と使えるのでラピッドプロトタイピングや一品物の工作には持ってこいです。

是非ともこの記事を参考に、もっと面白いアプリケーションを作ってくれる人が現れる事を期待しています。

(履歴)

2019.09.30 公開
2019.10.07 一部追記・修正


トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS