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

[Damon Hart-Davis]

Hi,

Thanks for all this sterling advice!  I’m just emerging from a very busy few days so sorry for the delay in replying (and I am conscious that I have another email from you to get to, too).

The Golay page is helpful, thanks, and I’m still working my way through it.

The truth is that we may want to use multiple different sorts of underlying channels with different characteristics, eg from in-home ISM to multi-kilometre hops.  At the moment all I am sorta kinda committing to is a run-time “try harder” or “important” hint to hand off to the underlying radio driver with each frame which may be able to provide a facility appropriate to that channel type.

At the moment for the in-home ISM channel it might simply be the double transmission that I am already doing.

For an already reliable medium, or a really constrained device/channel, that hint might be ignored entirely.

But in some cases those may be poor solutions, thus thinking about FEC as an alternative, though preferably with a better coding rate than from a double TX!

Rgds

Damon

> On 25 Apr 2015, at 12:55, EMAIL ADDRESS HIDDEN wrote:
> 
> 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_______________________________________________
> OpenTRV-interest mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-interest