Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3.0.99.10 fixes #514

Merged
merged 35 commits into from
Dec 30, 2019
Merged

V3.0.99.10 fixes #514

merged 35 commits into from
Dec 30, 2019

Conversation

terrillmoore
Copy link
Member

@terrillmoore terrillmoore commented Dec 30, 2019

Mega pull-request. Addresses:

#442, #453, #454, #466, #467, #485, #493, #502, #504, #507, #508, #510, #511, #512, #513.

In internal testing, this seems to address the downlink data integrity issues. Passes EU868 pre-compliance with RWC5020.

terrillmoore and others added 30 commits October 31, 2019 14:33
The US v1.3 compliance test section 12.5 requires that we not
increment the downlink count for an EchoRequest unless the
EchoResponse is permitted with the current data rate (what the
LMIC code calls "feasibility"). We can't tell if a message is
feasible unless we actually try to send it, and we increment the
downlink count centrally. Workaournd is to decrement the downlink
count if the LMIC says the EchoResponse is infeasible.
US compliance testing doesn't support v1.0.3 devices that support
the extended power range. For squeaky-clean logs, add an option to
select whether we're complying with 1.0.3 or 1.0.2. Do it in a way
that allows generalization to future 1.1 support.
On STM32L0 platforms, capture the 32 kHz clock in LPTIM1, and output
the values, giving a useful 100ppm time reference.

Display additional entries in the log (like the scheduled RX time) so
we can compare time to desired times.

Miscellaneous enhancements.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants