Hey all,
Im testing out The Things Network Arduino library (for The Things Uno)
I cannot find in the library where to access the Rn2483 mas set bat so we get a battery level when it receives a DevStatusReq from the network.
I see that the device does reply to this message with DL margin and battery level = 255.
It would be great if anyone has exposed this in a sketch.
Cheers
P
OK I tried this: in the .CPP
sendMacSet(MAC_BAT, “128”);
which seems to work.
It would generally be better to periodically slip a battery reading into an ordinary uplink.
The reason is that TTN can only send a downlink query in response to an uplink, and downlinks are fairly expensive of network capacity.
So really it’s better to periodically send this information unprompted, than to have to expensively ask for it.
Depending on how you do things, you can either use a different port number to tell packets with a battery status apart, or just have your parsing code notice the fact that a packet is an extra byte long. Worth noting too that the 4/5 coding means that sometimes adding a byte doesn’t add any airtime and is entirely “free”, until you hit the threshold where another coding group is added and the airtime cost dramatically jumps up; playing with the airtime calculator when contemplating packet designs is wise (make sure you are including the protocol overhead bytes though!)
1 Like
Thanks for the response!
Yes I agree for TTN.
I worked something out and added a quick and basic function for my needs. (Im testing using my own Chirpstack network here).
Its a good library and im really happy to see that ADR can be turned off as well it having LinkCheck (LMIC seems lack this feature) So I have the option to make up my own ADR.
Chalk & cheese - the ThingsUno uses a Microchip LoRaWAN module (RN2483) to handle the protocol, LMIC is software that actually runs on the main microcontroller. This may not be relevant right now, but may come as a surprise at a later date if you need to move to a different board.
Using DevStatusReq & making up your own ADR may feel like a good move, but anything that increases transmissions on these frequency bands impacts all users.
For a newly deployed node, you need only transmit battery voltage once in a blue moon or if there are any substantive changes. Only near end of life does the battery status need to be more frequent, the irony being that could speed up its use, but as you already have a ballpark figure, you only need send a single byte (or less) in your uplink.
The ADR scheme is already well thought out and there are other potential schemes - including turning it off if the application server knows the device is being heard by two or more gateways with good reception. See some thoughts on this here: TTN linkCheck command - #4 by descartes