<?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>current optimisation in terms of conn interval and slave latency</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/30644/current-optimisation-in-terms-of-conn-interval-and-slave-latency</link><description>Hi 
 
 which is better for reduced current consumption 
 1. lesser value of of MIN_CONN_INTERVAL, MAX_CONN_INTERVAL with large SLAVE_LATENCY 
 2. or vice versa 
 
 Thanks.</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 26 Feb 2018 12:37:13 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/30644/current-optimisation-in-terms-of-conn-interval-and-slave-latency" /><item><title>RE: current optimisation in terms of conn interval and slave latency</title><link>https://devzone.nordicsemi.com/thread/121954?ContentTypeID=1</link><pubDate>Mon, 26 Feb 2018 12:37:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:89e3ff1b-e03d-45e3-835b-0d402c9ffbf1</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Make sense yes.&lt;/p&gt;
&lt;p&gt;A small addition, all data transfer in BLE is reliable on the link layer,&amp;nbsp;ensured by sequence numbers, thereby the difference between write command and write request is mainly handling in application layer. The most common (and efficient) way of sending data is typically&amp;nbsp;through notifications.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: current optimisation in terms of conn interval and slave latency</title><link>https://devzone.nordicsemi.com/thread/121735?ContentTypeID=1</link><pubDate>Thu, 22 Feb 2018 19:02:21 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1c93a7a4-bd38-4764-adf7-66184583eb48</guid><dc:creator>hmolesworth</dc:creator><description>&lt;p&gt;Seems we are all after the same goal :-) My notes so far, indicating &amp;quot;Write Command&amp;quot; is preferable for improved throughput and implicit lower power consumption since repeated receive packet processing is avoided:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;// BLE Packet Transmission
// =======================
// Packet format - see Bluetooth 5.0 spec (was Vol 6, Part B, Section 2.2)
// https://www.bluetooth.com/specifications/bluetooth-core-specification
//
// BLE packets are sent ping-pong fashion, with maximum throughput occurring when Master-&amp;gt;Slave
// packets have no payload
// Packets are separated by the Inter Frame Space (IFS) of 150uSecs
// Note - MIC Encryption field adds 4 bytes, included in timings below
//
// Connection interval: Determines how often the Central queries data from the Peripheral.
//   Peripheral may request an update between between minimum 7.5 ms and maximum 4 sec
// Slave latency: A Non-zero slave latency allows the Peripheral to not answer when the
//   Central asks for data up to the slave latency number of times. However if the Peripheral
//   has data to send it can send data at any time. This enables a peripheral to stay sleeping
//   for a longer time, if it doesn&amp;#39;t have data to send, but still send data fast if needed
// Connection Supervision Timeout: Determines the timeout from the last data exchange untill
//   a link is considered lost. A Central will not start trying to reconnect before the timeout
//   has passed, so a short timeout is preferred for devices often going out of range
//
// &amp;quot;Write Command&amp;quot; is a write without acknowledgement and &amp;quot;Write Request&amp;quot; is write with acknowledgement.
// The ATT will automatically send ack when you transmit write request from the central device. Write
// Command on the client side should generate BLE_GATTS_EVT_WRITE(WRITE_CMD, data) event on the server
//
// An integral number of packets can be sent in each connection interval. Shortest interval
// is 7.5mSecs, longest 4,000mSecs in steps of 1.25mSecs
&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: current optimisation in terms of conn interval and slave latency</title><link>https://devzone.nordicsemi.com/thread/121385?ContentTypeID=1</link><pubDate>Tue, 20 Feb 2018 13:12:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e7d31121-113f-4d10-92f6-74a05ad86236</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;There will be an data exchange every (min_conn_interval * (slave latency + 1)) between the central and peripheral. In general it is preferred to have a low connection interval to allow packets to be sent with short latency when there is data available, but have a large slave latency to sleep and save current consumption when there is no data to be sent.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>