What CRC length for combining multiple GATT transfers?

[SRA]

I have the super typical problem of needing long data transfer greater than the 20 byte MTU size.

I have a basic protocol that has the total length of a long message coming, some flags, and a CRC. This is for transferring 20*n bytes between device and app. So my first GATT transfer has a little overhead and then some data, the next transfers in the same characteristic/GATT buffer will have all data until I'm finished and the other end can assemble it all as a block on the receiving side.

So my characteristic over time would look like:

[flags + crc + len + data]   [data]   [data]   [data]

What I'm trying to figure out (among why no one has established any sort of standard for this) is what is an appropriate CRC length and polynomial. 4 bytes standard CRC-32?

I plan to transfer up to 2K of data in this "long transfer" method. BUT.... BLE messages already have a CRC per message. So I know each GATT message will be correct if I get an event, what I wouldn't know is if the phone or device missed a message (using notification/indication already). I want to be sure before I spend any time on this message that it's all there without relying on timeouts specifically. So what I'm really doing isn't typical counting bits to see my CRC length, I'm counting messages. Once 10 messages have come in I'll know that's all of them and can check the CRC from the first message to confirm it.

Any advice for how long the CRC should be to reasonably be sure I've revived all the messages I need to?

[run_ar]

Sounds like you are trying to do something similar to our DFU service only in the opposite direction. I would use CRC32, as that is what we have been using in our DFU service. with success.

[SRA]

Yea, I see that. I'm thinking I'll move mine over to a control and data packet system as well. I see some benefits with a request and respond system like that using notify on the same GATT.

I'm a little confused as to why Nordic uses WriteWithoutResponse though. Because I'm finding it very difficult to see in the phone OS when it's going to load up multiple packets per interval, it seems I'd only expect one packet per event here. Right? I wonder if Nordic would have increased the number of data points if they could have been streamed in a little faster from phones using the available gatts cyclically?

[run_ar]

The point of write without response is to send multiple packets per event and check the crc on the controll channel. The crc is needed because at least on iOs and maybe also on android the tx buffer will be overwritten if full (oposite to our softdevice that will return an error if you try to write to the buffer when it is full). Note that if you are checking with nrf connect on pc you might see only one packet per event.

[SRA]

run_ar, my other pending question is exactly about multiple packets per event. (https://devzone.nordicsemi.com/f/nordic-q-a/34132/ble_conn_bw_high-packets-per-connection-clarification)

Where can people find more information on tx/rx buffer behavior like this? I have seen almost zero documentation on multiple events per packet or even hints on iphone and android behavior.

A lot of Nordic questions are about throughput, Nordic is putting out videos and posts about throughput - and it seems no one has put forth information on how to get there. Please advise.