I am facing a problem that chirpstack receives packet from my end device with data = null through fport 0, while my device is configured to send data through fport2.
I’ve setup a LoRaWan gateway with the Things Network(TTN) and it received the payload correctly with fport = 2. The firmware of my end device used for testing on both TTN and Chirpstack were the same.
I wonder how to fix this problem. Do you guys have solution upon this question yet?
It is devastatingly urgent to solve this issue.
Chirpstack SHOULD received null data on fport = 0 because that’s used exclusively for MAC commands. See this TTN V3 bug, if you don’t believe me.
In my limited experience, only fport > 0 are valid for data. That is, most of my devices send data on fport 1…5, depending on intended meaning of data. This is a great way to minimize number of bytes sent out: “ff12” can mean battery voltage when sent on fport = 1, or firmware version number when sent on fport = 2, and can even signify actual sensor data when sent on fport = 3, for example.
Yes I believe you. I know that Chirpstack should never receive data on fport0.
My setting is: one device with SX1276, two LoRaWAN routers with two Gateway Bridge respectively: Chirpstack and TTN.
When I sent my data to TTN, TTN received our packet with the whole customized payload, with fport2 as programmed. While when I sent my data to Chirpstack, Chirpstack received our packets with data:null, and with fport0 for no reason.
do you guys think of any possible case causing such issue?
Is there any possible scenario that Chirpstack would automatically change the fport to zero?
I configured my device to send payload to LoRaWAN gateway through fport2 and it succeeded on TTN.
While I could never get my payload transferred to Chirpstack. Chirpstack recognized my packet but with no data, and it showed that the packets were from fport2.
I have no clue how to fix the problem or even dig into the problem right now. Do any of you get any hunch or insight on fixing this problem?
I know that Chirpstack should never receive data on fport0.
That is wrong, Chirpstack should never receive data on fport0.
I already answered this question in an other topic where the same was asked. In summary, fport = 0 is used for mac-commands in the frmpayload field, thus mac-layer data. ChirpStack exposes these fport = 0 uplinks to the end-application as even they don’t contain data, the RX meta-data (RSSI, SNR, …) can be very useful. If you are only interested in fport = 2, just ignore these message.
Thanks for clarifying that fport 0 is for mac-layer data.
Yes at the moment I am only interested in fport = 2, and I found out the actual situation already.
I think you may be one of the expert or active member here. In case you have never come cross a problem like mine, you may take my answer and help the others.
I have been searching for a fix including browsing in this forum but yet I didn’t quite see an answer here even if someone has asked similar questions.
I am not authorized to manage the Chirpstack gateway bridge. I had been able to send 30 bytes data to the gateway but not suddenly after some time. Finally I found that the authorized party did some changes on the gateway bridge and limited the size of data to process.
Therefore, if someone is having similar problem, you may want to try sending less data to the gateway to see what happen.
The cause/reason: If Chirpstack gateway bridge receives data packets larger than allowed size, the fport would be automatically changed to zero and no data shall be processed.
First off, the gateway bridge does no processing at all, only format translation between two different backhaul protocols. The transcribed radio packet itself, where both the fport and any payload are found is copied through entirely unaltered and not even interpreted - it’s just “I heard this on my antenna”. Processing only happens in the central servers. But even there, this kind of change is not made.
Packets sent on port 0 are network housekeeping traffic, likely part of a series of settings and confirmations between Chirpstack and your node’s LoRaWAN stack. They don’t contain application data, but they’re still important, having either an ack bit or a more meaningful response in the fOpts rather than they packet payload field. If there is network housekeeping traffic that needs to be sent up, and it cannot be attached to an ordinary application data packet (retaining that packet’s non-zero fport), then a typical node’s LoRaWAN stack will either send that instead of any requested application packet, or autonomously on its own, as a housekeeping-only packet on fport 0. A situation where the combination of housekeeping content and application payload would exceed the legal maximum (for that spreading factor, bandwidth, and location) is one where the stack would have to send the housekeeping traffic instead rather than as well. But it’s the node’s own LoRaWAN stack doing that - Chirpstack is NOT altering a message already transmitted. The one way that Chirpstack is involved is that the details of the conversation between network server and node would be different for different servers - Chirpstack and TTN aren’t going to be having exactly the same conversation in the same way, even if they need to send similar configuration down to the node.
If you want to understand exactly what is going on, you’ll need to post the full details of one of these packets, and also any downlinks preceding it.
Remember also that a given node can only be registered with one of Chirpstack or TTN at a time - if it were registered with both, completely chaos would ensue.
Hello experts!
Using custom firmware based on the Murata 1SJ module, I’m experiencing a very similar phenomenon as the OP of this thread - Uplink packets with a FRMPayload size > 11 are SOMEWHERE in chirpstack, having their fPort changed to 0 and their data discarded. These packets are valid packets with FPort=2 when transmitted.
For this example I’m using CayenneLPP, but I have other sensors that use a custom JS decoder and payload format with the same result.
I’ve just (yesterday) setup chirpstack on a RAK 7244P RPI gateway that had been working with the same sensors on TTN. FYI - completely new SDCard and OS on the PI: chirpstack-gateway-os-full
If I change nothing in firmware except the payload size from 11 to 12 bytes, the FPort is changed (from 2) to 0 and the data payload is no longer decoded and is null.
I’m happy to include whatever logs, or other material to get this diagnosed as I REALLY want to use some of the awesome functionality in chirpstack as opposed to being oppressed the (TTN) man!
Thanks in advance for any insight you might be able to offer!
While stepping through the end node’s code, it looks like the issue has to do with DR0’s max payload constraints, though I’m not sure that ST/Semtech’s implementation doesn’t have a bug or an “unexplained feature.”
Sorry for the chirpstack “dis”
the backend sends a mac-request to the device on the downlink
the next uplink is: 11B user payload + answer on mac-request
→ mac-payload is calculated as part of the user-payload (must be within these 11B)
→ the mac-payload is going to be prioritized
→ the user-payload will not be attached
→ only the mac-payload will be send
→ mac-payload only is sent on FPort0 (source I don’t know anymore)
→ on the next uplink there is again the user-payload if no mac-payload is going to be send
We hae only seen this on DR0 because the limitation of the user-payload length only affects there, on DR1 51B is possible.
BR
