<?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>Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/104612/switch-to-lfxo-after-booting-and-starting-ble-with-lfrc</link><description>Our application requires that we boot and start advertising within about 60-70 ms. When we have the LFXO set as our LF clock source we fail to meet this requirement due to the start up time of the crystal. I read on another post that it is possible to</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 16 Oct 2023 07:50:50 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/104612/switch-to-lfxo-after-booting-and-starting-ble-with-lfrc" /><item><title>RE: Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/thread/450456?ContentTypeID=1</link><pubDate>Mon, 16 Oct 2023 07:50:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:12afa17a-09d8-4dcd-8c20-edbfd91429f6</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;You welcome, the best of luck with your project &lt;span class="emoticon" data-url="https://devzone.nordicsemi.com/cfs-file/__key/system/emoji/1f642.svg" title="Slight smile"&gt;&amp;#x1f642;&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/thread/450369?ContentTypeID=1</link><pubDate>Fri, 13 Oct 2023 15:45:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:32d175ee-d805-4584-a37b-35ab0e71c5e4</guid><dc:creator>jrhaws</dc:creator><description>&lt;p&gt;Thanks for the help. I think we&amp;#39;ll just stay with the LFRC then and go from there.&amp;nbsp; Thanks!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/thread/450203?ContentTypeID=1</link><pubDate>Fri, 13 Oct 2023 07:35:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1c190708-d355-48a7-bda1-73c7b9f45da3</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi Jon&lt;/p&gt;
&lt;p&gt;It is true that&amp;nbsp;the CLOCK module supports changing the LF clock source from one source to the next dynamically, but that will leave you without an LF clock source for the same amount of time,&amp;nbsp;you will just be able to schedule it later on. Essentially you would have to disable all BLE activity, change the clock source, and then re-enable it again. I am also not sure if this is properly supported in the nRF Connect SDK, but possibly you are still using the nRF5 SDK that is referenced in the old ticket?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;The external LF clock source is more accurate, true, but the Bluetooth stack is designed to accommodate both accurate and less accurate clock sources. When using the internal LF clock source it will run an automatic calibration scheme that ensures the accuracy is at least 500ppm or better, which is sufficient for the Bluetooth stack.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;In advertise mode there is no impact, as there is no need for an accurate clock in this mode. In connected mode the impact is a modest increase in average current, as the link layer needs to increase the receive window to account for higher clock drift. This is most notable when trying to run long connection intervals with very low average currents, as the potential clock drift is larger when the connection interval is larger.&amp;nbsp;&lt;br /&gt;To get a feel for the difference in average current you can try out different settings using the &lt;a href="https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le"&gt;Online Power Profiler&lt;/a&gt;.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I am not quite sure about the comment about the firmware guys thanking you.&amp;nbsp;Selecting internal LF source should be as simple as setting some configuration settings, and the Bluetooth stack and the clock library will handle the rest.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Best regards&lt;br /&gt;Torbjørn&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/thread/450117?ContentTypeID=1</link><pubDate>Thu, 12 Oct 2023 15:22:16 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:0a985522-e4dd-41a9-acd3-c2c2d4b39906</guid><dc:creator>jrhaws</dc:creator><description>&lt;p&gt;Here is the link:&amp;nbsp;&amp;nbsp;&lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/21020/nrf52832---how-to-reduce-initialization-time"&gt;nRF52832 - how to reduce initialization time&lt;/a&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I am running okay with the LFRC, but my understanding was the LFXO would provide better, more stable performance. Is that not correct?&amp;nbsp;I&amp;#39;m told by our hardware designers that they were directed to use an external oscillator by the Nordic FAEs because &amp;quot;your firmware guys will thank you&amp;quot;. :/&amp;nbsp; The thing is, the external crystal startup time is WAY too slow!&amp;nbsp; If there is a way to&amp;nbsp;easily switch so we have the better clock that would be great, but it sounds like that isn&amp;#39;t really supported.&lt;/p&gt;
&lt;p&gt;Thanks!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Switch to LFXO after booting and starting BLE with LFRC</title><link>https://devzone.nordicsemi.com/thread/450043?ContentTypeID=1</link><pubDate>Thu, 12 Oct 2023 11:56:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:341c5f55-1680-461f-bbb9-04c1faf7a43f</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi Jon&lt;/p&gt;
&lt;p&gt;I am not sure the nRF52 clock system supports transparent handover from one LF clock source to the next, like it does for the HF clock.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Normally you only need to start the LF clock after a power reset, which should happen very rarely in the lifetime of the application.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Do you have a link to the case where it was mentioned that this was supported?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Is there any particular reason you can&amp;#39;t just run from&amp;nbsp;the internal LF clock source all the time?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Best regards&lt;br /&gt;Torbjørn&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>