ブロックを積みながら(24) BBC micro:bit v1.5、消費電流測定その1

Joseph Halfmoon

別件で、ダラダラとBBC micro:bit v2を動作させつづけているので、micro:bitの消費電力がチト気になってきました。しかし本日v2は忙しくしているので、お手すきのv1.5をターゲットにして測定。マイコンの場合、消費電流が動的に変化しまくるのですが、今回はADALM1000のSMUを使って捕捉してみました。

※「ブロックを積みながら」投稿順 index はこちら

本当はv2のBluetooth使用時の消費電力を把握しておきたいのですが、まずはv1.5の簡単なケースで測定方法を確立?してみたいと思います。micro:bitに書き込んだのは、基本中の基本、以下の「Lチカ」コードであります。

  • 100m秒毎に、LEDマトリックスの左上のLED1個を点滅させる
  • LEDの輝度は初期設定値で指定

輝度は、0(消灯)、125、そして255(最高輝度)の3段階で調べてみることにいたしました。
DUT code

micro:bit には電池端子から3V電源を与える

micro:bitに電源を供給する場合、以下の2つの方法で大きく動作が変わります。

  1. USB端子から5Vを供給
  2. 電池端子から3Vを供給

USB端子から電力を供給すると、ファイルの書き込みやデバッグを司るインタフェースマイコンが起動し、USBの5Vから3.3V電源を生成してnRF51(v1.5の場合)をはじめとするボード上のデバイスに電力を供給してくれます。これに対して電池端子から3Vを供給した場合、インタフェースマイコン側には電力が供給されず、nRF51やセンサなどのみ電池からの3Vで動作します。当然、後者の方が電力は小さい筈、今回はこちらを測定です。

消費電流は動的に大きく変化

多くのマイコンシステムの電力消費は時間変化が速くて変動も大きいです。何か操作をするたびに一瞬電流が大きくながれたり、減ったりすることを繰り返します。スリープとかパワーダウンなどを併用すると、絶対値的にもダイナミックレンジがかなり広くと思います。その動的に変化する値のうち、測定対象の条件に当てはまる部分を取り出して平均(積分)する必要があると思います。

実際に micro:bitのLEDを100mS毎にトグルさせたときの電流波形を以下に示します。輝度設定は255。なお、測定は例によって、アナデバ様のお手軽アナログ学習ツール ADALM1000(M1Kと呼称)を使用。CH-AをSVMI(電圧供給、電流計測モード)のSMUとして使用(設定電圧3V)し、これをmicro:bitの電池端子に接続しています(アイキャッチ画像参照。)

ledB255

約1200m秒付近までの波形は、電源投入Power on RESET後の初期化時の波形だと思います。これはこれで興味深いのですが今回は流します。1200m秒付近でようやく通常処理が開始され、ほぼ100ms毎の電力を食っている部分が3回みてとれると思います。観察するとLEDが3回点滅しているので、ここはLEDの点灯に対応していると推定できます。micro:bitのマトリックスLEDの駆動はPWM波形で行われているために細かいパルス列として見えているようです。

知りたいのは通常処理時の消費電流(電圧かければ電力)です。ここはエイヤー方式にて

1200msより後のドタバタしている電流波形の平均値を求める

ということにしてしまいました。

次の波形は輝度設定をほぼ半分の125に設定したもの。ledB125

みたところあまり255のときと変わりませぬが、後で平均値をとると差が分かります。

さらにもう一つ、プログラム的には点滅させているのだけれど、輝度を0、つまり消灯状態にしたものが下に。

ledB0これは寂しい感じの波形が観測できてます。

さて、画面で波形を観察しても消費電流は求まらない(ターゲットの時間区間をうまく設定してADALM1000を制御するAliceソフトウエアの演算機能を駆使すれば多分求めることはできるかもしれないです。使いこなしてないだけ。)ので、データを外部に吐き出させ、表計算ソフトで1200ms以降の800ms分80000個のデータの集計を行うことといたしました。データを吐き出させる方法は、こちらに書かれています。

Active Learning Interface (for) Circuits (and) Electronics M1K:

実際に欲しいのは電流波形なので、上記の例をチョイ変した実際の操作がこちら。AliceソフトウエアはPythonで書かれており、Command Line Interfaceを使うと、Pythonコードをそのまま実行できます。結構な荒業?です。データ配列には定番のnumpy使っていることが分かります。
M1K_CLIF

測定結果のまとめ

さて、測定結果を以下の表にまとめました。AVGが800ms間の平均値。MINがその間に観測された最小値、MAXが最大値です。だいたい10μs毎にサンプリングして測定していることになります。十分な測定点数があるので平均値は実態からそれほど乖離していないのではないかと思います。MAXはスパイク上に現れるので、たまたまサンプリングに引っかかれば良いですが、見逃している山もあるやに思われます。

DutyはLED点滅周期のデューティです。100ms点灯、100ms消灯の繰り返しなので50%としています。brightnessは、LEDの輝度の設定値です。LED点灯はPWM制御されているので、こちらにも周期とデューティがありますが、測定忘れました。また今度ということで。

データをみるとだいたいMIN値に相当している「床」が見えます。ほぼ1.33mAくらいの電流が常時流れているようです。ソフトウエア動作によって変動する処理分はその上に載ってくる感じでしょうか。brightnessに応じて平均電流がちゃんと変化しているみたいなのでよかったです。current measurement result

Bluetooth使っているときの電流も測定したいけれど、予想するに問題ありそうです。上記のグラフは2秒分ですが、これはM1Kの制御ソフトウエアの制限なのです。手元のM1Kの制御ソフトウエア Alice Desktopは、画面1画面分の間、SMUを動作させ電力を供給し、同時に測定を行います。しかし、1画面分データを取り終えるとSMUからの電力供給もOFFってしまうのです。見えないところは動作させないというポリシーみたい。通常のオシロであると、トリガして見えている波形の裏で別電源で動作が続いているのが普通なので大分違います。そして測定点はどうも100000点固定。10000点あたり最大200msというレートが最長測定期間を与えてくれるみたいです。よってMAXが2秒。Bluetooth通信の測定するときはもっと長時間測定しないとコネクトして通信まで行きつけなそうです。どうするかな~。なにか設定変えられるかな~。また今度だな~。

ブロックを積みながら(23) BBC micro:bit v2とラズパイでサウンドモニタ に戻る

ブロックを積みながら(26) BBC micro:bitとラズパイでサウンドモニタ その2 へ進む