Getting next beacon/slot time in class B

[upwis-gabriel]

I'm working on a project where the end node is periodically uploading data (every X minutes) but still requires class B. The project is running on ST's modified version of the 4.4.7 LoRaMac release, but I believe the lower layers are basically the same.
Before transmitting the message, the device reads from a serial port, and that can take some time. I have found that it sometimes collides with the beacon or RX slot, causing issues. Therefore I would like to schedule around them, and need to know when they will happen. Is there a simple way to find the next scheduled beacon reception and RX slot?

[djaeckle]

Hi @upwis-gabriel ,

thanks for starting the discussion. In general, the stack does not have an easy interface to get the time when the next beacon or ping slot will occur.

However, the beacon transmission time is based on GPS and the periodicity is 128 seconds. Thus, if you know either the GPS time or you have once received a beacon, you can calculate the next occurrences.

For the ping slots, its not that easy, as the calculation of the windows depend on several parameters. Nevertheless, the stack provides a callback to the application layer to call the process function if a ping slot window will be opened. Actually, i see the use case that you would like to schedule you tasks around the class b operations, so would a functionality to easily track the timings be of interest?

[upwis-gabriel]

Hi!
I got around the issue by adding two functions to LoRaMacClassB.c

TimerTime_t LoRaMacClassBTimeToNextBeacon(void) {
#if ( LORAMAC_CLASSB_ENABLED == 1 )
	if (TimerIsRunning(&Ctx.BeaconTimer)) {
		uint32_t ttb = 0;
		if (TimerGetRemainingTime(&Ctx.BeaconTimer, &ttb) == 0) {
			return ttb;
		} else {
			return ~0;
		}
	}
#endif /* LORAMAC_CLASSB_ENABLED */
	return ~0;
}

TimerTime_t LoRaMacClassBTimeToNextPingSlot(void) {
#if ( LORAMAC_CLASSB_ENABLED == 1 )
	if (TimerIsRunning(&Ctx.PingSlotTimer)) {
		uint32_t ttp = 0;
		if (TimerGetRemainingTime(&Ctx.PingSlotTimer, &ttp) == 0) {
			return ttp;
		} else {
			return ~0;
		}
	}
#endif /* LORAMAC_CLASSB_ENABLED */
	return ~0;
}

They simply return the remaining time in the timers. It may not be the best way of solving the issue, but by checking if the returned value is more than x seconds I have reduced the issue of collisions between the LoRa stack and the rest of the functionality.
Outside of this case where other functionality interferes with LoRa or the other way around, I am not sure if there's much need for the ability to schedule around class B. If a gateway sends a message to a node during a ping-slot, is there a response window to time? If so there may be cases where there's not enough time between reception and the response window to perform an action, create a message, and then send it. Then the application could instead prepare before the slot.