<?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>Low latency, low power mode for interrupt-driven wearable</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/105772/low-latency-low-power-mode-for-interrupt-driven-wearable</link><description>We have a wearable that performs real-time operations on data streaming from an array of magnetic sensors where the data stream is initiated by the asynchronous presence of a permanent magnet which causes an interrupt to the CPU. We need to capture the</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 20 Nov 2023 15:21:00 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/105772/low-latency-low-power-mode-for-interrupt-driven-wearable" /><item><title>RE: Low latency, low power mode for interrupt-driven wearable</title><link>https://devzone.nordicsemi.com/thread/456499?ContentTypeID=1</link><pubDate>Mon, 20 Nov 2023 15:21:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:daf51d9e-a92d-4dc8-a132-05cb73fc5b68</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;When you need to maintain a BLE connection, the only viable low-power mode (and the one that is by far most used) is system ON low power mode. In this mode, the CPU enters sleep (wait for event), and most peripherals are disabled, but the RTC keeps running for time keeping. In the nRF5 SDK, this mode is entered by calling&amp;nbsp;sd_app_evt_wait(), either directly or often via&amp;nbsp;nrf_pwr_mgmt_run(). This is done by most if not all BLE examples in the SDK.&lt;/p&gt;
&lt;p&gt;Note that the SDK examples enable UART logging, and this will prevent low power (keeping the HF clock running etc), so in order to test power consumption you should disable logging.&lt;/p&gt;
&lt;p&gt;To enable constant latency mode&amp;nbsp;(increasing power consumption) you can enable that with&amp;nbsp;&lt;code&gt;sd_power_mode_set(NRF_POWER_MODE_CONSTLAT)&lt;/code&gt; after enabling the SoftDevice. (or using&amp;nbsp;&lt;code&gt;NRF_POWER-&amp;gt;TASKS_CONSTLAT = 1;&lt;/code&gt; if testing without SoftDevice).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Low latency, low power mode for interrupt-driven wearable</title><link>https://devzone.nordicsemi.com/thread/456257?ContentTypeID=1</link><pubDate>Fri, 17 Nov 2023 23:50:26 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:50e0a6e9-a90f-40c4-b4c4-0f5445f87dfe</guid><dc:creator>apdobaj</dc:creator><description>&lt;p&gt;And one thing in particular, what sort of low power modes are available when you need to maintain a BTLE connection?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Low latency, low power mode for interrupt-driven wearable</title><link>https://devzone.nordicsemi.com/thread/456228?ContentTypeID=1</link><pubDate>Fri, 17 Nov 2023 16:54:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:565a88c3-7198-4d69-8a47-dd5d39bd7be6</guid><dc:creator>apdobaj</dc:creator><description>&lt;p&gt;OK, great, I can do that but first I need some information about how to programmatically using the 17.1 SDK get the device into the low power low latency mode in the first place. Can you please point me to where this is explained?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Low latency, low power mode for interrupt-driven wearable</title><link>https://devzone.nordicsemi.com/thread/456140?ContentTypeID=1</link><pubDate>Fri, 17 Nov 2023 11:41:56 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f8fa51da-dd87-4a70-91e3-d927ce528bbe</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;You can find most relevant numbers at the end of the&amp;nbsp;&lt;a href="https://infocenter.nordicsemi.com/topic/ps_nrf52840/power.html?cp=5_0_0_4_2_7_2#unique_1752780615"&gt;Device startup times table&lt;/a&gt;. &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/57002/interrupt-capture-time-on-high-and-low-accuracy-using-gpio/231320"&gt;This post&lt;/a&gt; is also relevant. A key point is that the interrupt latency is depends on several factors, so it makes sense to test your configuration with a logic analyzer to see that the actual numbers are close to what you would expect (and within your requirements).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>