LoRa-E5 mini joining to network

I programmed the Seeed LoRa-5E Mini board from STM32CubeIDE and joined it to ChirpStack Gateway Bridge.


And all work for only two uplinks ended from that device. Next uplinks have problems:

90s041:VDDA= 254
90s045:TX on freq 868300000 Hz at DR 5
90s048:SEND REQUEST
90s120:MAC txDone
91s103:RX_1 on freq 868300000 Hz at DR 5
91s149:IRQ_RX_TX_TIMEOUT
91s149:MAC rxTimeOut
92s154:RX_2 on freq 869525000 Hz at DR 0
92s352:IRQ_RX_TX_TIMEOUT
92s352:MAC rxTimeOut.

From the point of view of the ChirpStack application server, it looks the following:

Every reset of LoRa-5E gives another device address.

The device address from the configuration in se-identity.h (when joining the gateway) differs from that the ChirpStack receives.

Is it wrong? What should I do to confirm uplink?

If the node uses OTAA, then every join will have a new address. This is correct.
The node will do a join after every reset. This is correct, too.

It looks like your node uses OTAA as there is JoinAccept and JoinRequest.
So the hardcoded device address will not be used.

Hardcoded device address is used when you use ABP.
OTAA is newer and prefer over ABP btw.

1 Like

@datnus
Thank you very much, so I will change STATIC_DEVICE_ADDRESS to 0.
But, looking into serial output when it has answers without timeouts. How to build a message to send VDDA and temp?
And why, after gateway responses only two times with UnconfirmedDataDown and after that, gateway responses with timeouts.

It could be that the two UnconfirmedDataDown are mac-commands (e.g. ADR) and after two downlinks, there is nothing more to send. As the device doesn’t receive any data on RX1 and RX2, it will show the timeout. Which is more to inform you that there wasn’t any data rather than that there was an error. This is just my assumption.