I’m working on integrating the RN2483 (fw 1.0.1) in my software and I think I have most quirks managed right now, but I’m still seeing issues with using ABP join.
I do query the status bits and the reply always states “joined” bit is 0, even after the ABP join returned “accepted”.
Is this a known bug in the firmware, and if so, what should I do to check if the controller does think it has joined?
For now, I am turning the “joined” status bit around a bit ( 
)
I do set it manually and “or” it with any status update I perform.
So it is kept “1” as long as I don’t set it to “0”.
I do set it to “0” if the module responds with “not_joined”
Is this the correct approach?
There is no such thing as a state of being “joined” when ABP is used.
The term only has meaning within the context of OTAA, ie, where you have issued a join request and received a join accept.
OK, that does make sense, but my point is that the status bit (mac get status) does not return the joined status bit to 1.
It does however reply swiftly when you try to mac tx when not joined, as if it knows it is not joined.
So that’s a bit counter intuitive, that the status bits have one bit reserved for “joined” state, but it doesn’t seem to be used or at least it is not set persistent for as long as it is “joined”.
it may be “configured” and so able to transmit but it is not “joined” because there is no such thing in ABP mode
The reply I get is not_joined, which does make it a bit confusing then.
On the other hand, it is a clear indication of what command you should run (mac join abp)
This doesn’t make sense at all. You should fix the problem, not mess with the module’s internals.
Combining information from your above posts, it seems mac join abp works:
And that at some point (or right away?) mac tx fails:
Right?
So, what happened between the successful mac join abp and the failing mac tx?
The RN2483 cannot know if the session configuration you set before running mac join abp is correct. So, it can only return accepted for mac join abp, regardless the values that you set for DevAddr, NwkSKey and AppSKey. Even more: it won’t transmit anything at that point; it’s just a means to tell the device that you claim that you configured the device properly. (Remember that “ABP” is “Activation by Personalisation”, so: activation by just configuring a fixed “session”. Indeed, not a “real” join like @cslorabox says, and quite a bad choice in naming of the RN2483’s commands.)
Next, when transmitting at some point later, it still won’t know if the DevAddr and session keys that you set are the ones known by TTN. It will just assume you set the correct values, use those to create a LoRaWAN packet, transmit that encrypted packet, hope that one or more gateways receive it, and that the backend servers can handle it. There’s no reason to throw any error at that point.
So: I’d assume you either did not set all of the ABP parameters, using mac set devaddr, mac set nwkskey and mac set appskey before calling mac join abp. (If true, then it’s weird that it does return accepted at that point but still throws not_joined later on. But who knows.) Or that you power cycled or somehow reset the RN2483 between running mac join abp and mac tx?
And asides:
Why are you not using OTAA rather than ABP? In EU868 OTAA will also get you the correct network settings in the OTAA Join Accept, which you need to set manually for ABP. Also, the frame counters are reset automatically for each join, which is helpful during development. (See How often should a node do an OTAA Join, and is OTAA better than ABP? And see OTAA shows "Activation DevNonce not valid: already used" for a workaround for OTAA issues during development.)
And note:
I’m not.
I am writing a library for this module and the “joined” state is something I am now keeping as a member of that library.
And “writing” is more a (complete) rewrite of this library: RN2483-Arduino-Library (Preview of my rewrite)
This rewrite is to make it as async as possible so the code does not block execution on the ESP node for other tasks (it is meant as a controller for ESP Easy, I posted here about before) and right now no call to the library should take more than 100 msec, except mac save, which takes about 1300 msec.
So in this light, I was also testing what would happen if wrong credentials are given
This to make it as user friendly as possible and give proper feedback to the user what’s wrong.
So for this reason it would be great to know as soon as possible what’s happening and thus I was looking at the Status bits.
I now made it to look at the return value of the TX command, so if the RN2483 somehow has been reset I will know it when it returns not_joined. Still have to add checks for the counter (not sure if needed)
It is good to know I should not call ABP activation “joining” anywhere in the software as it is not in line with LoRa/LoRaWAN terminology.
As the nodes running ESPEasy will be deployed anywhere, I must have support for ABP as well as OTAA, so the node can also start sending (and boot) in the middle of nowhere and its messages will be received whenever a gateway will pick it up.
One such use case is an environment monitoring device I am developing which can be installed in vehicles.
This means I also have to make sure to find a good balance between saving states (counters) and write cycli, but that’s already discussed offline with @kersing 
Your last note was probably exact what I was looking for and too bad this forum engine doesn’t support side line or footnote markup, as that’s the place where traditionally is the most important information to be found 
So to summarize what I understand that should be done:
I would actually start by updating modules to the newer firmware. For the plain RN2483 version 1.0.3 is known to work well. Versions below have known issues and should be avoided.
The newer firmware will help with saving state as well, older firmwares left critical things unsaved.
As I understood it, the 1.0.3 also has the “Joined” bit in a different place compared to 1.0.4 and newer.
So that still leaves a difference between the Status implementations.
Of the 3 modules you gave/sold to me (still have to decide what kind of transaction that was ) 1 did not survive my “debugging” efforts so 2 are left and I doubt those are very accessible for firmware upgrades or I have to implement it in software to upgrade them.
For now they are great debugging items as I expect some future users of this ESPEasy controller I’m writing will end up buying modules with old firmware.
I do have a few “A” modules with 1.0.5 firmware but have not yet soldered them on a board.
Unless the provided credentials are misformated or incomplete, that’s not knowable in ABP mode. There’s no way to distinguish having credentials that do not match any known to a network, from simply being out of range of a network. And unless you are using ADR or have something configured to send infrequent downlinks, there’s no way to even know that you are in range of network and have credentials it knows about.
What OTAA gets you is a round trip handshake - if an only if the root shared secrets match and the network is in range.
In order of increasing awareness of success/failure from the node side:
ABP uplink only - no success feedback and not really acceptable for non-fixed installation given inability to tune data rate
ABP with ADR - data rate gets tuned and (at least the LoRaWAN stack) gets occasional feedback that network is listening. Or optionally have occasional application downlinks perhaps creating your own need-tuned sense of a “joined session” and appropriate data rate
OTAA without ADR - fairly illogical choice no reason to do this
OTAA with ADR - standard recommendation
OK, so I also have to add ADR support (not yet enabled)
But just for my understanding, is ADR useful on “moving” nodes?
I can understand why it is absolutely useful on stationary nodes, to make sure power consumption and ether pollution is minimal.
But for a moving node, its conditions are changing constantly, so is ADR useful at all then?
Depends on the rate of the actual ADR implementation compared to the rate of the movement.
To an extent, rapid movement isn’t really supported either with or without ADR - you’re not allowed to use a fixed SF11 or SF12 (in some places those data rates aren’t usable anyway), and you’re also not allowed to send lots of frequent round trip traffic to adjust to changing conditions. In effect, a node that moves a lot (say vehicle mounted) is just going to have to accept fairly sporadic success and perhaps do something like use SF10 with extremely small and not very frequent packets.