denshikobo’s blog

PICプログラミングやPCの操作で感じた日々の由無し事を綴ります

NCR18650Bの充放電試験を始めた

18650

(2016.10.10)
Oscilogi410に新たに組み込んだデータ・ロガー機能は、18650と充電器（これです↓）の評価試験を行うためでした。

https://www.amazon.co.jp/gp/product/B010FJTEFC
https://www.amazon.co.jp/gp/product/B00IFXP1NU


試験の結果、電池容量はおよそ1000mAh（1A放電時）ということになりました。

f:id:denshikobo:20161010170135p:plain


公称容量3000mAhの1/3がこの電池の実力なのか？
それとも充電器との相性が悪いのか？
（電池の保護回路と充電器の保護回路が重複している）
その辺りの調査は今後の課題です。

何といっても安いし、私が必要としてる性能は満たしているので、1000mAhという結果に不満はありません。（^_^;）

電池ボックスと充電器が２個余ったので、新たにこれ（↓）を購入し、調べてみることにしました。
https://www.amazon.co.jp/gp/product/B00ATP5A88


すると・・・

f:id:denshikobo:20161010170149p:plain

見事、公称容量3400mAhを超える放電試験結果を得ることが出来ました。
パチパチパチ～

いわゆる生セルと呼ばれるもので、過充電・過放電保護機能を備えた充電器との相性が良かったようです。


終わりの方で電池電圧がバタバタしています。そこの時間軸を拡大してみると・・・

f:id:denshikobo:20161010170202p:plain
（１）過放電保護回路の働きで電池の放電が止まる
（２）すると電池の電圧が回復してくる
（３）過放電保護回路が切れて放電を再開する
（４）電池の電圧が急速に下がり、過放電保護回路が働く
これを繰り返しているようです。気になる動作ですが、過放電保護は大丈夫なんじゃないでしょうか？


ただ今充電試験の最中ですが、試験時間がどれだけ掛かるか、5時間か？それとも７時間を超えるのか？、検討もつきません。

２４時間連続計測の実績を誇るオシロジ・データ・ロガー無しでは、考えられない試験です。

Oscilogi2(PIC基板)の動作がおかしい

オシロジ

(2016.10.02)
Raspi3に乗せたOscilogi2の動作がおかしいことに気付きました。
Osci_Logi_Consoleの起動直後に計測ボタンが点滅しています。計測ボタンを押していないのにPICは計測中のようです。しかも、中断ボタンを押しても止まりません。データ・ロガー・モードばかりテストしていたので、通常計測の異常に気付きませんでした。orz

リセット直後のOscilogi2に異常は見られません。しかし、計測を開始すると中断できなくなります。驚いたことにRaspi2Bの方はこれまで同様、計測開始／中断が出来るのです。

いったい何が起きているんでしょうか？

データ・ロガーと通常計測の大きな違いは、計測中にコマンドとデータの送受を行うか否かです。通常計測の場合は、計測を終了（または中断）するまで、受信コマンドの解析を行いません。（I2C割り込みで受信は出来ます）
唯一、BRKコマンド（最初の文字B）だけ、I2C割り込みの中で識別してbreak_flagを立てています。それによって計測を中断しています。

PICkit3でOscilogi2の動作を調べてみると・・・

（１）I2C割り込みの中でbreak_flagを立てる所にbreakポイントをセットする
（２）Osci_Logi_Consoleで中断ボタンを押す
（３）PICkit3がbreakで止まる
（４）break_flagはセットされている

ふむ、正常。

（１）通常計測ループを抜けた所にbreakポイントをセットする
（２）Osci_Logi_Consoleで中断ボタンを押す
（３）PICkit3がbreakで止まる
（４）break_flagはセットされている

ふむ、正常。

（１）breakポイントを外す
（２）Osci_Logi_Consoleで中断ボタンを押す
（３）PICkit3でbreakを掛ける
（４）通常計測ループを走っている

一旦計測ループを抜けて、また計測を再開している？
えーとコマンド・ステータスは・・・LOG_COMMAND?
LOGコマンドを送っていないのに？

あっ！

2016.09.28のブログの中で”計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理は削除した”と記しましたが、単純に削除してはいけなかったようです。

denshikobo.hatenablog.com

Raspi2Bの場合
（１）文字Bを受信して計測を中断
（２）BRKコマンドを全て受信してから（30μS以上経過）
（３）コマンド・ステータスがBRK_COMMANDになると
（４）Oscilogi_mainループで計測再開判定==>再開せず

Raspi3Bの場合
（１）文字Bを受信して計測を中断
（２）BRKコマンドを全て受信する前に（20μS未満）
（３）コマンド・ステータスがLOG_COMMANDのまま
（４）Oscilogi_mainループで計測再開判定==>計測再開

と言うことことではないでしょうか？

以前判定したLOG_COMMANDステータスで計測を再開しないよう、新たにコマンド・ステータスの有効/無効を示すフラグを設けて、不具合は解決しました。

やれやれ

100mHzサンプリング試験が無事終わった

オシロジ

(2016.09.30)
時間の掛かるOscilogi410の24時間連続計測試験ですが、不具合無く動いてくれればサクサク進みます。500mHzサンプリングと100mHzサンプリングの連続計試験が無事終了しました。100mHzサンプリングだと24時間で反復回数は４回ですが、まぁ十分なんじゃないかと思います。

500mHzサンプリング試験の最初の反復で新しい不具合が見つかりましたが、動作停止するような重大なバグではなく、対策もすぐ出来たので再試験の必要は無いと判断しました。これでデータ・ロガー関連のノウンバグに対する対策は全て完了しました。
パチパチパチ～

実は1mHzサンプリングの計測試験がまだ残っています。しかし、始めると23日掛かる試験なので、（いつかはヤルつもりですが）当面は実施を見合わせます。

いよいよ、Oscilogi410は懸案事項の改善に取り組みます。
（１）ログ・ファイルのフォーマット変更
（２）グリッドの見直し
（３）2ndカーソル導入
（４）Horizontalカーソルの導入<==やるかどうかまだ迷っている

何だか、とっても楽しみです！

Oscilogi410のプロセスを調べてみた

オシロジ

(2016.09.29)
Raspi上で走るOscilogi410のプロセスについて調べてみました。

$ ps －C java -o pid,ppid,psr
 PID PPID PSR
1952 1950 2

$ ps －C bcm2835_for_java -o pid,ppid,psr
 PID PPID PSR
1968 1952 3

bcm2835_for_javaの親はOsci_logi_Console.jarを実行しているjavaプロセスです。
二つのプロセスは走っているコアが異なるので、プロセス間のContext切り替えで問題を生じたという考え方は変な気がしてきました。

プロセス間のコーディネーション、砕いて言えばring_bufferのempty対策が不十分だったために起きた（<==それが全てでは無いとしても）不具合だったのではないか？と思い始めました。

ーーーーーーーーーーーーーーーーーーーー
そこに重点をおいた対策は既に施しました。
ーーーーーーーーーーーーーーーーーーーー
まぁ、動いているのだから良しとしましょう。

 

Oscilogi410の不具合対策で苦労した

オシロジ

(2016.09.28)
24時間連続計測試験について、『連続計測試験に失敗して・・・何とか対策を施して・・・』と記しましたが、”エラーで通信が途絶えたら、それを修復して計測試験を続行する”という対策でした。充電器の充放電試験を出来るだけ早く行いたいという事情を抱えて、苦肉の策でした。

少し余裕が出来たので、そもそも通信が途絶えてしまう原因は何なのか調べてみることにしました。

Oscilogi410は次の三つのプログラムで構成されています。
（１）Osci_Logi_Console（JAVA Swing）
（２）BCM2835_FOR_JAVA（C）
（３）Oscilogi2（XC32）

通信が途絶えてもOscilogi2の計測動作は継続していて、BCM2835_FOR_JAVAを再起動すると停止した通信が回復するので、Osci_Logi_ConsoleとBCM2835_FOR_JAVA間で問題が発生していることが推察されました。しかし、計測データとコマンドの送受を何千回も繰り返すことが出来るのですから、基本的な動作に問題は無く、ある特定条件下で回復出来ない不具合が発生していると考えました。つまり、どこか拙いタイミングでOsci_Logi_ConsoleとBCM2835_FOR_JAVA間のContext切り替えが生じているのではないか？ということです。しかし、その対策のために異なるプロセス間のContext切り替えを望むように操作することなんて出来るんでしょうか？

----------------------------------------------------------------
(2016.09.29)
そもそも、マルチコアのRaspi2Bや3BでContext切り替えというのは間違いです。
buffer-empty対策が抜けていただけだったのかも・・・----------------------------------------------------------------

対策その１
BCM2835_FOR_JAVAのnice値を+1してみる
対策その２
Osci_Logi_ConsoleとBCM2835_FOR_JAVAのContext切り替えを意識して行う
==>切り替わっても良いと考える所にusleep(5000)を入れてみる

この二つの対策で通信が途絶えることは無くなりました。残ったのはPICのデータ・ポインタが時折変な値を示すという不具合でした。どうやら一連の計測を終えて再計測を開始する辺りで、何かが起きているようです。

ここはPICkit3の出番です。データ・ポインタが異常値を示したときのOscilogi2の状態は・・・COMMAND_NULLになっています。これでデータポインタを読みだすと数値ではなく"NULL"という文字列が出力され、受け取った異常値（1314212940）と一致します。このとき受け取ったコマンド文字列は・・・”RCV 3”で正しく受信している。ということは・・・一旦設定されたCOMMAND_RCV_3が、その後でCOMMAND_NULLに書き換えられた？

ビンゴ～
一連の計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理が見つかりました。

データポインタを読みだす部分はこんなプログラムです。
i2c_write("RCV 3");
ope_sync();
idle_10ms();
i2c_read(buff,8);

”RCV 3”を出力してから、８バイトのデータを読み出すまでの僅かな時間に、偶々計測を終了してコマンド・ステータスをCOMMAND_NULLに書き換えていたという訳です。

計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理は必要ないことが判ったので、これを削除して一連の不具合対策は

『これにて一件落着～』 チョン（<==拍子木の音です）

------------------------------------------------------------------------------

このブログを読んで、自分もやってみたいと思ったあなたへ
是非、組み込み系の世界に飛び込んで下さい。
マルチコアのぐちゃぐちゃしたデバッグ作業があなたを待っています。

うへ～と思ったあなたへ
その反応は正常です。組み込み系（特にマルチコア・プログラミング）には近づかない方が身のためです。

動作テストでOscilogiを壊した

オシロジ

(2016.09.25)
机の脇にPIC32MX250F128Bが二個転がっています。充電器の動作テスト中に交換したものです。Oscilogi410の信号入力端子に保護回路は付いていないので、０～３．３Vを越える電圧を掛けるとPICに異常電流が流れて壊れてしまいます。Oscilogi410に接続する箇所の電圧はチェックしてあったのですが・・・

充電器の動作テストは、こんな回路で行いました。OUT+とBAT+、IN-とOUT-は基板上で接続されていて、IN-とOscilogi410のGNDを接続しました。IN+とBAT+は3.3Vを超えるので、抵抗分割（半分に）した電圧を計測しました。それとBAT-とOUT-の間に入っている過放電保護回路の影響を見るため、BAT-端子を計測する（<==これが誤りだった）ことにしました。

f:id:denshikobo:20160925125933j:plain

充放電試験を１回行い、さらにもう一回行おうとしたところで異変に気付きました、コマンドの送受が行えなくなっています。調べてみるとPICが熱くなっていました。orz

どこかで（USB電源を接続する時とか？）3.3Vを超える電圧が発生したのでしょうか？
やむを得ずPICを交換して再試験に臨みました。試験前に計測箇所の電圧を再確認してから計測に臨みました。

充電試験・・・無事完了。放電試験・・・無事完了。えっ！
PICが熱くなっています。あっ！

ようやく気付きました。放電試験終了時に過放電保護回路が働いてBAT+端子の電圧が0Vに落ちます。するとBAT-端子は-3.5Vになるのです。その結果PICから異常電流が流れて・・・

 

という訳でBAT-端子の計測は止めて、３個目のPICで計測した結果がこれです。

充電試験の結果。グラフの縦軸は単位換算した電圧（V)で、横軸は時間（秒）です。

f:id:denshikobo:20160925130028p:plain

放電試験の結果。同じく縦軸は電圧（V)で横軸は時間(秒）です。

f:id:denshikobo:20160925130000p:plain

凡そ１Aの電流が4200秒流れていて、最後に過放電保護回路が作動してバッテリー電圧（BAT+端子）が0Vに落ちています。


充電完了時のBAT電圧は4.0Vで満充電には達しないようです。その結果、１A放電時の電池容量は1000mAhと、公称値の1/3程度しかありませんが（<==自分にはこれでも十分なので）、取りあえずO.K.です。

 

連続充放電試験の準備がもうすぐ整う

オシロジ

(2016.09.12)
（これ↓）の動作テストを行うため、Oscilogiにデータ・ロガー・モードを組み込みました。

https://www.amazon.co.jp/gp/product/B010FJTEFC/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

データ・ロガー・モードの24時間連続計測試験に失敗して暫くジタバタしましたが、何とか対策を施して24時間連続計測試験を終えました。Oscilogiはメモリの許す限り、何日でも計測を続けることが出来るようになったものと思います。

今日はDS18B20を使った温度計測機能を組み込みました。
この（↓）辺りの情報を参考にして、カーネル・モジュールで温度計測を行い、
http://blog.livedoor.jp/victory7com/archives/33399310.html
その結果をJAVAから読み取るという方法でOsco_Logi_Consoleに温度計測機能を組み込むことにしました。

秋月電子に注文した部品（5Wのセメント抵抗他）が届いたら、いよいよ充電器+18650の連続充放電試験です。