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

LMIC can mishandle piggybacked data #570

Closed
terrillmoore opened this issue May 11, 2020 · 0 comments
Closed

LMIC can mishandle piggybacked data #570

terrillmoore opened this issue May 11, 2020 · 0 comments
Assignees
Labels
Projects

Comments

@terrillmoore
Copy link
Member

A keep-alive uplink while there's pending piggybacked downlink data will do the wrong thing.

@terrillmoore terrillmoore self-assigned this May 11, 2020
@terrillmoore terrillmoore added this to In progress in V3.2.0 May 12, 2020
V3.2.0 automation moved this from In progress to Done May 12, 2020
terrillmoore added a commit that referenced this issue May 12, 2020
The primary purpose of this PR is to fix #524, allowing the LMIC to run without disabling interrupts at all, and without requiring any changes to underlying BSPs. When configured for interrupts, interrupts simply cause the current time stamp to be captured. The secondary ISR is run as part of os_runloop_once(). This should also fix #503, and address #528, #558, #548, and others.

In addition, since we're updating the radio driver, I addressed #524.

In testing, I discovered a subtle bug with one of our applications that uses LMIC_sendAlive() -- there was a path when sending piggybacked MAC data with a poll that would result in trying to take the port 0 path instead. This caused problems with ChirpStack and TTN, at least. (This is #570.)

Finally, updated to use Arduino IDE 1.8.12 in test.

Version of library changes to v3.1.0.20.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
V3.2.0
  
Done
Development

No branches or pull requests

1 participant