Android 周辺機器通信 (この場合は MOTOROLA MOTO E ジェネレーション 2) をサポートする 2 つの Android デバイス間で次の BLE 通信を行うプログラムを作成しています。接続 -> 通信 -> 切断し、それらができるかどうかを確認します安定性が良い。テストで見つかった問題についても説明します。
このプログラムでは、最初に、デバイスを周辺機器にするか中央機器にするかを選択できます。中央側では、プログラムは最初にサービス UUID のフィルターを使用して周辺機器をスキャンします。
ScanSettings.Builder ssb = new ScanSettings.Builder();
ssb.setReportDelay(0);
ssb.setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY);
ScanSettings ss = ssb.build();
ScanFilter.Builder sfb = new ScanFilter.Builder();
sfb.setServiceUuid(BLEShared.SERVICE_UUID);
LinkedList<ScanFilter> lsf = new LinkedList<ScanFilter>();
lsf.add(sfb.build());
BluetoothLeScanner leScanner = m_BluetoothAdapter.getBluetoothLeScanner();
if(leScanner != null)
{
leScanner.startScan(lsf, ss, blePeripheralScanner);
isScanning = true;
currentState = BLE_CENTRAL_STATE_SCANNING;
}
次に、周辺機器がスキャンされると、ハンドラーはメインスレッドから次を呼び出します。
stopScan();
mGatt = result.getDevice().connectGatt(BLECentral.this, false, m_BLECentralGattCallBack);
周辺機器 (別の MOTO E によって動作) が接続されると、onConnectionStageChange() で次の処理が行われます。
if(newState == BluetoothGatt.STATE_CONNECTED)
{
m_Handler.post(new Runnable(){
public void run()
{
gatt.discoverServices();
}
});
}
すべてのサービスが検出されると、プログラムは次のことを行います。
記述子を更新して通知をサブスクライブし、データを書き込み、セントラルから送信されたデータを受信するとペリフェラルに送信します。ペリフェラルは値の変更を通知します。ペリフェラルからデータ変更通知を受信すると、ペリフェラルにデータを送信します。書き込みと通知のプロセスは 11 回行われます。次に、gatt.disconnect() を呼び出して、ble 接続を切断します。
上記のプロセスは、安定性をテストするためにループされます。
通常の接続中、上記のプロセスは 1.7 ～ 2.5 秒以内に実行できます。各 write-notify プロセスの間に、約 0.1 秒かかります
テスト中に次の問題が見つかりました。
- onConnectionStageChange() device.connectGatt() の呼び出しに最大 30 秒かかります。このような長い待ち時間が発生すると、次の onConnectionStageChange() は、まれに接続に失敗する可能性があります。
- onConnectionStageChange() は device.connectGatt() の後ですぐに呼び出されますが、newState = STATE_DISCONNECTED がときどき発生します
- 各書き込みコマンドの間に 0.5 秒かかる場合があります。
- プロセスは、どの段階でも停止するか遅くなります。
Android BLE スタックの根底にあるいくつかのバグのようです。したがって、私はウォッチドッグを実装しようとします。プロセスのいずれかが予想どおりに速く進まない場合、ウォッチドッグがアクティブになり、中央デバイスの Bluetooth をオフにしてから再びオンに切り替え、Bluetooth からの応答の待機を積極的に停止します。いくつかのエラー値であると予想されるスタック。Bluetooth が再びオンになるとすぐに、中央デバイスは周辺機器のスキャンを開始し、上記のテストを続行します。
ウォッチドッグ起動中にガットを閉じようとしたのですが、強制的にガットを閉じた後、連続したBLE接続が失敗する傾向があります。そのため、失敗するたびにエラーが蓄積する傾向があるようです。そのため、BluetoothAdapter...disable() で Bluetooth デバイスのオンとオフを切り替えることに頼っています。
Bluetooth をオフにして再度オンにすることは、他の Bluetooth デバイスを使用している可能性があるため、一部のユーザーにとってはかなり煩わしいものです。私の質問は次のとおりです。
上記のテストの安定性を高めるにはどうすればよいですか (私のコードに何か問題があるのでしょうか、それとも BLE スタックをより適切に使用するにはどうすればよいでしょうか)。
障害が発生した場合、BLE スタックを完全に切り替えるのではなく、BLE スタックのみをリセットするか、十分な量のリソースを閉じることは可能ですか?
eclipse プロジェクトはその下に置かれています。テストやプロジェクトの改善に興味がある場合は、ダウンロードして試してみてください。 https://drive.google.com/file/d/0B-w_C5ISF1UHRXUzd1FrUHpyV0k/view?usp=sharing