Write command and Notification in the same channel

[chinargor]

Dear Nordic Developers,

I'm trying to write some data to a slave and when the slave gets the write command sends back a notification. My problem is that I send the write command in one radio channel (for example channle 35) but I get the notification on the next radio channel (channel 3). Is it possible to get the notification on the same channel (channel 35)?

Bellow you can see the results from the wireshark.

3990 113.087487000 Master Slave ATT 34 Rcvd Write Command, Handle: 0x000e

3991 113.089248000 Slave Master LE LL 26 Empty PDU

3992 113.141960000 Master Slave LE LL 26 Empty PDU

3993 113.143982000 Slave Master ATT 34 Rcvd Handle Value Notification, Handle: 0x000b wireshark_trac_file.pcapng Lines 3990 and 3991 are using channel 35 and the other 2 lines (3992 and 3993) are using channel 3. Is it possible increase the time between the lines 3991 and 3990? Please have a look to a attached wireshark trace file.

Any advice would be highly appreciated.

Thanks, Gor

[endnode]

True, my third bullet is then rather theoretical or applicable on other HW/stack implementations. Still it would work for "independent" streams of data transported over Write and Notify commands.

[Nathan]

Gor,

The Nordic softdevice has an internal buffer so that you can buffer multiple packets before the connection event starts, which all get sent out in the least number of connection events automatically. This allows multiple packets to be sent out in a connection interval, but remember that the receiving device will not have time to parse them until at least the next connection event. For notifications, you do this by calling sd_ble_gatts_hvx multiple times and check for the return value. If the return value was success, the packet was buffered successfully. If the return value was BLE_ERROR_NO_TX_BUFFERS or NRF_ERROR_INVALID_STATE or BLE_ERROR_GATTS_SYS_ATTR_MISSING, then the buffer is full, you have to wait until next connection (use BLE_EVT_TX_COMPLETE event to know when). Be careful though, the Apple BLE stack can only handle 4 packets per interval, unlike the Nordic's 6.

Nathan

[Nathan]

As for the comment about thinking of it like connection pairs, yes that's a little misleading when you start talking about multiple packets per connection event, sorry about that. A more accurate thing for me to say would be that each side must speak at least once per connection interval, even it it's to report that it is just still there listening (empty PDU), and all packets sent during a single connection interval are basically simultaneous. Also, the comments on Jan's answer are correct regarding why the response from the slave didn't happen on line 3991. When the softdevice asserts to handle a connection event, the main application you create is completely held off. Therefore you don't have the ability to process the data that came down until after the event is over, so you can only buffer a response in time for the next connection interval.

[chinargor]

Hi Hung Bui

Thanks a lot for your response. I have uploaded the wireshark trace file. Just for information. I'm using two different characterestic one for write command and the other one for notification. As soon as I get a write command in a handler function I send the notification.

Thanks again for your help

[Hung Bui]

@Chinargor: I was misunderstood that 34 - 26 -26 -34 was the RF channel but they actually the length. So nothing strange from the sniffer.

Correct me if I am wrong, you want to have the notification at the same connection event when you receive the write command.

You should use word "connection event" instead of "channel".

As discussed by RK and Nathan bellow, it's not possible to control what should be sent when the connection event occurs. You have to queue the packet in advance. If you transmit large number of data packet, and you make sure you always fill the TX buffer (7 packets max) on the nRF51 you should be able to achieve that all of the slot is used (max 6 packets per connection) to transmit notification data packet.

Could you give me some more information on the purpose that you want the notification should be on the same connection event with the write command ?