I have now seen larger JSON messages so the RX FIFO almost full threshold has been adjusted to 56 bytes.<br><br>The code adjustments made seem to be working very well with almost perfect packet transfer with the following largely understood issues (in frequency order)<br>o with eavesdropping disabled periodically then RX listening and thus RX reception does not occur as expected<br>o during FHT8V SYNC then loop overrun can occur whilst debug reporting !RXerr - only seen while test TX active at leaf (test TX reception reported as !RXerr) seems to cause no practical problems<br>o rare (2): RX FIFO overrun observed (first/1 byte corrupt) - probably associated with intrinsic imperfect/irregular pollIO invocation<br>o rare: receptions not seen by RFM22/3B - not well understood could be due to TX issues, not in listening state (for whatever reason) when TX occurs, RFM22/23B issue, or RF issues (unlikely - still very little evidence of RF corruption unless thisis it :) ) <br>o very rare: LBT activation<br>o very rare: TX packet sent failure (assume RFM22/23B issue)<br>o very very rare (1): !RXerr F3 observed and undiagnosed<br><br>I have attached the (hack) code changes I have made - they are free for others to use. I think this is as far as I can take this until suitable changes are made to the main line. My detailed understanding of OpenTRV is not perfect so their ramifications should be considered. I apologise for the hackiness - I have no control of the code line and thus it makes no sense to over invest in what is effectively dead experimental branch development.<br><br>There are various log files from various stages of investigation - 15 07 18 Transceive Working.txt reflects a log taken from the attached code with the leaf still test TXing - missing transmissions are due to periodic disabling of eavesdropping IMHO as prior to this with eavesdropping hacked to "continuously" reception was perfect.<br><br>Once again I hope this helps.<br><br>Aside: The library work Damon is producing is looking very good (sourceforge access permitting).<br><br>Regards Gary<br><br>
<blockquote>
----Original Message----<br>
From: gary.gladman@talktalk.net<br>
Date: 13/07/2015 21:44<br>
To: <opentrv-dev@lists.opentrv.org.uk><br>
Subj: Re: [OpenTRV-dev] Residual Receive Strangeness<br>
<br>
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>></blockquote></blockquote>