How much and how fast you can send data will depend on your connection interval and how long it takes to transfer samples between microcontrollers. Assuming a pretty fast connection between the BCM BLE module and the Data Acquisition Microcontroller (I recommend looking into the SPI (spiffy) interface for this... and for iPhone you can get connection interval of 30 msec (I hear 7.5 msec is possible with other devices). Maybe iPhone allows 20 now(?).. but from experience, with a 30 msec connection interval, if you keep the transmit queue at least half full and have a data payload of about 20 bytes per packet (23 is the max possible I think), you might be able to get 100 packets per second to the iPhone... or about 2 K Bytes per second payload transfer. I think this is the upper limit, at least with an iPhone. With a shorter connection interval (7.5 to 20 msec?) you might get more, but I doubt it. I think 2K is about at the theoretical limit, although I don't really know for sure...anyway at that point you should consider standard Bluetooth instead of BLE. The BLE Architecture is specifically designed for the non-streaming applications.
You also have to consider that if the iPhone (or other master) is busy with other tasks, it may not allow your device to have the 30 or 20 msec interval that you ask for. You might get something less, or you might just get a disconnect if the rate your device asks for is not available or disallowed.
Also, with so much activity going on and the fact that you cannot synchronize the connection events with the application thread (they run on independent clocks or schedulers).. your data acquisition activity might occasionally (or frequently) interfere with the connection activity. There is a feature in SDK 2.2.1 that is supposed to allow your application to get an advance notification of an upcoming connection event, but after a day or two of trying I gave up and concluded that it doesn't work as advertised, or at best, it is non-trivial to get it to work.. In that case the best you can do is to try to set up your connection events and acquisition events so that they collide infrequently and when they do the collisions don't persist for longer than your slave latency allows.
Thanks Eric, great explanation!