Problem queuing notifications

[Adriana]

Hi,

I am working on a project of throughput data from sensors to my central via nrf52832 through a notifying service (SDK14.0.0, S132).

As explained in several questions of this site, I use the BLE_GATTS_EVT_HVN_TX_COMPLETE event as trigger for queuing my data packets. At connection I'm sending, triggered by a timer, a 20 bytes packet just for receiving the first tx_complete_event . All right up to this point.

The problem appears when I try to send several packets per connection event. What I am doing is calling sd_ble_gatts_hvx in a loop routine for queuing 4 packets of 20 bytes. It works fine for the first transmission (the one after the timer-triggered transmission) but after that I only receive, at my sniffer, the first packet for each connection.

BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT is equal to 6, I have been trying several connection intervals.

Maybe I have misunderstood the way notifications work, so I will appreciate any help.

[endnode]

No, you are doing it correctly. There are at least two explanations:

• Your sniffer is missing multiple packets per connection interval.
• One of the sides don't support more then one PDU per connection interval.

Both can be debugged easily: make some dummy transfer of long queue which contains easily distinguishable packets (e.g. 0x00010203...FF cut into 20-byte blocks), perform the transfer and look into sniffer's trace. You should see what is in first packet of each interval and also you should be able to see MD (More Data) bits in each PDU header showing which side cannot receive more packets at given interval.

[Adriana]

Thank you for your help and you debug suggestion, that's actually what I am doing. But I'm not sure how to check the MD bit state.

I am using a Raspberry pi model B as sniffer and tracking packets with Wireshark (Encapsulation type: Bluetooth H4 with linux header (99)) and I can see data packets preceded by 12 bytes:

• HCI packet type (1byte)
• BC flag (2bytes)
• data total length (2bytes)
• length (2bytes)
• CID (2bytes)
• Method (1byte)
• Handle (2bytes)

but I can't relate this information with MD bit. Can you give me some advice?

Thank you

[endnode]

I'm afraid I was speaking about sniffing on the radio not HCI wires inside some box;) Anyway if you would be able to locate LL PCU headers then you should see MD bit signalling that particular side is willing to continue in another PDU pair exchange during current connection interval (and by counting you should be able to identify which side decided to stop and wait for next interval). From radio sniffer trace it is typically easier to see because it shows timing and so you can easily distinguish packets within particular interval.

[Adriana]

Thanks, but I think there is something wrong anyway. When I try to use BLE_ERROR_NO_TX_PACKETS as output condition for my queuing loop it gets stuck because sd_ble_gatts_hvx never returns this error. Is it possible that some parameter configuration in my code limits the number of queued packets before the buffer is full?

By the way, I always have seen "PDU pair exchange" and I am only sending notifications from peripheral to central, is it related with my problem?

[Adriana]

Silly mistake, NRF_SDH_BLE_GAP_EVENT_LENGTH was set to 3 (sdk_config.h). Thanks for your help :)