2025/07/17

カラー化した温湿度&暑さ指数表示端末を、ちょっと改良【2025/07/18追記】

おうちサーバーの温湿度データから求めた暑さ指数を表示する小箱を、昨年作った白黒表示のものからカラー表示に置き換えました。これで正面から見る限りでは現在のWBGT指標がとても見やすくなったのですが、ケース内のLEDを「危険」レベルの時の赤色だけにしてしまったので、正面以外からは指標が分からなくなってしまいました。

また、作っている時から気が付いていた夜間消灯時にスイッチでバックライトを点灯すると輝度MAX.になってしまう問題が、やはり地味に不便でした。

上記2点の不都合を、ちょちょっと改良しました。変化は後ろ姿だけです:
Cterm08
右上で光っているのはマイコン内蔵カラーLEDで、ゆっくり明滅します。また、左下に輝度調整用のボリュームが見えています。
回路図は次の通りです:
Wdd_term_color_sch05
GitHubのリポジトリも更新しておきました。

配線済みの基板とLCDを部品面側から見ると、XIAO上側のLEDが赤色単色からカラーに代わり、左下にLCD輝度調整用のボリュームが付きました:
Cterm09
回路面(部品反対面)は、少し配線が変わっただけです:
Cterm10
BOMは次の通りで、合計2087.5円でした(78円の追加)。なお、電線・ハンダ・ピン・ラベル・LED光拡散キャップ等の副材はカウントしていません:
itemdetailpricepcssubtotal
MPUSeeed XIAO ESP32C6104011040
LCDM154-240240-RGB7501750
C105:RDER71H105K2K1H03B20120
C104:RPEF11H104Z2P1A01B10110
LEDPL9823-F540140
SWTCF-06210110
SWSS-12D00-G520120
VR3362P 10350150
subsAE-FRSK-120-UV-TH1201120
case内寸約60x40x30mm27.5127.5

ところで、GitHubにコードをアップするとCopilotによるAI添削が受けられるようになりました。起動すると"How can I help you?"と英語で訊いてきますが、試しに日本語で「何か問題があれば教えて下さい」とプロンプトを打ってみると日本語で回答されました。その結果、大きな問題は無いけれども関数に付ける注釈はdocstringにすべきだとか、定数は大文字が慣例だ、などと教えてくれました。この辺り、私が体系的に学んでいないことがあらためて突きつけられたということで、とりあえず簡単なところだけ直しました。その他、循環的複雑度の悪かったmain()を分割したり、エラーハンドリングを共通化するなどのリファクタリングもしました。他にも気になることがコメントの英語化など色々あるのですがキリが無いので、とりあえず今日のところはこれぐらいで勘弁してやります(ぉぃ)。ちなみに、今回使ったマイコン内蔵カラーLED配色がGRB(緑-赤-青)順なのですがCopilotはRGB順だと思い込んだようで、コメントで明記しても執拗に「間違ってる」と言ってきました。(PL9823の色順についてweb情報が少ないのはホビー用途で「動けば正義」だからか。まぁ、3.3Vで使っている段階で「動けば正義」そのものなのですが。)

以上、引っかかっていたところが解消してスッキリしています。何かの参考になれば幸いです。

パドラッパ from MacBook Air (M2)

【2025/07/18追記】
ケースを横向きにして蓋をLCD開口にした方が造形的にも加工的にもよかったかも、と今さらになって考えています:
Cterm11
というのは、画面が斜め上を向くのは良いし、DAISOミニパックは蓋素材PEの方が本体素材PPよりも切りやすいからです。もしかしたらAmazon Echo Show似になるのを無意識が避けたのかも知れませんが(似てない)、1年前に気付きたかったところ。
あと、ケース加工にはホットナイフなどがいいかも、とMastodonで教えてもらいました。次に向けて考え中です。

| | | コメント (0)

2025/07/12

温湿度&暑さ指数表示端末をカラーLCD化しました

2025年の西日本は梅雨明けが平年より20日ほど早まって6/27になり、既に猛烈な暑さが来ています。6/25には昨年作った温湿度&暑さ指数表示端末カラーLEDが煌々と赤く輝き、同時におうちサーバーに付けているスピーカーから「暑さ指数が危険レベルです」という合成音声が流れてきました。
その、カラーLEDが赤く光っている私のMastodon投稿を見て、カラーLCDで温湿度計付きデジタル時計を作っている方が「暑さ指数の色を液晶の背景色にして表示してみた」と投稿されました。一目見て「面白い」と思い、私もカラーLCD化してみた次第です。
Cterm01

あらためて秋月電子さんのLCD一覧を眺めていると、
a. 1.54インチ240x240ドット (M154-240240-RGB) と、
b. 2.8インチ320x240ドットのタッチパネル&SDカードスロット付き (MSP2807)
の2つが目に留まりました。最近発売されたばかりのa.は「いつもの」100均ケースにちょうど入りそうです(但し、下の方が蓋と干渉して見えないので、実質的に240x200程度になります)。b.は面白そうなのですが、少しばかり大きいのと、POSハンディ端末のようなオマケ機能を使うアイデアが浮かばなかったので、今回はパス。というわけで、LCDはa.を使うことにしました。

機能的には去年作った白黒端末と同様に、おうちサーバーからWi-Fiで室内外のデータを貰ってきて表示することにします。
  1. 文字と背景の色は環境省の「運動に関する指針」を用います(私自身の体感とも合ってます)。
  2. 室内・室外表示切り替えにスイッチを付け、「危険」レベルになったら目立つようにLEDを点滅させます(今回は単色の赤色LED)。
  3. バックライトはふだん起きている時間帯だけ点灯し、通常は消灯する夜間でも「危険」レベルになったら点灯することにします。

使うLCD(a.)は電源とI/Oの電圧範囲が2.4〜3.3Vと低めなので、マイコンもこれに合わせる必要があります(まぁ、組み込みなら大抵大丈夫でしょう)。去年出てから気になっていた、Seeed Studio XIAOシリーズで初めてWi-Fi内蔵アンテナを搭載したESP32C6も大丈夫なので、これを今回は使ってみました(手持ちのRaspberry Pi PICO Wも考えたのですが、細長すぎて使いにくくて)。電圧は3.3VでOKですし、内蔵DDコンの3.3V出力も余裕ありそうです。(回路図やIC仕様を確認するとXIAO内蔵のDDコンは1A出力で、ESP32C6自体は高々400mA、a.のLCDはドライバー7.5mAとバックライト40mA max、あとはLED程度。但しレーティングは不明。)CircuitPythonもサポートされていて、a.のLCDドライバST7789Vも使えます。

部品が着いて、すぐに検討を始めました。いきなり面食らったのがXIAO ESP32C6にCircuitPythonのF/Wを書き込んでリセットしてもドライブがマウントされないこと。実はESP32C6はUSB OTG非対応で、同じXIAOシリーズのnRF52840などとは使い勝手が違うようです(ちなみにESP32S系はUSB OTG対応)。USBシリアル接続にはThonnyが推奨だということで、Muエディタ終了のお知らせを承けてインストールだけしていたものを使うことにしました。(他にwebシリアルという手もあるのですが直接編集できないなど不便でパス。)
ツールの使い方だけ分かれば、あとは大体いつも通り。CircuitPythonはチュートリアルがしっかりしているので、初めてだったWi-Fi接続液晶表示も特に問題無くできました。特にWi-Fiについては、ssidなどのパラメータをsettings.tomlファイルに隠蔽することが推奨されており、このおかげで手軽にコードを共有できます(このやり方は便利なので他でも使おうと思います)。ただ、デフォルトのフォントが好みでなかったので、ちょっとFelo AIさんに訊いて、MINTIAで有名なFuturaフォントotf2bdfで変換して使うことにしました(これは再配布しません)。ところが、フォントを変えると表示はいいのですが処理が重く、書き換えているのが目で見えるほど時間が掛かります。
このタイミングで表示エリアが縦に広がったことと等幅フォントを使わなかったことに対応したwebアプリも新たに起こしました。そのレスポンスは次の通りです:
Cterm02
(PCのChromeによるキャプチャ)

・・・というようなことをしながらでも、1日でブレッドボード上で一通り動くところまではできました。その後、関数を整理したりエラー発生時の処理を加えたりウォッチドッグタイマを仕掛けたりしてコーディングに区切りを付け、実機制作にかかりました。手順としては配置をざっくり検討し、ケースのLCD面を開口し、部品をはんだ付けし、スイッチと電源コネクタの位置を現物合わせで開口して、一安心したら配線です。まず、できたケースはこの通りです:
Cterm03
加工はカッターナイフがメインで、一部ハンドドリルを使いましたが、もうちょっと楽な方法は無いものか。

続いて配線済みの基板とLCDを部品面側から見ると、この通りです:
Cterm04
回路面(部品反対面)からは、この通りです:
Cterm05
LCD裏側のピンヘッダ高さに相当する厚さの消しゴムを貼って、回路側の基板と水平が出るようにしています。これをしないと、何かの拍子にLCDを触るとケース内にLCDが倒れます。

組み立てたものが、こちらです(冒頭の写真再掲):
Cterm01
従来の白黒端末と重ねて見ると、こんな感じ:
Cterm06
コントラストが良く、文字も明瞭になって見やすくなりました。

ところが、組み立てた後にネットワークエラーが頻発するようになりました。配線は合っているようで(というか、基本的に動いているし電圧関係もおかしくない)、Thonnyに繋いでもデバッグが利かないというピンチ。もしかして、と思ってXIAO ESP32C6とLCDの3.3Vにパスコンを入れたらあっさり直りました。Wi-Fiを使うのに不用意にピンヘッダを使ったりペリフェラルへ長いラインを引いたりしたらダメだね、という基本的なお話でした。

実際に使い始めたところ、わが家の居間ではバックライトが眩しすぎるという問題も出ました。これはHigh/LowのみだったバックライトのコントロールをPWMで調整し、結果として20%ぐらいで落ち着きました(上記の写真はバックライト輝度調整後です)。しかしながら、夜間消灯時にスイッチでバックライトを点灯するときはLCDの内部プルアップで単なるHighレベルになってしまうので、暗く点いて欲しいタイミングで眩しくなる、というトラップになっています。これだけのためにポートを1つ使うのもなぁ、と悩んでいるところです(いっそ可変抵抗で調整した方がいいかも)。

以上の検討を踏まえた回路図は次の通りです:
Wdd_term_color_sch
XIAO ESP32C6が機能てんこ盛りなおかげで、とてもシンプルになりました。
コードはGitHubにリポジトリを作って置いておきました。なお、ここにはネットワークパラメータ(settings.toml)とフォントは置きませんので、そのまま動くものではありません。

BOMは次の通りで、合計2009.5円でした。なお、電線・ハンダ・ピン・ラベル等の副材はカウントしていません:
itemdetailpricepcssubtotal
MPUSeeed XIAO ESP32C6104011040
LCDM154-240240-RGB7501750
C105:RDER71H105K2K1H03B20120
C104:RPEF11H104Z2P1A01B10110
LEDOSR6LU5B64A-5V12112
SWTCF-06210110
SWSS-12D00-G520120
subsAE-FRSK-120-UV-TH1201120
case内寸約60x40x30mm27.5127.5
白黒からカラーになって部品点数が激減して1000円もお安くなったのは、XIAO ESP32C6が機能の割に安く、LCDの値差も無かったおかげです。

さて、
関東以北の梅雨明けはまだですが、空梅雨の高温になったりゲリラ豪雨に見舞われたりしているようです。琵琶湖の水位も低めで推移しています。この、全体的には雨が降らないけれど降るときは土砂降りになるという現象が地球温暖化に伴うものであることを、竹筒の太くなった「ししおどし」モデルで説明されているのを最近知りました:
Cterm07
出典:国立環境研究所 気候変動適応情報プラットフォーム(A-PLAT)気候変動適応における広域アクションプラン:災害対策分科会:災害時の孤立に備える~地域特性に応じた減災としての適応~(気候変動 適応における広域アクションプラン2024年度版) p.10
折しも参議院選挙が7/20まで行われているところ、温暖化防止・再エネ化などへ本気で取り組む候補者・党が躍進できればいいなと思っているところです。もちろん自分でも温暖化抑止にできることを引き続き行います。

以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (M2)

| | | コメント (0)

2025/05/14

【お知らせ】「電子工作」カテゴリを追加しました【2025/05/16追記】

これまでArduinoSeeed XIAOESP32Raspberry PiTinkerBoardなどを使った電子工作についての記事は「パソコン・インターネット」のカテゴリに入れていたのですが、ボリュームが増えてきたので「電子工作」カテゴリを作って2つのカテゴリを併用することにしました。ご利用下さい(いちばん使うのは私自身だと思いますが〜)。

パドラッパ from MacBook Air (M2)

【2025/05/16追記】
No imageで寂しかったので、ChatGPTさんに『「電子工作」という言葉でイメージする絵を描いてみて下さい』とお願いしてみました。その結果がこちら:
Diy01
ハンダごて周りが間違い探しみたいになっていて興味深いです。ブレッドボードからリードがはみ出すのは心当たりあるかも。
続けて、英語で Please make a image of "Electronics as a DIY project". とお願いしたのがこちら:
Diy02
テスターさん仕事して〜

| | | コメント (0)

2025/03/20

Wi-Fi・BLEハイブリッドリモコンのカーソル泳ぎ対策

主にラグビーをテレビ観戦するために作ったWi-Fi・BLEハイブリッドリモコンを 前々回前回の2回で紹介しました。特に前回のスリープモード導入で復帰後のBLE接続が安定して使いやすくなりました。

ただ、ひとつ引っかかりが残っていました。何らかの不具合が生じて処理が著しく遅くなる(またはフリーズする)とウォッチドッグタイマが検知して自動的にリブートし、そのリブート後にジョイスティックの校正をするようになっているのですが、ジョイスティックを触っている時にリブートが掛かると中点でないところを中点だとみなして校正してしまうので、手放すとカーソルが勝手に動き出してしまうのです。ThinkPadのトラックポイントのようなポインティング・スティックを使ったことがある人の多くが経験した「カーソルが泳ぐ」という現象です。これが自爆的に発生してしまうのでした。

今回マイコンに(紆余曲折を経て)ESP32を使っているため、内部のフラッシュメモリであるSPIFFSを使ってCALデータを保存することにしました。幸い使い方はExamplesのSPIFFS_Test.inoを読んだらすぐ分かりました。ところが動かそうとすると一筋縄ではいかず、
E (98) SPIFFS: mount failed, -10025
というエラーが出て暫くしてリブートが掛かってしまいます。実はこれ、SPIFFSを初めて使うときに SPIFFS.begin(true) でフォーマットが掛かるのですが、この作業に40秒ぐらいかかり、その完了前にウォッチドッグタイマが作動していたのでした。これはフォーマットの時だけWDTを60秒にすることで解消しました。また、CALデータが古くなるとまたカーソルが泳ぎだす可能性があるので、Optionを押しながら起動することでCALデータを書き換えるように仕込みました。

ついでにキーアサインを1つ変更しています。RugbyPass TVでフルスクリーンにするときだけ使える'F'をOption+ESCに割り当てていたのですが、それよりもFirefoxのタブを閉じる方がよく使うので、'Ctrl+w'に変更しています。この変更を加えた回路図が次です:
Jst14
修正したコードはGitHubに置いておきました。コード中のコメント等も見直しています。

以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (M2)

| | | コメント (0)

2025/03/16

Wi-Fi・BLEハイブリッドリモコンへのスリープモード導入

まずはお詫びから。一昨日の記事の電流測定時に校正方法を間違えており、電流値が約10%大きくなっていました。記事は修正済みです。

さて、
Wi-Fiを切っても(WiFi.disconnect(true);しても)消費電流が44mA39mAも残ってしまうことからスリープを入れることを検討する方が良さそうだと書いていました。今回使っているESP32にはスリープモードがライトとディープの2つあり、再起動のトリガーも複数用意されていて細かく設定できます。私の大雑把な理解では、ディープスリープからの再起動は電源投入に相当し(Arduinoでいうとグローバルパラメータを読み込んでsetup()からスタートする)、ライトスリープからの再起動はメモリ内容などを保持したままスリープに入った位置から動き出します。
今回の場合、スリープから再起動する時にジョイスティックの校正などを飛ばして素早く動かしたいので、ライトスリープを使ってみました。
ユースケースを考えると、スリープに落ちるときはリモコンを置きっぱなしにしているはずです。また、スリープに落ちているかどうかを意識して、特定のスイッチを押して再起動するのは煩わしい。そこで、ESP32に備わっているタッチセンサー機能を使ってみました。
ブレッドボードでタッチセンサー対応ポートにリード線を繋ぎ、プラ板に貼った銅箔テープと接合して銅箔の裏側からタッチして値を読んでみると、触らない時の値は大体40台後半で、触ると値が3〜8ぐらい小さくなることが分かりました。また、この値が銅箔テープの長さなどによって変わることも分かりました。この感じだと、あらかじめ閾値を決め打ちしない方が良さそうだと思い、スリープに入る前に10回測定して平均値を求め、それよりも2だけ小さい値を閾値にすれば安定して動作しそうだと見当を付けました。

次の写真が、ケース内壁の手前側(ジョイスティックのある側)へ銅箔テープを貼っているところです:
Jst09
銅箔テープの端の方、あとでESP32のタッチセンサー対応ポート(今回はT2 = GPIO2)に接続しやすいところへリード線をはんだ付けしています。リード線の反対側にはピンヘッダーを付けるので、先にピンの絶縁用に熱収縮チューブを通してあります。
銅箔が剥き出しのままだとショートの危険があるので、上から絶縁用の紙シールを貼りました:
Jst10
そしてケースに基板を収めて、あらかじめタッチセンサー対応ポートに取り付けたソケットと、リード線に付けたピンヘッダーを嵌合します:
Jst11
これでハード面の改造は終了です。ソフトの方は、Wi-FiとBLEそれぞれにタイマーを設けてタイムアウトしたら切断するようにしていた(BLEは切断ができないので再起動をかけていた)ところをまとめて、ひとつのタイムアウトでスリープするようにしました。具体的には、Wi-Fiのタイムアウトを1分、BLEのタイムアウトを2分にしていたところ、2分でスリープするように設定しました。

あと、使い勝手を良くするためにFirefoxの再読み込み(F5)を、空いていたOption+Pauseに仕込みました。これらを行ったあとの回路図がこちらです:
Jst12
…我ながら、ほとんど間違い探しですね。IO2にTOUCHが付いているところと、Option+PauseがF5になったことが差分です。修正したコードはGitHubに置いておきました

今回の改造前後の電流値比較がこちらです:
Jst13
前はBLEのタイムアウト後に再起動がかかって定常的なアイドリング電流が39mAあったところ、ライトスリープ導入によって4.3mAになっていて、電池の負荷は格段に少なくなりました。肝心のスリープからの再起動はとても安定しています。また、スリープから起きると直ちにBLEが繋がっているのが便利です。

今後も使い勝手が良くなるように修正していくかも知れませんが、これで開発は一通り完了です。
以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (M2)

| | | コメント (0)

2025/03/14

ラズパイ5とテレビでラグビーを観るための、Wi-FiとBLEのハイブリッドリモコン【2025/03/16追記・修正】

ネット動画(私の場合はほとんどラグビー)を観るために買ったRaspberry Pi 5(ラズパイ5)の電源スイッチをリモート操作する方法が分かったことに気をよくして、おうちサーバーからラズパイ5+関係AV機器を制御する仕組みを作りました。さらに、動画再生で頻繁に使う一部の機能を補助するデバイスも作りました。
これで様々なコントロールができるようになったものの、webアプリ用スマホとラズパイ5用のマウス、それに補助デバイスの3つが絡んできて、少々煩雑な感じになってしまいました。

やはりここまできたら専用マウスを自分で作った方がいいけれど機構をどうしよう、と思いながら秋月電子さんのサイトを見ていたところ、アルプスさんのジョイスティックをユニバーサル基板に繋ぐキットを売っていることに気が付きました(他にもいくつかありますが、これと目が合った)。そこでwebアプリの操作をWi-Fiで行い、ラズパイ起動後の操作をジョイスティックとスイッチで行うBLEマウス&キーボードを作ろうと思い立ちました。少々の紆余曲折を経てできたものは、こちらです:
Jst01

さて、こんな紆余曲折がありました。
まずはBLE機能だけで「いつもの」Seeed XIAO BLE Sense (nRF52840) を使った回路とレイアウトを考えたところ、ジョイスティックのADC2系統とスイッチ9個でXIAOのI/O数はピッタリで、「いつもの」ミンティアブリーズのケースに収まるメドは立ったのですが、なんだか面白くありません。どうせならWi-Fi経由でのラズパイ5電源&周辺AV機器の操作も1デバイスでやりたいと考えていたところ、Raspberry Pi Pico Wがちょうど合いそうだと思って買って検討してみたところ、MicroPythonではWi-Fiが不安定だったのとBLE HIDが難しそうだったので早々に諦めて、CircuitPythonにスイッチ。まずはWi-Fi動作を確かめてからBLEに移ったのですが、コードが見事に動かない。なんでかなと思ったら、現時点でのCircuitPythonはPico WのBLEをサポートしていないのでした
Jst02
続いてESP32でもCircuitPythonが使えるという情報があって試してみました。素の(Sが付いていない系統の)ESP32はプログラム領域をUSBメモリとして動作させることができないためシリアル経由で操作するのですが、これがどうにも不安定かつ煩雑で、ちょっとやっていられない感じでした。
以上の紆余曲折を経て、今回はESP32-WROOM-32EをArduinoで動かすという古典的な方法にしました。

先日の動画再生補助デバイスを作ったとき昔のコードではコンパイルエラーが出ていたことから、先にライブラリのバージョン等を確認しました。BLEについては3年前に公開されていたマウスとキーボードのコンボライブラリを使うことにしてサンプルプログラムをコンパイルしたところ、Arduinoのesp32ボードライブラリ(by Espressif Systems)のメジャーバージョンが3になるとエラーで弾かれ(現行最新は3.1.3)、バージョン2系最終の2.0.17であれば動きました。そこで、以後の作業は2.0.17を用いることにしました(公式の移行ガイドがあるものの、私の技量では手に余るので)。
すっかりPython慣れしているせいでカッコや変数型などに悩まされながらも、BLEによるジョイスティック周り、同じくBLEによるキー入力周り、Wi-Fi周りとブロックごとに作っていきました。ここで、BLE関連だけでメモリ使用量が85%に達していたのでWi-Fiを合体したらオーバーするのではないかと思っていたところ、案の定130%になってしまいました。どうしようか途方に暮れながら"Sketch too big"というエラーメッセージで検索したところ、同様のトラブルはままあることのようで(一例)、Arduino IDEのToolsにあるPartition SchemeからAPPに割り当てるメモリを初期値1.2MBから最大3MBまで拡張できる仕組みがありました。今回の場合ログなどを蓄積する用途でないためSPIFFSが小さくなるのは問題無く、無事にコンパイル・実行できるようになりました(最終的に2MB割当てて81%)。

ブレッドボードでの作業はここまでとして、回路図を整理し、部品配置をあれこれ考えて、ジョイスティックやスイッチ(キー)を上側の基板に、ESP32と電源系を下側の基板に置いて、ロープロファイルのピンヘッダーピンソケットでスタックすることにしました。これで組むと、ケース内の部品高さはジョイスティック部分で約16mm、他は約15mmになりました:
Jst03
高さが不揃いになるとスイッチのキーが寸足らずになってしまうので、ジョイスティック部分のケースを刳り抜き、これでケース内は約15mmで揃います(今度はジョイスティックが低くなるので厚紙を切ったスペーサーで調える)。前にキッチンタイマーを作ったときに使ったのと同じダイソーで2個110円のばんそうこうケース(ケース内高さ16mm)に入れようと考えていたのですが、その通りにできました。ちなみにケース内寸の短辺は約33mmで、いまは亡きプラケースのフリスク用に作られた基板(例:秋月電子さんスイッチサイエンスさん)がちょうど入ります。

スタックを開いた部品面が次の写真です:
Jst04
上側の基板にスイッチ類が並んでいます。下側の基板にESP32とLiPo充電モジュール、電源系切替ジャンパを置いています。ここで充電モジュールはTP4056Aを使ったもの(Aと無印はほとんど同じ)で、2000mAh級の18650バッテリーを充電するために1A給電するように設計されているのですが、使おうとしているバッテリーは160mAhなので充電電流を1C=160mA以下にしなくてはいけません。そこで電流制御抵抗を1.2kΩから10kΩに付けかえました。仕様書の上では130mAになる設定ですが、実測値は120mAでした。


次の写真は配線面。下側の基板にシリパラ変換器とレギュレータを入れました:
Jst05
ここではLiPoバッテリーに配線やバリが直接触れて傷やショートを招かないようにマスキングテープを貼っています。また、シリパラ変換器のVBUS(5V)ラインに付いている300mA程度のポリスイッチがESP32の突入電流で動作してしまい自動リセットを繰り返すのでバイパスしました(回路側のショートに注意)。

マスキングテープを剥がすと配線です:
Jst06
LiPoバッテリーの高さマージンがあまりないので(ロープロファイルのヘッダ&ソケットで6.14mm、バッテリーの厚さが4.0mm)、電池の入るところをできるだけ避けています。

さぁできた、というところでラベルも作って組み上げて試運転を始めました:
Jst07
すると、ブレッドボードの時と違ってBLEがとても不安定でした。色々と確認したところ、縦持ちの設計で写真の左側を手で持って操作するときにBLEが切れ切れになることが分かりました。実はこちら側にESP32のアンテナが入っているので、手で電波の放射が妨げられるという初歩的なミス。Wi-FiでRSSIを見ると、手で持つことで15dBぐらい落ちていました。それでもWi-Fiは繋がっていたのですが、BLEの方が弱いようです。元々Pico Wで同じケースに収める検討をしていた時にはアンテナが中央付近に来るのでちょうど良かったのですが、ESP32に路線変更したときに見落としていました。

これは作り直しかと思っていたところで横向きに持てば大丈夫だと分かり、スイッチの機能割り当てとラベルを見直しました。さらにベータテストで機能の見直しなどをして、最終的にできたものが冒頭の写真です(再掲):
Jst01
回路図はこうなりました:
Joysticktermsch

さて、ESP32-WROOM-32Eで気になる消費電流を測りました。以前XIAO BLEの消費電流を測るために作ったハイサイドI/Vコンバータは約50mAまでしか測れず、あっさりとクリップしてしまいます。そこで1Ωセンス抵抗と並列に0.1Ωを入れて、測定倍率を(1.0*0.1)/(1.0+0.1) = 1/11 (~0.091) としてみました。
【2025/03/16 次の一節を修正しました】
この状態で消費電流を測った結果がこちらです:
Jst08a
ブート時に44mA、
無線なしでのADCを含む定常動作が33mA、
Wi-Fi起動時にピークで210mA、
Wi-Fiのスキャンで88mA流れます。
Wi-Fiを切っても6mAぐらい増えた39mAが定常的に流れ、
Wi-Fi接続するとピークで210mA・ビーコン時に88mA・ボトムが39mAを推移します。
ここにBLEが重なるとアドバタイズ時に110mA流れ、Wi-FiとBLE両接続ではビーコン時に88mA・ボトムが39mAを推移します。 今回、Wi-Fiのタイムアウトを1分、BLEのタイムアウトを2分として、BLEがタイムアウトしたらソフトリセットを掛けるようにしているので、実質的なアイドリング電流は39mA強。バッテリーが160mAhなので4時間しかもたない計算です。これは、スリープを入れることを検討する方が良さそうです。
【修正はここまで】

コードはGitHubにリポジトリを作って置いておきました。
BOMは次の通りで、合計2547円でした。なお、電線・ハンダ・ロープロファイル以外のピン・ラベル等の副材はカウントしていません:
itemdetailpricepcssubtotal
MPUESP32-WROOM-32E3601360
JoystickAE-RKJXY10000066001600
S/PCH340E module60.8160.8
ChargerTP4056A module25.4125.4
R10k 0.1% 160820120
Reg.NJM2845DL1-3350150
Sub.ESP32 to Frisk3461346
Sub.universal for Frisk1202240
Sub.D-type Non-th40140
LiPo401430 160mAh230.41230.4
casefor adhesive plaster55155
Pin socketlow profile 1x20802160
Pin headerlow profile 1x4040140
SWDTS-63 and so on1012120
SWTS8855SG-P222122
SWTVBP0620120
SWSS-12D00-G520120
C10uF60160
C1uF13452
LEDOSG8HA3Z74A Green10110
LEDOSR5JA3Z74A Red10110
R1/6W 3x100k, 2x10k155

まとめたことで課題が出て良かったと思っています。改善検討をぼちぼちやりつつ、後半に入ったラグビーシーズンを楽しもうと思います。

以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (2017 → M2, 2022)

【2025/03/16追記・修正】
初出時の電流測定で校正を誤っており、約10%大きい値となっていたことに気が付いたので再測定し、記事中のグラフおよび値を修正しました。
修正前の内容を記録のため残しておきます:
この状態で消費電流を測った結果がこちらです:
Jst08
ブート時に44mA、
無線なしでのADCを含む定常動作が33mA、
Wi-Fi起動時にピークで230mA、
Wi-Fiのスキャンで99mA流れます。
Wi-Fiを切っても10mAぐらい増えた44mAが定常的に流れ、
Wi-Fi接続するとピークで230mA・ビーコン時に102mA・ボトムが44mAを推移し、
切れる前に200mAぐらい瞬間的に流れます。
BLEはアドバタイズ時に110mA程度流れ、
接続するとピークで120mA・ビーコン時に100mA・ボトムは44mAを推移します(Wi-Fiより若干少ない程度)。
あと、Wi-Fi接続中にBLEアドバタイズすると120mA流れます。
今回、Wi-Fiのタイムアウトを1分、BLEのタイムアウトを2分として、BLEがタイムアウトしたらソフトリセットを掛けるようにしているので、実質的なアイドリング電流は44mA程度。バッテリーが160mAhなので4時間はもたない感じです。これは、スリープを入れることを検討する方が良さそうです。
【ここまで修正前】

| | | コメント (0)

2025/02/19

簡単な動画再生補助デバイス(ラズパイ5・Firefox用)【2025/05/14追記】

Raspberry Pi 5(ラズパイ5)の電源SW制御がうまくいったのに気をよくしてコントロールボックスとwebアプリを作ってFirefoxで各種のラグビー配信動画を楽しんでいます。ほとんどの操作は無線マウスで済むのですが、動画を少し飛ばしたりリプレイしたりしたいときに、マウスでシークバーをいじるのが少し面倒に感じます。我ながらズボラだと思いますが、ラグビーの場合フルゲームでは2時間ほどありますから、精度良くクリックするのが少々難しいのです。

さて、ほとんどの動画サイトでは短いスキップが左右の矢印キーに割り当てられています:  
サイト左矢印右矢印備考
RugbyPass TV-5秒+5秒Jで-10秒、Lで+10秒
TOP14-10秒+10秒
HANAZONO LIVE--スキップなし
J SPORTSオンデマンド-30秒+30秒
ただ、これだけのためにキーボードを持ち出すのも面倒(またズボラな…)。というわけで、ちょっとスキップするだけのHIDデバイスを作ろうと思い立ちました(作るのは全然面倒だと思わない)。

イチから作ることも考えたのですが、ちょうど手元に使わなくなったページめくり機があるので、とりあえずこれのキーアサインとラベルを差し換えるだけで様子を見ようということで、作ったのがこちらです:
01rpi_movie_ctl
左が元のもの、右が今回手直ししたものです。ちなみに、ページめくり機として現役なのはSeeed Studio XIAO nRF52840 Senseを使ったものです。

コーディングは
「戻る(KEY_MEDIA_VOLUME_DOWN)」だったキーを「右矢印(KEY_RIGHT_ARROW)」に、
「送る(KEY_MEDIA_VOLUME_UP)」だったキーを「左矢印(KEY_LEFT_ARROW)」に、
「本棚へ(KEY_MEDIA_WWW_BACK)」だったキーを「ESC(KEY_ESC)」に、
それぞれ置換しました(ESCはフルスクリーンを解除するキー)。これだけだと少し芸が無いので、もうひとつマウスで面倒に思っていたFirefox起動をマクロにしてESC長押しに割り当ててみました。具体的には
🍓>下矢印>下矢印>右矢印>下矢印>リターン
↑berry mark
という手順です。私のラズパイ5ではメニューバーが上・ブラウザが2番目・Firefoxが2番目になっているので、このような手順になっています。なお、間にdelay()を適当に入れています。

ところで、これをArduino IDEでコンパイルして転送しようとしたところ、次のエラーが出てできませんでした:
error: 'adc_gpio_init' was not declared in this scope
このエラーで検索すると、Espressifのボードライブラリが2.0.3に更新されたときに出るようになったらしく、2.0.2に戻せば動くということで、その通りの対応で動くようになりました(現時点の最新は3.1.1)。どうやら今ではadc_gpio_init()自体が要らないようなのですが、その辺りの詳細は詰めていません。
コードはGitHubのページめくり機と同じリポジトリに「rpi_movie_ctl.ino」という名前で置いておきました。

もうここまできたら専用マウスを自分で作った方がいいのでは、という気もしていますが、以前にマウスのようなデバイスを作ってみたときにフィーリング通り動かすのがとても難しかったので、いまのところはペンディング。そのうちに、アイデアが湧いたら作ってみたいモノのひとつです。

以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (2017)

【2025/05/14追記】
TOP14のフル動画閲覧に会員登録が必要になりました。手順をまとめておきましたのでご参考まで。

| | | コメント (0)

2025/02/07

ラズパイ5の電源SWと周辺AV機器のリモコン+webアプリ【2025/05/14追記】

この1つ前の記事でRaspberry Pi 5(ラズパイ5)の電源をリモート起動できることを確認しました。続けて、わが家のラグビー観戦環境を整えに掛かりました。最終的にできた制御ボックスはこんな感じになりました:
04upper
…プリンタの不調でラベル品質がイマイチです。

まずは機能の検討です。ラズパイ5とともに、少なくともテレビの電源ON/OFFと入力切換はしたい。これはArduinoのIRremoteライブラリを使って赤外線LEDから送信すればいいので、以前やったことを思い出しながらやりました。実はバージョンがすごく上がっていて少々戸惑いましたが、結果としてexampleのReceiveDemoを使ってリモコンコードを読み込み、REGZAの場合はIrSender.sendNEC()に乗せるだけでした。
また、テレビをVIERAからREGZAに買い換えたせいだと思うのですが、パナソニック製サウンドバーの入力切換がREGZAに追随してくれず、先にDIGAを使っていた場合にサウンドバーのリモコンで入力をTVに切り換えないと音が出ません(たぶん、VIERAリンクとREGZAリンクの方言に引っかかった)。よって、サウンドバーの入力切換もできるようにしたい。これも赤外線リモコンなので上記と同様にコードを読み込み、IrSender.sendPanasonic()に乗せて、テレビとサウンドバーの両方が受信できる場所に赤外線LEDを置くことにしました。
ここまでの4機能(ラズパイ5電源・テレビ電源・テレビ入力切換・サウンドバー入力切換)は、デバッグ用を兼ねて、プッシュスイッチでも動かせるようにします。

リモートでのコントロール方法は、おうちサーバーとして常時稼働しているTinkerBoardにwebアプリを乗せて、ここからSPIでArduinoにコマンドを送ることにしました。事前実験でこちら(そのものズバリの簡潔な記事)こちら(SPIの基礎)こちら(spidev : Linux用Python SPIライブラリ)などを参考にして動作確認したあと、
a.一方通行でいいことからMISO(Master In Slave Out)が要らないか
b.1対1で1バイト送れればいいことからSS-/CSが要らないか(マスタのSSはNC、スレーブの/CSは常時L)
の2点を確認したところどちらも大丈夫だったことから、TinkerBoardとArduinoのSPI接続はMOSI・CLK・GNDと3.3V電源の計4本で済み(なんとGPIO端子も並んでいます)、するとUSB2.0ケーブルを流用できるというアイデアが出ました(高々9600bpsなのでMOSIとCLKのクロストークも問題無いと考えた)。試しにジャンクのUSBレセプタクルでTinkerBoard側・Arduino側それぞれのアダプタを作ってUSB A-MicroBの1.5m充電・転送ケーブルで繋いだところ、無事に通信できました。(ところが下記の通り、おそらくb.で副作用が出た。)

ここまでの検討をもとに、プッシュスイッチとSPI通信によって4機能を動かすスケッチを書いたのですが、ひとつ問題が発生しました。それはラズパイ5の電源で【ON-delay(500)-OFF】としていたところ、スイッチでは0.5秒待ちになるのに、SPI通信だとdelay()が消えてしまったのです(millis()で確認すると0〜1msecのパルスになっていたが、オシロでは確認していない)。実際ラズパイ5に繋いだところ、スイッチは確実に効くにも拘わらず、SPIでは不発多発で不安定。色々検索したところ割り込み関係のようだったのでdelayMicroseconds()やdetachInterrupt()などを試してみたのですが効きませんでした。おそらく上記b.でSS-/CSを省いたため、SPIデータが入ったあとタイムアウトするまで割り込みが解除されないのだろうと考えていますが、このままでは肝心のラズパイ5の電源制御ができません。
そこで、ラズパイ5については【ON-delay()-OFF】とするのでなく、【コマンドが入るごとにトグルする】ことを考えました。スイッチの場合はダブルクリック、SPIの場合はマスタ側のPythonスクリプトにtime.sleep()を入れて2回コマンドを入れることで、ONとOFFを切り換えるわけです。これで、必要な動作になりました。

あと、制御ボックスに付けられるスイッチは数個までですが、実際に使うシーンを考えると、音量調整などをリモートでできると便利です。そこで、スイッチとSPIで共通のコマンド以外のデータがSPIから来た場合にはテレビのリモコンコードだと見なして赤外線LEDから送信することにしました。これにより、新たな機能を付け加えたい場合には制御ボックスに無関係にマスタ側のアプリ(今回はwebアプリのスクリプト)を変更するだけで済むようにできました。

最終的な回路図は次のようになりました:
05sch

内部の基板は2段重ねです。次の写真左上がラズパイ5と赤外線LEDへのコネクタとスイッチおよびインジケータLEDの基板、左下がATmega328PとSPIインターフェース(に使っているmicroBレセプタクル)周りの基板です。写真の右側がwebアプリのキャプチャで、基本の4機能に加えて、音量調整やテレビのYouTubeアプリのコントロールができるようにしています。
06inside

BOMは次の通りで、合計1051円でした。なお、電線・ハンダ・ピン・ラベル等の副材はカウントしていません:
itemdetailpricepcssubtotal
MPUATmega328P w/bootloader4401440
microUSBAE-USBmB-PNL2501250
Tr2SC1815L-GR5210
IR LEDOSI5FU3A11C20120
RED LEDOSR5JA3Z74A5.515.5
Green LEDOSG8HA3Z74A616
PH postS2B-PH-K-S10220
PH housingPHR-25210
Push SWTVBP06-B043CW-B20120
Push SWDTS-63-F-N-V15460
C0.1uF10110
C1.0uF25125
C47uF10220
R47111
R10k144
R100k122
case内寸約60x40x30mm1101/427.5
D基板AE-DB1403120

Arduinoのスケッチと、マスタ側でマニュアル操作するためのPythonスクリプトは Githubにリポジトリを作って上げておきました(上記webアプリはサーバー環境に依存しますのでアップしません)。
世界屈指のハイレベルリーグであるフランスTOP14ではフル尺の試合動画が無償公開されていてStade Toulousain(トゥールーズ)の齋藤直人選手やUnion Bordeaux-Bègles(ボルドー)のテビタ・タタフ選手らが頑張っている姿が観られますし、ワールドラグビーの動画サイトRugbyPass TVは無料登録で多くのコンテンツが観られます。このRugbyPass TVでは、2025秋の女子ワールドカップや、セブンズシリーズがフル尺で観られ、サクラフィフティーン&サクラセブンズの勇姿が観られると思います(国内で放送・配信されない試合に限る;権利関係ですね)。今回作った仕組みで楽に観られるようになったので、これからも楽しく応援していきます。

以上、何かの参考になれば幸いです。

パドラッパ from MacBook Air (2017)

【2025/02/11追記】
1. 実働でラズパイ5電源制御のトグル動作が十分安定していることが確かめられたので、delay()の効くloop()内で2回電源制御コマンドを送ってトグルON-OFFするようにしました(RP5ctrl.ino)。これで、ラズパイ5の電源だけダブルクリックする必要が無くなりました(メモ貼りも不要になった)。
2. linuxコマンドラインツール(rp5etc_cli.py)内のウェイトを入れる場所を間違えていたので直しました。
以上2点を加えたソースはGithubに上げておきました。
3. ケースの蓋を開けるついでにラベルを作り直しました。
07upper2
…少しはマシになったかな。

【2025/05/14追記】
TOP14のフル動画閲覧に会員登録が必要になりました。手順をまとめておきましたのでご参考まで。

| | | コメント (0)

ラズパイ5の電源SWをリモート操作する方法【2025/05/14追記】

web上の動画コンテンツ、例えばRugbyPass TVTOP14MBS HANAZONO LIVEJSPORTS RUGBY(要はラグビー)を大画面で観たいとき、これまではWindowsノートPCをテレビの横に持っていってHDMIケーブルを繋いで映していました。はっきり言って面倒だったのですが、ふとASUS TinkerBoard 2Sが使えるかもと思って試したところ、ギリギリ再生できるもののメモリが2GBでは不足するようで安定に動くとまでは言えない感じでした。基本的にラズパイよりもTinkerBoardの方が好きなのですがハイパフォーマンスモデルが出ていないので、最新のRaspberry Pi 5(以下ラズパイ5)を買いました(メモリはスイッチサイエンスさんの検証記事を参考にして4GB)。かなり久しぶりのラズパイで、Bluetoothキーボードのセットアップなどが簡単になっていて感心し、プリインストールのFireFoxで各サイトのコンテンツもスムーズに再生でき、導入して良かったです。ブックマークなどを一通り設定したあとテレビの裏に常駐させ、普段の操作は330円の無線マウスだけで済むようになりました。

ところが今度は、ラズパイ5の電源を入れに行くためだけにテレビの裏に回るのが面倒になってきました。我ながらズボラだと思いつつ、ほかのAV機器はリモコンで動くのですから当然と言えば当然です。
そこでラズパイ5をリモート起動できないか検討してみました。

ラズパイは5から基板上に電源スイッチが付いています。普通の小さなタクトスイッチなので、おそらく一方がプルアップされて電源コントローラか何かの割り込み入力に繋がっているのだと思います(回路図が公開されていないため推測)。そうであれば、次の図のように電源スイッチと並列にスイッチング素子を入れてコントロールできるだろう、と考えました。
01concept

しかし安くないラズパイ5本体の素子に直接はんだ付けするのは危なっかしいと思っていたところ、実は外部スイッチ接続用のジャンパ端子「J2」があると公式にアナウンスされていると知りました。それで現物確認したところ、基板端から見て左側が電源スイッチと内部配線で直結されており(ここでは「SWin」とします)、右側がGND電位でサーマルランドにしてくれていると分かりました。
02j2terminal

公式の説明では「ノーマリオープンのスイッチを付けたらいいよ」とだけ書かれていますが、綺麗な2.54mmピッチのジャンパ端子があるのなら、変な電圧を掛けないように気をつけつつ、電子制御できそうです。

さっそく手持ちの部品を使って試してみました。マイコンはATmega328PのArduino、スイッチング素子は汎用Trの2SC1815です(フォトMOSリレーを使おうかと思ったが手持ち無し)。
03block

まず単純にプッシュスイッチを押したらGPOがHigh出力でSWinがLow-Zになり(この状態をONと呼びます)、離したらLow出力でHi-Zになる、というスケッチを書いたところ、ラズパイ5自体に付いているスイッチと同じ挙動になりました。続いてプッシュスイッチを押すと一定時間だけONになるようにしたところ、大体200msec以上あれば安定して動くようでした。(ちなみに、スリープ状態で数秒ONにすると起動せずスリープに戻るので、ON-OFF動作が必要です。また、稼働状態で数秒ONにするといきなり落ちて心臓に悪いです。)

これで当初のコンセプト通りに動くことが確認できました。あとは、このプッシュスイッチを赤外線リモコン(マイコンはArduinoなど)、Bluetooth(同Seeed Studio XIAO nRF52840など)、Wi-Fi(同ESP32-WROOM-32Eなど)、そのほか何らかの通信手段にすればいいわけです。
私の場合は常時稼働している宅内サーバー(TinkerBoard)にwebアプリを乗せてテレビなど周辺機器のコントロールを併せて行おうと思い、マイコンにATmega328Pを使って有線のSPI接続にしました。この話は別稿に分けました

以上、何かの参考になれば幸いです。実行される場合は自己責任でお願いします。

パドラッパ from MacBook Air (2017)

ps.
外部接続に剣山を立てるのがラズパイ流だと思いきや、J2端子がTHだったことに驚きました。剣山や裸のジャンパはショートさせそうで、ソケット接続のArduinoタイプが好きなのですが。

【2025/05/14追記】
TOP14のフル動画閲覧に会員登録が必要になりました。手順をまとめておきましたのでご参考まで。

| | | コメント (0)

2024/10/04

TinkerBoard3が出たらしい【2025/02/07追記】

TinkerBoard2が2021年に出てから3年半、もうASUSからSBC(シングルボードコンピュータ)は出ないのかなぁと思っていたところ、昨日2024/10/03に新機種の発表がありました:
ASUS IoT、多様な垂直分野に対応するArmベースのTinker Board 3/3SシングルボードコンピューターとTinker System 3Nを発表 | ASUS JAPAN株式会社のプレスリリース
Tinker Board 3S商品ページ

この3/3SはRaspberry Pi(ラズパイ)と同じサイズのSBCで、MPUが2のRockchip RK3399からRK3566に変更されています(6コアから4コアになりピーク性能を抑える方向で、たぶん発熱も減っている)。また、同じRockchipのNPU(ニューラルネットプロセッサ)が搭載されていて、端末自体(エッジ)でAI処理しやすくなっているようです。S付きの方は従来と同じくeMMCストレージ付きで、2Sで選べた32GBは無くて16GBのみになりました。microSDスロットは、初代は触ったらバネで飛び出す危険仕様だったところ、2/2Sと同じく摘まんで抜くタイプです。あと、写真を見る感じでは2でラズパイ3までと大幅に変わっていたI/O配置が、初代&ラズパイ3までに近い配置に戻っています。但し、電源はUSB microBではなくてφ5.5/2.5mmの12-19Vです。

ユーザー認証に使えそうなエッジAI対応、性能バランス重視などはプロ向けの進化かな、という印象です。逆に言うとご家庭用のSBCとしては3の出番は無くて、初代と2の使い分けになると思います。ちなみに私は初代をおうちサーバー用、2SをLinux作業用にしています。このおうちサーバーは連続稼働6年で、microSDは何度か壊れましたが、本体は元気で、さすがはASUSの品質だと思っています(ラズパイは何度か痛い目に遭っているけれど、ASUSはマザボやタブレット等でも外したことが無い)。

ちなみに、いつも買っているPhysical Computing Labさんでは、ラズパイサイズでは無い方の3Nを早速取り扱っていますが、いまのところ3/3Sはありませんでした:
Tinker Board | Physical Computing Lab

以上、自分で使う気が無いにもかかわらず、着実な進化が嬉しくてまとめた次第。何かの参考になれば幸いです。

パドラッパ from MacBook Air (2017)

【2025/02/07追記】
Physical Computing Labさんによると、初代TinkerBoard系のR2.0がディスコンになって、上記TinkerBoard 3Sが後継機種になるようです(道理で性能アップしていないわけだ)。同店では現在取り寄せ中とのこと。電源(とケース)が変わるので要注意。

| | | コメント (0)

より以前の記事一覧