N.Yamazaki's blog

主に音声合成について思ったことを書いてみようと思います。
サンプリング周波数変換(リサンプリング)技術 - 応用編

keyword: サンプリング周波数変換、リサンプリング、サンプリングレート変換、アルゴリズム・方況

 

前記事(基本編)では、sinc関数を使ったサンプリング周波数の変換方法を紹介しました。
ただ、sinc関数は無限長(時間軸上で-∞から∞までの長さ)のため、そのままでは実装できません。今回は、これを有限長にする時のいくつかのテクニックを紹介します。


 

■sinc関数に窓関数をかけて有限長にする


sinc関数は、xが大きくなるにつれて次第に振幅が小さくなる関数なので、まずは適当な長さで打ち切った場合を考えてみます。

 

図1は打ち切る長さ(LW)を128、32、8と変えたときの周波数特性です。

長さを短くするほど、sinc関数の本来の周波数特性(理想のLPF)からずれていきます。遷移域(通過域から阻止域に向かう途中の徐々に減衰する部分)は短くするほど広くなり、阻止域の大きさは、短くするほど大きくなっているのがわかります。

 

図1 打ち切り長さによるsinc関数の特性の変化

 

阻止域の大きさ(サイドローブのゲイン)が大きいと、アップサンプリングの場合はナイキスト周波数で折り返した位置にエイリアシング(折り返し雑音)が現れます。ダウンサンプリングの場合は阻止域にあった信号が変換後に帯域内にエイリアシングとして出現します。これらのエイリアシングを少なくするためには、阻止域のゲインを小さくする必要があります。

 

遷移域の幅が大きいとナイキスト周波数付近の信号成分によるエイリアシングが現れます。通常、これは阻止域のより大きなエイリアシングが現れるので注意が必要です。このエイリアシングを少なくするためには、遷移域の幅を狭くする必要があります。

 

リサンプリング処理は上記2つのポイントを考慮して設計します。この2つを同時に満たすには窓長を長くします。ほかに方法はありません。しかし、窓長を長くすると、処理量の増加、遅延、プリエコーという問題が生じます。これについては後述します。

 

ところで、固定の長さでsinc関数を打ち切るというのは、sinc関数に矩形の窓関数をかけることと等価です。

矩形窓の代わりにブラックマン窓をかけた場合は図2のようになります。矩形窓と比べると、阻止域のゲインがより小さく、遷移域の幅はより広くなっていることが分かります。

このように窓関数によって特性のバランスを変えることができます。

 


図2. ブラックマン窓をかけた場合

 


■窓関数の選び方


世の中には多種の窓関数があります。Wikiの窓関数の説明では20種類以上の窓関数が示されています。なぜこんなにたくさんの種類があるのでしょうか。


窓関数には、阻止域のゲインは大きいけれど遷移幅は狭い、あるいは、阻止域のゲインは小さいけど遷移幅は広いなどがあり、いずれの窓関数もそれぞれ一長一短で、また、その周波数特性のカーブも微妙に異なります。
そのため、サンプリング周波数変換においては入力信号の特性や変換に要求される精度によって窓関数を選択することがあります。

 

例えば、入力信号に高域(ナイキスト周波数付近)の信号成分が多く重要視される場合は、阻止域が大きくても遷移域が狭いものが望ましく、24bitデータなど全帯域のエイリアシングを少なくする場合はその逆の阻止域のゲインが小さい窓関数を選択します。

 

また、阻止域のゲインも窓関数に応じて傾きが異なるため、これも選択の基準にすることもあります。

 

表1. 代表的な窓関数の遷移域幅と阻止域ゲイン
窓の種類 阻止域の大きさ 遷移域の幅
矩形         -13db 1(これを基準)
Hanning         -32db  2
Hamming         -41db  2
Kaiser         -46db(β=6.3) 2.2

 

 

■fcを下げる


リサンプリング処理は、遮断周波数(fc)をナイキスト周波数としたLPFフィルタリングと考えることができます。
そこで、fcをナイキスト周波数よりわずかに下げて遷移域を全体的に低域側にずらせば、遷移域のエイリアシングを少なくすることができます。


    sinc(x) ⇒ sinc(rx)  r:ナイキスト周波数に対するfcの割合

 

図3. fcを90%にしたときの周波数特性


デメリットは、ナイキスト周波数付近の信号レベルが小さくなります。例えば、fcを90%にした場合、fi48K fc24k*0.9=21.6KHz 21.6KHzの信号ゲインが3db小さくなります。

 

このテクニックは、入力ソースの信号にナイキスト周波数付近の信号成分が小さかったり無視できる場合に有効です。もっとも、この帯域を無視できるのであれば、それ以上高い周波数の折り返し雑音があっても無視してよいのではという考え方もできますが...。

 


■最小位相化


エイリアシングを少なくするには窓長を長くする必要がありますが、窓長を長くすると今度は遅延やプリエコーの問題が生じます。

 

遅延は通信や放送などのリアルタイムの変換が求められるときに問題となります。窓関数の長さをtwとすると、時刻tの変換値を得るには入力のt+tw/2までの値を使います。したがって、理論上tw/2(窓長の半分)の時間の遅延が生じ、窓長が長いほどその影響が大きくなります。

 

プリエコーとは、遅延と同様に、時刻tの変換値は入力のt+tw/2までの値を使うため、未来の信号の影響が先立って現れる現象をいいます。特に無音の後にアタックの強い信号が来るときに目立ちます。これも窓長が長いほど影響が大きくなり、例えば、窓長が4msのリサンプル処理にパルス状の信号を与えた場合、その2ms前から振幅が始まります。

 

この遅延やプリエコーは、"最小位相化"によって(理論上)なくすことができます。
これまで示した窓かけsinc関数は、すべて左右対称の時間波形です。これは線形位相(またはリニア位相)と呼ばれ、フーリエ変換したときの位相がすべて0になります。
これに対して、最小位相は時間波形では時刻0を中心に片側だけの波形となります。これは因果的な応答特性です。これにより時刻tの変換値を過去の入力値だけから求めることができ、遅延やプリエコーが無くなります。

 


図4.線形位相と最小位相化の時間特性


最小位相化は、窓かけsinc関数をケプストラムに変換後、時系列の片側を0で埋め、元の時間領域に戻すことで得られます。最小位相化を行っても周波数の振幅特性は変わりません。変化するのは位相だけです。

 

ちなみに、すべての位相がゼロなのが最小位相ではなく線形位相というのはややこしいですね。最小位相は本来は群遅延が最小という意味です。

 

リサンプリングにおける線形位相と最小位相の特徴をまとめると次のようになります。

 

●ゼロ位相:左右対称
・変換後の位相が変化しない
・遅延やプリエコーがある


●最小位相:片側のみ
・原理的な遅延が無い
・位相が変化する(波形の形が変化する)
・ゼロ位相より窓長を短くできる


SoXは、オプションの指定で最小位相を用いることができます。SoXのサイトには、オプション毎のさまざまな窓長や位相のサンプルが示されています。このなかで、-vsM -vM -vMa オプションが最小位相です。

 


■各種リサンプラーの実際のパラメータ


各リサンプラーで、44.1KHz⇒96KHzにリサンプリングするときのパラメータを調べてみました。

 

表2.各種Resamplerの分析パラメータ例
窓長 窓の種類 fc     処理量(参考値)
FFmpeg 32 Kaiser(beta=9) 1.0 1(これを基準)
SoX  156 Kaiser(beta=14) 0.96 2.6
AqResample  16 一般化ハミング  1.0 0.5

 

測定条件:

  • オプションは指定せずデフォルトでの値、
  • 窓長は入力サンプリング周期を1とした時の長さ、
  • fcはナイキスト周波数に対する比、
  • 処理量はWindows PC (CPU:Intel Haswell) で実データを変換したときの処理時間の実測(FFmpegを1に正規化)

 

処理量については、それぞれSIMDを使うなどの高速化を行っているため、動作環境によって大きく変わります。また、サンプリング周波数比によっても大きく変わり、特にSoXは比が大きい場合、急激に処理量が増える傾向があるようです。あくまでPC環境での目安にしてください。

 

インパルスレスポンスから求めたそれぞれの周波数特性は図5のようになりました(44.1KHz⇒96KHz)。

 

図5. FFmeg/SoX/AqResampleの周波数特性

SoXは遷移域の幅が狭く、ナイキスト周波数以下に収まっています。これによりナイキスト周波数付近のエイリアシングは無く理想LPFに近いことが分かります。阻止域の大きさはFFmpegより大きくなっています。窓長が長いのにこれはちょっと不思議な結果です。スイープ音を変換した場合はエイリアシングの抑制が-100db以上あったので、インパルス応答を用いた測定が適当でないのかもしれません。AqResampleは、窓長が短いため、遷移域の幅が広く、折り返し雑音がかなり目立ちます。FFmpegはその中間の特性です。

 

 

■最後に


ここまで、サンプリング周波数変換の特性について書いてきましたが、最終的なパラメータ等の選定基準は、実際に聴いてみて判断することが大切です。

 

今回3種類のResamplerを取り上げましたが、各々で変換したオーディオデータを実際に聴き比べてほしいと思います。Windows版 AqResampleは組み込み用のため処理量を優先し窓長をぎりぎりまで短くしています。数値上の特性では品質の劣化が激しそうですが、実際に聴取したらどう感じるでしょうか。

 

驚いたことに、高精度な処理でエイリアシングをなくしたものより、エイリアシングが残っているほうが、きらびやかでよりリアルに聞こえるなどという高評価が得られたことがありました。

数値だけを追い求め、人間が知覚できないレベルの品質にこだわったり、それを喧伝することについて、もっと考えるべきだと思います。
 

 

■おまけ - FFmpegの使い方(いろいろなオプション)


FFmpegでサンプリング周波数変換をするときの各種パラメータの指定方法です。

 

●窓長を指定
 filter_sizeに窓長を指定します。

>ffmpeg -i in.wav -af aresample=filter_size=64 -ar 48000 out.wav

 

●カットオフ周波数(fc)の指定
 resample_cutoffにカットオフ周波数を指定します。値は出力側のナイキスト周波数に対する比率です。

 下の例では、fc=48K/2*0.9=21.6KHzとなります。

>ffmpeg -i in.wav -af aresample=resample_cutoff=0.9 -ar 48000 out.wav

 

●Kaiser窓のβパラメータを指定
 kaiser_betaにβ値を指定します(2-16の間)。
 なお、βを変更すると窓長も変化するようです。このあたりの挙動は未確認です。

>ffmpeg -i in.wav -af aresample=kaiser_beta=12 -ar 48000 out.wav

 

●FFmpegでSoXと同等の変換を行うときの指定(44.1KHz->48KHzの場合)
 なお、以下は44.1KHz->48KHzの場合となります。
 fcは出力側のサンプリング周波数に合わせます fc=0.96*44.1/48=0.882
 また、複数のパラメータは':'で区切って指定します

>ffmpeg -i in.wav -af aresample=filter_size=156:resample_cutoff=0.882 -ar 48000 out.wav

 

●FFmpegでSoXのリサンプルエンジン(soxr)を使うときの指定
 resampler=soxr を指定します。

>ffmpeg -i in.wav  -af aresample=resampler=soxr -ar 48000 out.wav

 

 

■LINK


| 音声合成一般 | 15:32 | - | - |
サンプリング周波数変換(リサンプリング)技術 - 基本編

Keyword: サンプリング周波数変換、リサンプリング、サンプリングレート変換、アルゴリズム・方法

 

サンプリング周波数変換とは、オーディオデータなどのデジタル信号を、異なるサンプリング周波数の信号に変換する処理のことです。例えば、CD規格の44.1 kHzのデータをDVDの48kHzへ変換するときに使用します。

 

■原理



ここで、サンプリング周波数 fiからfoへの変換を考えます。fiとfoは単純な整数比である必要はありません。
Wikiでは、fiとfoの最小公倍数を求め、同値の内挿によるアップサンプリングを行い、LPFを通し、間引きする といった方法が示されています。しかし、以下の方法を使えば任意のサンプリング周波数にダイレクトに(ワンパスで)変換できます。

 

サンプリング周波数 fiからfoへ変換するということは、入力サンプルのfi/foおきに入力サンプルの補間値を求めることといいかえることができます。

 

ここで、
 Xn:入力信号のn番目の値
 Ym:出力信号のm番目の値
 X'(t):入力信号の時刻tの補間値(tは実数)
とすると、

formula

 

ここで、m x fi / foを、整数部(n)と小数部(dn)に分ける。

fomrmula

 

このとき、Ymは次式で求められます

formula

 

ここで、

sinc_func

 

 

upsampling

 

 

downsampling

 

 

■解説



繰り返しになりますが、サンプリング周波数 fiからfoへ変換するということは、入力サンプルのfi/foおきに入力サンプルの補間値を求めることです。

 

ただ、ここでの補間は、見かけの滑らかさとは違うことに注意が必要です。直線補間やスプライン補間などは折り返し雑音(エイリアシング)が酷くて実際には使えません。サンプリング周波数変換では式(1.1)と式(1.2)のようにsinc関数というもので補間します。

sinc関数の周波数特性は矩形特性で、カットオフ周波数がナイキスト周波数(fs/2)で急峻に減衰する理想のLPF特性です。

 

sinc関数の周波数特性

sinc_spec

 

ところで、sinc関数ってとても美しい式だと思いませんか。矩形の周波数特性の応答波形を、こんなシンプルな式で表現できます。しかも、いきなり原点が0で割るという、おちゃめな部分もあります。私がこれまでデジタル信号処理に携わってた中で一番お気に入りの関数です。

 

閑話休題。
式(1.1)と式(1.2)は、FIRデジタルフィルタの畳みこみ演算と似ています。違いはフィルタの係数列が固定ではなく、dnによって出力サンプル点毎に変化(シフト)する点です。これにより、フィルタをかけながら入力サンプル間の途中の値を求めているのです。

 

アップサンプリングとダウンサンプリングで式が異なるのは、sinc関数のカットオフ周波数(fc)を、アップサンプリングの場合は入力側のナイキスト周波数(fi/2)、ダウンサンプリングの場合は出力側のナイキスト周波数(fo/2)に合わせるためです。ダウンサンプリングの場合は、sinc関数がfiとfoの比によって横に伸長されたイメージです。

 

ここで、もうお気づきかもしれませんが、sinc関数は無限長のため、このままでは実装できません。なんらかの方法で有限長にする必要があります。

 

sinc関数はxが大きくなるにつれ振幅が次第に減少していく関数なので、適当な時点で打ち切ればよさそうですが、この部分はもう少しテクニックがあります。次回は応用編として、sinc関数を有限長にする方法について書こうと思います。

 

 

■おまけ(実践)


 

ここにWAVフォーマットのファイル in.wavがあるとします(このサンプリング周波数は任意です)。
これを、各種のコマンドプログラムで、44.1KHzのサンプリング周波数のout.wavに変換してみます。

 

FFmpegの場合
> ffmpeg -i in.wav -ar 44100 -y out.wav

 

SoXの場合
> sox in.wav -D out.wav rate 44100

 

AqResampleの場合
> AqResampleCmd in.wav 44100 out.wav

 

なお、最近のFFmpegはSoXのリサンプリングエンジンlibsoxrを内包しています。
以下のように"-af aresample=resampler=soxr"を指定することでlibsoxrを使用できます。

 

> ffmpeg -i in.wav  -af aresample=resampler=soxr -ar 44100 out.wav

 

基本的に、各プログラムの変換結果の違いは、使用している補間の関数(フィルタ係数)の違いとなります。


■リンク


 

| 音声合成一般 | 11:44 | - | - |
CentOS i386(32bit)でC++11を使う

環境:CentOS 6.9 i386

 

■debtoolsetでGCCのバージョンアップ

CentOSのGCCが4.4.7であり、C++11が使えない。GCCのバージョンアップを行うことにした。
ネットの情報によると、Software Collections のDeveloper Toolset というのをインストールすればよいとのこと。

しかし、その情報の通りに行うと、次のコマンドがエラーになってインストールできない。

# yum install devtoolset-4-gcc

[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

原因は、導入したリポジトリがx86_64用であるため。

 

■i386用のリポジトリ
そこで、見つけたi386用のリポジトリがこちら。
https://copr.fedorainfracloud.org/coprs/hhorak/devtoolset-4-rebuild-bootstrap2/

 

■インストール

# cd /etc/yum.repos.d/
# wget https://copr.fedorainfracloud.org/coprs/mlampe/devtoolset-4.1/repo/epel-6/mlampe-devtoolset-4.1-epel-6.repo
# yum install devtoolset-4-gcc devtoolset-4-binutils devtoolset-4-gcc-c++

 

■環境の切り替え
新しいバージョンのGCCを使うには次のコマンドで変更。

$ scl enable devtoolset-4 'bash'
$ g++ --version

これで、GCC 5.3.1の環境になり、C++11が無事に使えるようになった。

 

ちなみに、

 GCCはC++11 ABIの安定性の保証をバージョン5.1以降でのみ提供しています。

とのこと。

また、devtoolset-7(GCC 7.2)のリポジトリもあるようだ。
https://copr.fedorainfracloud.org/coprs/mlampe/devtoolset-7/repo/epel-6/mlampe-devtoolset-7-epel-6.repo


■参考LINK

「Developer Toolset 4でCentOS6にお手軽にGCC5.2をインストール」

CentOSで新しいGCCなどといった開発ツールを使いたい場合のメモ

CentOS 6でC/C++開発環境を整える

 

| その他 | 19:40 | - | - |
「ゆっくり声」は進化するか?!

■AquesTalk10をリリース

音声合成エンジンAquesTalkのリリースから約10年が経ち、ようやく新バージョン AquesTalk10 を、本日リリースしました。
「ゆっくり声」の音声合成エンジン、AquesTalk/AquesTalk2の後継バージョンです。

 

特徴:
・音声の周波数帯域を2倍にしてクリアな音質に
・音素データをすべて一から作り直り、さらにこれをチューニングをして、明瞭性を向上
・エンドユーザが複数の声質パラメータを操作して、自由に声質を作れる

 

当社サイトのデモページにて、9種のプリセット声種のサンプル音声が聴取できます。
また、評価版パッケージの中に、声質パラメータを自由に操作して音声合成できるサンプルアプリ「AqTk10App」が含まれています(評価版の制限あり)。

 

「 AqTk10App」

AqTk10App

 

■新しい声というジレンマ

AquesTalkの合成音声は、「ゆっくり声」として、長い間、多くのコンテンツに使われ、コンテンツの作者も、それを聴取するユーザーの耳にも、おなじみの声になっています。
これを新しい声に変更すると、サザエさんの声優が交代したときのように、間違いなく違和感が生じるでしょう。
幸い、声優と違って音声合成ソフトは歳をとらないので、ずっと同じ声を使えます。
実際、ゆっくり霊夢でよく使用されるAquesTalk F1は、2006年にリリースしてから11年間、声質は一切変わらないまま、今も使われています。そう考えると声を変えるニーズはそもそもあるのでしょうか。

一方、私としては、少しでも良いもの、進化したもの作り、それを多くの人に使ってもらいたいというエンジニアとしての勝手な欲求があります。

 

今回の新しい音声合成エンジンの開発にあたり、旧エンジンとの継続性を念頭に置きました。
新しい声になっても、これまでの声とできるだけ違和感が無いように、かつ、より良い声にすること。

これで、エンジン変更の壁を少しでも低くして、新しいエンジンを使ってもらおうと考えました。


今回、音声帯域を2倍に拡張しています。これまでの電話を通したような"こもった"音声が、テレビの音声くらいになりました。
音素片データも、すべて一新し、すべての音素にチューニングを施して明瞭性を向上させています。
 

ベースとなる音素片として、実況動画でよく使われる声種のF1E(女声1)、F2E(女声2)と、M1E(男声)の3種類を用意しています。

F1Eは、AquesTalk-F1のバージョンアップ版として、声質をできるだけ維持するように作り込みました。
音声合成の方式が異なるため、新規に作るより既存の声質に合わせるのは手間がかかる作業でしたが、違和感なくAquesTalk-F1から乗り換えられると自信を持っています。

F2Eは、AquesTalk-F2のバージョンアップ版としては少し声質が異なっています。
実況動画の「ゆっくり霊夢」と「ゆっくり魔理沙」の掛け合いを見ていると、2つの声質が似通っていて混同しやすいと感じていたため、F2EはF1Eとの違いを明確にしました。そのため、F2のバージョンアップ版としては、違和感があると思います。
うーむ。旧エンジンとの継続性が損なわれていますね。これで良かったのか・・・。
 

■実況動画で使われるか?

この新しい音声合成エンジンが実況動画で使われるようになるでしょうか。
あっという間に新しいエンジンに置き換えられることはありえませんが、完全スルーで今後も旧エンジンが使われ続けるるのは悲しいですね。
普及するかは正直わかりませんが、ゆっくり時間をかけて、少しずつこの新しいエンジンの声が使われていくことを願っています。
あと、AquesTalk10にはユーザが様々な声種を作れる機能があるので、過去にこだわらない新しい定番の声種が生まれるかもしれない。そんな期待もあります。

 

いずれにせよ、多くのユーザに使ってもらうには、まずは「SofTalk」「棒読みちゃん」「YukkuriMovieMaker」「ゆっくろいど」などの定番アプリケーションに採用してもらう必要がありますね。
 

    「ゆっくり、つかっていってね!!!」

 

■Links

| AquesTalk | 17:38 | - | - |
ミルエネのUSBドングルでスマートメーターからリアルタイムに消費電力を取得する

Keywords: Wi-SUN, HEMS, スマートメーター, ECHONET Lite

 

■概要
USBドングル「UDG-1-WSNE」を使って、スマートメーター(電力量計)から瞬時電力を習得・蓄積し、現在の消費電力などをグラフと共に表示する表示するシステムを作りました。このモニター端末をリビングに常設し、電気の「見える化」を実現。

 

表示画面

monotor-sample

スマートメーターとの接続には、920MHz帯のWi-SUN規格の無線通信で行いますので、Wi-SUN通信のハードウェアが必要です。
このWi-SUN通信デバイスとしては ROHM の BP35A1 を使った例はありますが、今回はUSBドングル「UDG-1-WSNE」を使用しましたので、はんだ付けなどの電子工作は一切ありません。
なお、この記事では、このUSBドングルを使うときの注意点のみ詳しく記述します。


■システム構成
ハードウェア

hardware
スマートメーターは、電力会社が無料で設置してくれます。スマートメータにアクセスするためのIDやパスワードの取得に、Bルートサービスの利用申し込みが必要です。

 

USBドングル「UDG-1-WSNE」は、NTT東日本の「フレッツ・ミルエネ」サービスを申し込んだときに購入しました(¥5,400)。

サーバーは何でも良いのですが、我が家では既にサーバーとして使っていたWindowsのPCを使いました。USBドングルのデバイスドライバが入れられれば、Raspberry Pi等のLinux環境でも構築できそうです。

 

表示部分は、任意のWebブラウザでOK。今回は常時表示したかったので格安の中華タブレットを購入。なお、VPNを使えば外出先から手持ちのスマホでも見れます。

 

ソフトウェア

software

毎分瞬時電力と積算電力量をファイルに書き込む「データ取得プログラム」と、そのファイル情報をグラフ等に整形してHTTP出力する「表示プログラム」の2つから構成されます。

 

データ取得プログラム

- 機能は、毎分0秒に瞬時電力と積算電力量をスマートメーターから取得し、日時と共にファイルに追加書き込む。
- プログラム側からはUSBドングルはシリアルCOMポートとして見える。
- 通信プロトコルはスカイリー・ネットワークス社のSK STACK。
- 瞬時電力等の各種情報取得にはECHONET_Liteのフォーマット。
- 今回はC++で書いたコンソールアプリ(.exe)を作って常時起動。

 

表示プログラム

- 規定のURLにアクセスすると、グラフや各種消費電力を表示し、毎分30秒になると表示を自動更新。
- WebサーバーにはIISを用い、ファイルの情報を表示用に変換する部分はPHPで記述。

 

現在、我が家では次のような項目を表示しています。

- 現在の消費電力
- 待機電力
- 今日これまでの電力量
- 分単位の消費電力グラフ
- 毎時の電力量と累積のグラフ
- 過去30日の積算電力量

 

■UDG-1-WSNEのデバイスドライバ
このUSBドングルをWindows PC(Windows7 64bit)に挿しただけでは、不明のデバイスとなりました。
「UDG-1-WSNE」のドライバーは探しても見つからなかったので、デバイス名称「USB-UART LP」からCypressのチップと想定し、CypressのUSB-SerialドライバーのPIDを以下の方法で偽装してインストールしました。

 

1.    http://www.cypress.com/sdc から USB-Serial Driver Installer - Windowsをダウンロード(アカウントが必要)
2.    ダウンロードした CypressDriverInstaller_1.exe  を実行すると以下のフォルダに展開される。
        C:¥Program Files (x86)¥Cypress¥Cypress USB-Serial Driver¥DriverBinary¥
3.    この中のCDC_Driver¥bin¥win7¥x64フォルダを任意の場所にコピー(使用するOSに応じたものを選択)
4.    CypressUsbAndBus.inf をエディタで開く。
5.    [Cypress.NTamd64]の項目に次の行を追加
        %USB¥VID_0409&PID_04C7&MI_00.Desc% = CypressUsb.NTamd64, USB¥VID_0409&PID_04C7&MI_00
6.    [Strings]の項目に次の行を追加
        USB¥VID_0409&PID_04C7&MI_00.Desc="UDG-1-WSNE CypressUsb"
7.    同様に CypressSerial.inf をエディタで開く。
8.    [Cypress.NTamd64]の項目に次の行を追加
        %CypressSerial% = CypressSerial.NTamd64,Ports¥VID_0409&PID_04C7&MI_00
9.    [Strings]の項目に次の行を追加
        CypressSerial = "UDG-1-WSNE USB Serial Port"
10.    CypressUsbAndBus.inf(USBのドライバ)、CypressSerial.inf(仮想COMポート)の順序でインストール。

 

ドライバーのインストール後、115200bps/8bit/none-parity/1stop-bit/none-flow-control のパラメータでシリアル通信が出来るようになりました。

 

■通信シーケンス
以下に、瞬時電力と積算電力量を取得したときのシリアル通信の送受信内容を示します。
コマンド体系はBP35A1と同じSK STACK IPですが、バージョンが異なるため、BP35A1と比べて使えるコマンドが少なく、フォーマットも微妙に異なっているので注意が必要です。[BINARY:XX XX...]の部分は、ASCIIでなく8bitバイナリ列として送信します。送信はバイナリで受信は16進ASCIIって仕様はちょっと違和感ありますね。なお、送信時の改行コードはCRLFです。

積算電力量は、正しくは補正係数や単位も都度取得して求めるべきですが、今回は固定としました。補正係数と単位を別途取得したところ、私の場合は積算電力量計測値(EPC:E0)の単位は0.1KWhでした。

 

SKSETPWD C  XXXXXXXXXXX ←Bルートのパスワード
OK
SKSETRBID XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ←BルートのID
OK
SKSCAN 2 FFFFFFFF 6 0 ←フォーマット注意
OK
EVENT 20 FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0
EPANDESC
Channel:2F
Channel Page:09
Pan ID:XXXX
Addr:ZZZZZZZZZZZZZZZZ
LQI:7D
Side:0
PairID:XXXXXXXX
EVENT 22 FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0
SKSREG S2 2F  ←上のChannelを指定
OK
SKSREG S3 XXXX  ←上のPan IDを指定
OK
SKLL64 ZZZZZZZZZZZZZZZZ    ←上のAddrを指定
FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX ←スマートメーターのIPアドレス取得
SKJOIN FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX ←スマートメーターのIPアドレス設定
OK
EVENT 21 FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX 0 00
〜中略〜
EVENT 25 FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX 0
ERXUDP FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX FF02:0000:0000:0000:0000:0000:0000:0001 0E1A 0E1A ZZZZZZZZZZZZZZZZ 1 0 0012 108100000EF0010EF0017301D50401028801 ←node start時の基本シーケンス
SKSENDTO 1 FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX 0E1A 1 0 000E [BINARY:10 81 00 01 05 FF 01 02 88 01 62 01 E7 00] ←E7:瞬時電力計測値 フォーマット注意
ERXUDP FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0E1A 0E1A ZZZZZZZZZZZZZZZZ 1 0 0026 1081000102880105FF017302EA0B07R0031F0B000000000E7DEB0B07E0031F0B00000000001B
EVENT 21 FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0 00
OK
ERXUDP FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0E1A 0E1A ZZZZZZZZZZZZZZZZ 1 0 0012 1081000102880105FF017201E70400000195	←最後の195が16進の瞬時電力計測値(W)
SKSENDTO 1 FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX 0E1A 1 0 000E [BINARY:10 81 00 01 05 FF 01 02 88 01 62 01 E0 00] ←E0:積算電力量計測値 フォーマット注意
EVENT 21 FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX 0 00
OK
ERXUDP FE80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX FE80:0000:0000:0000:YYYY:YYYY:YYYY:YYYY 0E1A 0E1A ZZZZZZZZZZZZZZZZ 1 0 0012 1081000102880105FF017201E00400000EB9 ←最後のEB9が16進の積算電力量計測値(100Wh)

 

■リトライは必須
無線を使ったシステムなので、通信プロトコルの途中でタイムアウトやエラーが生じます。データ取得プログラムでは、エラー時のリトライの回数や待ち時間、エラー時にプロトコルのどこから再開するかなど、多くの工夫が必要です。これまで数ヶ月運用して、週一程度の頻度で10分程度取得できなくないことがありますが、いまのところ連続運用しています。


■参考リンク

■あとがき
消費電力の「リアルタイムな見える化」は想像以上に面白いです。グラフから冷蔵庫の消費電力の時間パタンなどもわかるようになります。今はスマートメーターとの接続だけですが、今後HEMS家電を購入したら、これらもすぐに応用できそう。高価で融通のきかないHEMSモニター機器を購入しなくても、自由に好みに合わせた情報を表示・利用できるのが自作のよいところですね。


 

| 電子工作 | 13:50 | - | - |
PROFILE
Follow
CATEGORIES
LATEST ENTRIES
SEARCH THIS SITE
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
SONY MDR-CD900ST
SONY MDR-CD900ST (JUGEMレビュー »)

普段これで開発しています。
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND