RX Timing is wrong for SF12

[terrillmoore]

LoRaWAN MACs calculate a start time for starting the receiver.

It looks like SF12 is wrong for the LMIC -- too late. I found this with EU RX testing. Here are the times in ms.

Code	SF12	SF11	SF10	SF9	SF8	SF7
LMIC	41	8	-8	-16	-20	-22
Semtech reference code	33	17	5	-2	-8	-9
mbed	88	39	14	2	-4	-7

(Semtech reference: RegionCommon.c RegionCommonComputeRxWindowParameters()).

It's OK if you start early, but not OK if you start late, as you can miss the start of the packet.

In fact, the current LMIC only shows problems at SF12.

Part of the problem is that both use a specific number of symbols as "min syms". But LMIC uses 5 whereas Semtech uses 6. If LMIC uses 6, the table becomes:

Code	SF12	SF11	SF10	SF9	SF8	SF7
LMIC	41	8	-8	-16	-20	-22
Semtech reference code	33	17	5	-2	-8	-9
mbed	88	39	14	2	-4	-7
LMIC with min RxSym = 6	29	-3	-19	-27	-32	-34

We'll test tightening this up, but also will test just changing RxSym to 6.

[terrillmoore]

It appears that there's more to this than meets the eye. See #483 (comment)_, #311 and #477.

[terrillmoore]

More testing revealed that grounding (and ground problems) can mess up the SX1276 front end (no big surprise). See new note at #483 (comment).

However, even with crummy grounds, it was clear that starting RX before TX was better than starting while TX. As far as I can tell, there is no power advantage to starting late, unless there is a downlink. If there's a downlink, then starting late means you run the receiver for less time just watching the preamble. However, if there's no downlink, it doesn't matter at all. And most of the time, there's no downlink.

So I plan to push a change to the 3.0.99 branch for test, that will move the RX window to start before the TX window. We'll set RXSYMs high enough to allow us to be sure we have some overlap with the preamble. Even at SF7, 1023 symbols is over 1 second, so we have plenty of margin (as long as we apply the fix for #467). I think we should ignore user-specified clock inaccuracy of more than 1%; and we should track the number of times we miss deadlines. (We should schedule assuming a slow clock, and set the number of symbols assuming a fast clock.) But our target should be just before the tx time.

[cyberman54]

Sounds promising. Hope we get rid of the EU868 TTN join problem this way.

[terrillmoore]

@cyberman54 I'll have something for others to test later today, I think.

[cyberman54]

@terrillmoore i will be standby

[terrillmoore]

Here's the plan.

1. I will add a check for "late" window opening (i.e., a call with the target receive time in the past). This will record a few statistics in LMIC.
2. we'll change strategy to bias towards opening the window promptly.
3. we'll deprecate the clock error because... it was probably compensating for a non-problem. (I'll leave a conditional compile to enable it, but... it really should not be used.)