Device-status (margin and battery)


#1

I want to know what exactly does the ReportDevStatusBattery do? In term of MacLayer. Actually, i want to send my device battery status to loraserver and read it on received JSON Payload but I don’t really know how to proceed.

I guess the ReportDevStatusBattery sets up a downlink with the MAC command “DevStatusReq” as it can do for ADR or ack message. Thus, the only thing I have to do is to check if my end-node support the reception of this MAC-command (which is probably not (LMIC node)) Then I have to send a MAC-command DevStatusAns from my device with the correct payload ? And the server will automatically read this mac-command ?


#2

You need to configure this in the service-profile. LoRa Server will then periodically send a downlink device-status request to your devices, and your devices report back. Please refer to the LoRaWAN specification on the internals. How the margin and battery status are set by your device is device / firmware specific.


#3

Hello. When using DevStatusReq MAC-comand, my LoRaserver gets 2 node parameters: “battery” and “margin”.
“battery” is the level of the node’s battery. But what is the field “margin” (the meaning I get is -30 dB)? My Lora-server-app shows it to me as a Link Margin. But the real link margin must be over 0. If not, and the level of the incoming signal is lower than the sesivety of the reciever, the reciever couldn’t recieve this message. So, my question is what is the “margin” I get through DevStatusReq MAC-comand? And why does Loraserver call it “link margin”. Thank you for your time.


#4

Hi, same question here. getting negative link margin for my nodes. Would be great to have explanation. thanks


#5

You should add some debug output to the code in your node which answers the request. There are typical a number of conversions involved, as the SX127x RSSI register output itself has an offset, and the software may try to pack intermediate values into a single byte where they may not fit without yet another offset.

The LMIC code mentioned earlier does have at least the beginning of support for this, using the value from the SX127x RSSI and a function to get the battery status which the integrator must add appropriate code to if it is going to do anything useful.

Also consider putting at least battery information in routine measurement packets so that you don’t have to downlink to ask for it, and because watching battery over time is a good idea anyway.


#6

Thanks. Will consider the option to include battery data in payload