[OpenTRV-dev] Residual Receive Strangeness

[gary.gladman at talktalk.net]

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.

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.


Hopefully, I can try and help out within the limits of my understanding of how OpenTRV operates, and subversion. 


----Original Message----
From: dhd at exnet.com
Date: 11/07/2015 20:16
To: "Closed list for developer discussions"<opentrv-dev at lists.opentrv.org.uk>
Subj: Re: [OpenTRV-dev] Residual Receive Strangeness

Thanks for the analysis: I shall revisit.

And it’s highly likely I’m doing many stupid things…

Just on this item:

> 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.

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.

I had neither the programming time nor the code space.

Rgds

Damon

_______________________________________________
OpenTRV-dev mailing list
OpenTRV-dev at lists.opentrv.org.uk
http://lists.opentrv.org.uk/listinfo/opentrv-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150711/0053623a/attachment.html>