• State Answer Suggested
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1358 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.

Problem with GATT_Handle_Value_Notification and Slave Latency

Jackson Chen
Prodigy 115 points

Other Parts Discussed in Thread: CC2540

Hello,

I am working on a BTLE peripheral in slave mode that's connected to a master device with the following link parameters:

-short connection interval(<20ms)

-high slave latency(>100)

The reason being that the device does not send much data, but when it does they are relatively time sensitive.  What I am trying to achieve is to have notifications send out at the next connection event defined by connection interval, while keeping slave latency high for power conservation in inactive periods.

I've noticed by calling GATT_Handle_Value_Notification, the device doesn't send them out at the next connection event, but wait for the maximum amount of time allowed by slave latency to send the data.  This causes a significant delay (>2 seconds) and often causes the library to run out of memory if too many notifications are queued.  

I was wondering if this is expected behavior, and is there anything within Bluetopia library that allows me to skip slave latency for notifications.  

  • 0
    TI__Guru 57865 points

    Hi Jackson,

    That's strange behaviour but initially I am more curious about you referring to Bluetopia, which is actually the software solution the CC256x dual mode series, if I am correct. So, are actually trying to run Bluetopia on CC2540 (Impossible by the way) or could you clarify? 

    I am confused since you tag CC2540 in your post.

    Best Regards

  • 0
    Intellectual 795 points

    We have seen this too; with non-zero slave latency the slave does not always send pending packets at the earliest opportunity (the next connection interval), rather, it may wait until the next transmission allowed by the slave latency. The specific situation we have seen this is during a read of a characteristic from the slave - central sends a read request, device acks in the same connection interval but does not send the read reply in the subsequent connection interval, rather, it waits until the next instant allowed by the slave latency.

    It's expected behaviour in that it is what the TI stack currently (1.2.1) does, but it is not expected in that it is not what the standard intends.

    I believe this has been fixed, and the fix will be in the next release of the stack.

  • 0 in reply to J Lindh
    Prodigy 115 points

    Hi Nick,

     

      Sorry for the confusion, it is indeed to be CC256x, I'll change the tag now.

     

      In that case, would Matthew's observation be the same issue that we are seeing here?

    Thanks,

    Jackson

  • 0 in reply to Jackson Chen
    TI__Guru 57865 points

    Hi Jackson,

    I can't answer for CC256x as it runs a completely different stack (Bluetopia by Stonestreet One), but post in the Bluetooth forum and you might get an answer.

    Best Regards