<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Pysense wake on pin enhancements]]></title><description><![CDATA[<p dir="auto">Hi all,</p>
<p dir="auto">The project we work on involves detecting presence in a room with PIR motion detectors coupled with a LoPy and Pysense.</p>
<p dir="auto">We currently use PIRs that can keep the signal high for a configurable duration, which will be extended as further motion is detected, so the signal will only go down after inactivity for that duration.</p>
<p dir="auto">This works pretty well, but there are several issues we're facing:</p>
<ul>
<li>the delay is configured via potentiometers on the PIR, so we cannot adjust it remotely</li>
<li>the max delay is about 10 minutes, which in some scenarios is not necessarily long enough</li>
<li>the PIRs we are using have limited sensitivity and relatively high current consumption compared to other PIRs available on the market. But those &quot;better&quot; PIRs do not have that logic and will just keep the signal high as long as there's actual movement.</li>
</ul>
<p dir="auto">For these reasons, I would like to implement the &quot;stay high for duration X, and extend if further motion is detected&quot; behaviour in software rather than in hardware.</p>
<p dir="auto">Given the pretty high power draw of the LoPy when it is active, we can't just have wake up the LoPy every time there's movement, so I would like to have the Pysense PIC do most of the work. However, we don't have access to the PIC firmware source code (hint, hint). I previously disassembled earlier versions of the firmware for fixes, but it's really time consuming, so I'd rather have you do it (unless you can share the sources).</p>
<p dir="auto">The idea would be to add the following features for wake on pin:</p>
<ul>
<li>expose the following configuration variables:
<ul>
<li>add a setting for a <code>hold</code> duration (in seconds, 16-bit int). 0 means keep the current behaviour</li>
<li>add a setting for a <code>retrigger</code> flag</li>
<li>add settings for <code>wake_on_rise</code> and <code>wake_on_fall</code></li>
</ul>
</li>
<li>add an internal <code>armed</code> flag (initially false)</li>
<li>add an <code>active</code> flag which can be read (this is the &quot;output&quot; of the logic below), initially false</li>
<li>set <code>INTEDG</code> to true</li>
<li>set <code>INTE</code> to true</li>
<li>when <strong>INT</strong> goes up:
<ul>
<li>set <code>INTEDG</code> to false</li>
<li>if <code>active</code> is false:
<ul>
<li>set <code>active</code> to true</li>
<li>if <code>wake_on_rise</code>, trigger LoPy wake up, reason <code>WAKE_REASON_INT_PIN_RISE</code></li>
</ul>
</li>
<li>else:
<ul>
<li>don't change <code>active</code></li>
<li>don't wake up the LoPy</li>
<li>if <code>retrigger</code> is true and <code>hold</code> is non-0
<ul>
<li>cancel the timer</li>
<li>clear <code>armed</code></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>when <strong>INT</strong> goes down:
<ul>
<li>set <code>INTEDG</code> to true</li>
<li>if <code>hold</code> is 0:
<ul>
<li>set <code>active</code> to false</li>
<li>if <code>wake_on_fall</code>, wake-up the LoPy, reason <code>WAKE_REASON_INT_PIN_FALL</code></li>
</ul>
</li>
<li>else if <code>active</code> is true and <code>armed</code> is false:
<ul>
<li>set the timer to <code>hold</code></li>
<li>set <code>armed</code> to true</li>
</ul>
</li>
</ul>
</li>
<li>when the timer expires:
<ul>
<li>set <code>active</code> to false</li>
<li>set <code>armed</code> to false</li>
<li>if <code>wake_on_fall</code>, wake up the LoPy, reason <code>WAKE_REASON_INT_PIN_FALL</code></li>
</ul>
</li>
</ul>
<p dir="auto">The only issue I see is the timer... As far as I understand it, only the WDT and Timer1 are available during the PIC sleep, and I'm not sure which one is used for timer wake-up. If the same timer needs to be shared between timer wake up and the logic above, this will add quite a bit more work to keep both functionalities.</p>
<p dir="auto">Feedback welcome.</p>
<p dir="auto">Thanks!</p>
]]></description><link>https://forum.pycom.io/topic/2800/pysense-wake-on-pin-enhancements</link><generator>RSS for Node</generator><lastBuildDate>Sun, 16 Aug 2026 20:09:11 GMT</lastBuildDate><atom:link href="https://forum.pycom.io/topic/2800.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 08 Mar 2018 12:28:51 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Pysense wake on pin enhancements on Thu, 08 Mar 2018 12:28:51 GMT]]></title><description><![CDATA[<p dir="auto">Hi all,</p>
<p dir="auto">The project we work on involves detecting presence in a room with PIR motion detectors coupled with a LoPy and Pysense.</p>
<p dir="auto">We currently use PIRs that can keep the signal high for a configurable duration, which will be extended as further motion is detected, so the signal will only go down after inactivity for that duration.</p>
<p dir="auto">This works pretty well, but there are several issues we're facing:</p>
<ul>
<li>the delay is configured via potentiometers on the PIR, so we cannot adjust it remotely</li>
<li>the max delay is about 10 minutes, which in some scenarios is not necessarily long enough</li>
<li>the PIRs we are using have limited sensitivity and relatively high current consumption compared to other PIRs available on the market. But those &quot;better&quot; PIRs do not have that logic and will just keep the signal high as long as there's actual movement.</li>
</ul>
<p dir="auto">For these reasons, I would like to implement the &quot;stay high for duration X, and extend if further motion is detected&quot; behaviour in software rather than in hardware.</p>
<p dir="auto">Given the pretty high power draw of the LoPy when it is active, we can't just have wake up the LoPy every time there's movement, so I would like to have the Pysense PIC do most of the work. However, we don't have access to the PIC firmware source code (hint, hint). I previously disassembled earlier versions of the firmware for fixes, but it's really time consuming, so I'd rather have you do it (unless you can share the sources).</p>
<p dir="auto">The idea would be to add the following features for wake on pin:</p>
<ul>
<li>expose the following configuration variables:
<ul>
<li>add a setting for a <code>hold</code> duration (in seconds, 16-bit int). 0 means keep the current behaviour</li>
<li>add a setting for a <code>retrigger</code> flag</li>
<li>add settings for <code>wake_on_rise</code> and <code>wake_on_fall</code></li>
</ul>
</li>
<li>add an internal <code>armed</code> flag (initially false)</li>
<li>add an <code>active</code> flag which can be read (this is the &quot;output&quot; of the logic below), initially false</li>
<li>set <code>INTEDG</code> to true</li>
<li>set <code>INTE</code> to true</li>
<li>when <strong>INT</strong> goes up:
<ul>
<li>set <code>INTEDG</code> to false</li>
<li>if <code>active</code> is false:
<ul>
<li>set <code>active</code> to true</li>
<li>if <code>wake_on_rise</code>, trigger LoPy wake up, reason <code>WAKE_REASON_INT_PIN_RISE</code></li>
</ul>
</li>
<li>else:
<ul>
<li>don't change <code>active</code></li>
<li>don't wake up the LoPy</li>
<li>if <code>retrigger</code> is true and <code>hold</code> is non-0
<ul>
<li>cancel the timer</li>
<li>clear <code>armed</code></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>when <strong>INT</strong> goes down:
<ul>
<li>set <code>INTEDG</code> to true</li>
<li>if <code>hold</code> is 0:
<ul>
<li>set <code>active</code> to false</li>
<li>if <code>wake_on_fall</code>, wake-up the LoPy, reason <code>WAKE_REASON_INT_PIN_FALL</code></li>
</ul>
</li>
<li>else if <code>active</code> is true and <code>armed</code> is false:
<ul>
<li>set the timer to <code>hold</code></li>
<li>set <code>armed</code> to true</li>
</ul>
</li>
</ul>
</li>
<li>when the timer expires:
<ul>
<li>set <code>active</code> to false</li>
<li>set <code>armed</code> to false</li>
<li>if <code>wake_on_fall</code>, wake up the LoPy, reason <code>WAKE_REASON_INT_PIN_FALL</code></li>
</ul>
</li>
</ul>
<p dir="auto">The only issue I see is the timer... As far as I understand it, only the WDT and Timer1 are available during the PIC sleep, and I'm not sure which one is used for timer wake-up. If the same timer needs to be shared between timer wake up and the logic above, this will add quite a bit more work to keep both functionalities.</p>
<p dir="auto">Feedback welcome.</p>
<p dir="auto">Thanks!</p>
]]></description><link>https://forum.pycom.io/post/16878</link><guid isPermaLink="true">https://forum.pycom.io/post/16878</guid><dc:creator><![CDATA[jcaron]]></dc:creator><pubDate>Thu, 08 Mar 2018 12:28:51 GMT</pubDate></item></channel></rss>