![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2022-05-27T11:43:39+09:00","","") #contents *本ページについて [#l9526a59] 本ページはIEEE802.15.4/ZigBee対応パケットアナライザ「SK Sniffer」の製品サポートページです。 製品については http://www.skyley.com/products/sksniffer.html をご覧ください。 *FAQ [#l9526a59] ** Windows 7で動きますか？ [#ld42fe4c] SK SnifferはWindows 7でも動作します（Vistaは動作保証していません）。 Windows 7用のインストーラーをダウンロードページにご用意いたしましたので合わせてご利用ください。64bit版も対応しています。 ** XBee以外のモジュールでもデータは見れますか？ [#m776a6e5] データ取得対象のデバイスは、XBee以外でもIEEE 802.15.4 準拠のICで通信していれば、SK Snifferでキャプチャは可能です。 ** データが何も表示されない場合[#m776a6e5] 「Open」メニューからCOMポートに接続してStartボタンを押したけれど、何も表示されない場合は、観測対象のデバイスのチャンネルとスニファのチャンネルが合ってるか確認してください。スニファからでは、対象デバイスがどのチャンネルで動作しているか調査することはできません。 それでもデータが表示されない場合は、以下の手順でキャプチャデバイスの動作確認を行ってください。 1. ハイパーターミナルやTera Termで、キャプチャデバイスのCOMポートに以下の設定で接続します。 115,200bps 8bit, non parity stop bit 1 フロー制御なし 2. 数字の8キーを押してください。以下のメニューがターミナルソフトに現れるはずです。 8 (Set RF channel) Select Channel: [UP] decrease channel [DOWN]increase channel [Enter]Set [ESC] Cancel [A]2405MHz [B]2440MHz [C]2480MHz [S]Manual RF Channel : 2405MHz (Ch:11) もし上記メニューも含めて、文字が何も現れないようでしたら、キャプチャデバイスの初期不良の可能性がありますので、サポート宛にメールでご連絡ください。初期不良の場合は無償で交換させて頂きます。 *追加ドキュメント[#l9526a59] SK SnifferでのZigBee通信の読み取り方のコツを若干まとめましたので、以下よりダウンロードしてご覧ください。 -[[SKSniffer Tips:http://www.skyley.com/sksniffer_tips.pdf]] *SK Snifferユーザのためのちょっとした解説 [#g980a970] **IEEE802.15.4におけるデータ送信 [#a786fde0] IEEE 802.15.4では、データフレームの送信時に相手からの送達確認（ACK）を要求することができます。送達確認要求のあるデータフレームを受信した場合、受信側は必ずACKフレームを応答します。ACKを利用することでデータが相手まで届いたということを確実に知ることができます。ここでデータフレームとACKフレームは同じシーケンス番号を持っており、受信したACKがどの送信データに対応するものなのか判断できるようになっています。 ここでもし相手からのACK応答がない場合、IEEE 802.15.4では標準で最大３回まで送信側が再送を行います。再送は同じ内容のフレームが、初回のデータ送信と再送合わせて４つ連続している状態としてSK Sniffer上で観測できます。 &ref(図４.png,nolink,image5); ３回再送してもACKが無い場合、通信エラーという形で上位層に通知されます。送信先のデバイスが物理的に壊れている場合は常に通信エラーになるので原因も特定しやすいですが、むしろ開発の現場では不規則なエラーが現れる場合が多く、原因の特定が往々にして困難です。 パケットアナライザでこのような再送が頻繁に観測される場合、いくつかの原因が考えられます。 a)その周波数に干渉が存在する~ b)通信相手との距離が物理的に離れすぎている~ c)データの送信頻度が高すぎて受信処理が追いついていない~ などです。 **ZigBeeにおけるブロードキャストストーム [#bd4537f3] 一方でZigBeeにはブロードキャストストームという固有のトラブル要因があります。ブロードキャストストームとは、同報通信を用いた場合にパケットが際限なく転送されて無線帯域を逼迫させてしまう現象で、主にアプリケーション上の設計ミスによって発生します。ブロードキャストストームはパケットアナライザ上では図ように、「To」「Dst」欄が「0xFFFF」や「0xFFFD」のフレームで埋め尽くされた状態として観測されます。 &ref(図６.png,nolink,image5); ブロードキャストストームが発生している間、IEEE 802.15.4におけるACK要求のデータ通信は通信エラーになりやすく、開発者は通信が安定していないという印象を持つことになります。しかしブロードキャストの転送は一般にZigBeeスタックが自動的に行うため、開発者は転送が発生していること自体を把握できません。相手先デバイスの状態を調べても問題がなく、別のPANや無線LANの干渉源が存在するわけでもないため、結果的に原因不明の不安定現象と結論付けられてしまいます。 ブロードキャストストームはほとんどの場合、アプリケーションの設計ミスによって発生するため、アプリケーションの修正が必要になりますが、パケットアナライザで通信を観測しないと発見できないという意味で、きわめて解決しずらい通信トラブルの一つです。
