[OpenTRV-interest] Golay Encoding (et al) and Interleaving

[EMAIL ADDRESS HIDDEN]

Hi

(Damien: see we were listening :) )

For my sins I have spent a LOT of time working with these in the past (in a weak sense it is one of my area of expertise).

This http://www.aqdi.com/golay.htm should give you a very useful understanding.

When we used this approach we were working with a VERY VERY noisy channel and with copious processing capability. As an approach it was very effective, but only because we had a very good understanding of the channel characteristics to begin with.

I think the key consideration here is only responding to the observed and well understood noise characteristics of your channel. Until the channel is well understood/characterised then solution approaches (e.g. golay) should not be selected. First understand the problem, only then consider the solutions.

Given the limited amount of channel information captured by OpenTRV I would suggest the key issues presently are monitoring and loss rather than corruption e.g. too early to worry about these solutions.

Loss and understanding its cause should be addressed first.
    o) A channel or protocol being lossy is not the same as it should necessarily suffer loss - first thoroughly understand each loss since it is unbeleivably human to attribute loss to the channel rather than an imperfection in the mechanism which is often the true cause.  
    o) Capture timestamped evidence as a matter of course (it takes a lot of human real time and effort to identify and resolve these issues - log whatever you can whenever you can as much as you can)
    o) Have a (preferably independant) channel monitor to help seperate transmit and receive concerns.
    o) Monitor and report RSSI at the point of transmit.
    o) Monitor and report RSSI periodically and whilst receiving. (NB probably worth collating as part of stats.)
    o) If you are looking for solutions I suspect that LBT (Listen Before Transmit) would be a more rewarding starting point (given my experiences with OpenTRV - see emails). Most of the observed Rx failures in my experience are preamble problems rather than payload corruptions (unless the corruption is so bad it is corrupting the preamble) and beyond that losses (i.e. no reception) are more common. This implies to me that resolving the losses is far more important and potentially rewarding than resolving the corruptions especially when both could have the same underlying cause.
    o) Whatever recovery mechanisms exist make it possible to turn each off independently - recovery mechanisms tend to obscure fundemental faults. This is especially true when multi-level recovery mechanisms interact. Log active recovery mechanisms and their activity.

I hope that helps even if OpenTRV was not your prime concern.

Regards Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-interest/attachments/20150425/f3e4d7ce/attachment.html>