Class B switch procedure

[ingpjb]

Hi All,

Does anyone know of a document that accurately describes the procedure followed by a wireless device and the network when switching from Class A to Class B ?

The obvious action as given in the example applications is the LmHandlerRequestClass( LORAWAN_DEFAULT_CLASS ) function (where LORAWAN_DEFAULT_CLASS was set to Class B). This initiates a procedure comprising a few mandatory steps, like a DeviceTimeReq/DeviceTimeAns, PingSlotChannelRe/PingSlotChannelAns, actual BEACON reception and PingSlotInforReq/PingSlotInfoAns. But on some occasions the procedure gets stuck in an erroneous condition.

I've noticed it is necessary to send a few uplinks to trigger the various network responses, but sometimes I get stuck in an everlasting BUSY BEACON RESERVED TIME (I use a random uplink interval of 30 to 60 seconds). So, what is the official 'way to go'? Does one have to use an uplink interval greater than the BEACON_Interval (128s), or is the locked BUSY BEACON RESERVED TIME a bug? I also tried restarting the uplink interval every time the LmHandlerCallback OnBeaconStatusChange returned a status LORAMAC_HANDLER_BEACON_NRX, but this did not solve the problem.

If someone knows the answer, please enlighten me. Thanks in advance !

Peter

[djaeckle]

Hi @ingpjb ,

thanks for starting this discussion. Do you have some more information of how you enter the erroneous state? Is there a way to reproduce it?

[ingpjb]

Hello @djaeckle,

Till now I haven't found a way to force reproduction of the problem. The only thing I found is that during the actual class switch procedure the function LoRaMacClassBIsBeaconExpected(void) is regularly called (in LoRaMacClassB.c). This returns a 'true' whenever the beacon acquisition is still pending, or when the status is BEACON_STATE_RX. Whenever I run into the situation my device remains stuck forever the value for Ctx.BeaconCtx.Ctrl.AcquisitionPending remains 1 indefinitely. So the MAC layer never reaches the BEACON_STATE_LOCKED in the function LoRaMacClassBProcessBeacon(void) in the same file. This is the actual cause of my lock-up, but I haven't found out yet what causes this to happen.
Sometimes I get the 'busy beacon reserved time' a few times in a row, but in the end the system continues and a beacon is actually received and decoded. However, on some occasions this is not the case and a device reset is needed.

I hope this helps!

Peter