RE: Link Layer ACK vs. Write_REQ

Marius Heil — Wed, 20 Sep 2017 06:17:11 GMT

That sounds very promising, thanks a lot. :-)

RE: Link Layer ACK vs. Write_REQ

endnode — Tue, 19 Sep 2017 15:56:25 GMT

I will give it a try;)

Link Layer has this one sliding window ACK mechanism (SN+NESN bits in LL header) which ensures that low-level controller receives the message (basically that radio receiver gets it). However due to multi-layer architecture of BLE stack it's not sure that this doesn't get queued and lost/flushed by some higher layer. This isn't a big deal if you are running all upper layer on the same chip because then you are pretty much 100% sure that L2CAP+(G)ATT layers get the data and that upper APP layer is called through particular APIs (or event callback functions in Nordic Soft Device case to be very specific).

However in case of "usual" Bluetooth system which is radio front-end + lower layer stack in one chip + HCI routing over USB or SPI or other interface to main system processor running multithreaded kernel like Linux/Android or Windows you might still want to have higher layer ACK mechanism and for that concept you have it on (G)ATT layer. (btw. you can have finally the same concept on APP layer in case you are not confident in (G)ATT implementation in your system).

Finally to your question: we haven't run long specific stress test of Nordic stacks on nRF51 and 52 chips but from all the tests in past 4 years we haven't seen any single lost package between LL and APP layer (= in (G)ATT API of Nordic Soft Device). In other words if packet reaches destination and is decoded without any noise issues we also get it on higher layers of the stack.