<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>How to send large data through BLE notification using nrf52832</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/24094/how-to-send-large-data-through-ble-notification-using-nrf52832</link><description>Hi everyone, 
 I am writing a program in Keil whereby I have to send a large amount of data through BLE notification in real time. The program works by having two timers, one timer is used for the ADC to sample at 400Hz, so every 2.5ms, the other timer</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Sat, 05 Aug 2017 10:50:07 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/24094/how-to-send-large-data-through-ble-notification-using-nrf52832" /><item><title>RE: How to send large data through BLE notification using nrf52832</title><link>https://devzone.nordicsemi.com/thread/94867?ContentTypeID=1</link><pubDate>Sat, 05 Aug 2017 10:50:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:66812e9f-d877-49df-b1ab-7169dbff788b</guid><dc:creator>endnode</dc:creator><description>&lt;p&gt;Hi Bryan,&lt;/p&gt;
&lt;p&gt;Throughput of 4800 Bytes per second can be challenging when not controlling one part of the link (= if you want to use phone or similar &amp;quot;black&amp;quot; box with incomplete API to lower BLE layers). Most of Android devices use ~50ms connection interval when in GAP Central (master) role and even they usually support multiple MTUs per interval (let&amp;#39;s say 6) not all of them accept extension of basic ATT_MTU size (which gives you effective space of 20B per &amp;quot;packet&amp;quot;) or lowering the interval to 7.5-20ms range where you want it to be. So assuming any &amp;quot;dumb&amp;quot; cheap Android phone will give you 1000/50&lt;em&gt;20&lt;/em&gt;6=2600Bps in ideal case of no packet loss and re-transmission. As you see only with good phones where you can lower the interval or extend ATT_MTU size to be able to send more then 120B per 50ms you can get more but at the range of ~5000Bps you will definitely have problem to make it outside range of pre-selected &amp;quot;flag ship&amp;quot; devices (e.g. iPhones support today ATT_MTU size of at least ~150B and they will use connection interval of 30ms but it&amp;#39;s question how many of such long MTUs will squeeze into one interval).&lt;/p&gt;
&lt;p&gt;I would definitely start with pure feasibility of your BLE connection throughput where you &amp;quot;stream&amp;quot; just dummy strings to see what are the ideal ATT_MTU and LL PRU sizes (these are properties of nRF52 stack you need to provision basically during compile time because of RAM allocation) and how low with connection interval you can go through Peripheral Connection Parameters Update Request procedure (this is more &amp;quot;per connection&amp;quot; thing). Finally you will need to evaluate it on as many &amp;quot;reference&amp;quot; phones as possible, especially if you want to market it later to general consumers. Once you find optimal values then you will see how you need to fragment your stream of ADC samples (or other data). As these are basically continuous in you case you should be free to go from 20-byte up to thousand-bytes packets as needed.&lt;/p&gt;
&lt;p&gt;Cheers Jan&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>