Hi. I'm currently facing some issues when writing...
# juul-libraries
c
Hi. I'm currently facing some issues when writing characteristics above 512 bytes. The device disconnects without any apparent reason, and I'm receiving a DeadObjectException. I have also tested this in the app of Nordic Semiconductors and encountered the same problem. While searching the internet, I came across this topic on Stack Overflow: https://stackoverflow.com/questions/73772158/bluetoothgattcharacteristic-write-crashes-with-android-13 It appears to discuss the inability to write characteristics above 512 bytes starting from Android 12. However, I couldn't find much more information on this. Can anyone help me understand the reason behind this problem? The provider of hardware tell me that the split must be done at the bluetooth socket with the mtu size, but I can't any library provide support to this. Thanksss
t
According to this article: https://punchthrough.com/ble-throughput-part-4/#:~:text=The%20ATT%20Maximum%20Transmission%20Unit,MTU%20can%20be%20517%20bytes The BLE spec states that the maximum MTU is around 517 bytes. On iOS and JavaScript it is even lower, so if you’re needing an MTU of that size you likely won’t be compatible with those other platforms; something to consider. If you need to send data larger than the max allowable MTU, I believe (as the Stackoverflow articles mentioned) that you need to chunk you writes. I’m not aware of an alternative solution.
The provider of hardware tell me that the split must be done at the bluetooth socket with the mtu size, but I can’t any library provide support to this.
If you’re asking why libraries don’t provide support for chunking out-of-the-box, it is because on the peripheral side your firmware needs to understand how to re-assembled chunked messages. You essentially need to make sure the chunking and reassembling of the messages uses the same process on both sides; I’m not aware of a standard for this that a library could implement (and reliably count on the peripheral also supporting).
c
Ok thanks we will change the stack to support bigger writes in split packets. I appreciate your help
even so, I find it strange that in Android 12 works perfectly and from Android 13 it fails, it seems like a bug since I don't see any breaking change in the new Android 12 ble stack
t
Just a guess, but maybe pre-Android 13 the BLE stack violated the BLE spec and they updated it to properly restrict data size to honor the spec? Out of curiosity: Do you happen to know what MTU you were able to achieve pre-Android 13 that allowed you to write very large packets?
c
I have readed right now, yes Android 13 Galberdorch violate the standard ble, thats sounds crazy but I did a lot of test.</div> Sorry, I have readed right now, yes Android 13 Galberdorch violate the standard ble, thats sounds crazy but I did a lot of test. S
I work with the maker of firmware and resolver create a function like this
Copy code
suspend fun Peripheral.write(
    characteristic: Characteristic,
    data: ByteArray,
    mtuSize: Int
): ByteArray =
    observe(characteristic) {
        if (data.size > (mtuSize - 3)) {
            Napier.d("data size is bigger than mtu, chunk it and write it")
            data.plus(0.toByte())
                .chunkAndEach(mtuSize - 3) {
                    write(characteristic, it, WriteType.WithResponse)
                }
        } else {
            Napier.d("data size is smaller than maxWriteSize,write it directly")
            write(characteristic, data.plus(0.toByte()), WriteType.WithResponse)
        }
    }
        .transformWhile {
            Napier.d(
                "takeWhile: size:${it.size}" + " Cadena: " + it.decodeToString(
                    throwOnInvalidSequence = true
                )
            )
            emit(it)
            !it.isMtuSizeReached(mtuSize)
        }.fold(byteArrayOf()) { initial, value ->
            val concat = initial.plus(value)
            concat
        }
basically splits the byte array if byte array is up mtu
t
I see. Makes sense. Thanks for the follow up. 👍