subsystem: lorawan: fixed problems with join accept not working and misc improvements #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Use the device-tree to define which RTC should be used by the LoRa driver. Signed-off-by: Alexander Wachter <alexander@wachter.cloud> Signed-off-by: Kuba Sanak <contact@kuba.fyi>
A simple fix to allow code to compile. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
Including the necessary dts overlays and kconfig. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
Signed-off-by: Kuba Sanak <contact@kuba.fyi>
Added lorawan_send() Checks whether the Ack is received from Gateway or not for OTAA. Note LoRaMacProcess() in lorawan_join_network(). Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
The port mappings were incorrect as dipo and dopo do not refer to pins but rather to SERCOM pads. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
Only one of the six available DIO lines is required for correct operation of the device so ammed the description to reflect that. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
Miscallenous bugs in the driver were collectively preventing it working with the loramac-node library port. This commit fixes them, including: - RtcAlarmStop should only stop the alarm an not the whole counter due to the loramac library calling it whenever the alarm list becomes empty, but starting the counter only once at initialisation - RtcSetAlarm always set the timout to a hardcoded 2 ticks - CheckRfFrequency was not assigned correctly to the Radio. This lead to the system hang when the loramac library tries to call a relevant Radio method when processing a join-accept message - miscellaneous debug prints were removed. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
As the loramac-node library expects a function be run explicitly to process all things non-time-critical it makes sense to put it in its own thread freeing the library user from having to call it in the app. This commit also removes a blocking temporary code which used to be used to debug join-accept messaging. Signed-off-by: Kuba Sanak <contact@kuba.fyi>
… feat_lorawan Signed-off-by: Kuba Sanak <contact@kuba.fyi>
|
@KubaFYI Thanks for the update! Coincidentally, me and Kwon just fixed the LoRaWAN issue and we got Ack as well as send working. Anyway, I'll see what you have got and will try to reuse whatever applicable. |
|
It's a shame you didn't let me know that you were planning to continue working on the issue. I told you I was going to focus on this myself and that double effort could have been prevented. |
It's not intentional. I never told you that I stopped working on this. It's just getting time for me was difficult and today Kwon sent me an email that he has solved the Ack issue. So I quickly integrated his change. In fact, I was about to write an email to you letting this progress. I know how hard it is to see the redundant effort but since this work is kind of unorganized it is inevitable (this factor is more common in open source world). I think I need to create a mailing list of IRC for discussion since now we got several developers working on this. Again, sorry about this. |
|
That's fair enough. I understand that's how things sometimes work out in the open source world and I'm still getting used to it as it's my first time doing a whole bunch of contributions. I saw you opened a lorawan dedicated channel on Slack so I'll move there to discuss further! |
KubaFYI
force-pushed
the
feat_lorawan
branch
from
e63d4d5 to
da06cb8
Compare
Mani-Sadhasivam
pushed a commit
that referenced
this pull request
Apr 22, 2020
Fix two issues: 1. The script assumes the default CMake generator build tool platform is installed. On Linux at least, that's Make instead of Ninja, but Make might not be installed since Zephyr recommends Ninja. On Windows, that might be VS Code or nmake. Calling `cmake -P pristine` instead of `cmake --build <path> --target pristine` has the benefit of removing the dependency on a build command, and hence the default generator is not relevant. 2. It also assumes run_cmake() returns control, and therefore pristine can be run. However, if the cmake command fails hard (say, due to issue #1 before this patch), run_cmake() throws an exception instead. Fix that by trying to run the pristine target in a finally block instead, and adding some manual cleanup steps in case the build system is in a bad state and pristine fails too. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no> Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Mani-Sadhasivam
pushed a commit
that referenced
this pull request
Apr 23, 2020
Implement deep sleep mode #1 using the shutdown state on the CC13x2/CC26x2. Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Mani-Sadhasivam
pushed a commit
that referenced
this pull request
Jun 29, 2020
This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write #1: 16 bytes (0 bps) Write #2: 32 bytes (3445948416 bps) Write zephyrproject-rtos#3: 48 bytes (2596929536 bps) Write zephyrproject-rtos#4: 64 bytes (6400 bps) Write zephyrproject-rtos#5: 80 bytes (8533 bps) Write zephyrproject-rtos#6: 96 bytes (10666 bps) Write zephyrproject-rtos#7: 112 bytes (8533 bps) Write zephyrproject-rtos#8: 128 bytes (9955 bps) Write zephyrproject-rtos#9: 144 bytes (11377 bps) Write zephyrproject-rtos#10: 160 bytes (7680 bps) Write zephyrproject-rtos#11: 176 bytes (8533 bps) Write zephyrproject-rtos#12: 192 bytes (9386 bps) Write Complete (err 0) Write zephyrproject-rtos#13: 208 bytes (8533 bps) Write zephyrproject-rtos#14: 224 bytes (9244 bps) Write zephyrproject-rtos#15: 240 bytes (9955 bps) Write zephyrproject-rtos#16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Mani-Sadhasivam
force-pushed
the
lorawan-temp
branch
from
b617e35 to
d52a271
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've fixed the problems with join accept not working and moved the LoRaMacProcess loop into it's own thread. Also, updated the branch with upsteam. See individual commits for details.