Hi,<br><br>I am now confident that I have evidence that receive overrun is the primary cause of !RXerr F2.<br><br>Regards Gary<br>
<br>
<blockquote>
----Original Message----<br>
From: gary.gladman@talktalk.net<br>
Date: 11/07/2015 19:53<br>
To: <opentrv-dev@lists.opentrv.org.uk><br>
Subj: [OpenTRV-dev] Residual Receive Strangeness<br>
<br>
Hi<br><br>I have been investigating and trying to resolve a number of receive transmit issues.<br><br>I have made a number of changes to both resolve and investigate (latest changes attached including a log file as examples/evidence of what is still being observed with relevant logging is enabled).<br><br>I have implemented Listen Before Transmit (LBT) for JSON statistics. Practically in my two node system (boiler/hub, leaf) LBT activates rarely if at all.<br><br>Overall I beleive the system is now operating better with more regular results, but my testing is limited to my system and mode of use, and I still see inexplicably bad runs so I cannot guarantee the changes - your mileage may vary.<br><br>I continue to observe residual corrupt receptions which IMHO demonstrate
damage of a systematic rather than random nature which implies to me a
system implementation rather than an RF noise cause. The changes I have
made do seem to have resolved/regularised some of these issues which
reinforces the view that there is an underlying systematic rather than
noise concern.<br><br>Corrupt receptions are still seen and IMHO still massively imply a system rather than a noise concern. My understanding is limited and I have been unable to resolve the underlying cause of these.<br><br>Some typical examples ...<br><br>The bulk of the content of each and every reception in error (seems) uniformly correct.<br><br>Typical damage:<br>~90% - The lead byte(s) are in error. A repeated value is present instead. The value is 0.<br><br>e.g. (from logs which may not be presented well here)<br><br><span style="font-family: Lucida Console;"> 689:40:1 R=36<br>0000CCE33338E38E38E3338CE338CE3333333333338CCE38CE333333333338E38E338E333370493569FE5000000000000000000000000000000000000000<br> . . L c 3 8 c . 8 c 3 . c 8 N 3 3 3 3 3 3 . N 8 N 3 3 3 3 3 8 c . 3 . 3 3 p I 5 i ~ P . . . . . . . . . . . . . . . . . . .<br> !RXerr F2<br><br> 693:20:4 R=38 002240223A2231663261222C222B223A362C22547C433136223A3536302C227661637C68223A302C22767C25223A30FD5A00000000000000000000000000<br> . " @ " : " 1 f 2 a " , " + " : 6 , " T | C 1 6 " : 5 6 0 , " v a c | h " : 0 , " v | % " : 0 } Z . . . . . . . . . . . . .<br> !RXerr F2<br><br></span>Where<br> R= ... is the background RSSI<br> 0000CCE33338E38E38 ... is the RX buffer content as hex<br> . . L c 3 8 c . 8 ... is the RX buffer content as printable ascii otherwise ".".<br><br>~5% - The tail byte(s) are in error. A repeated value is present instead. The value is 0.<br><br>e.g.<br><br><span style="font-family: Lucida Console;"> 686:20:2 R=36<br> 7B2240223A2231663261222C222B223A322C22547C433136223A3532312C227661637C68223A302C22767C25223A30000000000000000000000000000000<br> { " @ " : " 1 f 2 a " , " + " : 2 , " T | C 1 6 " : 5 2 1 , " v a c | h " : 0 , " v | % " : 0 . . . . . . . . . . . . . . .<br> !RXerr F5<br></span><br>~2% - The tail byte(s) are in error. A repeated value is present instead. The value is the last (valid?) value.<br><br><span style="font-family: Lucida Console;"> 672:20:4 R=35<br> 7B2240223A2231663261222C222B223A332C22547C433136223A3431392C224F223A312C227661637C68223A302C22767C25223A30FDFDFDFDFDFDFDFDFD<br> { " @ " : " 1 f 2 a " , " + " : 3 , " T | C 1 6 " : 4 1 9 , " O " : 1 , " v a c | h " : 0 , " v | % " : 0 } } } } } } } } }<br> !RXerr F5<br></span><br>The last issue is interesting because it is conceivable that this behaviour is seen in all scenarios, even valid receives.<br><br>Has anyone got any idea what could be causing these systematic errors within the system?<br><br>I have a suspicion (based on little evidence and the RFM22/23B manuals unclear definition of operation) one or more of following combined with OpenTRV variable Tx sizes and variable timing may explain the evidence:<br> o Tx is overrunning (due to incorrect Tx control) causing over long Tx of something.<br> o Tx is transmitting the last byte repeatedly (due to incorrect Tx control) causing last byte to be repeated.<br> o Rx is overrunning (due to either Tx overrun, or incorrect Rx control) causing over long Rx of something which fills/ overfills/ cycles through the RX FIFO/buffer corrupting beginning of FIFO (other wise how can FIFO be so radically uniformly corrupted at the beginning having just so succesfully received preamble and sync word with rest of buffer being received without error?)<br> o Rx is receiving background noise repeatedly (due to incorrect Rx control) causing a uniform resulting value to be extracted from noise.<br> o Tx length is overlong on occaison (due to incorrect calculation) causing intended content to be truncated which may explain occaisional JSON F5 error where CRC is likely missing.<br><br>RFM22/23B Tx Rx operation/behaviour through FIFO's is not well explained in the mode OpenTRV is using. It is not clear to me what other than changing mode stops a Tx or Rx once begun. OpenTRV operation tries to save power by checking status occaisionally which means when large/FIFO filling transmissions occur it is conceivable that they execute for significantly longer than (strictly) intended potentially resulting in TX/RX FIFO overflow the practical results of which are unclear.<br><br>Note: In the mode OpenTRV operates the RFM22/23B the preamble+sync is present in the TX FIFO but removed before entering the RX FIFO meaning that for any given transfer the Tx is bigger (in the FIFO) than the Rx.<br><br>Other issues:<br>?DROPPED stats:<br>o Local stats are overwriting received stats<br>o Depth 1 buffers are vulnerable<br>o 2 buffers (1*FHT8V stats, 1*JSON stats) multiply up depth 1 vulnerability<br><br>Might be better for many reasons (not just DROPPED stats issues) to reorganise OpenTRV receive processing to separate a) reception from b) (post) analysis then presentation via one receive depth 2 buffer, rather than current organisation of a) reception then analysis from b) (post) presentation via two distinct single depth 1 buffers.<br><br>Probably too much to digest at once - apologies.<br>Regards Gary_______________________________________________<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>