Programminblog

Power Log Readerをアップデート

2021-05-15T10:01:00.001+09:00

PCの電源イベントから出退勤時刻を推定するアプリに機能を追加しました。

記録の無い日をカレンダー上で選択できないようにしました
日毎の要約を丸め無しで表示できるようにしました

インストーラはGitHubからダウンロードできます。

https://github.com/true-nature/PowerLogReader/releases

Power Log Readerの多言語化

2021-02-11T12:57:00.001+09:00

PCの電源イベントから出退勤時刻を推定するアプリを、英語に加えて日本語でも表示できるようにしました。GitHubで公開しています。

https://github.com/true-nature/PowerLogReader/releases/

在宅勤務者の勤怠時刻をイベントログから推定するアプリ

2021-01-02T01:46:00.001+09:00

タイムレコーダーの無い在宅勤務環境で、PCの起動/シャットダウン時刻から出退勤時刻を推定するためのアプリ Power Log Reader を作りました。

　Windowsのイベントログの中からカレンダーで選択した日の記録を抽出し、PCの開始/終了に関する記録をピックアップして時刻と一緒に表示します。ノートPCでの利用も考えて、スリープ/復帰に関するイベントも抽出するようにしました。

　勤怠時刻の単位時間、丸め規則(四捨五入/切り上げ/切り捨て)、PCの起動/シャットダウンに要する時間を設定すると、日毎のサマリーに反映されます。日付の切り替わり時刻を0時以降にずらす事もできます。

　アプリ製作のきっかけは、自己申告制の勤怠管理で記入忘れを補完するためでした。PCの動作記録を簡単に調べられたら、記憶に頼らずとも正確な時刻が推定できると考えて作ってみました。

ビルド済みのインストーラをリリースページに置いておきました。動作には .NET Framework 4.8 が必要です。

https://github.com/true-nature/PowerLogReader/releases/

TWELITE SDK on Docker

2018-10-14T08:08:00.002+09:00

最近、仕事で非公開用のgitサーバとしてGitLabをインストールしたところ、おまけで付いてきたGitLab CIと、gitlab-runnerで動かすDockerがとても便利で気に入りました。
　Linux上でビルドできるなら大抵のものに応用できるはずなので、試しにTWELITE SDKのLinux版を組み込んだDockerイメージを作って、GitLab CIと組み合わせてみました。
　サンプルのプロジェクトを、GitLabで公開しています。
　　https://gitlab.com/twelite/app_twelite

　Dockerイメージを作るためのDockerfileは以下のようにしました。

FROM ubuntu:18.04

RUN sed -i s://archive.ubuntu.com://jp.archive.ubuntu.com:g /etc/apt/sources.list
RUN apt-get update
RUN apt-get install -y make curl libc6-i386
RUN curl -o MWSDK_Linux-i386_201805.tgz https://mono-wireless.com/download/SDK/MWSDK_201805/MWSDK_Linux-i386_201805.tgz
RUN tar zxf MWSDK_Linux-i386_201805.tgz
RUN rm -r MWSDK_Linux-i386_201805.tgz MWSDK/Wks_TWELITE

基本は、Ubuntu 18.04にTWELITE SDKをcurlでダウンロードして展開しているだけです。一点重要なのが、libc6-i386をインストールしておくことです。TWELITE SDKに入っているコンパイラの実行ファイルは32bit Linux用なので、これが無いと64bit Linuxのmakeからコンパイラを起動できず、

make: /builds/ChipLib/SW4063V1416/../../Tools/ba-elf-ba2-r36379/bin/ba-elf-gcc: Command not found

のようなファイルがあるのに「コマンドが無い」という不可解なメッセージが出ます。
上記のDockerfileをビルドしたDockerイメージを、Docker Hubに用意しておきました。
https://hub.docker.com/r/truenature/mwsdk/tags/

　GitLab CIの設定ファイル .gitlab-ci.yml は、以下のようにしました。

image: truenature/mwsdk:18.04_201805

stages:
  - build

before_script:
  - pwd
  - ln -s /MWSDK/* ../../

blue:
  stage: build
  script:
    - cd Master/Build
    - make TWELITE=BLUE clean all
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    expire_in: 2 weeks
    paths:
      - Master/Build/*.bin

ビルドしておいたDockerイメージを image: で指定しています。
　TWELITE APPSとして公開されているサンプルアプリは、2階層上のディレクトリにTWELITE SDKのツール群が配置されていることを前提にMakefileが用意されていますので、before_scriptで最初にシンボリックリンクを用意しています。
　サンプルアプリにはテストコードが含まれていないため、stageはbuildだけです。サンプルアプリのトップにあるMakefileは下位のmakeにビルドを丸投げして失敗を無視する仕様のため、Master/Buildまで下りてmakeを行います。
　ビルドしたファームウェアバイナリは、artifactsでダウンロードできます。

　GitLab CI/CDを有効にしておくと、pushやマージリクエストが処理される毎にpipelineが実行されます。
　　https://gitlab.com/twelite/app_twelite/pipelines
GitLabにホストされたプロジェクトでshared runnerだけを使っているので、とても時間がかかっているように見えますが、ローカルにGitLabをインストールして専用のgitlab-runnerを登録しておくと、見ている間に(数十秒で)完了します。

　プライベートなGitLabでローカルにビルドしたDockerイメージを使う場合は、

ローカルに命名、タグ付けしたイメージを image: で指定する
gitlab-runnerの pull_policy に'never'または'if-not-present'を指定してDocker Hubからのpullを予防する

のような設定が必要です。

Raspyberry Pi 3Bに小型ディスプレイを装着

2018-05-06T21:24:00.000+09:00

今まで、Raspyberry Pi 3BのディスプレイとしてPC用ディスプレイを使っていましたが、もっと手軽に使いたいので、安くてコンパクトなRaspberry Pi 3B用HDMIモニタをamazonで買いました。解像度は低いですが、私の用途では問題にはなりません。また、Windows 10 IoT用のドライバが無いのでタッチスクリーンが機能しませんが、USBマウスを使えば大丈夫です。

Windows 10 IOT Core + TWELITE

2018-04-21T22:37:00.000+09:00

Raspberry Pi 3Bで動いているWindows 10 IOT Core用にアプリを書き始めました。UWPアプリは初めてなうえに、XAMLも初心者の域を出ないので、なかなか捗りません。
　TWELITEでドアの開閉を検出して、予め登録したMACアドレスにWake On LANパケットを送出するのがアプリの主な機能です。同様の仕組みはPython/Raspbianで動作しているのですが、誰でもメンテナンスできるように、UWPアプリとして作り直すことにしました。

シリアルポートに流れるTWELTIEの出力を読むバックグラウンドアプリ
設定およびログ表示のためのフォアグラウンドアプリ

という基本構成は固まりました。バックグラウンドとフォアグラウンドの間の通信ができるまでに試行錯誤を繰り返し、BackgroundTaskとAppServiceでやりたいことができるようになるまでかなり時間がかかりましたが、ようやく見通しが立ってきました。

TWE-LITE 2525Aの連続稼働が終了

2017-03-07T07:44:00.001+09:00

TWE-LITE 2525Aの連続稼働が、電池切れにより3月6日の朝で終了しました。11月17日の夜から開始して、およそ3カ月半、108日動き続けました。

　電池切れ間際の電源電圧は約2Vでした。グラフを見ると、2.2Vあたりから電圧低下が早くなっているように見えます。2.1Vから約1週間で終了しました。

　記録された送信回数は25,000以上でした。年末年始にログが取れなかった期間があるので、実際には26,000回を超えていたのではないかと思います。一回のドア開閉で2回の送信が行われるので、一日当たりドア開閉回数はおよそ120回という事になります。

　加速度センサーの消費電流を仮に40μAとすると、一日当たり0.96mAhが消費されます。使用したコイン電池の容量は210mAhですので、加速度センサーとTWE-Liteでだいたい半分ずつ消費していたようです。この計算だと、ドア開閉が多ければ電池切れはさらに早くなりますし、殆どドアを開けなければ半年くらいは持つかもしれません。

　使用した電池は、amazonで買った中国製電池です。星一つのレビュー評価が多いですが、普通に使えました。

PWMとLPFで疑似DA変換

2017-02-05T23:16:00.004+09:00

TWE-Liteのオーディオアプリでは、PWM出力をLPFに通すことで、デューティー比の変化を電圧に変換しています。Analog Discovery 2を買ったので、この様子を視覚的に確認してみました。

　LPFを通す前のPWM出力と、LPFとスピーカーアンプを通った後の音声出力にプローブをつないで、同時に波形を見てみました。

プローブの接続箇所

波形は、このようになりました。上がPWM波形、下がスピーカー出力の波形です。この時は、テストトーン(正弦波?)を再生していました。

電圧の山では高デューティー比

電圧の谷では低デューティー比

　PWMのデューティー比が高い箇所(約60%)ではスピーカー出力の電圧が高く、デューティー比が低い箇所(約40%)では電圧が低くなっています。
　一見しただけではわかりにくいのですが、Quick Measureでカーソル位置の値を見ると、簡単に理解できます。

TWE-Liteで出力した赤外線リモコン信号の波形

2017-01-22T00:01:00.000+09:00

今までオシロスコープ無しで開発してきましたが、やっぱりあると便利なので、場所を取らないUSBオシロスコープ　Analog Discovery 2 を秋月電子で買いました。

　とりあえず、TWE-Liteで作った赤外線リモコン信号の送受信機が正しく動いている事を確認しました。下のスクリーンキャプチャで、水色が赤外線受光モジュールの出力、黄色がTWE-Liteの赤外線リモコン信号出力です。同じタイミングで信号が出ていることが確認できました。

TWE-LITE 2525Aの連続稼働が2カ月を超えました

2017-01-20T20:12:00.001+09:00

11月中旬から動かし始めたTWE-LITE 2525Aは、予想を超えて、まだ動き続けています。

　現在の電源電圧は、2.4V前後です。もう少し、頑張れそうです。

TWE-LiteのInfra-Red Transmitter

2017-01-14T18:03:00.000+09:00

TWE-Liteには赤外線リモコン信号を送信するための機能が用意されているのですが、使用例を見たことが無いので、考え方をメモっておきます。

　副搬送波の周期とデューティー比、データビットを構成する微小ビットの長さ等、タイマーの設定に関係するパラメータは、bAHI_InfraredEnable()で設定します。

bool_t bAHI_InfraredEnable(
uint8 u8Prescale,
uint16 u16Hi,
uint16 u16Lo,
uint16 u16BitPeriodInCarrierPeriods,
bool_t bInvertOutput,
bool_t bInterruptEnable);

u8Prescale 赤外線送信で使うTIMER2の分周比を指定します。Users Guideの例では2(=1/4)を指定していますが、16MHzの16ビットタイマーのまま分周しなくても無理なく使えますので、0で良いと思います。
u16Hi 副搬送波1周期のうちの非アクティブ時間をタイマーのクロック数で指定します。
u16Lo 副搬送波の周期をタイマーのクロック数で指定します。
u16BitPeriodInCarrierPeriods データビットを構成する微小ビットの長さを、副搬送波の周期(CarrierPeriod)で割った個数で指定します。
bInvertOutput 出力のHi/Loを反転する場合にTRUEを指定します。
bInterruptEnable 送信完了割り込みを発生させる場合にTRUEを指定します。

bAHI_InfraredEnable()で設定できる構造は微小ビットまでで、データビットの1/0やリーダーコード等は全て、u16BitPeriodInCarrierPeriodsで指定した個数の副搬送波を単位とする微小ビットの1/0の集まりとして表現します。例えば、下の図に示したNEC方式における'0'データビットは、微小ビットでは'10'という2ビットのデータで表現します。

　赤外線コマンドの送信は、bAHI_InfraredStart（）で行います。

bool_t bAHI_InfraredStart(
uint32 *pu32BufferAddress,
uint16 u16TransmissionLengthInBits);

pu32BufferAddress 微小ビットの連続で表現したフレーム構造をビッグエンディアンで指定します。
u16TransmissionLengthInBits pu32BufferAddressに含まれる有効な微小ビット数を指定します。

pu32BufferAddress の先頭はリーダーコードで始まります。NEC方式では、0xffff0000(の上位24ビット)になります。リーダーコードの後は、データビットの0/1をそれぞれ2進数の'10'および'1000'としてエンコードして、ストップビットの'1'を追加し、最後にフレーム間を'0'で埋めます。

　上の例は、我が家の日立製テレビの電源コマンドで、フォーマットはNEC方式、カスタマーコードは0x50,0xaf, コマンドデータは0x17です(リトルエンディアン)。これを、bAHI_InfraredStart()用にエンコードすると、パラメータは、

pu32BufferAddress = {0xffff00aa, 0x8a28888a, 0x28888a2a, 0xaa288880, 0x00000000, 0x00000000}
u16TransmissionLengthInBits = 192

となります。
2進数表現にすると、ON/OFFの様子が視覚的にわかります。

11111111111111110000000010101010
10001010001010001000100010001010
00101000100010001000101000101010
10101010001010001000100010000000
00000000000000000000000000000000
00000000000000000000000000000000

　複数のフレームを送信する場合は、

pu32BufferAddress に複数のフレームをエンコードして一気に送信する。
vAHI_InfraredRegisterCallback()で送信完了ハンドラを指定し、ハンドラの中で次のフレーム送信を行う。

のいずれかの方法になると思います。送信完了ハンドラを使用する場合は、オーバーヘッドを考えてu16TransmissionLengthInBitsを若干減らしたほうが良いかもしれません。

参考資料

TWE-Liteで赤外線リモコン信号を送信

2017-01-14T01:45:00.001+09:00

赤外線リモコン信号の受信だけでなく、送信もできるようになりました。

　送信用のパーツを追加した回路図は、こちらです。

TWE-LiteのGPIOでは赤外線LEDを十分な明るさで点灯させることができないので、余っていたトランジスタを使いました。LEDの電流制限抵抗は、もっと小さくしたほうが良さそうです(50mA位は流したい)。

　赤外線リモコン信号を駆動するTIMER2は、標準アプリでは代替割り当てによってPWM2(or DO0)に割り当てられていますが、NPNトランジスタのベースと一緒にDO0をプルダウンしてしまうとプログラムモードに入れなくなるので、代替割り当てではなくデフォルトのピン割り当てのDO12（標準アプリではDI1）をTIMER2の出力として使っています。
　p-ch FETやPNPトランジスタならば、標準アプリと同様の代替割り当てで問題ありません。その場合は、TIMER2の出力極性を反転する必要があります。

赤外線リモコン信号を送信する手順は、おおまかに以下のようになります。

vAHI_TimerDisable(E_AHI_TIMER_2) でTIMER2を止めておく。
vAHI_InfraredRegisterCallback(cbToCoNet_vHwEvent) で送信完了ハンドラを指定する。
bAHI_InfraredEnable(0, 281, 421, 21, FALSE, TRUE) で副搬送波とエンコード単位波数を指定する。
送信したい赤外線コマンドのパターンをuint32のバッファにビッグエンディアンで設定する。
bAHI_InfraredStart(pu32BufferAddress,u16TransmissionLengthInBits) で赤外線コマンドを送信する。
送信完了割り込みが発生したら、次のフレームを送信するために4.または3.の手順に戻る。

上記のbAHI_InfraredEnable()で指定しているパラメータは、NEC方式または家電協方式の場合です。SONY方式では、副搬送波が40kHzになるように指定します。

　赤外線コマンドの1ビットは、bAHI_InfraredEnable()で指定したエンコード単位幅(u16BitPeriodInCarrierPeriods)を複数使って表現します。リーダーコードやフレーム間の無信号部分も同様にしてエンコードに含めるので、1個のコマンドに必要なバッファ長は75-235ビット位になります(長さはフォーマットに依存)。

　送信部分を実装したソースコードも、githubで公開しています。

TWE-Liteで赤外線リモコン信号をデコード

2017-01-11T23:11:00.004+09:00

子供部屋の照明消し忘れが多いので、別室の照明を操作するリモコンをTWE-Liteで作ろうと思い立ちました。

　先ずは、リモコンから出ている赤外線信号を知る必要があります。オシロスコープがあれば波形を見て解読することができますが、残念ながら持っていませんので、TWE-Liteで赤外線信号を受信してデコードするプログラムを作りました。

　回路図

赤外線リモコンデコーダ回路図

計測方法

赤外線リモコンの信号については、検索すれば山ほど出てくるので説明は省略します。デコードの方式はいろいろありますが、リーダーパルスの幅と、ビットパルスの立下り間隔で見ることにしました。
　赤外線受光モジュールからの出力をDI2とDI3に同時に接続し、立ち上がりと立下りの各々で発生する割り込みでエッジを検出します。割り込みハンドラの中で、プリスケーラを調整したTIMER2のカウンタ値を読んで記録します。

デコード方法

最初のパルスはリーダーコードなので、幅の違いからフォーマット(NEC/家電協/SONY)を判定します。フレームの間には長めの無信号期間があるので、信号が途絶えたらフレームをデコードします。リーダーコードに続いて、0/1をエンコードしたビットのパルスが続くので、短間隔を0、長間隔を1として判定し、フレーム全体をデコードします。

ファームウェア

赤外線リモコンデコーダーのファームウェアは、サンプルアプリのSamp_ContTxをベースにして作りました。ソースコードはgithubに置いてあります。TWE-Liteで動いていますが、親機も子機も無く単体で動作し、電波の送受信は行いません。

　リモコン信号を受光モジュールに送信して暫く待つと、デコード結果をUARTに表示して、受信待ちに戻るという動作を繰り返します。出力は下記のようになります。

1 2 3 4
cnt=4
type:SONY , bits:20, 88 b4 f0
type:SONY , bits:20, 88 b4 f0
type:SONY , bits:20, 88 b4 f0
type:SONY , bits:20, 88 b4 f0
1 2 3
cnt=3
type:AEHA , bits:40, 34 4a 90 14 84
type:AEHA , bits:40, 34 4a 90 14 84
type:AEHA , bits:40, 34 4a 90 14 84
1 2 3 4 5
cnt=5
type:NEC , bits:32, 6a 95 8e 71
type:NEC(R), bits:0,
type:NEC(R), bits:0,
type:NEC(R), bits:0,
type:NEC(R), bits:0,

デコーダができたので、引き続き、赤外線信号の送信部分を作ろうと思います。TWE-LiteのMCU(JN5164)には赤外線リモコン信号を送信する機能があるので、タイマーやPWMの面倒な操作しなくても、パルスの周期とパターンを与えるだけで出力できるようです。

ブレッドボードでデバッグ中の赤外線リモコン受信機

TWE-LITE 2525Aの電池寿命を実測中

2016-12-19T21:18:00.003+09:00

先月から、自宅リビングのドアにTWE-LITE 2525Aを貼り付けて、ドア開閉のパケットを記録しています。季節変化のせいか、平坦だった電源電圧が12月に入ってから急に低くなりました。一カ月余り経過した時点で、電源電圧は2.6Vを切っています。この様子だと、２カ月は持たないかなという感じです。

闇の中で怪しく光るTWE-Lite

2016-06-17T22:28:00.002+09:00

我が家の戸締りチェッカーは、親機がRaspberry Piのある２階であるのに対し、子機は主に１階に設置してあります。子機の全てを親機だけでカバーできないので、親機の真下に当たる１階の部屋に、中継器を置いてあります。使わなくなったPHSの充電器を再利用し、三端子レギュレータで3.3Vの電源を供給しています。
　中継器としては電源つなぐだけでも事は足りるのですが、それだけでは動いている実感が無いので、PWMにLEDをつないで明滅させるようにしています。

　この中継器のソースも、githubで公開しています。

トランシーバーの電池もち見積もり

2016-06-08T08:12:00.002+09:00

TWE-Liteで作ったトランシーバーの電池もちは、およそ3か月以上と見込んでいます。算出の基にした数値は、以下の通りです。

TWE-Lite Warm Sleep(uA) 2

TWE-Lite 待機起床時(mA) 17

起床間隔(sec) 1

起床時間(ms) 32

TWE-Lite 受信時(mA) 80

TWE-Lite 送信時(mA) 20

1通話あたり送信秒数 15

1通話あたり受信秒数 15

通話回数/日 5

単3エネループの容量を2000mAhとすると、130日で電池が空になります。

　電池の消費割合を時間帯別に集計すると、下のグラフのようになります。

　スリープ中の消費は1%をはるかに下回り、1秒毎に32msの受信待ちを行う待機中起床時の消費が大半を占めています。
　起床間隔と起床時間の長さが電池もちを決定づける主なパラメータです。これらは、電池もちと応答性という相反する要求に直結しています。
　受信時はアンプでスピーカーを鳴らすため、消費電流が数十mA～100mA前後と非常に大きくなります。この部分の割合は、使用状況によって大きく変動します。

トランシーバーの回路を再検討中

2016-06-06T22:43:00.000+09:00

トランシーバーの回路を見直しています。

イヤホンでなくスピーカーからの出力を可能にしながら、マイクをコンパクトなMEMSマイクにしてオペアンプを省略し、電解コンデンサーを減らしたら、このようになりました。

トランシーバーの回路図

ブレッドボード上で組んでみた感じでは、出力は全く問題なし。オペアンプのLPFより低ノイズで聞き取りやすいです。

マイクのゲインが、コンデンサーマイク＋オペアンプに比べると、やや物足りない印象です。

TWE-Liteを使った電池ながもちトランシーバー完成

2016-06-05T01:04:00.002+09:00

TWE-Liteを使ったトランシーバーの初号機セットが完成しました。
今回のプラスチックケースは、タカチのLC115H-M2を使いました。

トランシーバーのセット

中はスッカスカです。
適当なケースさえあれば、もっとコンパクトにできそうです。

裏ぶたを開けたところ

TWE-Liteは前面に実装しています

　アプリケーションは、サンプルアプリのApp_Audioを間欠受信に改造したものを書き込んであります。設定が楽になるように、オートペアリングも実装しました。

自転車ビーコン電池交換

2016-06-02T08:15:00.003+09:00

今年もMaker Faire Tokyo 2016に出店応募しましたが落選しました(;_;)。

　2月中旬に入れた電池が一昨日から残量警告状態になったので、今朝交換しました。100円ショップのアルカリ乾電池で3か月半持ちました。

応答性向上のため、スリープ間隔を2秒に短縮して使用しています。3か月以上持ったので、この設定をデフォルトにしようと思います。今使っている送受信機ペアは好調で、呼んでも応答がない空振り状態になった記憶がありません。百発百中で応答があります。

トランシーバー組み立て中

2016-05-26T23:51:00.002+09:00

通販に注文した部品がそろってきたので、1,2号機の組み立てを開始しました。

コネクタ部品がないので完成には至っていませんが、ファームウェアを書いて電源とスピーカーを接続したら、ちゃんと音が鳴りました。強いエコーがかかっていて、カラオケのスピーカーで話しているような音が出ます。

トランシーバーの基板を発注

2016-05-08T21:53:00.000+09:00

トランシーバーの基板をElecrowに発注しました。

　こちらは、表面の3Dイメージ。大きな黒丸はスピーカー。
　

　こちらは、裏面の3Dイメージ。ケースはタカチのLC115H-M2です。

基板が届くまでに、部品を用意しなくては。

TWE-Liteのトランシーバを間欠受信に改造

2016-05-08T09:53:00.001+09:00

TWE-LiteのSDKに含まれているオーディオアプリはスリープしない連続動作ですが、これから作ろうとしているトランシーバはインターホン的な利用を想定しているので、少なくとも1-2か月は電池交換せずに使いたいと思っています。
　間欠受信のコツは自転車発見機の制作で理解していたいので、基本のモードが間欠受信となるように改造してみました。

1秒に一度、32msの受信待ちを行う
受信待ちの間にパケットを受信しなかった場合はスリープする
パケットを受信した場合はスリープせずに受信した音声データを出力する
PTTボタンが押されたらスリープを解除して送信を行う
パケット受信またはPTTボタン押下の無い状態が5秒間継続したらスリープする

このような動作で、1日当たり数十秒の通話を行ったとして、単三エネループで2カ月程度はもつ見込みです。

TWE-Liteのトランシーバを試作

2016-05-01T13:52:00.002+09:00

TWE-Liteのアナログ通信アプリを、ブレッドボード上で試作してみました。送信側にはマイクアンプを、受信側にはLPF＋アンプ＋スピーカーを外付けして、普通に聞き取れることが確認できました。

　実際に使いたい用途があるので、これから基板を設計して、プラスチックケースに収納できるようにします。常時通電では電池が持たないので、待ち受け中は間欠受信するようにソフトを改造する予定です。

自転車発見器の無音モード

2016-04-13T22:37:00.001+09:00

閑静な住宅地など、使用する場所によっては、自転車発見器のメロディーが邪魔になる場合が考えられます。そのような場合を想定し、受信機のオプションビットで音を消せるようにしてあります。しかし、この方法では、インタラクティブモードに入らないと切替ができません。
　ところが、もっと単純で利便性の高い方法がありました。その方法とは、休符のみのプリセットメロディーを用意しておくだけです。iPhoneでアラームを無音にする方法と同じです。
　早速、ソースコードを修正して、プリセットメロディーを追加しました。

　因みに、自転車発見器のメロディー停止は、ごく短い休符1個だけのメロディーを再生するという方法で実現しています。これは、ベースにしたApp_Melodyの機能をそのまま引き継いだものです。

TWE-Liteの自転車ビーコンにオートペアリングを実装

2016-02-15T22:27:00.002+09:00

自転車ビーコンにオートペアリングを実装してみた。

　自転車ビーコンは、ペアリングした送信機と受信機の間でのみ通信が成立する。今までのペアリングは、設定モードに入って手でIDを入力して行っていた。入力を注意深く行うのは面倒だし、動作確認するとはいえ、この方法ではいずれ間違いが発生するのは避けられない。

　オートペアリングでは、コールドスタート時に特定のボタンが押されていたらペアリングモードに入り、ペアリング用のパケットで双方が希望するAppIdとランダムに選んだチャンネルを送り合う。暗黙のルールの下にAppIdを決定し、従属的にチャンネルも決定する。ペアリングのパラメータが決まったら、新しいチャンネルで通信を確認し、一定数のパケットが交換できたらEEPROMに設定を保存する。
　オートペアリングで使うAppIdとチャンネルは固定だが、送信出力を最小にする事と、ペアリング用パケットに双方のシリアル番号を含めることによって、確実に1対1でペアリングする。同時に3台以上がペアリングモードに入ったとしても、ペアリングが成功するのは必ず1対1の組み合わせに限られる(または、ペアリングが失敗する)。

　今のところ、ペアリングのパラメータはAppIdとチャンネルだけ。他のパラメータを含めることも可能だが、自転車ビーコンでは、これ以上は必要無い。

ペアリングモードへの入り口は、cbAppColdStart()から呼ばれるvInitHardware()の中。cold startの時にGPIOの状態からモードを設定する箇所に、DI1によるペアリングモード判定を入れている。

if (bPortRead(PORT_INPUT1)) {
sAppData.bPairingMode = TRUE;
}

DI1は押しボタンスイッチなので、M1,M2,M3のようなプルアップ解除は不要。cbAppColdStart()では、オートペアリング用に状態マシンとAppContextを設定。

// 状態遷移マシンの登録
if (sAppData.bPairingMode) {
ToCoNet_Event_Register_State_Machine(vProcessEvCorePairing);
sAppData.prPrsEv = (void*) vProcessEvCorePairing;
sToCoNet_AppContext.bRxOnIdle = TRUE;
sToCoNet_AppContext.u8TxPower = 0; // 最小出力
sToCoNet_AppContext.u32AppId = APP_ID;
sAppData.u8AppIdentifier = u8CCITT8(
(uint8*) &sToCoNet_AppContext.u32AppId, 4);
sToCoNet_AppContext.u8Channel = CHANNEL; // pairing用に固定
sToCoNet_AppContext.u32ChMask = CHMASK;
}

状態マシンのスタートアップでペアリング用のパラメータを初期化。

static void vProcessEvCorePairing(tsEvent *pEv, teEvent eEvent, uint32 u32evarg) {
switch (pEv->eState) {
case E_STATE_IDLE:
if (eEvent == E_EVENT_START_UP) {
sAppData.u16CtRndCt = 0;
sAppData.u32ReqAppId = ToCoNet_u32GetSerial(); // 要求APP ID
sAppData.u8ReqCh = ((ToCoNet_u16GetRand() & 0xF) + 11); // 要求channel
sAppData.u32CandidateAppId = 0;
sAppData.u32AnotherAppId = 0;
sAppData.u8CandidateCh = 0;
sAppData.u16MatchCount = 0;
sAppData.u16PeerMatched = 0;
}

相手をスキャンして、見つかったら合意形成フェーズへ移行。

case E_STATE_APP_PAIR_SCAN:
// ペアリング相手が現れたら提案確認フェーズ
if (0 < sAppData.u16MatchCount) {
vfPrintf(&sSerStream, "!INF PEER EXIST.@%dms"LB, u32TickCount_ms);
ToCoNet_Event_SetState(pEv, E_STATE_APP_PAIR_PROPOSE);
}

合意形成フェーズで1秒待ち、この間に相手からの合意パケットが十分な量受信できていたら、確認フェーズへ移行。

case E_STATE_APP_PAIR_PROPOSE:
if (1000 <= PRSEV_u32TickFrNewState(pEv)) {
// 1秒待ってから判断
sToCoNet_AppContext.bRxOnIdle = FALSE;
ToCoNet_vRfConfig(); // 受信を一旦停止
if (AUTO_PAIR_COUNT_MIN <= sAppData.u16MatchCount
&& AUTO_PAIR_COUNT_MIN <= sAppData.u16PeerMatched) {
ToCoNet_Event_SetState(pEv, E_STATE_APP_PAIR_CONFIRM);
} else {
ToCoNet_Event_SetState(pEv, E_STATE_APP_PAIR_FAILED);
}
}
break;

確認フェーズでは、最初にRF設定を変更。

case E_STATE_APP_PAIR_CONFIRM:
if (eEvent == E_EVENT_NEW_STATE) {
// カウンタを一旦クリア
sAppData.u16MatchCount = 0;
sAppData.u16PeerMatched = 0;
// u32AppIdはcbAppColdStart以外で変更不可なのでu8AppIdentifierだけを変更
sAppData.u8AppIdentifier = u8CCITT8(
(uint8*) &sAppData.u32CandidateAppId, 4);
sToCoNet_AppContext.u8Channel = sAppData.u8CandidateCh;
sToCoNet_AppContext.u32ChMask = (1UL << sAppData.u8CandidateCh);
// 次のパケットのタイミングを仕込む
sAppData.u16CtRndCt = (ToCoNet_u16GetRand() & 0x3);
sToCoNet_AppContext.bRxOnIdle = TRUE;
ToCoNet_vRfConfig(); // 新たなRF設定に切り替える
}

確認フェーズでも、十分な合意パケットが受信できたら、完了フェーズへ移行。

if (1000 <= PRSEV_u32TickFrNewState(pEv)) {
// 1秒待ってから判断
if (AUTO_PAIR_COUNT_MIN <= sAppData.u16MatchCount
&& AUTO_PAIR_COUNT_MIN <= sAppData.u16PeerMatched) {
ToCoNet_Event_SetState(pEv, E_STATE_APP_PAIR_COMPLETE);
} else {
ToCoNet_Event_SetState(pEv, E_STATE_APP_PAIR_FAILED);
}
}
break;

完了フェーズでは、新しいAppIdとチャンネルに更新してEEPROMへ保存。

case E_STATE_APP_PAIR_COMPLETE:
// AppId,Chを書き換えて保存
{
tsFlash sFlash = sAppData.sFlash;
sFlash.sData.u32appid = sAppData.u32CandidateAppId;
sFlash.sData.u8ch = sAppData.u8CandidateCh;
sFlash.sData.u32chmask = (1UL << sAppData.u8CandidateCh);
sFlash.sData.u32appkey = APP_ID;
sFlash.sData.u32ver = VERSION_U32;
bool_t bRet = bFlash_Write(&sFlash, FLASH_SECTOR_NUMBER - 1, 0);
V_PRINT("!INF FlashWrite %s"LB, bRet ? "Success" : "Failed");
vWait(100000);
}

ペアリングモードでやり取りするパケットは、受信コールバックcbToCoNet_vRxEvent()の中でデコード関数に振り分け。

case TOCONET_PACKET_CMD_APP_USER_PAIRING: // auto pairing
if (PRSEV_eGetStateH(sAppData.u8Hnd_vProcessEvCore) == E_STATE_RUNNING) {
vReceivePairingData(psRx);
}
break;

デコード関数の中では、AppIdの大小で優先度を決定。確定したAppIdが送られてきたら、受信数をカウントする。受信数は状態遷移の判断材料として使用する。

// 要求AppId
uint32 u32ReqAppId = G_BE_DWORD();
// 要求ch
uint8 u8ReqCh = G_OCTET();
(void)u8ReqCh;
// 候補AppId
uint32 u32AcceptAppId = G_BE_DWORD();
// 対向AppId
uint32 u32AnotherAppId = G_BE_DWORD();
// 候補ch
uint8 u8AcceptCh = G_OCTET();
(void)u8AcceptCh;
sAppData.u16PeerMatched = G_BE_WORD(); // 相手方pairingマッチカウンタ
if (sAppData.u32CandidateAppId == 0) {
if (u32ReqAppId < sAppData.u32ReqAppId) {
sAppData.u32CandidateAppId = u32ReqAppId;
sAppData.u32AnotherAppId = sAppData.u32ReqAppId;
sAppData.u8CandidateCh = u8ReqCh;
} else if (sAppData.u32ReqAppId < u32ReqAppId) {
sAppData.u32CandidateAppId = sAppData.u32ReqAppId;
sAppData.u32AnotherAppId = u32ReqAppId;
sAppData.u8CandidateCh = sAppData.u8ReqCh;
} else {
// bad case
}
} else if (sAppData.u32CandidateAppId == u32AcceptAppId
&& sAppData.u32AnotherAppId == u32AnotherAppId) {
sAppData.u16MatchCount++;
} else {
// ignore u32AcceptAppId == 0 or bad case(maybe multiple peer).
}

その他、詳細はgithubのソースコードを参照。

TWE-Lite Warm Sleep(uA)	2
TWE-Lite 待機起床時(mA)	17
起床間隔(sec)	1
起床時間(ms)	32
TWE-Lite 受信時(mA)	80
TWE-Lite 送信時(mA)	20
1通話あたり送信秒数	15
1通話あたり受信秒数	15
通話回数/日	5