So the 7 ms timer is purely the "data generator" and in reality has nothing to do with the transmission.
The buffer check will see to it that only the messages that can be queued up is in fact queued up each connection event.
"This is example modification of CC2540 SimpleBLEPeripheral application to measure user data throughput. Initial testing shows we can reach 5.9K bytes per second. This is using a 10ms connection interval and 20 user data bytes sent in GATT notifications. 4 notifications are sent every 7ms, based on an OSAL timer. When sending the notifications, a check is made to see if a buffer is available. In all, 1000 notifications are sent. This is 20K bytes, which are sent over 3.35 seconds. "
I think I have understood the setup now;
- The connection interval in the given setup is 10 ms (stated in the text).
- The number of notifications transmitted per connection event is 3, not 4, this is backed up by the screenshot that shows blocks of three small (ack?) and three big (data?) messages.
- If we use these values when calculating we get that 3,35 sec should allow for 335 connection events, allowing 1005 notifications (the last 5 are due to lost packets I guess?).
Now why 3 notifications instead of 4? Does this again point back to the buffer check? Is it possible that the buffers are to small to hold four frames with 20 bytes payload?
- From the "CC253X and CC2540-41 User guide" I find that "FIFO full is defined as the length being 128" , according to the "Tx FIFO Packet Organization" each packet in the FIFO should include one byte indicating length, 0-1 byte address and 0-1 byte config, plus payload, so the messages in the example should take up a maximum of 23 bytes in the FIFO. This would allow five frames to be added to the FIFO before the buffer is too full to handle more frames.. Unless I have misread something that is..?!
Let's say that the system generates four frames but can only fit three into the buffers before each connection event, some frames are lost in transmission and the overall throughput is the stated 5.9K bytes.
- If we had decreased the payload enough we should be able to fit the maximum 4 frames into each connection event, and could also be able to decrease the connection interval to the minimum 7,5ms?
I guess the throughput under those circumstances would be lower, since more frames would increase the portion of overhead.. But if we count the number of notifications rather than payload this should allow for a much higher number of messages in total?
