ChirpStack chose to report data on port 0.

11
Viewed 42

ChirpStack chose to report data on port 0, which resulted in my data reporting failing. However, in my code, I specified that data should be reported on port 2. What caused this issue?

1 Answers

ChirpStack does have a validation on downlink enqueue:

        if self.f_port == 0 || self.f_port > 255 {
            return Err(Error::Validation(
                "FPort must be between 1 - 255".to_string(),
            ));
        }

Most likely the received downlink with FPort = 0 is a mac-command only downlink. This behaviour is specified in the LoRaWAN specs.

No, it's me who uploads the data to the gateway, and then the gateway uploads it to the server. The normal way of uploading data uses port 2, and the data can be uploaded normally. But when I checked the log, I found that the uploaded data only used port 0, and there was no data at all. Looking at the log, I discovered that the data was uploaded to a gateway that was farther away from this node (with a lower RSSI). What could be the reason for this?

uploaded data only used port 0, and there was no data at all

This is because FPort=0 is for mac-command payloads which are handled by ChirpStack. What your application sees is an empty uplink (FPort=0) such that you can collect meta-data (RSSI, SNR). Note that mac-commands get priority over application payloads (per specifification). You can ignore these paylaods if you don't want to handle them.

What I mean is that my device was supposed to upload a 120-byte piece of data every hour. Usually, port 2 is chosen for data transmission. But sometimes, for no apparent reason, port 0 was selected instead, causing me to lose the data that I was supposed to upload. What's going on here?