Hello All, Can I just burst If there are restrictions, are there any hard numbers? https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf Thanks. Karel [Quote for today:"You can tell I'm a hardware designer, can't you"] _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com I am developing code on the Texas Instruments CC2540. The LE stack which comes free with the chip has a restriction of only being able to send 4 packets per Connection Event Transmit Window (regardless of window size), which in most cases ends up giving me just 3 notification packets per connection interval. If I were to change chips or if TI were to be so generous as to increase our allotment of packets, are there any similar restrictions in the (client side) Apple software which would restrict a peripheral from sending transmit windows chock-a-block full of packets? Now, from the Apple Client side, are there any similar restrictions for number of packets? [p writeValue:data forCharacteristic:characteristic type:CBCharacteristicWriteWithoutResponse]; and have all the data magically crammed into each window, and miraculously interleaved with a spray of notifications from the server side, whilst ample buffering in the voluminous iPhone4S memory banks provide a safe haven for those yet unsent packets? Or Is it more like, WriteWithoutResponse types of packets are just tossed at the slightest sign of any other type of traffic, best not to use them, and I don't know how they crept into the spec. anyway etc etc. Or are there any guidelines as for example the guidelines regarding min/max connection interval settings in where we engineers can get a warm and fuzzy handle on the Apple algorithm approach.