Why chirpstack send mac command LinkADRReq,NewChannelReq, despite with ADR disabled

ChirpStack (v4)
1

Hello

I have a device in SF9, which can sendi a big datagram sometimes(> 60octet). I want to keep this SF9, so the device frame tells to chirpstack ADR=FALSE
Ok, it rssi is strong, -68dBM, and I understand Chirstack want to change the ADR

And it what I see .Chirptack 4 try to send pending MAC commands to the device ( it sends a downlink after a uplink)

chirpstack::integration::mqtt: Publishing event topic=agsplorawan/as/00000000-0000-0000-0000-000000000003/device/00800000000255ea/event/up
data_up: chirpstack::storage::mac_command: Pending mac-command block set dev_eui=00800000000255ea cid=NewChannelReq
data_up: chirpstack::storage::mac_command: Pending mac-command block set dev_eui=00800000000255ea cid=LinkADRRe
.....
 chirpstack::gateway::backend::mqtt: Sending downlink frame gateway_id=008000000002a6ba topic=agsplorawan/ns/eu868/gateway/008000000002a6ba/command/down json=true

My first idea was to force chripstack so disable the adr in region_eu868.toml

    # ADR is disabled.
    adr_disabled=true

But it still do the same thing.

So I go into the redis DB, and I drop the keys containing pending command

drop device:00800000000255ea:mac:pending:3
drop device:00800000000255ea:mac:pending:7
.....

But at the next frame this pending mac keys reappear in REDIS and Chirpstack try to send it in return.

Maybe something is wrong in my understanding.

My small concern is that the device might change its Spread Factor and no longer be able to send its large 60-byte frames.

1 Like
2

Please note that a LinkADRReq can also be used to update channel-mask configuration of the device. Even if the device sends with adr: false, ChirpStack might still send a LinkADRReq mac-command to sync channel-mask related settings.

The NewChannelReq mac-command is not related to ADR.

You need to look at the content of the LinkADRReq mac-commands to understand what exactly ChirpStack tries to change. You can inspect the content in the LoRaWAN frames tab of the device.

3

OK
I’ve checked the CS-sent Mac sequence. It’s related to frequency and rx window…

Capture
Capture325×820 30.2 KB

However, there’s something unique about how these devices are activated. Currently, they got automatically deactivated by Chirpstack due to an extended period of being unplugged (> 30 days).

Essentially, we manufactured the devices, conducted tests, registered them on our CS network, and they retained their session. Subsequently, we dispatched them to the customer, who installed them after a lapse of 45 days. Consequently, Chirpstack deactivated them automatically.

As a response, we reactivated them through the Grpc API (using the last devadr, session, and network key)… and this process succeeded without requiring a new join sequence.

However, it’s possible that Chirpstack might be expecting something else. Consequently, it views the device as not being sufficiently initialized. So it trys to send something about freq channel and rx window ?

4

I think that when you reactivated the devices through the gRPC API, that ChirpStack will assume these devices are using the standard frequencies (868.1, .3 and .5) and thus re-sends the NewChannelReq mac-commands during the first downlink(s).

Once the device acknowledges these mac-commands, ChirpStack will not re-send these again during the lifetime of the device-session.

Note that you can increase the device-session TTL in the chirpstack.toml configuration file if you do not want the device-session to expire after one month (which is the default setting).

5

OK thank you very much.

I like to understand this kind of tricks…it always better
Thank for you work on chirpstack,

1 Like
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.