versionに文字列が出ているので、デバイスから情報を読み取っているのは確かです。;DSP:ID9000r2963;i:B;f:22500;nMsg;s:Rel_1_3_prer1784:NM;と出力されるはずですが、途中から文字化けしているので、受信データが途中から0xFFになっていると思われます。mmと2組の数字が出るはずですが、seqに当たるところの数字が空なので、polling()が受信データが無く空回りしているか、または受信データを無効と判断している可能性があります。こちらもデータが0xFFになっていると思われます。PRするときのコメントにも書きましたが、なぜか受信データが途中から/先頭から0xFFとなる現象が出ています。そのため、0xFFのデータを無効とするロジックを入れてあります。具体的には、FlickHat.jsの下記の箇所です。{先頭データである受信データ長が0xFFはあり得ないため、それをチェックしています。このif文の直前にconsole.log(size)を追加してもらえば切り分けできると思います。)また、4バイトのジェスチャー情報が0xFFもあり得ないため、それをチェックしています。true;のコメントを外してもらえれば、FlickHat.jsの154-156行目で受信データをコンソール出力しますので、これで切り分けできると思います。こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。(上述の通り現在は最大サイズ132を指定しているため)以上、ご確認お願いします。ありがとうございます。何度実行しても同じで、i2cエラーは出るときと出ないときがあります。(比較的出ることが多いです)こちらから逆にAPIの確認ですが、i2c.readWait()に指定するlengthは最大受信サイズのつもりで使用しています。最大サイズであり「そのサイズ以下で受信する場合もある」想定ですが、必ずlength分だけ受信しようとする仕様であれば、実装を変える必要があります。(上述の通り現在は最大サイズ132を指定しているため)以上、ご確認お願いします。こちら、必ずlength分だけ取得します。ドキュメントが分かりづらくてすいません。obnizはi2cで相手に対してlength分のデータを共有し、受け取って送ります。length分にならない場合はエラーとなります。相手がi2cにおけるNAKという「それはうまくいきません」という主張をするとエラーとなります。さん、そうであれば、実装を変えて再PRする必要がありますね。コードのイメージだと以下のように。以上、ご確認お願いします。