y.hara
2024年5月23日 13時42分
お世話になっております。
現在Armadillo-X1のBLEをSPPのProfileで使用しています。
アプリケーション開発で必要なデータ長がBluetooth Ver4のLL PDU長（Bluetooth Core Spec Vol.6 PartB 2.4.1章/2.4.2章で定義）
である26Byteに収まらなくなったのですが、リモート側のBLEデバイスに26byteを超えるデータが送信されていないようです。
期待はSPPデータがX1内のBluetoothのL2CAP層で無線上のLL PDUサイズに複数に分割されるが、すべてが送達されるでした。
確認使用したハードウェアはArmadillo-X1の評価ボード、BTモジュールはSparkLAN社製です。
アプリケーションは搭載せずTeratermを接続し、gatttoolでリモート側BLEとconnectしてchar-write-cmd [handle値]で
書き込み評価しています。
Armadillo-X1の代わりにスマホを使い同じSPPデータを送信した場合には26byteを超えるデータもリモート側で受信できるので、
Armadiilo-X1で26byteを超えた分は送信されていないと判断しました。
この動作が仕様通りかのご意見を頂けないでしょうか。
Debianのバージョンは10.13
uname -aの出力は「Linux armadillo 4.9.133-at33 #2 SMP PREEMPT Wed Apr 24 09:58:54 JST 2024 armv7l GNU/Linux」。
X1の起動時にBluetooth: L2CAP socket layer initializedは表示されています。
お手数をおかけしますがご確認をお願いいたします。
コメント
y.hara
2024年5月27日 9時33分
アットマークテクノ 大塩様
ご確認ありがとうございます。
>
> 可能であればで良いのですが、対向機としているリモート側BLEとコマンドの詳細内容をお聞きしてもよろしいでしょうか。
>
リモート側BLEはMOKO社というメーカーのMK02Eという製品となります（アンテナ周りを一部変更開発してもらっています）。
https://www.mokosmart.com/seeking-bluetooth-module-manufacturer-qualifi…
コマンドの内容はファイルに添付しました(SparkLAN_NewMOKO_test.txt)。
| ファイル | ファイルの説明 |
|---|---|
| SparkLAN_NewMOKO_test.txt | Teratermの画面です。リモートBLEのBDアドレスはD1:5A:3C:9E:7D:CDになります。 |
at_syunya.ohshio
2024年5月28日 16時50分
大塩です。
情報ありがとうございます。
> この動作が仕様通りかのご意見を頂けないでしょうか。
gatttool の仕様のように見えます。
gatttool のソースコードを確認してみたところ、PDU長 を超えるデータをwrite しようとすると、false で終了するように見えます。
https://github.com/bluez/bluez/blob/5.66/src/shared/att.c#L340
そのため、リモート側のBLEデバイスに26byteを超えるデータが送信されていないと思われます。
以上です。
y.hara
2024年5月29日 17時07分
アットマークテクノ 大塩様
お世話になっております。
> gatttool の仕様のように見えます。
>
> gatttool のソースコードを確認してみたところ、PDU長 を超えるデータをwrite しようとすると、false で終了するように見えます。
> https://github.com/bluez/bluez/blob/5.66/src/shared/att.c#L340
> そのため、リモート側のBLEデバイスに26byteを超えるデータが送信されていないと思われます。
>
> 以上です。
Bluez内のソースファイルの解析をしていただきお手数をおかけしました。
BLEの規格のPDU長を超えた場合のBluezの振る舞いについて理解しました。
PDU長を超えないようにアプリケーションの設計を見直しする方向で進めます。
ありがとうございました。
at_ohsawa
2024年5月29日 17時26分
> Bluez内のソースファイルの解析をしていただきお手数をおかけしました。
> BLEの規格のPDU長を超えた場合のBluezの振る舞いについて理解しました。
> PDU長を超えないようにアプリケーションの設計を見直しする方向で進めます。
横から失礼します。
bluezプロジェクトとしては、既にgatttoolは運用環境としての利用は非推奨で
あくまでテスト用のデモ実装的な立ち位置になっています。
(bluezを廃止予定の実装を除いてコンパイルするオプションでビルドすると
gatttoolはビルドされません。)
androidで使われている実装にしても、bluezをライブラリとして使って
pdu長以上の場合分割して送信するようなアプリケーションを書いているはずで
gatttoolを使わずにライブラリとしてのbluezを使ったプログラムを書くという
選択肢もあります。
リファレンスとなるのはbluezのtoolsに入ってる実装が参考になります。
https://github.com/bluez/bluez/tree/master/tools
あるいはpython向けであれば、いくつかモジュールが公開されています。
たしかにgatttoolは簡単ではあるのですが、bluezプロジェクト的にもアップデート
していかないツールと言っているので、将来的なアップデートに備え、一応
プログラミングするのが正道ではあるというおすすめをしてみました。
at_syunya.ohshio
2024年5月24日 15時39分
大塩です。
> アプリケーションは搭載せずTeratermを接続し、gatttoolでリモート側BLEとconnectしてchar-write-cmd [handle値]で
> 書き込み評価しています。
可能であればで良いのですが、対向機としているリモート側BLEとコマンドの詳細内容をお聞きしてもよろしいでしょうか。
以上です。