Missing link margin and Battery

Hello, I am a collaborator of a technical office that deals with remote reading.
At the moment we only read one type of module applied on water meters, to be exact the module is RFM-LR1 by Bmeters.

In particular, I am writing to you and asking for information about a couple of things found on the Chirpstack portal.

A) Some of these modules join with our network server but do not report any Link margin and Battery information. I am attaching screenshots

B) Is it possible to move a module that has performed the join from an X application to a Y application always under the same network server? We have done this by removing the module from application X and putting it back on application Y but this module after this operation is no longer read by the gateway.

thank you in advance, greetings
Mattia

Please help keeping the forum organized by not mixing multiple questions in one topic. To answer your first question:

do not report any Link margin and Battery information

Please check the service-profile, there you can configure how often a DeviceStatusReq is sent to the device and what info must be reported to the AS.

1 Like

Nice. I didn’t realize that either. I changed the frequency from 0 to 1, and now get some info :+1: . I will have to think about what it is telling me though, as the batteries reporting back as “39.37%” are CR2032 3V powered devices and are at well over 3.0V (3.1V actually)… Should be much closer to 100%?

I think this might be device dependent how the battery value is measured…

I think you are right (the data seems to support that at least).

No worries! It still updates and trends - so it is useful even if I need a decoder ring for specific devices. :+1:

HI,

I can’t link the RFM-LR1 meters to our server, could you tell me how you did it and what lorawan version it is?

I have tried with several but I can’t get it.

Thank you very much.

Hi Ivan
We are using this device profile:

Lorawan MAC Versione:1.0.0
LoRaWAN Regional Parameters revision: A
ADR algorithm: Default ADR algorithm
Max EIRP: 0
Uplink interval (seconds): 0

In Join (OTAA / ABP) section:
Device supports OTAA (selected)

Neither other parameters confgured.

In Application / Device section we uset:
Device Name and Device Description as is (eg 19901014)
Device EUI as is for 19901014 (eg 70b3d5d7200409c3)
Once created device, we set Device Key.

Usually we wait device joined under a gateway linked to interned by our office connection; only after device joined to our chirpstack server, device will be mounted to water piper.

Waiting your Idea
Best regards
Alessio

Thanks Alessio.

The Application Key in OTAA uses a MSB or LSB?. Now im trying with MSB.

Yes, Application Key in OTAA use MSB notation

OK,

I asked Bmeter which options I had to set and they told me it was 1.0.2 and A. As I have two water meters I will try both options.

If it doesn’t work, do you know what could be wrong?

I linked a different device and it worked.

Thank you very much for your reply.

Until sometimes ago, we used 1.0.2.
But after encountered problems with some devices, we got back 1.0.0.

Have you check gateway data log?
Are theese devices installed or are test’s devices on a desk?

The devices are test devices, the devices are at 10 meters and 20 meters from the gateway.

I saw this on the gateway logs:

16:49:32 UTC ##################
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ ### [UPSTREAM] ###
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # RF packets received by concentrator: 1
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # RF packets forwarded: 0 (0 bytes)
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # PUSH_DATA datagrams sent: 0 (0 bytes)
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # PUSH_DATA acknowledged: 0.00%
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ ### [DOWNSTREAM] ###
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # PULL_DATA sent: 1 (100.00% acknowledged)
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # RF packets sent to concentrator: 0 (0 bytes)
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # TX errors: 0
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # BEACON queued: 0
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # BEACON sent so far: 0
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # BEACON rejected: 0
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ ### [PPS] ###
Thu Apr 29 16:49:32 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ # SX1301 time (PPS): 2064668784
Thu Apr 29 16:50:02 2021 daemon.info lora_pkt_fwd[2870]: REPORT~ ################## Report at: 2021-04-29

Maybe the problem is here…

I have already linked these devices with the gateway (dragino lg308) and the TTN and although it was a bit difficult at the beginning, everything worked fine.

Well… The problema was the Re-join. I had to remove the battery to force a re-join. Now I have to look at the same thing that happened to you with the battery and the link.

Thanks.

You are right.
Re-join of this devices, without a correct unregistration, go under a particular procedure that foresees 30 day waiting period or remove batteries.
Please say me if you solve your issues doing it.
Best Regards

Yeah I solved the link and battery problem. Thank you!

Now I’m trying to decode the payload. Did you use the cayenne LPP or a custom javascritp code?

Hi Ivan
We not working under chirp-stack; we get queue messagees in real time and produce an external file with all informations needed that afterwards decode our application server.

OK, so you did a integration like http, mqtt, aws sns… right?

Yes Ivan, we developed an MQTT integration under chirp-stack network linux server with Perl.
Another application on the windows server, the application server, get theese data files, decode payload and status messages and update database under SQL server, so clients get data with IIS.
All developed on AWS cloud.