バッテリー、モバイルバッテリーの使用について
M5Stackを1年以上使っていましたが、ついにバッテリーの形状が膨れ上がり、ボトムケースが割れてしまいました。
危険性を感じたので、大手メーカー製のモバイルバッテリーに切り替えようと考えました。
ですが、通販サイトを見てみると、
何と!
大手メーカー製の最新製品が全く見当たりません。
これはどういうことかと調べてみると、2019/2/1よりモバイルバッテリーが電気用品安全法の規制対象となったとのこと。
要するにPSEマークが付いていない製品は販売できないようです。
よって、通販サイトにある大手メーカー製モバイルバッテリーはPSEマークの無い旧製品だけでした。
リチウム系バッテリーは発火事故ニュースが多いので、私としてもPSEマーク付きのものが欲しかったわけです。
個人的には大手メーカー製の方が安全かな?? と思って、下図のようなELECOM製のものを買ってみました。
Amazonでは白色のものがありました。
これは最近、電気用品安全法(PSE)に対応した製品ですけど、残念ながら30分ほどでモバイルバッテリーの電流供給が停止してしまいました。
M5Camera や M5StackはWiFi通信時に瞬時大電流が流れるので、そのせいで保護装置が働いたのかな?と思いました。
そこでTwitterでツイートしてみると、Kenta IDAさんからリプライがあり、電流が少ないことによって自動電源OFF機能が働いたのではないか、とののアドバイスをいただきました。
確かに、スマホを充電する電流は1~2Aとすると、M5Cameraの電流は0.2A程度ですから有り得ますね。
また、紅樹 タカオさんからは USBload なるものを紹介していただきました。これはEdelWorksさんが製造し、スイッチサイエンスさんが受託販売しているものです。
モバイルバッテリーの自動電源OFF機能を動作させないようにするために間欠動作(一時的に大電流を流して、不要な区間は通常電流を流す)するらしいのです。
いわゆるダミーロードのようなものですが、間欠動作っていうのは素晴らしいですね。
実際に試してみたわけではないので何とも言えないのですが、近々買ってみたいと思いました。
それとは別に、totsucomさんとK.Nogさんからは、cheeroから販売されている以下のバッテリーを勧められました。
https://cheero.net/canvas-iot/
最初は単なるモバイルバッテリーかと思っていたのですが、メーカーページをよく読んでみると、何と
「微弱な電流でも給電できます」
と書いてあります。
K.Nogさんによれば、ラズパイで使っていて、自動電源がOFFにならない数少ないバッテリーだそうです。
へぇーー!!!
買う前にこれを知っていれば・・・、と思いました。
残念ながら私が買おうとした時には在庫切れでした。
今度はこういうのを買いたいですね。
Twitterというのは便利で、すぐにリプライ頂けて、欲しい情報が手に入りますね。
みなさん、ありがとうございました。
m(_ _)m
そんなわけで、バッテリーに関しては自分の目の届かないところに置くことが多いので、できるだけ安全性最優先で購入したいですね。
パケットロスについて
是非、合わせて参照してみてください。
M5StackとM5CameraでWiFi, UDPによる動画転送を長時間連続安定動作させる実験
(2019/12/18)
M5Stack と M5Camera間のWiFi, UDP動画転送で、最初に紹介した動画のようにパケットロスが所々発生しますが、それについてザッと考えてみました。
プログラミングによる通信トラフィック障害
最初に紹介した動画を見て頂けるとわかると思いますが、パケットロスするところというのは、決まって垂直50~100pixelくらいのところです。
WiFi, UDPデータ送信のトラフィックが混んでくると、そのあたりがパケットロスするということは、プログラミングの何かしらの原因かな?と思われます。
多分、画像データのUDP送信間隔が速すぎるものと思われます。
M5CameraからのUDP1パケットは、OV2640からの画像データ3列分を一まとめにして送信しています。
そこで、先ほど紹介したプログラミング(スケッチ)例でも述べたように、delayやdelayMicrosecond関数を使ってトラフィックが混雑しない様に調整したみたわけです。
delay間隔が大きすぎるとフレームレートが下がって、動画がカクカクしてスムースさを欠いてしまうので微妙に調整が難しいです。
先ほど紹介したソースコード(スケッチ例)では、垂直行番号もパケットで送っているので、プログラミングでパケットロスを検知してdelay間隔を自動で調整することも考えました。
ですが、特に改良しなくても、パケットがロスする様子を画像で観察できて、個人的には逆に良い感じだったので今回はそのまま改善しないことにしました。
これは今後の課題としたいと思います。
因みに、M5Camera起動したばかりの時はパケットロスが多く、しばらく暖気運転した後の方がパケットロスが少ないように見受けられました。
通信距離および通信障害物によるパケットロス(SoftAPモードの場合)
最初に紹介した動画では、iPadのYouTube動画WiFiストリーミング、M5Camera、M5Stackという、3つのWiFi機器が近接しています。
これは電波障害、通信障害が起きていると考えられますので、パケットロスは多いと思います。
純粋にM5StackとM5Cameraだけで、他のWiFi電波や電子レンジが近くに無ければ意外と良好に受信してくれるかもしれません。
また、その他の例として、壁を隔てて扉を開けておいた別の部屋にM5Cameraを置き、別の部屋にM5Stackを置いて画像を見てみました。
およそ5m離していましたが、画像の動きがカクカクしてしまいました。
逆に、電波の見通しがよく、電波が迂回しない直線距離で5m離した場所に置くと、画像がスムースに表示されました。
遮蔽物が何も無いと受信は良いですが、電波が迂回しそうな壁があるとパケットロスしますね。
部屋の扉を閉めていなくても、見通しが悪ければUDPのパケットロスが発生しました。
ESP32のSoftAPモード(自信がアクセスポイントになるモード)の場合、そんなに遠くには電波が飛ばないみたいです。
せいぜい5mくらいではないかなと思います。
遠くに飛ばしたい場合、出力の大きいWi-Fiルータにして、STAモードにした方が良いと思います。
是非、合わせて参照してみてください。
M5StackとM5CameraでWiFi, UDPによる動画転送を長時間連続安定動作させる実験
(2019/12/18)
編集後記
どうでしたか?
Arduino IDEプログラミングでここまでできれば、自前で何でも出来そうな気になっちゃいますね。
パケットロスが多いですが、自分で作るとそれも楽しめちゃいます。
ネットワークのUDPについても、いまいち理解していなかったのですが、前回記事ではその道のプロの方から厳しいご指摘を受けたおかげで、今回も更にちょっとだけ理解が進みました。
独学では厳しいものがありますが、ブログで発信し続けていれば、誰かしらから教わることができるという利点がありますね。
とにかく感謝感謝です。
そんなこんなで、画像転送に関しては自分のやりたいことはほぼできました。
ようやく何度も先延ばしにしていたディープラーニングに取り組みたいと思います。
(何度も同じこと言っていますね。。。スイマセン)
今回はここまでです。
ではまた・・・。
コメント
I would appreciate it if you fit with ESP32 Camera and ili9341
Thank you!