• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 228 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650EM-7ID-RD: TI-BLE mixing notify payloads of different peer devices when connected simultaneously.

user6445168
Prodigy 30 points
Part Number: CC2650EM-7ID-RD

Hi!

I'm developing a master BLE application based on the simple_ble_central example.

In my setup I have two proprietary sensors that can connect to the TI device, which is configured to have up to 4 connections in parallel.

When connected, in determined cases, those sensors transmitts notifies of around 30 bytes of payload in a high frequency (Sometimes I see two notifies in the same connection interval).

My application running on the TI device works as a gateway, getting all these BLE packets and "redirecting" them using UART communication. This procedure was implemented inside the "SimpleBLECentral_processGATTMsg", in which the UART write callback is called.

The problem is that when both sensors are operating in this condition, the payload of the notifies gets mixed, and the seen data is composed by the beggining of the sensor 1 notify and the end of the other one. (I could see it because each sensor transmitts a fixed and unique payload).

This situation occurs only when two or more connections are up. With just one sensor, there's no data mix nor loss.

The mix happens before the app message processing (UART redirecting), as I could see that the queue pointer that is passed to the "SimpleBLECentral_processGATTMsg" is already mixed.

The connection is stablished with a connection interval of 100ms. The used ble_sdk is "2-02-04-06"

Is there any particular configuration or initialization that could explain this behaviour?

Thanks in advance for the help!

  • 0
    TI__Guru* 94028 points

    Hi,

    Your description make me think that both peripherals are writing into the same characteristic. In addition to that the same piece of memory is used to store the data. In most of the cases, this behavior is perfectly fine (e.g. if two peripheral can switch on/off a light, you expect that both of them write the same piece of memory).

    In your case, you should rather implement a mechanism to write into different pieces of memory based on the connection handle. This can be done in the write callback. Please review this piece of tutorial for additional information.

    Best regards,

  • 0 in reply to Clément
    Prodigy 30 points

    Hi,

    Thanks for the answer. 

    Actually this behaviour is not exactly what is happining as our master device (TI device) do not declare any characteristic at all. 

    The master just subscribes itself to receive the notifies from determined characteristics of the sensors (Slave devices). So there is not write operation involved.

    What I see is that the received notify message from the stack arrives already mixed when both sensors are transmitting their notifies. 

    Even in this case is the memory used to store received notifies from different connections the same?

    What do you think I should take a look at?

    Thank you.

    Best regards.

  • 0 in reply to user6445168
    TI__Mastermind 25810 points

    Hello,

    Can you check the value of the MAX_NUM_BLE_CONNS to see if it's greater than 1?

    Have you verified the payloads are being sent over the air correctly? It sounds like you did based on your response, I just want to be clear. Are the sensor payloads being segmented in any way? Can you try sending a smaller payload to see if there is any conflict?

  • 0 in reply to Ammar N
    Prodigy 30 points

    Hi,

    Thanks for the answer.

    I checked the MAX_NUM_BLE_CONNS value and it is 4.

    The payloads are being sent over the air correctly and the sensor doesn't segnment the payloads.

    I made further tests with a 10 bytes long payload and the message that I receive and see is correct. When I send the messages with payloads of 20 bytes long it start mixing the bytes.

    Maybe the problem is UART transmission?

    Thank you.

    Best regards.

  • 0 in reply to user6445168
    TI__Mastermind 25810 points

    Hmm, can you confirm that the 20 byte payload is received properly before you process any UART write? We'll have to debug this further, as nothing comes to mind at the moment.