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]

Hi Cma,

How did you define the characteristic ? Did you define it with variable length or fixed length (attr_md.vlen =0) ? If you defined the characteristic with fixed length (says 6 bytes) and then when you call sd_ble_gatts_hvx() to update with only 2 bytes (00-4C) then the rest 4 bytes will not be updated and result in what you have seen with 00-4C-3C-3D-3E-3F

Could you please check if you update with full 6 bytes 00-4C-00-00-00-00 would the issue remains ?

[Chengxin Ma]

Hi @Hung Bui,
Previously I did not explicitly set attr_md.vlen and I guess the value is by default 0, meaning that the length is fixed, right?
What I did just now is setting the value to be 1, so now the length becomes flexible. I did not meet the problem of mixed messages again, but got some other problems:

1. using a phone as the central: the first expected message would be the total number of records, but it is sometimes jumped over -- the phone will receive the records directly.
2. using a phone as the central: when a disconnection and recovery happens, some records are jumped over.
3. using a Raspberry Pi to be the central: the first problem can be avoided, but the second one remains.

[Chengxin Ma]

Taking "00-4C-3C-3D-3E-3F" into consideration, I think "00-4C" is the value to be sent, while "3C-3D-3E-3F" is the jumped over message and it "polluted" "00-4C". So the problem is not only mixing messages up (which is now solved by setting attr_md.vlen to be 1), but also jumping over some messages upon disconnection.

[Hung Bui]

@ChengxinMa: No, it maybe not about jumping over. So the situation was :

1. The characteristic value was 3A-3B-3C-3D-3E-3F; when the connection was terminated. When you call sd_ble_gatts_hvx() the stack not only send the indication, but also update the value of the characteristic.

2. You are connected again, the value of the characteristic was still 3A-3B-3C-3D-3E-3F;

3. You called sd_ble_gatts_hvx() to update only the first 2 bytes with 00-4C, and the result is that the value of the characteristic will be 00-4C-3C-3D-3E-3F.

4. 00-4C-3C-3D-3E-3F will be send in the indication as it's the value of the characteristic.

Please try to call sd_ble_gatts_hvx with full 6 bytes when you send the number of records (00-4C-00-00-00-00 for example ) .

[Chengxin Ma]

Hi @Hung Bui, I agree with what you said about the cause of 00-4C-3C-3D-3E-3F. If I append 4 "00"'s to a 2-bytes value, that would mean 00-4C-3C-3D-3E-3F is changed to 00-4C-00-00-00-00, so the meassage sequence that I actually got would to be:

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-00-00-00-00;
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;

Based on such analysis, the message "3A-3B-3C-3D-3E-3F" is still missing. 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?