Problem activating LoRawan via ABP. #946
Replies: 4 comments 12 replies
-
Logic suggests that if that is the case, you should not be able to pass the join request to the network server, hence no activation. Unless the device has already been activated and restoring the session from persistent storage.
That is impossible at the moment, since you have not shared neither your code, nor debug output or any information about what sort of MCU and radio you are using. I honestly don't know how you expect us to help with the data you have provided ... try to put yourself in the shoes of the community here. Had somebody given you such a "report" to work with, would you be able to help them? |
Beta Was this translation helpful? Give feedback.
-
|
@AbbosAthamov that's better, now what about that debug mode output? -705 is a very generic error that can happen any time there is SPI communication with the LLCC68. So if you post the debug mode output, we will know where exactly where it failed. Also, to correct myself here:
I failed to notice you were talking about ABP - though it only underscores why we really need to get as much information as possible right away ;) |
Beta Was this translation helpful? Give feedback.
-
|
As for the gateway, it is active, and the same keys and settings are registered there.
Same error via OTAA Logs |
Beta Was this translation helpful? Give feedback.
-
|
@AbbosAthamov thanks for the debug output - now it's very clear. The command that actually fails is There are two probles at play here: first is that the data rate is not checked correctly (because |
Beta Was this translation helpful? Give feedback.
-
|
Before I tell you whether it is correct or not, I'd like to say that you should disable ADR on the LLCC68: the LNS may request your device to move to SF10+ which it of course will fail to do, causing many many downlinks as it tries repeating this maybe dozens of times.. For ABP, @jgromes we may want to check if the SF is settable for the @jgromes here - I don't have time to do this today, so if you could include some simple check there before 6.4.1 that would be awesome! |
Beta Was this translation helpful? Give feedback.
-
|
@StevenCellist can do, though I think it will need a new |
Beta Was this translation helpful? Give feedback.
-
|
Somewhat agree, but we already do the same for the Tx power ;) For now that can do in my opinion, and rework later for a bit more major update? Unless you'd want to implement those already. Or we just kind of ignore it, since I think the target audience is very small. |
Beta Was this translation helpful? Give feedback.
-
|
Oops, wrong reply field.. oh well |
Beta Was this translation helpful? Give feedback.
-
|
Tx power is slightly different, because it won't do any actual SPI transactions until the power level is valid. That's not the case for data rate, which needs to configure SF, BW and CR, so might do 2 transactions just to figure out it was all pointless and then you have to do 3 more to restore it. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see.. your call! I'm just here for the LoRaWAN stuff ;) |
Beta Was this translation helpful? Give feedback.
-
|
@AbbosAthamov can you give RadioLib 6.4.2 a try, where you configure the initial datarate as mentioned before ( |
Beta Was this translation helpful? Give feedback.
-
|
Rather like using the dreaded Single Channel Packet Forwarder, which can be done if you really know what you are doing, I think supporting the LLCC68 for LoRaWAN is likely to end up causing more problems than it's worth - don't prevent it, but make it less obvious to use. |
Beta Was this translation helpful? Give feedback.
-
|
@HeadBoffin I will have to disagree with you on this point - LLCC68 is one of sub-GHz LoRa transceivers, I don't see why it shouldn't be supported, or "made less obvious to use". Regardless of the fact that RadioLib architecture makes "preventing LLCC68 from using LoRaWAN" somewhat tricky even if we wanted to do so. We would actually have to actively work to prevent users from doing that as opposed to deleting a few lines and dropping support. As a fun side-effect, there's nothing in the library stopping you from using non-LoRa modules as In the future, there will be LR1110 support, and that will work with LoraWAN too. Yes, the LLCC68 is a bit less widespread than the SX126x, and it has a rather awkward configuration limits, but that's just a fun little challenge to work around :) |
Beta Was this translation helpful? Give feedback.
-
|
I mean't for LoRaWAN - and when I say make it less obvious to use I didn't say how and I'm aware you can pick any radio you like and try to do odd things with the wrong protocols so not in code, or maybe a compiler warning for inappropriate radios but that's @StevenCellist's fun - I've a load of notes on pinouts & tested combos for a Wiki page so for "less obvious to use" I'd just not list it as compliant - probably add a footnote explaining the issue with support for SF's. |
Beta Was this translation helpful? Give feedback.
-
Activation takes place even when the gateway is turned off. Then, when sending data, it gives an error: RADIOLIB_ERR_SPI_CMD_INVALID
Without the LoRawan protocol everything works.
Help me please.
Beta Was this translation helpful? Give feedback.
All reactions