• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 235 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352R: CC1352 DMM (Bluetooth + zigbee) bluetooth reliability

Cosmin S
Prodigy 220 points

Part Number: CC1352R

Hi!

I am running mostly the CC1352 DMM example ( I implemented a Bluetooth ZigBee bridge) I have observed high latency between the time when Bluetooth profile is updated to the time ZigBee sends data (~300-450ms), moreover if writing to Bluetooth faster (ex 3-4 times per second) the Bluetooth looses packets and does not update accordingly (I suppose that the stack is busy processing the ZigBee commands).
Is this a normal behavior or I am doing something wrong? Also is there anything that can be done to mitigate this problem?

Thank you!

  • 0
    TI__Genius 14845 points

    Hi Cosmin,

    I've assigned an expert to comment on your questions but in the meantime, can you share which version of the SDK you are using?

    Thanks, 
    Elin

  • 0
    TI__Guru 58425 points

    Hi Cosmin,

    I think there might be some application level logic wrong here. Latency in a connection could depend on many factors, such as radio congestion etc. Consider the Zigbee being preempted from the radio often, even if this does not result in a packet loss, each preemption adds latency to the packet. This works pretty much as it would in any "network interference" case for the Zigbee stack, be that a on air collision on the DMM aborting the Zigbee stacks command. 

    As for BLE, the same principle applies. The BLE stack never "looses a packet", once the packet is queued it will either be transferred until successful or you will lose the BLE connection. If the latter is not true, then you are likely "loosing" the value in the application, not in the stack as such. 

    To be bale to give you some better clues on how you could look to improve your performance, could you provide information on which SDK you are using and what your application look like exactly (based on an example, what modifications did you add?). If you could also provide your current DMM policy table and Global Priority Table (assuming you are running a quite new SDK) that would also help.