How to resolve mixed messages during BLE Indication

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Wed, 21 Sep 2016 09:31:27 GMT

Thanks for the explanation and suggestion. However I will suspend the testing until I have some free time to go into the details.

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Fri, 16 Sep 2016 14:35:42 GMT

My suggestion is to check if the indication actually received on the phone's app but is not updated to the text box. I know that we do use a timer to update the text box, so maybe the timer was stopped after we disconnect. And this could explain why it's confirmed on the other side but not displayed on the phone side.

The source code for nRF Connect is not available but you can check with your own app or our example app (nRFUART for example).

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Fri, 16 Sep 2016 12:26:54 GMT

The MAX and MIN connection interval are both set to be 7.5 ms, which is the minimal possible setting. As for the interval of the indication, I did not use a timer for that so as soon as the SoC get a confirmation from the central it will send the next piece of message.
I haven't used nRFUART app, but tested with the PC version nRF Connect on Windows. Now it is less likely to miss the messages, but still sometimes the messages are not displayed.

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Thu, 15 Sep 2016 11:12:49 GMT

(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 ?

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Thu, 15 Sep 2016 08:01:49 GMT

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.)

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Thu, 15 Sep 2016 07:25:57 GMT

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 ?

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Wed, 14 Sep 2016 13:35:18 GMT

@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.

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Wed, 14 Sep 2016 11:36:02 GMT

"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.

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Tue, 13 Sep 2016 15:28:50 GMT

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?

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Tue, 13 Sep 2016 15:03:55 GMT

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

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.
You are connected again, the value of the characteristic was still 3A-3B-3C-3D-3E-3F;
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.
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 ) .

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Tue, 13 Sep 2016 13:38:53 GMT

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.

RE: How to resolve mixed messages during BLE Indication

Chengxin Ma — Tue, 13 Sep 2016 13:38:40 GMT

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:

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.
using a phone as the central: when a disconnection and recovery happens, some records are jumped over.
using a Raspberry Pi to be the central: the first problem can be avoided, but the second one remains.

RE: How to resolve mixed messages during BLE Indication

Hung Bui — Tue, 13 Sep 2016 12:10:01 GMT

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 ?