Is there some “simple” documentation available for the LMIC library. I found a PDF on Github but that’s not what im looking for. I’m just a PHP developer and starting in C, but where making progress
What is see is that people strugling with the library where to put there own code in the sample’s. Normally you put your code in de void_loop() section. But in all the samples i see it in the EV_TXCOMPLETE of the select case statement.
What i’m looking for:
Description of what the functions/procedures do.
Like for example:
os_runloop_once() or os_runloop() what are the differences and when do you need to fire them.
os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send) what does this exactly. I know i can schedule when the do_send is fired.
What i’m trying to reach:
I want to make one basic sketch with for example the following functions:
LoraInit()
LoraJoinAPB()
LoraJoinOTAA()
LoraSend()
LoraReceive()
LoraSleep()
and on
I think the community will have there benefit from it. And surely the beginning C programmers
Hi, I agree on the library complexity. At least one the the PDFs around is “simple”, though not easy to apply without examples at hand. However, there you can find answers to the specific questions you are asking.
Regarding a wrapper for LMIC, I think it would be welcome, however there has been already some attempts (I remember to have crossed something on Github, but never switched to them).
Hi @basvaningen, How are you? Have you made any progress with this? Were you trying to joining the ABP and OTTA connection?
I’m trying to create code that changes the connection automatically. Example. 30 minutes connected and transmitting in OTTA to TTN, after that, 30 minutes connected in APB and so on.
Why in the world would you ever want to do that???
This is a very, very, very bad idea. The whole point of OTAA is to accomplish a joining process which should happen with exceeding rarity - ideally only once in the entire lifetime of the device. And the point of ABP is to simply hard code what would be the result such that it never needs to happen.
Toggling modes is severely unwise, produces unecessary excess traffic load on the network, and drastically decreases reliability, to no benefit of any sort whatsoever.
@cslorabox … Uoool, haha You are absolutely right, I am playing with my project, trying to understand the MCCI library better. But I changed my mind, at least a little. I want to have a unique code, which after recording is possible through the serial, configure keys and determine the connection, ABP or OTTA. I understand serial communication well, this is no problem, but not the library. What in the device define if the connection is OTTA or ABP? I didn’t find anything specific in the source code, what changes from one to the other are the keys … I’m using the examples from the MCCI 3.2 library… You can help-me ?
First, there is no “connection”. Second, OTAA and ABP are only used to activate the device and, for OTAA, possibly get some network settings. Once activated, there is no difference between OTAA and ABP devices†. And they still don’t have “a connection” but will just transmit when they want, hoping one or more gateways will receive their transmission and forward it to TTN. This is general LoRaWAN, not specific for LMIC.
In a way, one could say that LMIC is OTAA-only: if you schedule a packet using LMIC_setTxData2 then when it’s time to transmit, LMIC will always first do an OTAA join if it has not been activated yet. That is: if it has no session keys yet. There is no choice: LMIC always does OTAA then, and at that point things fail if you did not program the OTAA details into the device.
To avoid that, one can manually invoke LMIC_setSession first. That, for example, is required for an OTAA device that already joined earlier, but for which the state is not kept in memory during deep sleep. (And then there’s more to restore than just the session secrets, most importantly the frame counters but much more; see How to persist LMIC OTAA parameters with an ESP32? - #12 by jofleck)
So, when one explicitly wants ABP rather than OTAA, then one can call LMIC_setSession before scheduling the first packet. This way LMIC also supports ABP.
I’m sure one can figure out from the LMIC internals if it last activated using OTAA or LMIC_setSession. But as you already know in your own code, the question would be: why?
† Well, except that an OTAA device might easily re-activate if ever needed, and then by design gets a clean state on the network. When resetting an ABP device then all sorts of state mismatch will happen between network and device, most notably the frame counters being reset in the device but not on the network. Go OTAA.
