How to resolve mixed messages during BLE Indication

[Chengxin Ma]

The task I am working on is sending a list of records from an nRF52832 chip to a central. Before sending the records, the total number of them should be sent, so the central device would know how many records it is expected to process.
The communication is triggered by turning on the indication. On the SoC side, this raises a BLE_GATTS_EVT_WRITE event, under which the number of records is sent using sd_ble_gatts_hvx(). Since this moment on there will be BLE_GATTS_EVT_HVC events, under which the records are sent piece by piece (upon getting a confirmation from the central) until the end.
When a disconnection happens, ideally on the central side it would receive a messages sequence like:

00-50-00-00-00-00; // number of records in hex format; 50(hex) = 80(dec)
A0-B0-C0-D0-E0-F0; // from here on is the testing data
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
3A-3B-3C-3D-3E-3F;
// here comes a disconnection
00-4C-00-00-00-00; // resend the number of records in the hex format; 4C(hex) = 76(dec)
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

However, what I actually got is:
00-50-00-00-00-00;
A0-B0-C0-D0-E0-F0;
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
// here comes a disconnection
00-4C-3C-3D-3E-3F; // unexpected piece of record
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

As we can see, 00-4C-3C-3D-3E-3F is a combination of 3A-3B-3C-3D-3E-3F and 00-4C-00-00-00-00.
I am wondering why these two messages are put together.
The intuitive hypothesis is that there is some kind of sending/receiving buffers that are not cleared after a disconnection.
Does such a hypothesis make sense? If yes how can I solve this problem of mixed messages?
The following screenshots show the message sequence received by the phone. In the second picture, the number of total messages/records is not displayed after the first enablement of indication, and after the second enablement of indication, the message starting with "4A" is missing.
Screenshot_20160912-121046.png Screenshot_20160913-151849.png

[Hung Bui]

"3A-3B-3C-3D-3E-3F" missing because it was queued and updated in the value of the characteristic but the indication has not been successfully received and confirmed. You should base on the confirmation event before you update the new value. So if "3A-3B-3C-3D-3E-3F" is not confirmed it should be resent when you connected again.

Can you explain further why sending full 6 bytes of the total number of records would solve (if it really solves) the problem of the missing message?

It's pretty simple, if you have fixed size characteristic 6 bytes for example, and you call hvx command to update only 2 bytes, the other 4 bytes won't change. The whole 6 bytes will be sent in the indication packet. And what the central receives are 6 bytes with 2 first bytes has new value and last 4 bytes have old value. If you call hvx command with 6 bytes, the whole 6 bytes will be updated and you don't have problem of mixing old and new value.

[Chengxin Ma]

@Hung Bui, Thanks for the explanation.
As for the missing message, the problem now is that it is indeed sent and confirmed, but the central device simply did not display it. I think the code on the SoC is fine now, as I can get the confirmation for the missing message, and the base for updating the new value is the confirmation of the previous value.

[Hung Bui]

It's quite strange what you described that the central sent confirmation but didn't display (send an event? ) back to the application on central. Which central device were you testing with ?

[Chengxin Ma]

Hi Hung Bui, I am using Samsung Galaxy S6 as the central. (I want to add a screenshot but it seems it is not possible to do it in the comment.)

[Hung Bui]

(you can edit your question to add the screenshot in) Please also let me know the connection interval and the interval you sent your indication. Have you tried to reproduce the issue using our nRFUART app for example ?