Not sure if LMIC is responding to MAC request from gateway #742
-
|
In my program I set the data to be sent using "LMIC_setTxData2" and run "os_runloop_once()" until "LMIC.opmode & OP_TXRXPEND" return true. I can see my data (highlighted in yellow) being sent to the gateway. It was all working great but recently I discovered the gateway is sending a downlink to my device (highlighted in pink) every time. Which indicates my device should respond to that? Since I am seeing I thought the MAC command will be processed during the TX event, so my device basically goto sleep after "LMIC.opmode & OP_TXRXPEND == true". I suspect this is the issue since I am not running "os_runloop_once()" all the time. Am I stopping at the wrong flag or I am missing some flag that I also need to wait? To understand the issue I have, I print out "LMIC.pendMacLen" and the data in "LMIC.pendMacData[]", they are: I try "LMIC_sendAlive()" with the intention of sending the pending data to the gateway but the function return immediately and I cannot see the payload arriving at the gateway. What should I do to make LMIC send the pending MAC response to the gateway and correctly process it? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
I manage to solve the issue by running "os_runloop_once()" until the next TXRX event if "LMIC.pendMacLen>0", now the device is responding to MAC command correctly. Is there any method for me to get the exact time of the next TXRX event so that I can enter standby during the waiting period? |
Beta Was this translation helpful? Give feedback.
-
|
You need to call os_runloop_once() continuously in a loop. I've submitted a PR to add a method os_timeToNextTimeCriticalJob() that allows you to find out how long you can sleep for here: #641 |
Beta Was this translation helpful? Give feedback.
-
|
For a variety of reasons, I've been reluctant to add an explicit API: you have to check two return values (is there a job scheduled, and if so how long it will be). This is even more trouble-prone, in my experience, than the current situation. There's a very workable API, |
Beta Was this translation helpful? Give feedback.
-
|
In any case, this problem is not a bug as described. Converting to a discussion. |
Beta Was this translation helpful? Give feedback.
For a variety of reasons, I've been reluctant to add an explicit API: you have to check two return values (is there a job scheduled, and if so how long it will be). This is even more trouble-prone, in my experience, than the current situation.
There's a very workable API,
os_queryTimeCriticalJobs(), which tells you whether you can sleep for a given period of time. It's not ideal, but it's correct, and it's very hard to get the use of the API wrong. It can be used while I think about whether I want to provide yet another API that ties us to the current implementation, or replace the current implementation with something more suitable.