電気と電子と電波の日記

自分のための備忘メモです

GPS NEO-6M

令状無しGPS捜査の是非の最高裁判断が報道されている今日、ebayで送料込み4.6ドルだったGPSモジュールが香港から届いた。注文から1ヶ月で到着。
f:id:t1000zawa:20170316082541j:image


f:id:t1000zawa:20170316082719j:image
GPSモジュールはu-blox NEO-6M。

ラベルはカラープリンタで印刷したようなものが雑に貼り付けてある。shopには、oldと書いてあるが偽物、コピー品の可能性は??

付属のアンテナは2個入っていた。
f:id:t1000zawa:20170316013742j:image

PCと接続し評価ソフトで動作確認。GPSとMSAS のPRN#129(MTSAT1 ひまわり6号)、PRN#137(MTSAT2 ひまわり7号)が受信でき、測位成功。このモジュールはGNSSのうちGPSのみ対応。さて何に使うか。

 

ebayで中国から購入する超安価モジュールが増えていく…。

http://www.enri.go.jp/~sakai/pub/symp10_msas.pdf

http://www.amtechs.co.jp/2_gps/pdf/NEO-6_j.pdf

 

 

60MHz帯STL/TTL

FM放送帯がノイズっぽいこともあり、無線機 IC-7100でFM放送帯の上下を受信していたところ、63.17MHzで中波ラジオの放送音声が強力に入感していることに気づいた。イメージ混信かと思ったが内容からSBS静岡放送ラジオのSTL(演奏所ー送信所間の中継回線)とわかった。さらに65.15MHzでもNHK静岡第一放送が、弱いが入感する。いずれも熱海中継局向けの回線と思うが、50Wくらいのはず。どこから送信しているのだろう。

60MHzのアナログSTLってまだあったのかと思ったが、マイクロ回線より設備が安価で、長距離飛ぶなどの理由で利用されている。総務省の委員会ではデジタル化によってステレオ化するとか議論されていたが、今後はどうなるのだろう。

http://www.soumu.go.jp/main_content/000333628.pdf

http://www.soumu.go.jp/main_content/000358592.pdf

構築誤差

今期のサッカーJリーグの配信を担うDAZNというサービスが開幕初日からトラブったらしく報道でクローズアップされている。サービス運営会社から発表された原因は、

「配信映像へ方式変換するプラットフォームにあるスケジューリングシステムの構築誤差」

つまり配信システムの技術的な問題ということらしい。技術的な問題なら解決できる。

 

「構築誤差」って、初めて聞く日本語 。 原文は?construction error?


f:id:t1000zawa:20170301225347j:image


f:id:t1000zawa:20170316082405j:image

 

7セグLEDを使ったNTP時計

ebayでわずか1.72ドル（送料込！）で売られている中華8桁7セグメントLEDモジュールを購入。

MAX7219 8-Digit LED Display 7 Segment Digital Tube For Arduino Raspberry Pi

f:id:t1000zawa:20170226204856j:plain

 

ドライバがMAX7219なので、信号線3本でESP8266と接続可能が可能。

MAX7219のLEDライブラリと、NTPライブラリを用いて、NTP時計を試作してみた。

ESP側のピン割当を、7セグ側のピン配列にあわせることで、ブレッドボードを介して超シンプル接続。

 

7SEG側 ---- ESP側

VCC --- IO2(+3.3Vに接続)

GND---IO15(GNDに接続)

DOUT---IO13

CS---IO12

CLK---IO14

 

これ以外の配線は、ESP側のIO16をRSTに接続、3.3VとENを接続したのみ。

ちなみに下2桁は秒間を33msで歩進させ、NTSCのタイムコードジェネレーターっぽい表示（ノンドロップフレームモード）をするようにしてみた（笑）

f:id:t1000zawa:20170221002315j:plain

f:id:t1000zawa:20170221002323j:plain


f:id:t1000zawa:20170227083707j:image

 

 

 

スマートメーターと通信する その4

 ここまでに製作したブレッドボードをありあわせのクリアケースに収めて運用を開始した。ケースからは電源用のUSBケーブルが1本出ているだけ。こんな小さなブレッドボードに920MHz帯と2.4GHz帯の無線機があって、32bitMCUが2つも動いて、ネットにも接続できているというのはすごいもんだ。リアルタイムの表示は、下手に液晶や７セグLEDで頑張るよりhtmlのrefreshで表示させたほうが、文字は大きくできるし見やすく、家族受けも良い。 下の写真では液晶表示とWebサイト（30秒でrefresh）の例。数値に差があるのは表示のタイミングの差による。

f:id:t1000zawa:20170122172515j:plain

ambientには電力、R相電流、T相電流、R相＋T相電流の棒グラフが表示できている。電力の利用状況でその家庭の生活サイクルが想像できるというのがよくわかる。また、スマートメーターと何らかの理由で通信ができない時間帯も把握できる。

f:id:t1000zawa:20170214212902p:plain

 (上の表示例、横軸(時間軸)の設定が異なっているので注意)

 

ここ３週間程度連続運用した実績からわかったことは

・スマートメーターが30分おきに積算電力値を送信してくるが、そのタイミング以降、しばらく（２～５分程度）通信できない場合があるようだ。これはソフトのエラー処理がいい加減だからなのかもしれないが、teratermで手動でコマンド送信して実験していたときにも、不可解な動きのときもあったので、一概にそうとは言えないのかもしれない。また、2,3時間通信できない状態になっているのも3週間のうち4回ほどあったがどういう状態に陥るのか調べられていない。スマートメーター自身はAルート（電力会社が相手）の通信しているはずなので、Aルート側の通信時にBルートから通信要求があった場合にどうなるかなど、よくわかっていない点も多い。（（追伸）2，3時間通信できない状態になっているように見えたのは、ambientの１日のアップロードデータ数3000件の制約によるものでした）

　それでもほぼリアルタイムに電力が把握できるのは魅力的である。例えば蛍光灯を消せば、消費電力が下がるのが目に見えてわかるし、小型の機器をコンセントから外すと待機電力の数Wが下がるのもわかる。また朝食時にオーブンやトースターを使っているときにドライヤーを使うと一気に3500Wを超えて(我が家は40A契約)、もう少し電気を使うとブレーカーが落ちるのではないかというような状態もリアルに感じることができる。一定の電力量になったらアラーム出すとか、電気料金に換算して表示するとかもやろうと思えば自在。我が家は消費電力の大きな家電がR相側に偏っているのもわかった。

今回自作したようなもの(適当な名前が無いが、スマート電力ウオッチ?)が、もっとオシャレなケースに入って、台所にちょこんと置けるワイヤレスなガジェットにするとか、常時稼働しているWifiルーターや、CATVや衛星のSTBに組み込んで、HEMSのホームサーバーとしてテレビ画面に電力の状況を表示するとかしてエコ（節電）に役立つようにすればよさそうだが、そういう商品やサービスがまだ少ないのは、やはりWiSUN無線モジュールのコストやHEMS機器の認証制度がハードルなのだと思う。

無線回線は特定小電力無線局として法制度が整備され、技適も取得されていて、信頼性が高い。通信プロトコルは、国際標準化されているものが利用されている。電力の利用状況はその世帯のライフスタイルが想像できるものなので容易に傍受されてならないので、認証と暗号化がされている、などいいことづくめのようだが、あまりにしっかりしていて、通信モジュールのメーカーも国内メーカーに限られていて単価が高く、家電にどんどん組み込んでいくのはハードルが高そう。自作したシステムの原価だけでも１万円はかかっているので、量産品に内蔵するにしてもコストは5000円くらいになってしまうのではないか。

　また、今回の実験の前提である電力の スマートメーターに関しては、導入の経緯を探ると、電力自由化や省エネといったキーワードで国策として取り組んで来た様子が窺える。常識的に考えれば、電力会社からすれば検針コストは下がるものの、電力自由化や省エネは、本音は否定的だったであろうから、スマートメーターの導入自体あまり乗り気ではなかったのかもしれないし、メーターの導入コストは電力料金に転嫁され、消費者に選択の余地がないのはいかがなものかといった議論や、メーターが電波を出すのだから、電磁波の健康影響を懸念した意見など、いろいろな議論があったようだ。

一時的なはなしだがこういうエピソードも。

http://diamond.jp/articles/-/72437

 

今回の実験はそうした経緯があって、その上で遊ばせてもらっている。Wi-SUNとECOHNETLite、今回の実験を通じて触れることができたのは良かったが、まだまだいばらの道を感じる。

 

 

 

スマートメーターと通信する その3

さて、実際にやってみます。

 
■仕様
電力スマートメーターBルートサービスを利用して、屋外に設置されている電力会社のスマートメーターと通信し、現在の消費電力（瞬時電力計測値）と電流（瞬時電流計測値）を取得して出力するシステムとする。
得られたデータの出力先は、シリアルポート、液晶表示器、ESP内に動作させる簡易httpサーバー、IOT用クラウドサービス"ambient"とする。
 
■ハードウェア
お手軽にブレットボート上に配置した。主なハードウェアは3つ。
・スマートメーターと通信するWi-SUN対応無線モジュールBP35A1（技適取得済）
・WiFiモジュールESP-WROOM-02(ESP8266)（技適取得済）
・PCとWiFiモジュールを接続するためのUSBシリアル変換モジュール
 
・BP35A1とESPは、ESP側は仮想シリアルポートライブラリSoftwareSerialを使ってシリアル接続(12,13番pinを割り当て。9600bpsに設定）
・ESPとPCは、ESPのハードウェアシリアルポートをUSBシリアル変換モジュール経由で接続（115200bpsに設定）
・ESPと液晶表示器は、I2Cで接続。(4,5番pinを割当）
・ESPはWifiで自宅LANに接続。
・電源電圧は3.3Vで設計（BP35A1もESPも3.3V動作なので）
 
■ソフトウェア
・ArduinoIDEで作成。
先人のブログにしっかりとしたソースが公開されているところがあり、多少手直ししてコンパイルしたものESP8266に書き込んで動かすとwdtエラーが出てうまくいかなかった。（loopにdelayを入れたが解決せず、深追いしていない）
とりあえず手打ちのコマンドを単にコード化しただけのようなもので試作。ソースなんぞ恥ずかしく公開できない。概要だけメモする。
 
(1)BP35A1の設定
あらかじめ、BP35A1の電文を、ROPTコマンドで16進ASCII dumpモードにしていることが前提。teratermから手動でいろいろコマンドを叩いて慣れたこともあり、相手の出方もだいたいわかったので、相手の言うことは無視してひたすら一方的に走り、意図した応答がなければしばらく経ってからリトライする、という乱暴なコードで試してみた。ESPとはSoftwareSerialで通信するようにしたが、ハードウェアシリアルの方が安定しているというレポートが多く、確かに文字化けが時々発生するようだが、入れ替えが面倒なのでそのまま。
 
#include <SoftwareSerial.h>
　SoftwareSerial sSerial(12, 13);
で開いたシリアルポートを使って、無線モジュールに必要なコマンドを発行する。SKSCANの後のレスポンスは相手の応答が時間がかかることが多いので、delayを多く取っている。SKSREGのパラメータ（920MHz帯のチャンネル番号とPAN ID）は、SKSCANの結果得た値を固定値で入れている。周囲にスマートメーターが増えてきたら、変更が必要になるかもしれない。SKJOINのパラメータ（スマートメーターのIPv6アドレス）もあらかじめSKLL64コマンドで得ておいた固定値を入れている。
 
 void setup_BP35A1() {
  sSerial.println("SKVER");
  delay(500);
  sSerial.println("SKTERM");//念のため
  delay(500);
  sSerial.println("SKSETRBID your ID");
  delay(500);
  sSerial.println("SKSETPWD C your password);
  delay(500);
  sSerial.println("SKSCAN 2 FFFFFFFF 6");
  delay(15000);
  sSerial.println("SKSREG S2 33");
  delay(5000);
  sSerial.println("SKSREG S3 001D");
  delay(5000);
  sSerial.println("SKJOIN FE80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx");
  delay(10000);
}
 
(実際はハードウェアシリアルポートにコマンド発行の進捗を出力してるがここでは省略)
 
 SKJOINのあと無線モジュールからEVENT25（PANA接続OK)が返ってくればOKだが、頑としてEVENT24（PANA接続NG)しか返してくれない状態が続く場合があり、その際はSKSREGから戻って再度SKJOINするようにしている。
ENENT25を返してくれることを前提に、次に進む。
 
(2)ECHONETLiteコマンドの発行
PANA接続がOKになれば、暗号化されたUDPパケットでの通信に入る。SKSENDTOコマンドで 相手のIPv6アドレスに対して、即時電力値と電流値をくれ、と言うだけなのだが、いろいろ前口上を言わなくてはならない。（値の意味の解説はここでは省略）。ECHONETLiteコマンド部分だけバイナリデータで送る必要があるので16進ASCIIで送れる部分は普通に送った後、バイトデータを送出、最後に改行で締める。
 

void send_ECHONETLiteComm() {

　int ECHONETLiteComm[17] = {0x10, 0x81, 0x00, 0x01, 0x05, 0xFF, 0x01, 0x02, 0x88, 0x01, 0x62, 0x02, 0xE7, 0x00, 0xE8, 0x00}; //コマンドバイト列

　　sSerial.print("SKSENDTO 1 FE80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx 0E1A 1 0010 "); //UDPハンドラ、宛先、宛先ポート番号(0x0E1A)、暗号化フラグ、送信データ長の送信(16byte) 、スペース(0x20)

　　int d = 0;  for (d = 0; d <= 15; d++) { //コマンドの送信

  　　　　int senddata1 =  ECHONETLiteComm[d];   

　　　　　sSerial.write(senddata1);

　　　　  }

　sSerial.println();

}　//改行送信して終わり

 

(3)電文の受信

　ECOHONET Liteコマンドを送り終えたら、仮想シリアルポートを監視して、データが来たら変数配列に格納。改行コードが来たら、改行コードの前の所定の位置が、瞬時電力取得値を示す0xE704かつ瞬時電流取得値を示す0xE804であるかチェックし、そうであるならば、それぞれの値(16進ASCIIテキスト)を取得し10進整数に変換するという手抜きなもの。各電文のヘッダは見ていない。

　スマートメーターは30分おきに積算電力値を送り付けてきたリ、900秒ごとにPAN認証をし直したり、ビーコンを撒いたりしてくれるが、それらの電文は無視している。また、コマンドを送出後相手がダンマリになった場合、所定の秒数経過後、SKSREG、SKJOINからやり直すようにしている。

(4)結果の出力

　瞬時電力測定値と、瞬時電流測定値（うちは単相3線式なのでR相、T相それぞれ電流値が得られる）が得られたら、簡易なhtmlを生成し、ESP8266webserverで他のPCのブラウザから読めるようし、さらに値をambientに送信し、液晶表示器にも表示されるようにした。現在時刻はNTPを使って得ている。

　スマートメーターとの通信頻度はとりあえず30秒。920MHz帯特定小電力無線の通信時間の制限は超えていないはず。

f:id:t1000zawa:20170207132522j:image

１枚のブレッドボードにまとめてみる。

f:id:t1000zawa:20170207132707j:plain

続く。

 

 

 

 

スマートメーターと通信する その2

スマートメーターと通信するためのシステムを自作するには、スマートメーターの通信規格にあわせた無線機と、データ通信のプロトコルに準拠したソフトが必要である。スマートメータの通信規格は、物理層からトランスポート層までは、「Wi-SUN（ECHONET Liteプロファイル）」、アプリケーション層は「ECHONET Lite」となっている。

　Wi-SUNは、物理層はIEEE802.14.g。日本国内の電波法では920MHz帯の特定小電力無線局の扱いになっており、ARIB STD-T106準拠。ネットワーク層はIPv6。認証や暗号化などセキュリティは「PANA」が採用されている。

　ECHONETは、エコーネットコンソーシアムのサイトによれば

スマートハウスを実現する通信プロトコルです。スマートフォンやコントローラから、家にあるエアコン、照明などを制御したいとか、電力の無駄遣いを抑えるために家の電気代を把握したいとかいう要望が増えています。（中略）どのメーカーの機器でも共通に理解できる約束（通信プロトコル）が必要で、その役割を果たすのがエコーネットです。特にエコーネットライト(ECHONET Lite)規格は急速に普及したインターネットに対応し、エコーネット規格より簡単で使いやすさを重視した通信プロトコルになっています。
エコーネットライト規格はすでに１００を超える種類の機器に対応し、今後全世帯に設置されるスマート電力量メータにおいても採用されています

とされている。

　Wi-SUNにしてもECHONETにしても日本発の規格で、国際的な普及を目指しているが、その経緯や進め方といまの普及状況からすると、イグアナの島のことを想像してしまう。

各規格の関連資料をまとめておく。

https://www.nict.go.jp/publication/NICT-News/1402/01.html

Home - Wi SUN Alliance

http://www.arib.or.jp/tyosakenkyu/kikaku_tushin/tsushin_std-t108.html

https://www.toshiba.co.jp/tech/review/2005/05/6　（東芝さんが「PANA」を語る（笑））

http://crypto-protocol.nict.go.jp/AKE_zoo/PANA/PANA_Abstract.pdf

0_05pdf/f03.pdf

エコーネット規格（一般公開） | ECHONET

 スマートメーターBルートサービスの総合的な解説はこれ。実質これを見ればだいたいわかるでしょう。

http://www.meti.go.jp/committee/kenkyukai/shoujo/smart_house/pdf/006_s03_00.pdf

http://www.iij.ad.jp/company/development/tech/techweek/pdf/151113_4.pdf

さて、これらの規格に準拠したシステムをゼロから自作しようとすると、素人にはほとんど手がでない。Wi-SUN対応で、ECHONET-Liteが利用可能な部品は、数社から出ていて、無線モジュールタイプのもの、USBドングル型のものがある。今回は、マイコン（Aruduino）に接続して楽しむのが目的なので、入手性や情報の多さで、ロームのWi-SUN対応無線モジュールを選んだ。2014年に発売されたBP35A1に加えて、 第2世代のBP35C0が出ているが、作例の多いBP35A1にする。

www.rohm.co.jp

購入は、チップワンストップを利用。

www.chip1stop.com

購入したのはこの３点。 DIP化してブレッドボード上で実験したいので。マザーボードBP359Cは、お値段高いので見送った。

BP35A1 ( Rohm )  7,490円  　本体
BP35A7A ( Rohm )   800円 　アダプターボード（DIP化のためのボード）
BP35A7-accessories ( Rohm )  190円 　ネジとピンヘッダのセット

それにしても、お値段が高いなあ。普及の状況を考えれば仕方なしか。12月21日に発注して、翌々日に届いた。クリスマスプレゼントだな。

 f:id:t1000zawa:20161223123916j:plain

f:id:t1000zawa:20161223124158j:plain

　さて、通信モジュールと、認証ID、パスワードが揃ったところで実験開始。折しもトランジスタ技術　2017年1月号　の第２特集のテーマがスマートメーターで、BP35A1での記事というのをAmazonのおすすめで知り、すぐに本屋に走った。

http://toragi.cqpub.co.jp/Portals/0/backnumber/2017/01/p118.pdf

　今回はWi-SUN無線モジュールを、Aruduino互換のESP-WROOM-02(ESP8266)とをシリアルポートで接続し、ESP8266側からシリアルポートで各種コマンドを送って920MHz帯で通信し、スマートメーターから得たデータを、ESP8266で処理して、消費電力を表示させたり、2.4GHz無線LANでアクセスして、ネット越しに消費電力が見えるようにしようと考えた。

　まずは無線モジュールの動作確認からやってみる。

f:id:t1000zawa:20170121172423j:image

ESP8266のシリアルポートに送られてきたデータを、もうひとつのシリアルポート（softwearSerial)に出力するスケッチを走らせて、PCから送ったデータをESP8266経由でBP35A1に送り、返事を返せるようにして、コマンドをたたいてみる。

f:id:t1000zawa:20170121172448j:image
 応答は正常に返ってくるが、文字化けが出やすい。PC-ESP8266間は115200bps、SoftwareSerialで接続しているBP35A1とは9600bpsにして落ち着いた。BP35A1のWUART設定は43（9600bps、フロー制御なし、キャラクター間インターバルなし）とした。（キャラクタ間インターバルは無いほうが文字化けが少なかった）

http://rabbit-note.com/wp-content/uploads/2016/12/50f67559796399098e50cba8fdbe6d0a.pdf#51

 

さて、この後を考えるにあたり、先人のブログを参考にさせていただく。

スマートメーターからリアルタイムに消費電力を取得する - Okiraku Programming

スマートメーターの情報を最安ハードウェアで引っこ抜く - Qiita

自宅がスマートメーターになったので消費電力を取得してみて、ついでにいろいろやってみたお話 | 雑記帳 - Just another WordPress site

 つづく