Raspberry Pi 5上のHackRFを使用したESP32+CC1101 433 MHzセットアップのデバッグをOpenClawが行う

OpenClawユーザーu/Gullexが、ESP32とRaspberry Pi 5でCC1101 433 MHzトランシーバーをデバッグした詳細な事例を投稿しました。このプロセスは、AIコーディングエージェントがハードウェアの癖に直面したときに、HackRFを診断ツールとして活用する方法を示しています。
問題
目標は、Pi 5上のOpenClawを使用して433 MHzのワイヤレススイッチを制御することでした。最初の試みは失敗しました:
- CC1101をPiのGPIOピンに直接接続 — 丸一日デバッグしても結果は得られず。
- CC1101をESP32に接続し、
CC1101-toolをフラッシュ — それでも成功せず。 - Flipper Zeroからキャプチャした信号をリプレイしても効果なし。
HackRFによるブレイクスルー
成功したアプローチ:ESP32+CC1101とHackRFを両方接続して、新しいOpenClawセッションを開始。ユーザーはエージェントに明確な指示を与えました:HackRFを使用してテスト信号を送信し、CC1101がそれをキャプチャ、その後CC1101が正常に信号を送信し返したことを確認して、CC1101を動作させること。期限は朝までにテスト可能な状態にすること。
翌朝、動作しました。AIは根本原因を特定していました:CC1101のTxピンとRxピンが入れ替わっていたのです。これが修正されると、PiはSub-GHz信号を自律的にキャプチャおよびリプレイできるようになりました。
重要な教訓
AIコーディングエージェントがハードウェアペリフェラルで失敗した場合、HackRF(またはロジックアナライザ、SDR)のようなリファレンスデバイスを追加することで、エージェントが自己修正するために必要な信号の真実を得ることができます。鍵は、タスクをクローズドループテストとして構成することでした:HackRFが送信→CC1101がキャプチャ→CC1101が送信→HackRFが確認。
📖 Read the full source: r/openclaw
👀 See Also

コーディングエージェントによるllama.cppの大規模プロンプト再処理:KVキャッシュとコンテキストスワップのデバッグ
あるユーザーが、opencode + pi.dev を使用中に llama.cpp が類似プロンプトに対して 40k 以上のトークンを再処理する問題を報告。LCP 類似度が高いにもかかわらず発生している。設定の詳細と推定原因が共有されている。

クロードコードエージェントは自動的にプロジェクトドキュメントを読みません
Claude CodeがSonnetなどのサブエージェントをディスパッチしてコードを書かせる場合、それらのエージェントはプロンプトに明示的に含まれた内容しか認識せず、特に指示がない限りCLAUDE.md、MEMORY.md、その他のプロジェクトコンテキストファイルを自動的に読み込むことはありません。

Claude Codeを使ったプレコーディングルーチン:コードを書く前に5つのMCPサーバー
ある開発者が、5つのMCPサーバー(メモリ、コードベースグラフ、Tavily検索、Context7ドキュメント)とセーフティフックを使用し、幻覚や無駄な編集を劇的に減らす60〜90秒のルーティンを公開しています。

チャット質問でクロードコードトークンを無駄遣いするのをやめよう
r/ClaudeAIの開発者が、週間トークン上限を節約するために、簡単なチャット質問はHaikuのような安価なモデルに回し、Claude Codeは複数ファイル編集などのエージェントタスクに限定した。