Lora Node Uplink by event

[vAnArhist]

Hi all! I have ported Lwan stack to nrf52+sx1262. Node sends uplink packet every minute by LORAMAC_HANDLER_TX_ON_TIMER event successfully.

Is there any mechanism to send two consequent messages?
The reason I need this feature is that I implemented batching of messages, but need to send them one after another.

From the code I clearly see LORAMAC_HANDLER_TX_ON_EVENT, but cannot understand how it can be used. Will be appreciated for Your answers.

[danak6jq]

@vAnArhist do you have a repo you're willing to share? I started the port of LoRaMac to an RAK4631 module (nRF52840 + SX1262), it builds, but I'm at the point where I initialize I/O. I'd be delighted to test and contribute.

Sending batches of messages: your application code needs to maintain a queue of UL traffic and send them one at a time, the LoRaWAN stack won't do this for you. I've implemented this on the STM32WL FW derived from LoRaMac, though ST has a more substantial LMhandler layer.

I'd be happy to see if I could port this in your repo.

[vAnArhist]

Hi @danak6jq! Cannot share private repository due to policy, but basic init is from: https://github.com/insightsip/ISP4520-examples.

[danak6jq]

I just realized my code is built on the STM32WL firmware package from ST, I recall the LMHandler implementation is extended. So here's some guidance I can offer. Maintaining a queue of packets for UL requires a hook in OnTxData() [I believe/assume this is called in interrupt context] to indicate to the foreground application code to possibly retry (such as a Confirmed UL with no acknowledgment) or start transmission of the next packet.
In the STM32WL firmware, they provide a facility that looks like a scheduler (really isn't) that you can use to run a foreground "task" (it's not really a proper task). Here's an example of code in my OnTxData() handler that maintains a count of un-acked confirmed ULs to cause a re-join, as well as handle deferred sending:

static void OnTxData(LmHandlerTxParams_t *params)
{
  /* USER CODE BEGIN OnTxData_1 */

	// Handle notification on Confirmed UL
	if (params->IsMcpsConfirm && params->MsgType == LORAMAC_HANDLER_CONFIRMED_MSG) {
		if (params->AckReceived) {
			missedCount = 0;
		} else if (++missedCount >= maxMissedCount) {
			// XXX: start re-join
			UTIL_SEQ_SetTask((1 << CFG_SEQ_Task_LoRaStartJoinEvent), CFG_SEQ_Prio_0);
			missedCount = 0;
		}
	}

	if (deferredSend > 0) {
		// If send needs a retry, oblige
		UTIL_SEQ_SetTask((1 << CFG_SEQ_Task_LoRaSendOnTxTimerOrButtonEvent), CFG_SEQ_Prio_0);
	}

  /* USER CODE END OnTxData_1 */

UTIL_SEQ_SetTask() sets a bit that the foreground application loop uses to call a function in foreground context. The deferredSend scheme might be sufficient in your case if you don't need to keep a queue of time of time-sensitive measurements, but can do the measurement again.

[danak6jq]

You mention batching of messages, so you probably have a queue. On each OnTxData() completion, you'd set a status that results in the foreground code calling a "send next packet" function. Depending on how you want to use confirmed ULs, you might implement retry logic here as well.

Background:
LoRaMac applications are basically a spin loop in the foreground that drops into deep sleep when there's nothing to be done. An interrupt (timer, radio, etc.) wakes the MCU, the IRQ is handled and may ultimately end-up notifying the app, like OnTxData(), that's why these are in interrupt context (and you generally don't want to modify global state and/or call LMHandler functions there).

Once IRQ processing is complete, the foreground loop returns from sleep, and can check for indications from IRQs, process them, before returning to sleep. This is where your queue processing would be done. Since the queue processing is sequential and in the foreground, it's not too complicated.

[yaswanthsk04]

Hi @danak6jq and @vAnArhist ,

Thank you both for the insightful discussion! I'm currently facing a similar challenge where I need to send multiple consecutive messages via LoRaWAN. I’m wondering if either of you could provide a reference code or additional insights into how you handled message batching and retries, particularly sending consecutive messages efficiently?

Your help would be greatly appreciated!

Thanks in advance!