head

2017年8月30日水曜日

esp8266, 稼動時間帯設定で連続稼動日の延長テスト




esp8266で消費電力を下げる事例は、ありそうですが検討してみました。
条件付で、電池の連続稼動日を延ばす方法となります。
稼動時間を設定(例: 9-17時)し、稼動時間以外はIoT機能を停止させる事で
消費電力を下げ、連続稼動日数を伸ばす仕組みです。
24時間稼動前程の運用では適用できません、
昼間稼動でのIoT活用で夜間は使用しない場合、

予想としては、日に8時間稼動で消費電力は電源回路周辺は
常時電力を消費するため、1/3以下まで下げる事は不可能と予想されますが、
動作的にはスリープ解除後の回数が減り、消費電力は下がると予想しています。

*1) 現在時刻の調査方法は、複数ありそうですが。NTPに接続して
 取得しています。RTC等の回路追加は無しです。
*2) NTPを起動時に毎回接続した場合、消費電力は増えましたので
 基準時間をRTC memory に保存し、タイマ起動時に計算処理で
 現在時刻を計算する処理も追加しました。



# 稼動時間イメージ




*) 指定時間帯は、active(稼動時間)のみです。


# 条件
a) 24時間稼動は対象外
b) sleep タイマは30分以上の場合はほぼ効果なし。
 想定タイマ: 5-15分
c) 稼動 -開始終了範囲が、0時 - 24時 まで。
d)電源周辺部品
LDO 出力 500mA : TA48M033F
入出力コンデンサ :入力=0.1u, 出力=47u

*) 例は、1日稼動時間= 8H


# 処理
ntp ( udp)を使って、起動時に現在時刻を取得し、稼動判定処理に使っています。
a) 開始終了時刻は、コード内に記載しています。
 *)改良としては、クラウド側から、範囲時刻を取得した方が良さそうです。
b) 稼動時間帯は、数分( 約5-15分)タイマ、30分以上のタイマの場合は、さほど効果ありません。
c) 非稼動時間帯は、60分タイマで、次稼動時間帯開始の監視を行います。



# code (BETA) -arduino IDE 1.8.4
https://github.com/kuc-arc-f/WiFiClient_ntpTest_2

==== Update :2017/08/31 ====
update 0.9.2 を更新しました。
不具合対応で、稼動時間帯の判定処理を修正しました。
=======

*) センサは接続していません。

*) 計測/集計用のコード - arduino/python (参考)
https://github.com/kuc-arc-f/read_adcUART




# 集計/分析
予測計算となります、1時間の実測値をもとに計算しています。
計測は前回の arduino (+電流測定抵抗= 1R)版電流測定機器、
で100mSec(0.1sec)単位で1時間測定、対象 36,000件

*1) 1mA以下の測定ができてないため、
テスタ計測の基板消費電流=0.8 mAを加算しています。
*2) 旧版は、単純なスリープ起動(deep sleep 5分)

a) 新版の 稼動時間帯/ 非稼動の波形


b) 表/ 新版の 稼動時間帯/ 非稼動、
稼動 / 1 時間当りの平均電流値= 2.9447 mAh
非稼動/ 1 時間当りの平均電流値= 1.0609 mAh
稼動 / 24時間当りの平均電流値= 70.6728 mAh
非稼動/ 24時間当りの平均電流値= 40.532  mAh



c) 旧/新 比較。
旧/24時間当りの平均電流値= 63.686 mAh
新/24時間当りの平均電流値= 40.532 mAh
旧/24時間当りの平均電力値= 318.42 mWh
新/24時間当りの平均電力値= 202.66 mWh

*) 電力消費は、旧/新比較= 63.52 % (新は消費が少ない)
終止電圧までの時間、旧/新比較=  1.57 倍(新は連続稼動可能)



d) 消費、累積30日のグラフ



# 考察
改良内容で、予想より消費は下がりませんでした、
50% 以下は期待していましたが。。悪影響は
電源部分の消費が大きく。常時電力を消費している為と
想定しています。
今回は、接続先の thingSpeakの更新時間が長めになっており
消費電力が大めになっていますが、全て同一接続先でテストした為、
比率は変わらないと思います。


# まとめ
将来的には、稼動カレンダ連動で
休日は 非稼動にできると、さらに稼動日数は伸びると思います。



# esp8266まとめ
http://knaka0209.blogspot.jp/2017/06/esp8266-matome.html



2017年8月19日土曜日

BLE 子機 消費電力測定結果 ,RN4020 +atmega (第1回)



連続稼動テストを続けていた、
RN4020 BLE子機の第1回目の、測定報告となります。



#条件
1日 =24時間稼動
タイマー間隔= 300sec (5分)
電池 : 二次電池単三- 2本 (ニッケル水素)
*) 100均さまの、モバイル電源(単三×2本 2.4V)で
 出力= 5V ( おそらく昇圧回路内臓 )
*) BLE server は前回と同じ, nanoPiを経由して
 クラウド連携する構成です。

# 結果
稼動時間 : 1095 H ( 45.6日 )


# 考察
条件としては、やや消費電力は多めとしました。
1) タイマー間隔を、300秒から 10/15分(600秒) 以上に変更すると
 稼動時間は延ばせそうです。
2) 周辺センサの電源を ON/OFF スイッチ機能を、
 追加していない為、やや消費は多めになっています。
3) 小型化の為、電池2本としましたが。昇圧時の電力ロス
 が想定されるので、使用できる電力量は少なめ
 だったと予想しています。

#
次も条件等を変更して、テストしてみたいと思います。


# 関連の記事
RN4020 BLE + ATMEGA328, 省エネ改良版
http://knaka0209.blogspot.jp/2017/07/esp32-21.html

消費電力比較、RN4020 BLE とESP8266
http://knaka0209.blogspot.jp/2017/07/raspi-8.html


# 関連のまとめ
BLE -IOT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html





2017年8月17日木曜日

Update, BLE gateway server 0.9.2


前回のアドレス指定の BLE gateway sereverの 
update行いました。 ( ble_gateway_sv2)
内容は、コンフィグからデバイスリストを読み込む方法に変更し、
デバイス追加時にコードにの変更を少なめに出来るように修正しました。



#
1) configの設定、
config.json を追加し、各デバイス名/ BDアドレスを記載しておきます(json形式)




*) 記載サンプルは、config-sample.json
*) デバイス名は、キー項目となり。重複名はNGとなります。
*) public addressを事前に調査が必要な点は前回と同じ。

2) コード修正 ( 前回と似ています )
http_func.py --送信先の設定 (* 例は thingSpeak
ble_gateway_sv.py  /send_http()
--request param設定、BLE収集配列から、HTTP送信用のバッファにセットします。
*) 今回は、config.json に記載した デバイス名/field を指定しデータ取り出します。
*) コード内の、BDアドレス定義は削除しています、

# Log には、デバイス名、アドレス、各BLE子機からの読み込み値
が出力されます。





# code
前回と同じプロジェクト URLです。
https://github.com/kuc-arc-f/ble_gateway_sv2



# 関連のページ
# Update, nanoPi BLE gateway server アドレス指定編(ble_gateway_sv2)
http://knaka0209.blogspot.jp/2017/08/nanoPi-4.html

RN4020 BLE + ATMEGA328, 省エネ改良版
http://knaka0209.blogspot.jp/2017/07/esp32-21.html

# 関連のまとめ
BLE -IOT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html




2017年8月7日月曜日

python ,GATT characteristic通信編


前回のGAP profileベースの advertising通信で
bt4.x プロトコル拡張もほぼ限界に達してきたようですので。
別の方法を検討しました。
GATT profileを使って、characteristic value
をperipheral から読見込みテストを行いました。

[環境]
GATT client/Central : nanoPi (python)
GATT server/peripheral : esp32

*) esp32は、省電力面ではNGでしたが、
 GATTのサンプルコードが存在したので、勉強には良さそうでした。
 連続稼動の場合は、省エネ化できるデバイスに変えたほうが良いでしょう。


# thanks / 参考のサイトさま
GATT(Generic Attribute Profile)概要
http://yegang.hatenablog.com/entry/2014/08/09/195246



# Log -python/ Central
sRead=0000..
の行が、読み込んだ行です。










# Log -esp32 /peripheral
GATT_READ_EVT 、のイベント当りが、
characteristic 読み込み実行された応答部分です。







# code(beta)、解説など

# Central/ GATT client --python (nanoPi)
getCharacteristic.py (bluepy を使用してます。 )
* BDアドレス (public address) を指定し、コネクト
*  characteristic  -UUID を指定します。
mCHAR_UUID = 0xFF01
* properties は、読み込み権限のある場合は、読めました。
* 指定の characteristic  -UUID が存在する場合、
読み込み処理 ( .read()  )を実行すると、valueが取得できました。

https://gist.github.com/kuc-arc-f/b5cd0e6f8f6901922571654d6d33160a


# peripheral /GATT server -esp32
gatts_demo.c --ESP-IDF
*  別タスクで、センサ値等のデバイス値を、変数にセットしておきます。
xTaskCreate(&sensorTask, "sensorTask", 4096, NULL, 5, NULL);

*  characteristic -UUID は固定にしておき、読み込み側で指定します。
#define GATTS_CHAR_UUID_TEST_A      0xFF01
*  callback の ESP_GATTS_READ_EVT で、
送信値をセットし、
esp_ble_gatts_send_response() で送信


https://gist.github.com/kuc-arc-f/b108bdc2306ba77cf59f412612a47737

*) 前回の、BLE Server(IoT連携 )と異なり
GATT部分の通信テストで、peripheral - SCAN処理や
クラウド転送機能は実装していません。



# 関連のページ

Update, nanoPi BLE gateway server アドレス指定編(ble_gateway_sv2)
http://knaka0209.blogspot.jp/2017/08/nanoPi-4.html

nanoPi NEO で、BLE Gateway Server を設置する
http://knaka0209.blogspot.com/2017/07/nanoPi-2.html

# 関連のまとめ
BLE -IOT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html








2017年8月5日土曜日

Update, nanoPi BLE gateway server アドレス指定編(ble_gateway_sv2)




前回のLinux版の BLE Gateway Server のアップデートを行いました。
改良内容は、プロトコルの拡張となり、1回に送信可能データ桁数を増やしました。
旧版は25byteで、識別に必要なデバイス名を3-5byte、残りの最大20byte
を利用できましたが、
新は、データ部最大 25byte使用可能です。

[改良の仕組み]
Bluetooth device adress(BD address)を使い、server側から、
子機(peripheral)を識別するように。検出方法を変更しています。
この変更により、advertising パケットの最大25 byteを全てデータ領域で
使用できるようになりました。

*) 下記のアドレス種類の例外があり、対象は
public address 機種のみです、random address は対象外としています。



# 概要
旧版(アドレス指定無し)と、同様です。





# 参考 /Bluetooth Device Address

Bluetoothに対応しているデバイスを識別するために使われるのがアドレス:Bluetooth Device Addressで、
BD_ADDR、BDアドレスなどと表記されることもあります。
Bluetooth v4のアドレスは48ビット(EUI-48)を使用しており、
Public AddressとRandom Addressの2種類のアドレスが使用可能です。

・Public Address
これはIEEE 802準拠のアドレスであり、EthernetのMACアドレスと同等のアドレスです。
製品製造時に機器ごとに書き込まれる固定のアドレスです。
機器を製造した企業や機器の個別アドレスを含みます。

*)
48ビットのアドレス
パブリック・デバイス・アドレスは、Bluetooth SIGが企業ごとに発行した24ビットの識別子と、
企業が製品1つづつに割り振る24ビットの識別子から構成されます。

・Random Address
セキュリティを考慮した、各端末(機器)で自動生成される端末アドレスです。
乱数を使います。Bluetooth v4では一般的で、機器の製造工程で書き込む必要がありません。


参考:
http://micro.rohm.com/jp/techweb_iot/knowledge/iot02/s-iot02/04-s-iot02/2732




# code (BETA)
central : nanoPi/ ble_gateway_sv2
https://github.com/kuc-arc-f/ble_gateway_sv2

peripheral : RN4020 +atmega
RN4020_sv2_0_9_1.ino
https://gist.github.com/kuc-arc-f/727cf086673ad33eaf1f6d9055cd3f0d

RN4020_sv2_0_9_3.ino
https://gist.github.com/kuc-arc-f/d2408ff3752d8023db81b33baf2555f0


==== 2017/08/06 ====
esp32 driver(ESP-IDF)
app_bt.c
https://gist.github.com/kuc-arc-f/93a175c7821331f0e0d4934579acd972

=== Update:2017/09/07 ===
update: 0.9.3 scan動作の変更等
http://knaka0209.blogspot.jp/2017/09/nanoPi-8.html

=== Update:2017/08/17 ==
update v0.9.2をリリースしました。
設定ファイルから、子機デバイス情報を設定可能になりました。
blog: http://knaka0209.blogspot.jp/2017/08/nanoPi-6.html

========


# 補足/プロトコル 新/旧比較


新verは、旧と比較してプロトコル仕様が異なり、互換性がありません。
25 byte 固定 (例は、5byte * 5 項目)
device nameを廃止
BD address を追加

V2/ プロトコル仕様(PDF)
https://github.com/kuc-arc-f/ble_gateway_sv2/blob/master/doc/Protocol-Spec-ble-Rn4020-pubAddr.pdf


#  V2/ 設定手順
#) public address の調査
BT アプリ等で、起動時の advertising データ内の BD address を確認します。



===2017/08/06 ===
BTアプリによって、アドレス英数の大文字/小文字が逆になる現象を発見しました。
bluepyは、アドレス英数文字は全て小文字表示のようですので、
チェック用の python 追加しました。必要あれば参考下さい。
scan5-checkAddr.py
https://github.com/kuc-arc-f/ble_gateway_sv2/blob/master/ble_gateway_sv2/scan5-checkAddr.py

=========


#) address メモしておきます。(参考)
複数デバイスを設置する場合ですが、
 *) 例、表形式にまとめておきます。
内容は、BD Addres , 用途、センサ種類



#) BLE server に設定します。
ble_gateway_sv2.py
=== 2017/08/23 ===
update 0.9.2 で、デバイス追加方法を変更しています。
http://knaka0209.blogspot.jp/2017/08/nanoPi-6.html
====

定数を追加し、デバイス追加処理 ( init_param()  ) 
で追加します。
*) 下記の mPubAddr01



旧版のREADME 手順と重複しますが
https://github.com/kuc-arc-f/ble_gateway_sv/blob/master/README.md
http_func.py --送信先の設定 (* 例は thingSpeak 
ble_gateway_sv.py  /send_http() 
--request param設定、BLE収集配列から、HTTP送信用のバッファにセットします。

完了したら、server 起動します。

# Log /クラウド転送が開始されます。
*) 今回は、2台で各1項目で 種類少なめですが。






# NANOPI NEO で、BLE GATEWAY SERVER を設置する
http://knaka0209.blogspot.com/2017/07/nanoPi-2.html

# Update, BLE gateway server 0.9.2
http://knaka0209.blogspot.jp/2017/08/nanoPi-6.html


# BLE -IOT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html


2017年8月2日水曜日

nanoPi ,BLE gateway Server 負荷テスト (第1回目)



前回のnanoPi gaetway Sererの子機の台数を増やして、
Server 負荷テストを行いました。6台までですが 
デバイス不足の為、esp32 のBLE子機も追加しています。

内訳:
RN4020 : 2台 スリープ= 300sec(5min)
esp32 : 4台 スリープ無 (負荷上げる為、連続BLE送信処理)

結果的として、複数台からの受信/転送処理を
問題なく処理できました。同時受信の負荷を高くしてテストを行いましたが
実際には、スリープ駆動(5/10 分以上)を想定している為。同時アクセス数は
少なめを予想していますので、上記より子機を増やしても
サーバ処理的には耐えられそうな予想はできました。(10 -20台程度)


# Log



# esp32(ESP-IDF) - Code
RTOS版です、
RN4020 ,Nコマンドと同様のGap profile仕様に修正しています。
AD type (Advertising Data Type)= 0xFF( Manufacturer Specific Data )
https://gist.github.com/kuc-arc-f/4e59b01c22f0a09874f7e9bfdcae3072

*) 参考、Bluetooth SIG/ Generic Access Profile
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile


# 関連のページ
NANOPI NEO で、BLE GATEWAY SERVER を設置する
http://knaka0209.blogspot.com/2017/07/nanoPi-2.html

#BLE -IOT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html


2017年7月28日金曜日

nanoPi NEO で、BLE Gateway Server を設置する




前の raspBerry Pi 2版の BLE Server 環境を、 nano Pi に移植してみました。
Ubuntu core にインストールしてます。
BLE子機も、前回と同じRN4020基板でセンサ値を送信しています。


# 概要



Central device=nanoPi, advertise スキャンしてクラウド転送します。



# version
> uname -a
Linux NanoPi-NEO 4.11.2 #266 SMP Thu Jun 29 17:46:10 CST 2017 armv7l armv7l armv7l GNU/Linux

# bluepy インストール方法は、前回と同じです、
bluez はインストール済みでした。
http://knaka0209.blogspot.jp/2017/07/raspi-5-BLE.html

# python service の起動も前回と同じ systemctl
を使いました。
参考 : http://knaka0209.blogspot.jp/2017/07/raspi-6-BLE.html

# Log



# code ,python server は前回のrasPi版と同じです。
最新のble_gateway_sv2、 public addressに対応しています。
https://github.com/kuc-arc-f/ble_gateway_sv2

関連 blog:
http://knaka0209.blogspot.jp/2017/08/nanoPi-4.html

http://knaka0209.blogspot.jp/2017/09/nanoPi-8.html


*)旧版 server、randam addressも対応できますが、最大送信桁数は短めです
https://github.com/kuc-arc-f/ble_gateway_sv


# まとめ
安定稼動できるか。しばらく様子見としたいと思います。
nanoPi は安価で、rasPi 2と比較して、 1/3程度の価格で
低価格な サーバー機として安定して使えると。良いのですが



=== update:2018/01/13 ====
OS 再インストール時の BLE処理エラー対応 (2018-01 版)
*)新規インストールもほぼ同様
復旧に時間かかったので、メモです。

昨年から半年程度、連続稼動していた。BLE gateway機能ですが
原因は不明で停止した為、復旧作業を行いました。
再度電源投入すると、電源LEDが点灯したり。
ハード故障に見えませんでしたが、ネットワークが起動せず。
ログインできない状況でした。
SDカードの破損が予想されましたが、
予備SDカードにOS書込み、起動確認後。
使用していた元のSDカードに再インストールしています。

# OSインストール、前回と同様のURLからコピー、zip解凍し
imgファイルを取り出し。SD書込み
*) 下記のファイル名
nanopi-neo_FriendlyCore-Xenial_4.11.2_20171122.img

#version、更新版みたいです。
pi@NanoPi-NEO:~$ uname -a
Linux NanoPi-NEO 4.11.2 #38 SMP Tue Nov 21 16:45:21 CST 2017 armv7l armv7l armv7l GNU/Linux

# bluepyのインストール
今回は、gitからinstall
https://github.com/IanHarvey/bluepy

$ sudo apt-get install git build-essential libglib2.0-dev
$ git clone https://github.com/IanHarvey/bluepy.git
$ cd bluepy
$ python setup.py build
$ sudo python setup.py install

# centralでscan機能のチェック
scanのサンプルを実行
bluepy のエラーが発生し、scan出来ませんでした。。

bluepy.btle.BTLEException: Failed to execute mgmt cmd 'scanend'

# lsusb を確認しましたが。問題なく認識してそうです。
> lsusb
Bus 008 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

# いろいろ調べたのですが、下記を参考にしました。感謝です

Raspberry Pi で Bluetooth を使ってみた。(2)
https://qiita.com/tchisaka/items/80d4dcbfe83bb88acf02

sudo apt-get update
sudo apt-get install libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libical-dev libreadline-dev libudev-dev libusb-dev make
sudo apt-get install bluez

hciconfig を実行し、 hci0 を up変えると、正常に動作しました。
>sudo hciconfig
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1B:DC:06:BD:89  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING
        RX bytes:543588 acl:0 sco:0 events:21808 errors:0
        TX bytes:52112 acl:0 sco:0 commands:6995 errors:0
修正前は、UP RUNNING の部分が、
downと表示されていたので、
下記の upを設定、実行できました。
>sudo hciconfig hci0 up

結局は、初期時はドライバ設定は無効みたいで、
修正が必要みたいですね。


# その他、systemctlのログの設定、
気になったので、
今回はログの容量を制限追加しました。
関連するjournalctl コマンド
ログ確認
journalctl --disk-usage
ログ表示
journalctl -e

# conf の修正
/etc/systemd/journald.conf
SystemMaxUse=3M

# systemctl 再起動、又はOS再起動
systemctl restart systemd-journald

# この設定でしばらくすると、5M程消費していました。
それ以上増えないようです。
pi@NanoPi-NEO:~$ sudo journalctl --disk-usage
Archived and active journals take up 5.0M on disk.

# 関連
systemd(journald)のログ容量を制限する
https://qiita.com/sharow/items/c56e81e4c2a658c3c921

journalctl 最低限覚えておくコマンド
https://qiita.com/aosho235/items/9fbff75e9cccf351345c


=========


# 参考
NANOPI NEO 512MB 初期設定編
http://knaka0209.blogspot.jp/2017/07/nanoPi-1.html



nanoPi NEO 512MB 初期設定編



安価で 小型のボードPCの、 nanoPi NEOを設定してみました。
無線機能は無いのですが、有線LANが使えてネット接続は可能ですので
いろいろな用途で使えそうな機がします。

[仕様]
CPU:Allwinner H3(クアッドコア Cortex-A7 @1.2GHz)
RAM:DDR3 512MB
EtherNet:10/100M




# 追加した部品
Nano Pi NEO 512MB
http://akizukidenshi.com/catalog/g/gM-12301/

Nano Pi NEOシリーズ用ヒートシンク
http://akizukidenshi.com/catalog/g/gP-12303/


# 裏面、ヒートシンク側



# セットアップ
先人さまの記事を参考に、 OS install しました。

# OS download

https://www.mediafire.com/folder/n5o8ihvqhnf6s/Nanopi-NEO

Ubuntu-core を選びました。
nanopi-neo_ubuntu-core-xenial_4.11.2_20170705.img.zip

DL し、zip解凍しておきます。

# SD 書込み
Win32DiskImager
で書込みました。

SDカードをセットし、有線LANを接続。
電源を投入。

# Login
1) ip アドレスを調べます。

他Linux PCから、fping で調べました。

2) ログインできました。
user =pi  ,pass= pi


=== update :2017/07/30 ===
5Vラインの消費電力を測定すると
アイドル時 170mA でした。 (10A  レンジ)
起動時は200mA以上に上昇していました。
波形は測定しませんでしたが




*1) raspPi-2 が 1W(1000mW / 200mA)
程度だった気がします。 ほぼ同等程度にみえます。

BLEの通信時に、210mAまで上昇しましたので、
ドングルの消費電力はやや多めにみえます。

==== Update:2017/07/30 (2 )  ====
ケースもをDIYで作成しました。100均さまの3個で108円
の食品用プラ箱を、側面にドリルで穴空け 程度です。



耐熱素材を準備していなかったのが、良くなかったのですが、
通常のLANポートを上面にした場合は、CPU ヒートシンクは底面になり。
耐熱性の低いプラ部品は溶けやすいので危険と見えました。
回避方法は考えたのですが、上下逆にして
ヒートシンクは上面にすると、底面は温度の高い部品は少なくなり
上面は、容器上部にスキマがあるので、ケースの温度上昇は少なめとなりました。
*)デメリットは、USB付近の電源ランプ類(LED)が底面に配置されるので、
見えにくくなりました。




*) ケース上フタは、風穴をあける予定ですが、
ホコリ等がケース内に入りやすくなるので、様子見て調整したいと思います。




# 関連のページ
NANOPI NEO で、BLE GATEWAY SERVER を設置する
http://knaka0209.blogspot.com/2017/07/nanoPi-2.html


2017年7月22日土曜日

BLE -IoT関連まとめ

BLE(Bluetooth 4.x)を活用した、IoT事例のまとめ となります。
BLEについては、ルーターに接続できない為、ネット接続が困難なイメージはありますが、
これまでに開発してきた、BLE server(中継機)等を活用した IoT構成の製作事例
設計ノウハウを中心に公開してきた関連 リストとなります。

*) 事例内容に wifi機器と比較し、大幅な省電力化が可能になる場合があります。
省エネ思考 IoT設計の方にオススメです。




# micro:bitでIoT ,mbed編
http://knaka0209.blogspot.jp/2017/10/mbit-1.html





# 電池1本駆動、BLE バッテリー小型化編
http://knaka0209.blogspot.jp/2017/09/RN4020-4.html






# 周辺センサ等の電源スイッチングの追加



# BLE 子機 電池配線/ケース etc,DIY編
http://knaka0209.blogspot.com/2017/09/RN4020-2.html





# Update, python BLE gateway server v 0.9.3
http://knaka0209.blogspot.jp/2017/09/nanoPi-8.html




#  RN4020 BLE 搭載用ベース基板 試作編
http://knaka0209.blogspot.jp/2017/09/RN4020-1.html







# BLE 子機 消費電力測定結果 ,RN4020 +atmega (第1回)
http://knaka0209.blogspot.jp/2017/08/nanoPi-7.html




# Update, BLE gateway server 0.9.2
http://knaka0209.blogspot.jp/2017/08/nanoPi-6.html



# python ,GATT characteristic通信編 #nanoPi #IoT #BLE #Bluetooth
http://knaka0209.blogspot.jp/2017/08/nanoPi-5.html





# Update, nanoPi BLE gateway server アドレス指定編(ble_gateway_sv2)
http://knaka0209.blogspot.jp/2017/08/nanoPi-4.html





# nanoPi ,BLE gateway Server 負荷テスト (第1回目)
http://knaka0209.blogspot.jp/2017/08/nanoPi-3.html





# nanoPi NEO で、BLE Gateway Server を設置する
http://knaka0209.blogspot.jp/2017/07/nanoPi-2.html





#RN4020


# 電源ライン電圧値の送信、RN4020+ATMEGA基板
http://knaka0209.blogspot.jp/2017/07/raspi-9.html










# 消費電力比較、RN4020 BLE とESP8266(途中編)
http://knaka0209.blogspot.jp/2017/07/raspi-8.html





# DHT11 / BME280 SENSOR対応、RN4020 BLE基板
http://knaka0209.blogspot.jp/2017/07/raspi-7.html





#RASPBERRY PI , BLE GATEWAY 設置、 複数台のBEACON からの送信値をクラウド転送。
http://knaka0209.blogspot.jp/2017/07/raspi-5-BLE.html





# RN4020 BLE + ATMEGA328, センサ値検知アラーム音出力
http://knaka0209.blogspot.jp/2017/07/esp32-22.html





# RN4020 BLE + ATMEGA328, 省エネ改良版
http://knaka0209.blogspot.jp/2017/07/esp32-21.html





# RN4020 BLE, ESP32 WIFI BRIDGE 接続編
http://knaka0209.blogspot.jp/2017/05/esp32-13.html




# その他

# ESP32,複数の BLE BEACON + WIFI BRIDGE の設置 (DEEP SLEEP版)
http://knaka0209.blogspot.jp/2017/05/esp32-11.html



#  ESP32,複数の BLE BEACON + WIFI BRIDGE の設置 (ESP-IDF)
http://knaka0209.blogspot.jp/2017/04/esp32-10-advBridge.html




# ESP32+ BLE, EDDYSTONE対応 (BEACON 編)
http://knaka0209.blogspot.jp/2017/04/esp32-9-BLE.html



# ESP32+ BLE, ADVERTISING パケットを受信する。
http://knaka0209.blogspot.jp/2017/04/esp32-8-BLE.html



# ESP32+ BLE, デバイス間通信、 GATTC TO GATTS
http://knaka0209.blogspot.jp/2017/04/esp32-7-BLE.html



#

2017年7月17日月曜日

電源ライン電圧値の送信、RN4020+atmega基板



電源の電圧値をarduino 内臓 ADC で測定し、クラウド転送する機能を
追加してみました。
電池駆動の場合で、電圧降下をチェックし。
電池切れの予想ができれば良いかと考えました。

測定用のICを使用せず、基板の空きスペースで なんとか
機能追加できないか検討しましたが。ギリギリ配線できました。

# 測定方法
3V3 arduino ですと、5V電源 ラインをADCで読み込むのは困難でしたので、
分圧抵抗で、1/10 程に降圧後 ADC(A1) で読み込み、
その後、下げた電圧分 約10 倍の電圧値を計算します。
analogRead(), map() あたりで可能でした。
直接電圧を測定していないので、精度は低めでした。

分圧抵抗、周辺の配線を追加した為、
基板の空きスペースが、ほぼ無くなりましたが。。
なんとか RN4020 BLE経由で、クラウド送信まで完了できました。



# 電圧値のLog



=== update:2017/08/20 ===
回路図を追加しました。
A1 に、分圧抵抗を結線しています。
終端抵抗(R6) 47K にしています。
分圧 : R4=47K ,R5=10K
この部分追加により、消費電力が上昇した為、
下げるように調整したいと思います。
(約 0.1mAh  程度)

driver (arduino IDE ):
https://gist.github.com/kuc-arc-f/e5a53f1ed64bedfd184c5eec30a835f1

PDF 回路図:
https://github.com/kuc-arc-f/ble_adv_bridge_RN4020/blob/master/schematics_breadBord/test-RN4020-2-sch.pdf





=======



# 関連のページ
RN4020 BLE + ATMEGA328, 省エネ改良版
http://knaka0209.blogspot.jp/2017/07/esp32-21.html

Raspberry Pi , BLE gateway 設置、 複数台のBeacon からの送信値をクラウド転送
http://knaka0209.blogspot.jp/2017/07/raspi-5-BLE.html


# BLE -IoT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html



2017年7月14日金曜日

消費電力比較、RN4020 BLE とesp8266(途中編)

前回製作した、rasPi対応のRN4020+ atmega基板で省エネ化が進んだ為
主に他機種との比較の消費電力調査を行いました。
測定機器/部品等の関係で誤差が出ましたので、測定方法等の見直し必要の状態ですが
ある程度まとまりましたので、公開したいと思います。

比較対象は WIFI(esp8266)とし、
測定方法としては、特定の時間帯の消費電力を測定し
理論値でモバイル電源の連続可能時間を予想する方法としており。
実測値での、連続稼動時間(電池切れまで)を測定している方法ではありません。

*1 ) esp32は、消費電力が大きい為 対象外としました。
*2) BLE server(rasPi)機の消費電力は計測しておりません。
 子機の消費部分となります。


#結果
RN4020 基板が消費電力が少なく、約 1/ 8.5 の電力で稼動できそうです
*) 測定誤差が確認でましたので、補正の計算を実施しています。


# 測定方法/測定機
arduino UNO 内臓 ADCを使って、100mSec 単位で電圧を測定、
PCに送信し、python でファイル保存 (集計)
電流測定用抵抗 =1R
を ADC/GNDで結線し、電位差を測定。電流値を算出
この場合 1Rなので、電圧値= 電流値として読んでいます。


計測条件:
測定間隔= 0.1sec (100 mSec)
測定時間 : 1H
測定サンプリング数: 36000 件(3600秒 * 10)
デバイス Sleep間隔: 5分 (300 sec)
測定箇所 : 5Vライン

*1) センサ等の周辺部品は外して計測しています。(両方のデバイス)
実際には接続するセンサ消費電力との合計値を把握する必要があると思います。
*2) 結果の差が大きかった為、各3回測定しています。
さほど差は出ませんでした。


*) 補正の計算処理について
この計測方法での、ADCの読み込み値が 1mV(1mA)より少ない値が、読み込み出来なかった為、
実際の消費と差が生じている点を発見できました。
暫定対応で、スリープ時の消費電力をテスタで計測し、
加算した計算結果を、最終比較データとしています。

# 消費電力グラフ


*) スリープ解除後の、上昇値で差が出ている部分は、
測定間隔(100 mSec) が長く、瞬間上昇値のタイミングを
計測できていない為と予想しています。

# 累計消費


*1) 累積 折れ線グラフを見ると、大差がよく把握できました。
*2) スリープ時が、平行になっている部分は。測定方法の問題で
実際には、少し右上がりに傾くのが正解と予想しています。

[考察]
右側が補正後の集計値となります。
測定不可能だった、 1mA以下のスリープ時 電流値を テスタ計測で加算しています。
補正値:
esp8266    : 0.80 mA
RN4020 : 0.10 mA

*) esp8266のスリープ時の消費電力が多いのは、
 電源周辺の部品(LDO)で、消費が多いようです。
 消費の少ない部品に変更できれば 基板全体で消費は下がると予想されますが
 LDO出力値の高い機種は、やや消費電力は多いのかもしれません。
 1mA - 0.5mAでも、この場合長時間が多くなると。悪影響が大きくなるようです

最終的に機種比較している電流値(mAh /1時間当り消費電流  )は
esp8266= 1.961527 mAh
RN4020 = 0.23011 mAh
*) ケタ違いで大差がでています。

[連続可能時間 (仮計算) ]
 例として、単三(二次電池)×4本の場合
1000mAh * 1.2V * 4 = 4800 mWh ですが、
出力誤差を考慮して、 4000mWh程度で仮定します。
電池容量 / 1Hあたりの消費電力(mWh) = 連続稼動時間(予想)
として、計算しています。













# まとめ
BLEデバイス等での、IoT 省電力化の検討面で
ご参考になればと。思います


# 関連のページ
RN4020 BLE + ATMEGA328, 省エネ改良版
http://knaka0209.blogspot.jp/2017/07/esp32-21.html

Raspberry Pi , BLE gateway 設置、 複数台のBeacon からの送信値をクラウド転送
http://knaka0209.blogspot.jp/2017/07/raspi-5-BLE.html



# BLE -IoT関連まとめ
http://knaka0209.blogspot.jp/2017/07/BLE-matome.html








google colaboratory お試し編 、GPUも使える機械学習の環境構築

前回続き、機械学習の関連となります。 開発環境まわりの内容となり。先人様の情報を元に調査しました。 google colab(google colaboratory) を試してみました。機械学習系の いくつかのライブラリがインストール済みで、 クラウド上で、ある程度機械学...

AD-parts

Shop
Bluetooth搭載
ベース基板

Social