I'm running the following test:
- initialize BLE in peripheral role, set up GATT database (off chip), make discoverable
- wait for connection, set up bonding, exchange keys, turn on encryption
- update connection parameters to 7.5 ms interval
- wake up every 36 ms
- send 20 byte notification on attribute 5 (the packet contains a timestamp and a packet counter)
- send 20 byte notification on attribute 6 (the packet contains a timestamp and a packet counter)
- send 20 byte notification on attribute 7 (the packet contains a timestamp and a packet counter)
- periodically on the master request the packet error status
- end the connection after 5 minutes
- on the central device, measure latency and count how many packets are received
I am observing the following:
PER stats
RX Pkts: 44536 RX CRC Fails : 1000 PER: 2.25%
Events : 40047 Missed Events: 5594
Missed packets:
0005: 148 (last: 8309)
0006: 314 (last: 8309)
0007: 743 (last: 8309)
I would have expected that packets carrying notifications for 5, 6, 7 to have an equal chance of 'crc error'. But what I am observing is that the 'survival rate' decreases logarithmically!
The packets are sent back-to-back using SPI. The 'command complete' event for the first notification is received 5.5 ms later, the 'command complete' for the second notification 3 ms after that and the third one 4.8 ms after that. Between sending the first notification and receiving the last status, there are 14 ms.
How much processing does CC2541 do on a notification packet? Reading the wiki and the forums, it should be able to send three data packets every 7.5 ms interval.