How the RFM22/23B operates is far from clear - given all the constaints I'm amazed how successfully you have managed to balance out all the competing needs within OpenTRV. Errors for whatever reason are simply a natural part of any development process. Hopefully I can help out by isolating issues and errors and offering potential solutions.<br><br>Unfortunately, I am in a position at the moment where I know something is wrong here but I can't work out exactly what. I was hoping maybe someone else who understands these aspects better will have some ideas which might bare fruit.<br>
<br>Hopefully, I can try and help out within the limits of my understanding of how OpenTRV operates, and subversion. <br>
<blockquote>
----Original Message----<br>From: dhd@exnet.com<br>Date: 11/07/2015 20:16<br>To: "Closed list for developer discussions"<opentrv-dev@lists.opentrv.org.uk><br>Subj: Re: [OpenTRV-dev] Residual Receive Strangeness<br><br>Thanks for the analysis: I shall revisit.<br><br>And it’s highly likely I’m doing many stupid things…<br><br>Just on this item:<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>Yes, it would be very good to implement a deeper-than-1 buffer as my API is begging for, which apart from anything else could usually easily drop the duplicates from double TXs.<br><br>I had neither the programming time nor the code space.<br><br>Rgds<br><br>Damon<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>