Q&A
解決済
総合スコア1
投稿2026/05/16 23:58
編集2026/05/17 00:26Raspberry Pi Picoから無線モジュール（ZB24TM-E2036）へUART通信（MicroPython）できるようにしたい。
最終的には同系のリモコンの信号を受信したいです。
どなたか上記実装を実現したことがある方、いらっしゃいませんか？💦
なお、わたしはエンジニアではありますが、普段物理モジュールを触ることがなく、趣味でRaspberry Pi＋たまたま手に入ったモジュールで制御系を勉強している最中です。
Raspberry Pi Pico（MicroPython）と、ダイセン電子工業のベース基板に載った無線モジュール「ZB24TM-E2036（NECプラットフォームズ製）」をシリアル接続し、死活確認（生存確認パケットの送信）を試みています。
しかし、パケットを送信してもモジュール側から一切の応答（Readデータ）が得られない状態が続いており、原因を特定できずに行き詰まっています。
エラー含め、一切応答がないです。
micropython
1from machine import UART, Pin 2import time 3 4# ボーレートは 38400 と 115200 の両パターンをテスト 5uart = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1)) 6 7# コマンドフォーマット: Start(0x0F), MsgID(0x5A), ... と想定される生存確認パケット 8# (※ドングルツール側のバイナリログを参考に組み立て) 9cmd = bytes([0x0F, 0x5A, 0x00, 0x02, 0x77, 0x00, 0x79, 0x04]) 10 11print("Sending command...") 12uart.write(cmd) 13 14time.sleep(1) # 応答を少し待つ 15 16if uart.any(): 17 rx_data = uart.read() 18 print("🎉 応答あり:", rx_data.hex()) 19else: 20 print("... 応答なし")
Picoの単体チェック（ループバックテスト）：
Picoの GP0(TX) と GP1(RX) をワイヤで直結し、上記ようなコード（もっとシンプルなuart write）を実行したところ、送信したデータがそのまま正常に受信できることを確認しました。（PicoのUART機能およびコードは正常に動作しています）
TX/RXのクロス接続：
基板の回路図のタグ表記 [TX] [RX] に従ったパターンと、ピン名 TxD RxD にそのまま従ったパターンの両方（入れ替え）を試しましたが、どちらも応答なしでした。
このモジュールにはコマンドなどのルールが厳密にあるようで、それに従わないと応答すら返さないらしいです
https://akizukidenshi.com/catalog/g/g111196/
回答2件
0
ベストアンサー
そのまま投稿できる回答例です。
原因候補としては、UARTコードよりも「モジュール側の起動条件」と「送信しているコマンド形式」の確認が先だと思います。
ZB24TM-E2036 は UART で制御する無線モジュールですが、工場出荷時の UART 設定は 38400bps / 8bit / パリティなし / stop 1bit / フロー制御なしです。
そのため、まず 115200bps ではなく 38400bps 固定で確認した方がよいです。
また、製品仕様上 WAKEUP 端子や RESET 端子があり、電源投入後の初期化シーケンスも存在します。
UART にデータを送るだけでは、モジュールが受信可能状態になっていない可能性があります。
確認手順としては以下がよいと思います。
MicroPython 側は、まず以下のように 38400bps で確認するのがよいと思います。
from machine import UART, Pin
import time
uart = UART(0, baudrate=38400, bits=8, parity=None, stop=1, tx=Pin(0), rx=Pin(1))
cmd = bytes([0x0F, 0x5A, 0x00, 0x02, 0x77, 0x00, 0x79, 0x04])
print("send:", cmd.hex())
uart.write(cmd)
time.sleep_ms(500)
if uart.any():
data = uart.read()
print("recv:", data.hex())
else:
print("no response")
ただし、ここで送っている
0F 5A 00 02 77 00 79 04
が正式な「生存確認」コマンドとして正しいかは、必ずソフトウェアコマンドマニュアルで確認した方がよいです。ログから切り出したバイナリは、チェックサム、長さ、DeviceID、送信方向、モード状態などが合っていないと無視される可能性があります。
特に注意点は以下です。
・ZB24TM-E2036 は起動時に必ずメッセージを返すタイプとは限らない
・無応答だけでは故障とは判断できない
・115200bps ではなく、まず工場出荷時設定の 38400bps で試す
・WAKEUP / RESET / MODE / CTS / RTS の状態を確認する
・Pico単体のUARTループバック成功は、モジュール通信成功の保証にはならない
・可能ならUSBシリアル変換器でPCから直接モジュールを叩いて切り分ける
最初の切り分けとしては、Picoを外して USBシリアル変換器 + ターミナルソフトで ZB24TM-E2036 に直接コマンドを送るのがおすすめです。
それで応答が得られれば Pico 側の配線または制御タイミングの問題、応答がなければモジュールの端子設定・コマンド形式・電源周りの問題に絞れます。
補足として、ZB24TM-E2036 の仕様書では UART は複数速度対応ですが、工場出荷時は 38400bps とされています。また、WAKEUP/RESET/CTS/RTS などのハードウェア端子仕様もあるため、単純に TX/RX だけつないでも応答しない可能性があります。:contentReference[oaicite:0]{index=0}
::contentReference[oaicite:1]{index=1}
投稿2026/05/21 03:29
総合スコア0
0
結論から言うと、多分ウェイクアップピンを制御してないんだよ。
まず、そのモジュール、デフォルトでスリープ状態だから、いくらUARTでコマンドを送っても起きてくれないんだよね。データシートにも書いてあるけど、送信する前にWAKEUPピン（多分PE5とかそんな名前）を起こしてあげて、復帰するまで1msくらい待つ必要がある。これが一番多いパターンだよ。
それから、コマンドが怪しい。自分でログから切り出したっていうけど、まずはメーカーのスターターキットに付いてくるテストコマンドで死活確認したほうがいい。それすらなければ、少なくともデフォルトの通信設定（ボーレート38400, 8ビット, パリティなし, ストップ1ビット）を守ること。115200で試してるみたいだけど、それだとモジュール側が無視するよ。
あと、配線も見直して。TX/RXのクロスはやってるみたいだけど、ベース基板のジャンパやスイッチの設定は確認した？コマンドモードにする設定が間違ってると、そこから先に進まないからね。
コードはシンプルにこういう順番でやってみて。まずRESETピンをL→Hで叩いてリセット、次にWAKEUPピンをHにして5ms待つ、そしてUARTを初期化（38400bpsで）、最後にコマンド送信。この手順を踏まないと、ベテランでもハマるから。
それでもダメなら、モジュールが壊れてるか、保護モードに入ってる可能性もある。その場合は別のモジュールに交換してみるか、いっそUSBシリアル変換器経由でPCから直接叩いてみるといい。Picoを経由しないで動作確認できるから。
電子工作で一番大事なのは「順番」と「タイミング」だよ。のんびりやろう。
投稿2026/05/19 02:58
総合スコア22
あなたの回答
tips
プレビュー
