<div><div class="gmail_quote">On Wed, May 11, 2011 at 8:33 AM, Sebastian Peschko <span dir="ltr"><<a href="mailto:speschko@gmail.com">speschko@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
Moy,<br>
question for you: Is there a general parameter in the mfcR2 where 'glitches' like the one here can be filtered or ignored? For example: a change in signal (like in this case 0x04 to 0x00 to 0x04) in less than 50 or 100 milliseconds would not make a change unless the new state is active for longer than this number of ms.<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody><tr>
<td>
</td></tr></tbody></table></div></blockquote><div><br></div><div>You can try using the advanced protocol file. See sample for details, the advanced parameter is timers.cas_persistence_check=100<div><br></div><div>That will not react on CAS signals immediately, but wait 100ms, if the signal persist it will handle it, otherwise will ignore it (if the signal gets back to the previous state). I have not tested that parameter in a while but should still work.</div>
<div><br clear="all">Moises Silva<br>Senior Software Engineer, Software Development Manager<br>Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada<br>t. 1 905 474 1990 x128 | e. <a href="mailto:moy@sangoma.com" target="_blank">moy@sangoma.com</a><br>
<br><br></div></div></div></div>