TTN + ABP + LMIC_setAdrMode(0) #554
Comments
|
@czuvich With TTN (on EU868?) you may try a |
|
I don’t think Join applies since I’m using ABP, so setting the linkCheck flag won’t really help. I’m on US915 |
|
Sorry you're having problems. If OTAA join doesn't work, high confidence: downlink doesn't work at all. (And if downlink isn't working, timing is broken on your platform; could be another variant of the interrupt problems.) In your reported problem, TTN US is trying to control your state by sending the downlink. I hypothesize that you never receive and ack the message (because downlink is not working), so on every uplink, TTN US repeats the message. I have not recently tested It would really help me out if you could use the How to use
|
|
Thanks for the reply! Responses below.
Downlink works fine using ABP regardless of which version of the library (between v3.0.99 or 3.1). I've verified this by scheduling downlinks to the node, and I am seeing the payload on the node. Things break when I turn off ADR on v.3.1.0. I'll take some time this week to run git bisect on this particular issue and post my findings here since I can consistently reproduce. I really appreciate the help! My hunch is that the findings in #524 are directly related to the OTAA issues me and others are having. In all honesty, I'm personally not a huge fan of OTAA since I "join" via my backend (not directly from a node - my node is registered through my mobile app, which then auth's to TTN). I personally think it overcomplicates the end node, but I'm going to post this on TTN and see some responses. I would say 70% of issues with LoRaWAN stacks are related to OTAA. |
|
If using a completely private network, ABP is ok; but on a standards-based network, it is very hard with cheap hardware to achieve the strict requirements of the spec related to reuse of FCntUp. Downlink is the issue with OTAA; it must work in order for OTAA to work. But on the other hand, generally if a device joins, the remaining downlink features are less challenging. So making OTAA work is well worth the effort. In any case, #524 is almost certainly related to your problems with downlink. I am working on a portable fix; there's no reason for the underlying problem other than ... that's the way they did it the first time. However, with all the changes in the MAC layer, it's very possible that |
|
Thank you for the very detailed explanation! I am pretty new to LoRaWAN, so I have a lot to learn. Pros/Cons of OTAA and ABP seem to make sense. I'm thinking one day, the software stacks for LoRaWAN will be as ubiquitous as HTTP/HTTPS in such a way that the application developer will not be concerned with either. It'll be the backend + library that negotiates the authentication. Anyways, I ran git bisect. I am new to doing this; however, I think I did it. Here are my logs. Let me know if this is what you're looking for: |
|
I was browsing through that commit ff21bc7ef7e369bf071e00294a0d6a2ccb28dbb2, and that's a huge commit. |
|
@czuvich in a big LORAWAN network the network server should be able to influence the radio parameters of the nodes. This is the purpose of MAC commands in LORAWAN. They can only work if downlink is working. Thus, we need downlinks in LORAWAN networks. And if we have them, we can use OTAA. I am running MCCI LMIC 3.1.0 on different nodes, mostly ESP32 with multitasking apps. No problems with crashes so far, and i don't see the "downlink after every uplink" issue with TTN any more (had this some time ago, but it disappeared, don't know why). |
Yup makes sense. And I'm guessing as the LoRaWAN spec evolves, so will the software stacks, and soon the app developers won't have to concern themselves with OTAA vs ABP (at least on the end node side).
Good to know it's working on ESP32. There are others running into the same issues as myself with different hardware setups. Hopefully, this latest git bisect sheds some light on it. |
|
It is a merge commit. You need to go through the branch. It appears that Git doesn’t walk you through the branch directly, which is unfortunate.
I suggest `git checkout -b tmm-issue453 3b9b02d` ; and then start the git bisect again (with the branch checked out). Use the first good commit as 05d304f or e961979.
You will see that there is are points where the compile fails. You’ll want to do `git bisect skip` to get past them, if run into one.
…--Terry
|
|
Ok.. ran it on the branch. Here are my results. Again thanks for your help! The --oneline log is really long, so I truncated it off. Let me know if you need all of it. |
|
I'm guessing the issue is in this line right here.. And I'm wondering if this is the same line that is causing other issues in downlinks/RX. 306330f#diff-7cce30ca97b97ac6a31ad515b700e604R273 |
|
Interesting.. so I fixed my problem with disabling ADR using the latest version of the library (v3.1); however, I do still see an uplink for every downlink with ADR turned back on. Here's what I did in the library: I used the timing defined for the DISCO board, and no more crash. I was seeing the app lock up in the hal_waitUntil method. Could this also be related to other issues with OTAA I'm seeing as well? I haven't tried it. |
|
Any suggestions or feedback? I’d be willing to send actual hardware for troubleshooting. It feels like the issue is directly related to the timing of downlinks and the hard coded delay timing vars. Perhaps if you can shed some light on why it’s done that way I can help. |
|
Sounds great! Again thanks for the outstanding work! And let me know if there’s anything I can do on my end. |
|
I hope you and your family are ok. I assume there won't be too much progress on the timing in #524 during this time correct? |
|
@terrillmoore Glad to hear your family is doing ok! I downloaded your latest update and it looks like OTAA is working for my board along with downlinks. Thank you so much for the great work! Now to convert my backend registration to OTAA :D |
I am using an nRF52840 Express from Adafruit and a HopeRF95. I have been having various issues with the latest version of the library (v3.1), and I downgraded to v3.0.99 which has resolved a few problems; however, I am noticing the following.
Library version: v3.1.0
Code: ttn-abp example
I am using ABP (OTAA just doesn't work for my hardware), and I was seeing a downlink for every uplink to the TTN Gateway on my End Node. I looked at the traffic, and TTN is sending a LinkADRReq for every uplink. I don't think that's expected behavior. I assumed LMIC would update the ADR info and send an ACK back; however, I don't think that's happening.
I then tried the LMIC_setAdrMode(0) in the setup(), and my end node froze after sending the uplink. I saw the uplink in the gateway.
Library Version: v3.0.99
Followed the same steps as above, but everything worked. The app did not crash, and I am no longer seeing a downlink for every uplink.
I do think there's an overall issue with timing and the latest update to the repo (v3.1.0).
Having said that, I was browsing the repository issues, and it'd be awesome to include some updated documentation on a more "best practices" workflow of using this fantastic library (for instance, I'll probably stitch together 552 with a few others to get this working for my app. GREAT job on this library, as I'm sure it requires a lot of time and testing.
The text was updated successfully, but these errors were encountered: