[OpenTRV-dev] Residual Receive Strangeness
gary.gladman at talktalk.net
gary.gladman at talktalk.net
Sun Jul 12 23:14:05 BST 2015
I seem to have largely resolved the reception issues I was experiencing.
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.
With these settings I am now getting runs with NO receive errors even with more frequent receptions.
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.
Regards Gary
----Original Message----
From: dhd at exnet.com
Date: 12/07/2015 14:06
To: "Closed list for developer discussions"<opentrv-dev at lists.opentrv.org.uk>
Subj: Re: [OpenTRV-dev] Residual Receive Strangeness
Hi,
> On 12 Jul 2015, at 12:58, Gary Gladman <gary at gladman.name> wrote:
>
> 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.
>
> RX Polling may simply be the wrong approach.
I’m sure that ultimately an interrupt-drivem approach may have to be adopted
The new RFM69 series that we will need to move to (RFM23B is EL) may have different ergonomics in this area too.
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/20150712/b20c1588/attachment.html>
More information about the OpenTRV-dev
mailing list