<?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>nRF5340 - real-time time capture</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/74883/nrf5340---real-time-time-capture</link><description>Hi, on nRF5340 I want to capture accurate timing of external events. I need a kind of real-time capture module to read the time period of a pulse train generated by a rotating turbine. The minimum period is 200 us. The time resolution of 10-20 us is acceptable</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 11 May 2021 07:26:22 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/74883/nrf5340---real-time-time-capture" /><item><title>RE: nRF5340 - real-time time capture</title><link>https://devzone.nordicsemi.com/thread/309117?ContentTypeID=1</link><pubDate>Tue, 11 May 2021 07:26:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:14821afc-1483-43f6-8afc-f43370a7e6ad</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Now I see. I was mostly focusing on the first line of your question, if you get a quadrature encoded signal which you typically get from something measuring rotation, then QDEC is definitely sensible.&lt;/p&gt;
&lt;p&gt;Regarding the QDEC on the nRF53 that is at least partially supported in NCS master. There,&amp;nbsp;HAS_HW_NRF_QDEC0 is defined, and that is equivalent with&amp;nbsp;HAS_HW_NRF_QDEC (See &lt;a href="https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_NRFX_QDEC.html?highlight=has_hw_nrf_qdec0#cmdoption-arg-CONFIG_NRFX_QDEC"&gt;CONFIG_NRFX_QDEC&lt;/a&gt;).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF5340 - real-time time capture</title><link>https://devzone.nordicsemi.com/thread/309013?ContentTypeID=1</link><pubDate>Mon, 10 May 2021 14:00:02 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6f70b5da-7944-4659-8749-101e8236984a</guid><dc:creator>Gabriele</dc:creator><description>&lt;p&gt;Thank you Einar.&lt;/p&gt;
&lt;p&gt;The aim is to measure instant flow and volume of air.&lt;br /&gt;Our encoder is a low inertial vane rotating in between two swirl plates deflecting the air entering the air flow path and converting the linear airflow into a helical flow. The vane angular velocity is proportional to the flow and is detected by the interruption of a pair of infrared beams.&lt;br /&gt;Thus we have two signals which are pulse trains in quadrature.&lt;br /&gt;The frequency of each pulse train is therefore proportional to the air flow and the number of pulses is proportional to the volume.&lt;/p&gt;
&lt;p&gt;QDEC is ready-made to immediately deliver the volume by counting pulses, with automatic&amp;nbsp;adjust of count direction upon reversing of flow.&lt;br /&gt;The approach you suggest is measuring the flow, by assessing time between consecutive pulses.&lt;br /&gt;At first glance I would say it is more complicated, for the fact that you have to use three objects (GPIOTE, TIMER, DPPI) instead of one (QDEC).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF5340 - real-time time capture</title><link>https://devzone.nordicsemi.com/thread/308970?ContentTypeID=1</link><pubDate>Mon, 10 May 2021 12:33:17 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8a0662cf-bf7a-4197-b888-a747c9542bcf</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Just out of curiosity, why does using QDEC make sense in this case? You would normally use GPIOTE and a TIMER hooked up via DPPI in such cases, for instance as shown &lt;a href="https://github.com/sigurdnev/ncs-playground/blob/master/samples/pulse_detector/src/main.c"&gt;here&lt;/a&gt; (some minor adjustments are needed for the nRF53140).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF5340 - real-time time capture</title><link>https://devzone.nordicsemi.com/thread/308899?ContentTypeID=1</link><pubDate>Mon, 10 May 2021 09:06:17 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b2af5ff6-e833-4a38-8eee-876bbd0087a1</guid><dc:creator>Gabriele</dc:creator><description>&lt;p&gt;Hi,&lt;br /&gt;I think nRF5340&amp;rsquo;s QDEC peripheral could be great to solve my problem.&lt;br /&gt;From&amp;nbsp;&lt;a href="https://docs.zephyrproject.org/latest/reference/devicetree/bindings/sensor/nordic%2Cnrf-qdec.htm"&gt;link&lt;/a&gt;&lt;br /&gt;I see Zephyr manages the quadrature decoder.&lt;/p&gt;
&lt;p&gt;The next question is how to activate it under NCS 1.5.1 ?&lt;br /&gt;I&amp;rsquo;ve enabled CONFIG_QDEC_NRFX in prj.conf, and put the following definition in dts overlay&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;&amp;amp;qdec {
    status = &amp;quot;okay&amp;quot;;
    a-pin = &amp;lt;3&amp;gt;;
    b-pin = &amp;lt;28&amp;gt;;
    enable-pin = &amp;lt;30&amp;gt;;
    led-pin = &amp;lt;0xFFFFFFFF&amp;gt;;
    led-pre = &amp;lt;0&amp;gt;;
    steps = &amp;lt;24&amp;gt;;
};&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;Build fails in parsing the input tree.&lt;br /&gt;From&amp;nbsp;&lt;a href="https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_HAS_HW_NRF_QDEC.html#cmdoption-arg-CONFIG_HAS_HW_NRF_QDEC"&gt;link&lt;/a&gt;&lt;br /&gt;I read nRF5340 is not listed among the SoC allowed to enable HAS_HW_NRF_QDEC.&lt;/p&gt;
&lt;p&gt;Is there a way to use QDEC on nRF5340 ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>