LoRaWAN v1.1 implementation attempt

[juansulca]

Hey,
I'm a student trying to adapt this implementation to work with LoRaWAN v1.1 specification. Currently, I am stuck with this and would be glad to get any help from more experienced people. My plan is to release this modified version to the public if I get it to work. My problem right now is that I get my device to send a join request and the gateway is able to process it and send a join accept that for some reason does not get to the device.

[terrillmoore]

My guess is timing. What board and radio are you using?

[juansulca]

I am using a TTGO LoRa32, but the problem was the gateway and servers. I solved it this week. Now I am able to receive the join accept, calculate the keys, and send an uplink. I am only missing sending a mac command on every uplink confirming the device joined the network.

[terrillmoore]

Congratulations. You might want to look at the compliance specs for 1.1, and adjust the compliance sketch if needed for 1.1 use. You might also want to look at the issue578 branch which not only adds secure element support, but refactors and adds 1.1 support for the multiple keys. If you rebase your work on that branch, we might be able to pull it in (and that gives me a test for the multiple key support).

Meanwhile, the LoRa Alliance has pushed out 1.0.4, which I've not digested, but apparently changes things somewhat again for "plain old 1.0.x".....

[juansulca]

Nice, I will check that out when I am done with v1.1 implementation. Any suggestion about where I should put the put_mac_uplink_byte2 so that I can send a mac command with a 1-byte payload on each message until the NS responds with a mac command. Already figured out where to get the command when the server replies, but no clue where I should call the function put_mac_uplink_byte2.

[terrillmoore]

The put_mac_uplink_byte* family is not used in that way. It's use for building the responses (use Visual Studio Code and do a search, you'll see quickly). This is fundamentally different than building an uplink request de novo, because there are numerous considerations (including not losing user data, and making the code analytically correct to the best of ability).

If you need to send a mac command (rather than reply to one), you need to look at the code for other commands that initiate uplink mac commands. LMIC_requestNetworkTime() is a good example, and you can find all the places touched by searching for LMIC_ENABLE_DeviceTimeReq. Synopsys: you need to set a flag that you want to do this; and later when constructing an uplink, you have to add code that checks the flag and adds your request. Finally, you need to trigger an uplink (as a class A device) to ensure that your message goes out. LMIC_requestNetworkTime() dodges the problem a bit by just setting a flag; the user decides whether to initiate an uplink. Null uplinks are initiated by LMIC_sendAlive(), which sets OP_POLL and calls engineUpdate(). engineUpdate() is safe to call recursively (i.e., inside the LMIC) as the recursive calls will set a deferred work flag and revisit it later in sequence. This was not always true....

One can chase bugs forever in the LMIC if one tries to change this structure, unless one replaces the forest of callbacks with an explicit finite state machine. If I ever get around to it, I hope to do that some day. But for now, you're pretty much stuck with the above approach.

[juansulca]

Thanks, now I get it. I will implement this and keep this thread updated.

[juansulca]

Update on the project

Got OTAA and ABP partially working with unconfirmed messages on Class A.

What is missing?

• Non-volatile storage for keys and counters
• Testing confirmed messages

[juansulca]

Update 2 on the project

Implementation is not perfect but at least it works.

1. OTAA and ABP working
2. Full class A support
3. Confirmed Uplinks and Downlinks working
4. Counters, DevNonce, and JoinNonce have interfaces to be stored in Non-volatile memory and retrieved.

Bugs

• ADR fails for some reason when using LoRaWAN v1.1