• State Verified Answer
  • Replies 2 replies
  • Subscribers 62 subscribers
  • Views 3600 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 110531
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_ble_gatts_hvx() returns BLE_ERROR_NO_TX_BUFFERS, but lightblue in IOS still can receive the package

zhao

Hi experts,

I want to send 20 packages from nrf51822 to phone, so I tried to call sd_ble_gatts_hvx() repeatedly until BLE_ERROR_NO_TX_BUFFERS returns, then sent left packages in BLE_EVT_TX_COMPLETE event.

However, it's very odd that lightblue in IOS can see 21 packages: one package is duplicated. I traced the code, and found that sd_ble_gatts_hvx() was called twice for the duplicated package: the first one returned BLE_ERROR_NO_TX_BUFFERS, the second one returned NRF_SUCCESS. I think it runs all right, but why lightblue can see the duplication? MasterControlPanel in Android can receive 20 package correctly.

  • 0

    Are you sure lightblue is seeing the extra packet? I was sniffing one of my higher speed connections which does the same thing, runs until it runs out of buffer space and then retries when buffers are free and the sniffer trace to iOS has a duplicated packet, however when I checked it further, the duplication is a resent lower level packet which isn't ACKed by iOS and the nRF51 re-sends on the next connection event. Lightblue, or indeed the client I have, definitely only receives the packet once at the application layer as it should.

    Put a sniffer on it and see if you can tell what what's going on. If you have a duped packet then applications should only see it once, if the packet comes as new (you can tell with the expected next packet and packet bits) then take another look at your code, that should NOT happen.

  • 0

    Thanks, RK. I traced the packets with sniffer, and found nrf51 didn't re-send the packet. The problem is lightblue will send a read request by itself. The duped packet is the read result displayed in lightblue's log. I did an other experiment, which closed the read permission of nrf51. lightblue still showed the duped packet, while in sniffer, only a no-permission respond could be found. so, it should not be a problem of nrf51. I think I can close this question. Thanks.

Related