<?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>Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/20685/timer-drift-clarification</link><description>Working with nRF52832 and SD132-v2.0.1 
 Using external 32.768kHz xtal in addition to 32MHz xtal. 
 I realize there are a lot of posts about timers, but I didn&amp;#39;t find any posts that answered my question(s). 
 I&amp;#39;m using a timer running at 1MHz to generate</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 10 May 2017 13:38:43 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/20685/timer-drift-clarification" /><item><title>RE: Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/thread/80690?ContentTypeID=1</link><pubDate>Wed, 10 May 2017 13:38:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:65797816-5181-4de7-84a4-971fea6eea87</guid><dc:creator>Sigurd</dc:creator><description>&lt;p&gt;Hi again,&lt;/p&gt;
&lt;p&gt;You should set the &lt;code&gt;NRF_CLOCK_LF_XTAL_ACCURACY_XX_PPM&lt;/code&gt; to match the PPM of the crystal you are using. The SoftDevice uses this information in calculating how long the BLE TX/RX windows should be. In order to measure the drift you should do this 100% in hardware (using ppi/gpiote to toggle a GPIO) and with a oscilloscope.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/thread/80688?ContentTypeID=1</link><pubDate>Tue, 28 Mar 2017 15:59:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:db549aec-8ead-4fe4-9d76-7ad085c07044</guid><dc:creator>jpelo</dc:creator><description>&lt;p&gt;thank you for the followup. i&amp;#39;m using external xtals for both. one thing i did notice when checking this is i&amp;#39;m setting the accuracy to NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM when i init/enable softdevice which could explain the additional drift -&amp;gt; need to source why this was set loose (since this tolerance covers a temp range for the xtal beyond what we need/expect). the information on how this is used to calculate the timing windows is very sparse (in terms of determining how this adds) - have you seen a good explanation of how this is used? in terms of the code snippet, its not easily postable -&amp;gt; sampling at 100hz and adding a timestamp from rtc to sample data on sample - i get in/out of int handler in plenty of time and i could expect some jiggle of the timestamp but in trends repeatable at ~1ms/11s.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/thread/80687?ContentTypeID=1</link><pubDate>Tue, 28 Mar 2017 11:49:06 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ccc68bab-ac47-479d-b52e-2670efb67995</guid><dc:creator>Sigurd</dc:creator><description>&lt;p&gt;Since you are in practice measuring the relative drift between the two crystals, a worst-case scenario is that 32K is at +20ppm, 32M is at -40ppm, so you get 60 ppm drift, but 90ppm seems high. Are you sure that HFCLK(TIMER) uses the external 32MhHz crystal, and that the LFCLK(RTC) uses the 32k external crystal? Check the CLOCK register, LFCLKSTAT SRC and HFCLKSTAT SRC. If both are correct, could you post the code that you use to measure the drift ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/thread/80686?ContentTypeID=1</link><pubDate>Tue, 28 Mar 2017 06:23:26 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:340ee663-4c15-4a37-a0b0-b46a0532b7a0</guid><dc:creator>jpelo</dc:creator><description>&lt;p&gt;thanks for the response Sigurd. yeah, i&amp;#39;m calculating the same (~90ppm) which is why i asked the question. i&amp;#39;m measuring my drift based on rtc ticks vs us timer ticks (time stamp from rtc). 32k is 20ppm. unfortunately im using a module so dont have direct access to the 32M inside, but assume its 40ppm or less. considering the latency of up to 1/16M and the 2 xtal tolerances, in absence of error this is possible?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Timer Drift Clarification</title><link>https://devzone.nordicsemi.com/thread/80689?ContentTypeID=1</link><pubDate>Mon, 27 Mar 2017 07:37:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1eae5802-41dd-447b-94f7-2467a82d234c</guid><dc:creator>Sigurd</dc:creator><description>&lt;p&gt;So with a 1ms drift every 11s, that’s about ~90 ppm frequency drift. Yes, Shorts should not require CPU activity. External crystals have often have similar PPM, and are therefore not calibrated against each other. The internal RC oscillator on the other hand is normally calibrated against the HFCLCK.&lt;/p&gt;
&lt;p&gt;What PPM do you have on your crystals? How do you measure the drift?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>