【波形観察】サーボテスタとサーボモータ間の通信をロジアナ・オシロで覗き見してみた
kimi以前の記事：「サーボテスターの信号」で、サーボテスタ単体の出力信号をオシロスコープやロジックアナライザ（ロジアナ）で観察しました。ただ、その時はサーボ本体を接続していなかったため、MCU（マイコン）が一方的に生成しているコマンド信号を見ただけに過ぎません。
そこで今回は、実際にサーボモータを接続した状態で通信波形を観察し、サーボ側からどのような応答（レスポンス）が返ってきているのかを検証してみました！
測定環境・接続構成
まずは今回の実験構成です。
サーボテスタとサーボモータの間の通信ライン（信号線）にプローブを割り込ませ、通信を「覗き見（スニッフィング）」する形でロジアナ／オシロ（Degilent社のAnalog Discovery 2）に接続しました。
- 送信側（コントローラ）：サーボテスタV2（デアゴスティーニ製）
- 受信側（デバイス）：シリアルサーボモータ（初代Robi付属サーボ）
- 測定機器：Degilent社のAnalog Discovery 2
通信波形の観察結果
サーボテスタから指示を送り、実際に信号ラインをキャプチャした結果の全体像がこちらの画像です。4つのステップに分けて信号のデコード結果を拾ってみますが、ここではまず、信号の状態について注目してみます。
オシロスコープのアナログ波形（上段の黄色波形）をよく見ると、テスタ送信時とサーボ返信時で電圧レベルに面白い違いが現れています。わかりやすいように最初のステップの波形を拡大してみましょう。
- テスタ送信時（前半 8byte）：Highレベルは約 3.0V
- サーボ返信時（後半 9byte）：Highレベルが約 3.3V へと約0.3V上昇（Lowレベルもわずかに上昇）
なぜ電圧が変わるのか？これは1本の信号線を双方向で共有する「半二重通信」ならではの現象ではないかと推測します。
- 駆動側MCUの電源電圧（VDD）の差
- 前半はサーボテスタ側のMCUが信号線をドライブしています（テスタ側の内部電源は約3.0Vなのでしょう）。
- コマンド受信後の約140〜150μsの無通信時間を経て、後半はサーボ内部のMCUに送信権が移り、サーボ側が信号線をドライブしています（サーボ側のレギュレータ電圧は約3.3Vと思われる）。
- ドライブする素子（MCU）が切り替わったことで、High出力電圧の差がそのまま波形に現れたと思われます。
- GNDレベルの微小な浮き
- プルアップ抵抗とサーボ側出力抵抗による分圧（Lowの浮き）の影響？
- サーボ返信時、テスタ（MCU）側は受信待機のために信号ピンを入力＋プルアップ（Pull-up）状態にしています。
- 一方でサーボ側が「Low」を出力する際、サーボ内部の出力トランジスタ（FET）がONになって信号線をGNDへ引き込みます。
- このとき、「MCU側のプルアップ抵抗」と「サーボ側の出力ON抵抗（およびケーブル抵抗）」の間で分圧が生じます。
- その結果、完全に0Vまで落ち切らず、0.1〜0.2V程度わずかに持ち上がったLowレベルとして観測されていると考えられます。
- ロジック閾値への影響と回路設計のポイント
- 一般的な3.3V系CMOSマイコンのLow入力判定閾値は概ね 0.8V〜1.0V以下 です。今回の0.2V前後の浮きであれば十分なノイズマージンがあり、デジタル通信上のエラーになる心配はないでしょう。
- ただし、通信の立ち上がりを速くしようと外付けプルアップ抵抗を小さく（強く）しすぎると（例：数百Ω〜1kΩ程度）、この分圧によるLow電圧がさらに上昇し、閾値に近づいて誤動作の原因になり得ます。自作基板でプルアップ抵抗を選定する際は、波形のなまり（時定数）とLowレベルの浮きのバランスを見て適切な値（一般的には 4.7kΩ〜10kΩ程度）を選定するのがポイントになりそうです。
ロジックアナライザのデジタル波形（0と1の判定）だけを見ていると気づきませんが、オシロスコープでアナログ波形を見ることで、「今どちらがバスを支配して送信しているのか」が電気的にもはっきりと確認できるのが面白いところです。ここでの仮説を元に新型自作基板を設計していきましょう。
取得できた信号（デコード結果）
一連の通信シーケンスを整理すると、大きく分けて以下の4つのステップ（フェーズ）でやり取りが行われていることが確認できました。通信シーケンスの全体像（4つのフェーズ）
[テスタ (MCU)] [サーボモータ]
| |
| --- ① コマンド送信 (8 bytes) -------------------> |
| (約140〜150μs 後) |
| <--- サーボ応答 (9 bytes) ------------------------ |
| |
| --- ② コマンド送信 (8 bytes) -------------------> |
| <--- サーボ応答 (10 bytes) ----------------------- |
| |
| --- ③ 設定/制御送信 (9 bytes) ------------------> | (返信なし)
| |
| (約100ms 後) |
| --- ④ 指示送信 (12 bytes) ----------------------> | (返信なし)
v v
フェーズ①：初期問い合わせ ＆ サーボ応答
前述の画像を参考に。
テスタ起動時（または接続直後）にテスタ側からサーボへ最初のコマンドを送信し、サーボが即座に応答を返しています。この段階で、接続されているサーボのIDは確認できます（ヘッダー信号（０ｘFD、０ｘDF）の次のデータ０ｘ０C、つまり、10進で12がサーボID）。
- MCU送信（テスタ → サーボ / 8 bytes）
0xFA, 0xAF, 0xFF, 0x0F, 0x04, 0x01, 0x00, 0xF5
- サーボ応答（サーボ → テスタ / 9 bytes） ※送信完了から約140〜150µs後
0xFD, 0xDF, 0x0C, 0x00, 0x04, 0x01, 0x01, 0x0C, 0x04
フェーズ②：パラメータ読み出し ＆ サーボ応答
続いてテスタ側から別の問い合わせパケットを送信し、サーボ側からやや長めのデータが返信されています。フェース①でMCU側はサーボIDを知り得る状態ですが、依然として全サーボ対象（0xFF）に送信しています。
- MCU送信（テスタ → サーボ / 8 bytes）
0xFA, 0xAF, 0xFF, 0x0F, 0x2A, 0x02, 0x00, 0xD8
- サーボ応答（サーボ → テスタ / 10 bytes）
0xFD, 0xDF, 0x0C, 0x00, 0x2A, 0x02, 0x01, 0xFC, 0xFF, 0x26
フェーズ③：設定・有効化コマンド（一方通行）？
①・②でサーボIDの取得や状態を確認した後、MCUから取得したサーボIDへ向けて設定またはトルクON等の制御コマンドと思われる信号が送られます。このパケットに対するサーボからの返信はありません。
- MCU送信（テスタ → サーボ / 9 bytes）
0xFA, 0xAF, 0x0C, 0x00, 0x24, 0x01, 0x01, 0x01, 0x29
- サーボ応答：なし
フェーズ④：目標値（角度・速度等）指示コマンド？（一方通行）
一連の初期通信が完了してから約100ms遅れて、MCUから実動作のための目標パラメータ（目標位置・時間・速度など）と推測される12バイトの長めのパケットが送信されています。こちらも返信はありません。
- MCU送信（テスタ → サーボ / 12 bytes） ※フェーズ③から約100ms後
0xFA, 0xAF, 0x0C, 0x00, 0x1E, 0x04, 0x01, 0x3E, 0xFE, 0x32, 0x00, 0xE5
- サーボ応答：なし
観察から見えてきた通信仕様の特徴
- パケットヘッダの構造
- テスタ（送信元）のパケット先頭はすべて
0xFA, 0xAFで統一されている。 - サーボ側の返信パケット先頭は
0xFD, 0xDFであり、送信方向が明確に識別できる。
- テスタ（送信元）のパケット先頭はすべて
- レスポンスの有無（読み込み vs 書き込み）
- ステータスやパラメータの「読み出し要求（フェーズ①②）」に対してはサーボが応答を返す。テスタは最初のフェーズで返答がないと、フェーズ②には進まない。
- 「設定や位置指令の書き込み（フェーズ③④）」は一方通行のコマンド送信となっており、通信トラフィックを抑える設計になっている。
- ターンアラウンドタイム
- フェーズ①やフェーズ②の送信完了からサーボ返信開始までの待機時間は約140〜150µs。1本線での半二重通信において、信号線の入出力切り替えとサーボ側マイコンの処理に十分なマージンが確保されている。
まとめ・次回予告
サーボを未接続の状態では「命令が出ていること」しか分かりませんでしたが、実際にサーボを繋ぐことで「コマンドに対するサーボの応答パケット」や「双方向通信のリアルなタイミング」をしっかり確認することができました。
通信仕様書（データシート）上のプロトコルが、実際のハードウェア上でどう動いているかを波形で追うのはとても興味深いですね。次回は、「返送パケットの各バイトの詳細解析 / 自作マイコンからの制御」について掘り下げていきたいと思います。
