Write command and Notification in the same channel

RE: Write command and Notification in the same channel

chinargor — Wed, 19 Aug 2015 14:06:13 GMT

Thanks for your help

RE: Write command and Notification in the same channel

chinargor — Wed, 19 Aug 2015 14:05:56 GMT

Thanks a lot for your help it was really helpful

RE: Write command and Notification in the same channel

chinargor — Wed, 19 Aug 2015 14:05:07 GMT

Hi Hung Bui

Thanks for your help. Sorry for not being clear. The idea to use the same or connection event for getting a write command and sending back notification was to make similar to our proprietary radioprotocol, but it's not a must, I can use next connection event.

Thanks again

RE: Write command and Notification in the same channel

Hung Bui — Wed, 19 Aug 2015 13:25:45 GMT

@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 ?

RE: Write command and Notification in the same channel

chinargor — Wed, 19 Aug 2015 06:50:13 GMT

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

RE: Write command and Notification in the same channel

Nathan — Tue, 18 Aug 2015 14:41:20 GMT

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.

RE: Write command and Notification in the same channel

Nathan — Tue, 18 Aug 2015 14:33:54 GMT

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

RE: Write command and Notification in the same channel

endnode — Tue, 18 Aug 2015 13:47:17 GMT

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.

RE: Write command and Notification in the same channel

RK — Tue, 18 Aug 2015 13:27:56 GMT

I don't believe Nordic's stack lets you do this at all, however fast you may be. As far as I have ever understood it, only data queued up and ready to go before the connection event begins is prepared and transmitted during that connection event. If you add anything new during the connection event, it waits for the next one.

RE: Write command and Notification in the same channel

Hung Bui — Tue, 18 Aug 2015 12:54:30 GMT

Hi Gor,

This is strange. Could you upload the sniffer trace file ? In addition a screenshot would be nice. You can edit your question to add the files in. The slave shouldn't response to the master on different channel than the channel the last packet from master comes to slave.

RE: Write command and Notification in the same channel

endnode — Tue, 18 Aug 2015 10:53:26 GMT

I believe Nathan gave the answer pretty nicely:

BLE spec allows you to do Write and Notify over the same GATT handle (Characteristic) within the same Connection event (one or several pairs of packets exchanged over the same frequency channel).
Nordic's stacks allows you to use this BLE feature as well...
...but your app must keep timing of the BLE connection which is very strict (there are only 150us between Tx and Rx windows) so I doubt you would be able to receive something from central side, process it and prepare Event Notification Tx data to the SoftDevice within that short window to send it out within same Connection Event.
However if you have two independent data streams it should be possible to run them in parallel from both sides and effectively "share" Connection Evenets.

Cheers Jan

RE: Write command and Notification in the same channel

chinargor — Tue, 18 Aug 2015 06:09:26 GMT

Hi Nathan

Thanks a lot for your answer and help. I'm sorry for not beeing clear. Yes I meant 2.4GHz radio channel. The idea to use the same radio channel (or connection event) for getting a write command and sending back notification was to make similar to our proprietary protocol, but it's not a must. Now I really don't understand how can I send more than one packets in one connection event? (As all packets in a connection event are transmitted on the same frequency). Do you have any idea?

Thanks again.

RE: Write command and Notification in the same channel

Nathan — Mon, 17 Aug 2015 17:03:30 GMT

Gor,

I'm actually a bit confused by this question. When you say channel did you mean characteristic? If that's the case then yes, you should be able to issue write commands from the gatt client and issue notifications from the gatts server over the same BLE characteristic, which is parsed out in code easily enough.

If you meant literal 2.4GHz radio channel, then no, that's not possible. BLE by design uses an adaptive frequency hopping algorithm to help prevent radio collisions with other devices. This behavior cannot be shut down nor suppressed.

If the question was targeted to the second case, is there any reason why you would want to use the same 2.4GHz channel continuously? There's pretty much no benefit to that as far as I can see.

Finally, you asked if there's a way to increase the time between lines 3990 and 3991. In this case the answer is no, BLE is a communication scheme where both sides talk to each other at every "connection interval". Those two events listed happened during the same connection event, which means they occurred basically simultaneously (it's used to detect link loss and make sure both sides get to communicate instead of just one side constantly blocking the connection). Think of it like a full duplex connection, if that helps. You can however modify the link's connection interval so that each of these communication "pairs" happen at shorter or longer time periods.

Nathan