It’s not entirely clear from the manuals how the scheduling should work if I want to do anything other than send some test data
Does anyone have some code showing a simple application such as reading a temperature sensor or gps position and sending immediately after measurement?
I’m also interested to know how people deal with a power cycle on OTAA - is it ok to rejoin on every power cycle and carry out the key negotiation or should the session keys be stored? Is there an example someone can point to?
Yes, this is how OTAA is intended (and why it is easier than ABP, where you will have to save values).
You should be able to ignore the osjob scheduling thing from LMIC and just do your own thing in loop(), though the examples do not really show this yet. I’m planning to update the examples to something more clear in the coming weeks.
Beware the OTAA connection cycle will require air time from the gateway. It might happen the gateway cannot complete the connection process as there is no more time allowance to respond to OTAA requests. If you connect once a day, you probably do it with an OTAA, but in case you do it every couple of minutes, it is very likely at some point your node will not be able to connect. This will impact the others’ nodes as well.
When the SW1276 module is not used, LMIC can control the board and MCU to go to sleep, the system consuming only some µA. This way, you are sure your system will be able to shout its message when needed, using power for a brief instant, rather than starting a transaction potentially taking several minutes with potential unsuccessful outcome.
I have a few nodes doing temperature, barometric pressure readings and looking at the battery voltage and I put those in the do_send() function. In the ttn_abp example that’s where the data payload is initialized for the next transmission.
Apologies for resurrecting and old topic, however the title is exactly the one I would choose for my question .
LMIC examples almost always are made for sending data in a scheduled way.
I am interested in sending data only when needed (PIR, only when movement is detected, plus an heartbeat with battery every some hours). I did it on a MKR WAN 1300 with no issues, but I am in trouble with the LMIC model.
In particular, it is not clear to me what is needed and what not:
initialization: ok, os_init(), reset, set session…
I do not want scheduled sends, so I do not need os_setTimedCallback, but should I use os_setCallback instead, or no need?
os_runloop_once(): is this one that allows events to be processed? Shall I call at every loop cycle, even if I am not sending packets, to allow serving the queue?
Alternatively, I was thinking to schedule with a short time (0.3s or so, which is what I need for movement detection), and inside the usual do_send, I will send or not depending on PIR status.
Of course. I was thinking at scheduling the LMIC loop, inside which I will send only when I need (that it, way below the duty cycle limit). And by the way LMIC enforces restrictions, thus even if you set it, it does not send really.
The question was a different one: how to implement an asynchronous packet delivery with the LMIC model?
In the meantime maybe I found a way. I call os_runloop_once() continuously, but I am calling do_send() only when needed, with no explicit scheduling. This seems to function, although I am not sure how LMIC interacts with delay() calls (in the LMIC manual: " Jobs must not be long-running in order to ensure seamless operation").