I'm worried.<br><br>My understanding was that the problem was fundementally caused by the addition of the JSON messages without adjusting the RX FIFO almost full threshold accordingly. My investigation worked bottom up - I pragmatically adjusted the threshold until all messages (i.e. FHT8V + stats, and JSON) were received correctly. I did not select the threshold based on theoretic message lengths. I saw no JSON messages that were larger than 55 bytes so the threshold identified seemed to be consistent and thus make sense. There is an interplay with the polling rate which means that any threshold that is to low could by compensated for by the polling rate meaning that longer messages could still practically be received correctly and consistently.<br><br>In theory the threshold should be set to the size of the maximum possible message to be received. Shorter messages will trigger the threshold once sufficient post message noise is received. Longer messages will trigger the threshold before the message receive is complete but the polling period may still allow sufficient extra time for the remaining bytes to be received thus allowing the whole message to be received succesfully before the receive is terminated.<br><br>If I am wrong about the max size of received messages e.g. JSON stats are longer than 55 then the threshold probably needs to be increased accordingly but practically this is a balancing act between threshold, poll rate, and buffer overrun.<br><br>Reading some of the other discussions then tighter control of Tx time may be a sensible change as well as in any case this should/could reduce the duty cycle by not allowing the Tx to overrun which is probably happening currently.<br><br>Regards Gary<br>
<br>
<blockquote>
----Original Message----<br>From: dhd@exnet.com<br>Date: 13/07/2015 11:32<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>Wow, oh wow!   Many thanks!<br><br>That’s particularly good to know for boards such as the REV1 with no interrupt available.<br><br>Now, how does that interact with variable length frames such as the JSON stats which can easily be either side of 55 bytes?<br><br>Rgds<br><br>Damon<br><br><br>> On 12 Jul 2015, at 23:14, gary.gladman@talktalk.net wrote:<br>> <br>> 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>> ----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>> <br>> _______________________________________________<br>> OpenTRV-dev mailing list<br>> OpenTRV-dev@lists.opentrv.org.uk<br>> http://lists.opentrv.org.uk/listinfo/opentrv-dev<br><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>