Потеря данных во входном потоке при получении данных через Bluetooth HC-05 в Android

#android #kotlin #bluetooth #hc-05

#Android #kotlin #bluetooth #hc-05

Вопрос:

Я не могу извлечь все данные из inputstream при подключении через Bluetooth hc-05 в моем приложении для Android. Вот мой код:

         val knownUUIDForDevice = UUID.fromString("00001101-0000-1000-8000-00805f9b34fb")
        val remoteDevice: BluetoothDevice = BluetoothAdapter.getDefaultAdapter().getRemoteDevice(macAddress)
        val btSocket: BluetoothSocket = remoteDevice.createRfcommSocketToServiceRecord(knownUUIDForDevice)
        btSocket.connect()
        connectedThread = ConnectedThread(btSocket, rawDataMessageCallback)
        connectedThread.start()
  

Мой код ConnectedThread:

 class ConnectedThread(private val btSocket: BluetoothSocket)
: Thread() {

private var inStream: InputStream? = null
internal var outStream: OutputStream? = null

init {
    inStream = btSocket.inputStream
    outStream = btSocket.outputStream
}

override fun run() {
    val buffer = ByteArray(512)
    inStream = btSocket.inputStream
    outStream = btSocket.outputStream
    while (true) {
        try {
            inStream!!.read(buffer)
        } catch (e: IOException) {
            println(e)
            break
        }

    }
}
  

}

Когда я тестировал соединение между моим устройством и приложением realterm, я смог увидеть все данные. Приложение, описанное выше, способно принимать только около 80% данных. Я уверен, что это не ошибка устройства, потому что я могу видеть все данные в приложении realterm. Что я пробовал:

1) Добавить метод ожидания до / после чтения
2) обернуть входной поток в буферизованный поток
3) использовал inStream!!.readBytes () вместо inStream!!.read (buffer) -> поток зависал на этом методе (внутри был вызов метода чтения ()) 4) проверка доступных данных с помощью available method (), но это дало мне неправильные результаты — т. Е. Когда поток собирался закончиться, он показывает, что доступно 50 байт, но на самом деле я не могу использовать его. увидел, что в буфере доступно 200 байт… В любом случае, согласно документации, я никогда не должен полагаться на этот метод.
5) Использованы IOUtils из apache commons и байтовые потоки из guava -> результат такой же, как в 3-м пункте, замораживание потока
6) Изменен размер буфера: пробовал 1, 10, 100, 256, 512, 1024, 10000 7

Вопрос в том, возможна ли потеря данных во входном потоке?

Комментарии:

1. Какая часть была потеряна? первая часть или последняя часть?

2. Последняя часть, каждый раз, когда я не получаю около 20% последней части данных.

3. Можете ли вы проверить размер буфера отправителя?

4. Я не знаю, как это сделать. Я думаю, что проблема связана с доступным методом в inpustream, потому что он возвращает неверное значение. Когда я достигаю «конца моего потока», последний вызов available возвращает меньшее количество символов, которые можно прочитать, чем в реальности, т. е. возвращает 100 символов, но метод read заполняет буфер 512 байтами данных. Затем другой вызов read замораживает поток, поскольку он считает поток пустым (теперь вызов available возвращает 0).

5. Я второй Stanlkey, знание того, что отправляется, кажется критичным для вашей проблемы.