[OpenTRV-dev] RX improvements
Damon Hart-Davis
dhd at exnet.com
Sun Sep 27 13:19:30 BST 2015
Hi,
Gary, thanks again for all that work!
I have yet to fully digest it, but I agree with you on the suspicion that maybe not enough ‘late errors’ are seen.
Note that for the frames (or portions of) that I protect with a 7 bit CRC I’ve only noticed 3 failures so far *in total*, ie bad data getting through (most would be glaringly obvious from the graphs that I watch), which suggests an error rate missed by the CRC of ~1/150k or maybe a raw error rate of 1/1000 frames at most. (Yes, please do correct that very poor error anaysis!)
What I take that to mean is that if the RFM23B accepts the sync and preamble then overwhelmingly the rest of the frame arrives OK.
This will probably only be true while the overall TX duty cycle across all radios in earshot of one another stays low. Beyond that I expect collisions to increase the overall error rate in interesting ways.
Rgds
Damon
> On 26 Sep 2015, at 08:57, gary.gladman at talktalk.net wrote:
>
> I have been running the following configuration on my network for about 11 days (since 15/09/15).
>
> OpenTRV 20150817-16WW
> OTRadioLink V0.8
> OTProtocolCC V0.3
>
> Compiled with Arduino 1.0.5.
>
> Ideal Current Configuration:
> o OpenTRV Rev 2: "hub" - manages an FHT8V (2532), intended to listen and collect stats from leaf, intended to listen for leaf and control boiler. Configured: no security, C1
> o OpenTRV Rev 2: "leaf" - manages an FHT8V (1f2a). Configured: no security
>
> Installed Current Configuration (as similar as I could get to my original setup within memory constraints and without tailoring for relevance to others)
> "hub": compiled and loaded CONFIG_Trial2013Winter_Round2_STATSHUB (i.e default) - doesn't give quite what I want but seems best available compromise. Configured: no security, C1
> "leaf": compiled and loaded CONFIG_Trial2013Winter_Round2_NOHUB. Configured: no security
>
> Evidence so far is that everything works and communicates very well.
>
> When in the same location where originally experiencing problems (see latest run analysis output below) now nominally experiencing ~0.21% duplicate JSON stats and ~3.8% missing JSON stats. Binary stats are also received (6724) but it is difficult (for me) to establish how many may be missing but I suspect it is very very few i.e. comparable to JSON stats. Assuming over a reasonably long period I should see as many binary stats (6724) as "FHT8V TX" (7017) this comes to ~4.2% binary stats missing. Double losses (3) compared to single losses (219) come out at around ~1.4% i.e. on a par with single losses (~4.1%). Given the size of the run this implies to me that nothing too strange is happening i.e. each individual loss is likely independent.
>
> The leaf had been moved further away in stages until it was probably in the worst location in the house for reception resulting in ~20% missing JSON stats.
>
> The system has worked well at all times with each unit communicating with its FHT8V and behaving entirely as expected IMHO within the limits of the configuration.
>
> NO direct radio communication errors have been reported at any time even when locating the leaf in a bad communication location.
>
> However, this absolute absence of radio communication errors makes me nervous. Seeing just one direct radio communication error would be comforting. Communications are good but the implication is that all lost messages are lost because they are never received at all which implies either they are
> o not listened for
> o never sent
> o badly corrupted exactly at their beginning (but NOWHERE else) and thus never detected
> o readily corrupted - their beginning is very weak and thus not very resilient in a not very noisy environment
> OR
> o detected but ignored (without note - BAD!, by intention, during radio mode changes ...)
>
> To me something here does not stack up. LBT might improve the diagnosis of the problem as it may be possible to identify whether noise exists when transmissions begin and/or proportions likely impacted. If someone could confirm corruptions are/are not being reported that would make more sense of this.
>
> From a radio communication perspective receiving duplicates is good, BUT it is not clear how many duplicates are being transmitted but not received and it is very important to understand this to assess cause of loss in all cases.
>
> Do we have any (stated/collated?) design numbers for hub and/or leaf for
> o average rate and duration of transmissions (by type)?
> o average proportion of time spent listening, transmitting, neither?
> o average proportion of transmissions (by type) are double transmits?
> For me this would really help clarify what might be happening and whether what is being experienced is by design, corruption, or by error. I then might be able to model and identify the gap between design and reality.
>
> I am potentially noticing a pattern appearing over time with more errors occurring at certain times of the day which might relate to increased electrical activity (unsurprising). I will see how this develops, however in my setup I seem to lose the connection between the PI and hub which has meant that I cannot do really long runs (I still do not understand how to replicate run, configure your monitoring setup). The reduction in error rate will make this analysis hard :)
>
> All in all IMHO this is a massive improvement - now very useable - very well done.
>
> Regards Gary
>
> Multiple analysis output from latest run (most recent analysis at the end). I can explain what it means if anyone is particularly interested.
>
> tail -n+3 /tmp/opentrv | ./opentrv.awk
> 00: 2
> 01: 4
> 02: 5
> 04: 4
> 05: 6
> 06: 3
> 07: 2
> 08: 7
> 09: 4
> 10: 5
> 11: 3
> 12: 7
> 13: 3
> 14: 2
> 15: 3
> 16: 4
> 17: 2
> 18: 5
> 20: 3
> 21: 3
> 22: 4
> 23: 4
> 1: 86 - 13:26
> 2: 1 - 21:25
> 3 87 (86 1 ) 2285 23903 0.131291% 3.80744% =14:12 2787 @2672
>
> $ tail -n+3 /tmp/opentrv | ./opentrv.awk
> 00: 9
> 01: 9
> 02: 10
> 03: 4
> 04: 10
> 05: 14
> 06: 9
> 07: 8
> 08: 12
> 09: 8
> 10: 7
> 11: 8
> 12: 13
> 13: 8
> 14: 4
> 15: 12
> 16: 13
> 17: 16
> 18: 13
> 20: 5
> 21: 6
> 22: 11
> 23: 12
> 1: 219 - 06:28
> 2: 3 - 18:50
> 12 222 (219 3 ) 5793 60218 0.207147% 3.83221% =06:29 7017 @6724
>
>
> ----Original Message----
> From: gary.gladman at talktalk.net
> Date: 10/09/2015 22:25
> To: <opentrv-dev at lists.opentrv.org.uk>
> Subj: Re: [OpenTRV-dev] RX improvements
>
> Hi
>
> I think I have answered my own question after a little further playing around.
>
> > OpenTRV Rev 2: hub - manages an FHT8V (2532), intended to listen and collect stats from leaf, intended to listen for leaf and control boiler.
> CONFIG_Trial2013Winter_Round2_STATSHUB (i.e default) - doesn't give quite what I want but seems best available compromise.
>
> > OpenTRV Rev 2: leaf - manages an FHT8V (1f2a).
> CONFIG_Trial2013Winter_Round2_NOHUB
>
> Hub receiving from leaf but thus far seems limited to JSON stats from leaf i.e. no JSON stats from hub, no minimal stats from either.
>
> I will monitor and see what happens.
> ----Original Message----
> From: gary.gladman at talktalk.net
> Date: 10/09/2015 20:49
> To: <opentrv-dev at lists.opentrv.org.uk>
> Subj: Re: [OpenTRV-dev] RX improvements
>
> Hi
>
> OpenTRV Rev 2: hub - manages an FHT8V (2532), intended to listen and collect stats from leaf, intended to listen for leaf and control boiler.
> OpenTRV Rev 2: leaf - manages an FHT8V (1f2a).
>
> So I guess the question is which configuration should/could I deploy in each unit to get the intended behaviour or some reasonable compromise given current capacity constraints.
>
> Regards Gary
>
> ----Original Message----
> From: dhd at exnet.com
> Date: 10/09/2015 09:22
> To: "Closed list for developer discussions"<opentrv-dev at lists.opentrv.org.uk>
> Subj: Re: [OpenTRV-dev] RX improvements
>
> OK, I’ll need to understand your setup again.
>
> The point that I was failing to convey by my hamfistedness, sorry, was that some options that were run-time configurable now also need explicit compile-time support because of code-space issues.
>
> So you may have to use distinct builds in different boxes where that was not the case before.
>
> Rgds
>
> Damon
>
>
> > On 9 Sep 2015, at 20:37, gary.gladman at talktalk.net wrote:
> >
> > Hi,
> >
> > In case I have created confusion when I said "NO communication reported from leaf to boiler hub" I was referring to what in my system is the OpenTRV acting as the notional "boiler" hub.
> >
> > I used the V0p2_Generic_Config.h file as supplied with the baseline (see attached) to create the install that I loaded into each of my leaf and hub OpenTRV's. The pre-existing configuration in the OpenTRV's was left unchanged.
> >
> > Regards Gary.
> >
> > ----Original Message----
> > From: dhd at exnet.com
> > Date: 09/09/2015 10:19
> > To: "Closed list for developer discussions"<opentrv-dev at lists.opentrv.org.uk>
> > Subj: Re: [OpenTRV-dev] RX improvements
> >
> >
> >> On 8 Sep 2015, at 20:27, Gary Gladman <gary at gladman.name> wrote:
> >>
> >> Code compiles, I have installed it, BUT I am seeing NO communication reported from leaf to boiler hub though I am seeing communication with the respective valves.
> >
> > Be aware that due to code size constraints a boiler hub is not necessarily a stats hub (and we anticipate that these will be separate boxes usually in fact) for example,
> >
> > Could you please share the V0p2_Generic_Config.h file settings you used to build each box, here or with me privately?
> >
> > I do need to steer the code back to primarily heating use on the HEAD very soon, apart from anything else to keep Bruno happy since he is upgrading his installation right now! Not to mention that we need to get code deployed to the valves that we are starting to crank the production handle for…
> >
> > Rgds
> >
> > Damon
> >
> > PS1. Deniz seems to have got a decent base code size for the AES code, which I’m hoping we can upload to the GitHub repo today and actually use on a bus stop very soon.
> >
> > PS2. Yes, I think you and Deniz came up with v similar boards.txt which helpfully verified that I was simply being a scaredy-cat… Thanks to both of you.
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >
> >
> > <V0p2_Generic_Config.h>_______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
More information about the OpenTRV-dev
mailing list