Hi descartes, thank you for your reply
I got this advice from another forum post on this topic (I’ll link it here: Microchip SAMR34 Joining Denied - #19 by Afremont ) and I should have mentioned that I was going to use ABP for development purposes, and then use OTAA for production.
I realize this, but my understanding is that with the way the API is built on Microchip’s stack, it is considered a “join” from the Microchip side, even if there’s no actual join process. Hence the quotation marks.
descartes:
Frame counter for ABP which is LoRaWAN 101 - and for OTAA, DevNonce for v1.0.4 isn’t something that we/you increment, that happens automagically, all you have to do is save it but the SAMR34’s lack of explicit NVM means the LoRaMAC-node code base doesn’t have that built-in like other examples.
I like the SAMR34/WLR089U as the pre-built library that’s certified is unalterable by us mortals so pretty much implies a certifiable device - but at the cost of absolute adherence to the spec.
Whilst you can turn off frame counters for ABP you still lose the benefits of OTAA not only clearing the frame counter for you, but setting up some other super-important things like channels and Rx1 delay and so forth. So you have two options, the PitA one of hitting the MAC reset button on the console for the device, or using the CLI to turn off the DevNonce check.
For development overall I do much of my work radio off - so the firmware does everything right up to the point where it passes the payload over to the stack but just prints it (along with any other info) to the debug console. As the LoRaWAN stacks are pretty much a black box, it seems pointless waiting for a send, delay, receive - your debug output can detail what’s happened and give you the final payload byte array that you can use any number of tools to check is correct - although payload creation is sufficiently simple that you shouldn’t really need to keep checking that - the debug output can show the real world values for you to sense check.
For testing the Application Server to my backend, I use the ‘Simulate uplink’ on the console as it saves me waiting for a device to transmit and I can do it faster than the FUP would normally allow.
For end to end testing I use the CLI to turn off the DevNonce check as pressing the console button isn’t always feasible.
For deployment, at worst a device may get restarted but it only takes a few join attempts to catch up with the previous join value, at best the DevNonce is saved to be restored on the next join attempt.
So, I’d go with OTAA and press the MAC reset button or turn off checks via the CLI.
This was incredibly helpful, thank you. I will try to go ahead with OTAA without DevNonce checks and see how far I get.
I’m not sure I understand what you mean by this. Can’t all text be copied and pasted?