I seem to have largely resolved the reception issues I was experiencing.<br><br>The essential solution is to set the RX FIFO almost full threshold to 55 and re-organise the rate of calling of PollIO to at least every 10ms. This combination ensure everything is received whilst polling is just fast enough to ensure the RX FIFO does not overflow.<br><br>With these settings I am now getting runs with NO receive errors even with more frequent receptions.<br><br>As soon as I have time I will forward my gash code. This has further enhancements to nap30andPoll to poll slow whilst listening and fast whilst receiving. You will probably need to tidy my changes up.<br><br>Regards Gary<br>
<br>
<blockquote>
----Original Message----<br>From: dhd@exnet.com<br>Date: 12/07/2015 14:06<br>To: "Closed list for developer discussions"<opentrv-dev@lists.opentrv.org.uk><br>Subj: Re: [OpenTRV-dev] Residual Receive Strangeness<br><br>Hi,<br><br>> On 12 Jul 2015, at 12:58, Gary Gladman <gary@gladman.name> wrote:<br>> <br>> Ultimately, the RX FIFO cannot be allowed to overflow by staying in receive too long once a preamble and sync has been seen as the FIFO (over) fills (and corrupts) until RX mode is exited it seems.<br>> <br>> RX Polling may simply be the wrong approach.<br><br>I’m sure that ultimately an interrupt-drivem approach may have to be adopted<br><br>The new RFM69 series that we will need to move to (RFM23B is EL) may have different ergonomics in this area too.<br><br>Rgds<br><br>Damon<br>_______________________________________________<br>OpenTRV-dev mailing list<br>OpenTRV-dev@lists.opentrv.org.uk<br>http://lists.opentrv.org.uk/listinfo/opentrv-dev<br><br></blockquote><br>