Payload intermittently missing in uplink message on the TTN console

TTN Network and Services The Things Stack v3
1

From time to time (once very 4-5 uplinks received), the payload is missing in the uplink messages that my nodes are sending to TTN console.

Capture d’écran 2023-01-05 à 16.50.31
Capture d’écran 2023-01-05 à 16.50.312978×406 121 KB

I noticed that when the upload is missing, the uplink message doesn’t include the frame port f_port. Below is a copy of one uplink with missing upload and one with payload included.

Is there an explanation for this and a fix to avoid that ?
Thanks much !

Example of an uplink with missing upload:

{
  "name": "as.up.data.forward",
  "time": "2023-01-05T16:20:10.454995553Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "hso-scale02",
        "application_ids": {
          "application_id": "ardbeescale-af01"
        },
        "dev_eui": "70B3D57ED0051F21",
        "join_eui": "0000000000000000",
        "dev_addr": "260B40CC"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "hso-scale02",
      "application_ids": {
        "application_id": "ardbeescale-af01"
      },
      "dev_eui": "70B3D57ED0051F21",
      "join_eui": "0000000000000000",
      "dev_addr": "260B40CC"
    },
    "correlation_ids": [
      "as:up:01GP1BQ62H7QZAT23PAXX4KJKP",
      "gs:conn:01GP12KEWDFMDE1XFSYADSBHC4",
      "gs:up:host:01GP12KEWK3C53CM5KTP7XQPH8",
      "gs:uplink:01GP1BQ5W0H5J1FHQ824GVVK3B",
      "ns:uplink:01GP1BQ5W1YMH9WBT6ETDR3Q0V",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GP1BQ5W17KB5QQ5EX7Y2E8TM",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GP1BQ62GHRX5QM2MRW8181NC"
    ],
    "received_at": "2023-01-05T16:20:10.448777374Z",
    "uplink_message": {
      "session_key_id": "AYV87/4xiG5e5LbzyR8ZRw==",
      "f_cnt": 109,
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "ttig-hso1",
            "eui": "58A0CBFFFE802B8B"
          },
          "time": "2023-01-05T16:20:10.171525955Z",
          "timestamp": 967737180,
          "rssi": -43,
          "channel_rssi": -43,
          "snr": 9,
          "location": {
            "latitude": 45.24887845795117,
            "longitude": 5.825484395027161,
            "altitude": 380,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChcKFQoJdHRpZy1oc28xEghYoMv//oArixDc/rnNAxoLCLrx250GEMDNxnIg4P6FjZWWAg==",
          "received_at": "2023-01-05T16:20:10.200606405Z"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "867700000",
        "timestamp": 967737180,
        "time": "2023-01-05T16:20:10.171525955Z"
      },
      "received_at": "2023-01-05T16:20:10.241305168Z",
      "consumed_airtime": "0.046336s",
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "eu1",
        "cluster_address": "eu1.cloud.thethings.network"
      }
    }
  },
  "correlation_ids": [
    "as:up:01GP1BQ62H7QZAT23PAXX4KJKP",
    "gs:conn:01GP12KEWDFMDE1XFSYADSBHC4",
    "gs:up:host:01GP12KEWK3C53CM5KTP7XQPH8",
    "gs:uplink:01GP1BQ5W0H5J1FHQ824GVVK3B",
    "ns:uplink:01GP1BQ5W1YMH9WBT6ETDR3Q0V",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GP1BQ5W17KB5QQ5EX7Y2E8TM",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GP1BQ62GHRX5QM2MRW8181NC"
  ],
  "origin": "ip-10-100-5-128.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01GP1BQ62PCX0JQ5G7PSKWE86X"
}

Exemple of a complete upload as it should always be:

{
  "name": "as.up.data.forward",
  "time": "2023-01-05T16:05:03.455826439Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "hso-scale02",
        "application_ids": {
          "application_id": "ardbeescale-af01"
        },
        "dev_eui": "70B3D57ED0051F21",
        "join_eui": "0000000000000000",
        "dev_addr": "260B40CC"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "hso-scale02",
      "application_ids": {
        "application_id": "ardbeescale-af01"
      },
      "dev_eui": "70B3D57ED0051F21",
      "join_eui": "0000000000000000",
      "dev_addr": "260B40CC"
    },
    "correlation_ids": [
      "as:up:01GP1AVGAV9BZNZB0Z85HTVBRX",
      "gs:conn:01GP12KEWDFMDE1XFSYADSBHC4",
      "gs:up:host:01GP12KEWK3C53CM5KTP7XQPH8",
      "gs:uplink:01GP1AVG4EZ73D9DNATFBGHWBA",
      "ns:uplink:01GP1AVG4E3RYRWZR21CGG9PQE",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GP1AVG4EQVTG16BV9JXZDRM4",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GP1AVGAT555B7SJRB8WYJAY3"
    ],
    "received_at": "2023-01-05T16:05:03.451087768Z",
    "uplink_message": {
      "session_key_id": "AYV87/4xiG5e5LbzyR8ZRw==",
      "f_port": 10,
      "f_cnt": 108,
      "frm_payload": "BQD5bDxSVQAC",
      "decoded_payload": {
        "humidity": 60,
        "internalTemp": 15.2,
        "lastDownlink": 0,
        "pressure": 982,
        "temperature": 15.53955078125,
        "voltage": 3.4,
        "weight": 10
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "ttig-hso1",
            "eui": "58A0CBFFFE802B8B"
          },
          "time": "2023-01-05T16:05:03.178865909Z",
          "timestamp": 60748692,
          "rssi": -46,
          "channel_rssi": -46,
          "snr": 7.5,
          "location": {
            "latitude": 45.24887845795117,
            "longitude": 5.825484395027161,
            "altitude": 380,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChcKFQoJdHRpZy1oc28xEghYoMv//oArixCU5/scGgsIr+rbnQYQ7ZGZdSCg9J2n4vsB",
          "received_at": "2023-01-05T16:05:03.206152946Z"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "867500000",
        "timestamp": 60748692,
        "time": "2023-01-05T16:05:03.178865909Z"
      },
      "received_at": "2023-01-05T16:05:03.246683098Z",
      "consumed_airtime": "0.056576s",
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "eu1",
        "cluster_address": "eu1.cloud.thethings.network"
      }
    }
  },
  "correlation_ids": [
    "as:up:01GP1AVGAV9BZNZB0Z85HTVBRX",
    "gs:conn:01GP12KEWDFMDE1XFSYADSBHC4",
    "gs:up:host:01GP12KEWK3C53CM5KTP7XQPH8",
    "gs:uplink:01GP1AVG4EZ73D9DNATFBGHWBA",
    "ns:uplink:01GP1AVG4E3RYRWZR21CGG9PQE",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GP1AVG4EQVTG16BV9JXZDRM4",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GP1AVGAT555B7SJRB8WYJAY3"
  ],
  "origin": "ip-10-100-5-128.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01GP1AVGAZQHFPF9S3Y469EM7S"
}
2

This is the essential clue to what is happening :slight_smile:
That means that the fport value was 0. Somehow TTN leaves out fields that are zero in its JSON messages. Fport 0 is used for MAC commands in LoRaWAN and these packets don’t carry user data (AFAIK), this could be link management responses for automatic-data-rate (ADR) for example.

You could just ignore it in your application or payload decoder. I don’t know if or how you can suppress upload of these fport 0 message.

3

Thanks for the explanation.
My application can easily ignore those uplinks with missing payload. But the payload is lost and I wonder how to avoid that. Any clue ?
Thanks

4

The “consumed_airtime”: “0.046336s” for the packet missing a payload suggests a packet size of 17 bytes.

Assuming port 0 with 4 MAC command bytes.
Or a frame with 5 MAC command bytes and no FPort byte.

Since your data packets are larger than 17 bytes, the node is sending a packet you are not expecting.

Do you have any record of a downlink sent to the device from the network?
Or a gateway record of the raw uplink frames?
Do you have insights into the node firmware, will it send payload with MAC commands?

5

There is no payload. This is a LoRaWAN stack internal admin only (MAC) packet. If you are trying to send an uplink at that time there might be an issue in the device code, otherwise this is perfectly normal and nothing to worry about.

6

@kersing : my nodes are sending an uplink with a payload every 15mn and once every 4 or 5 times (sometimes more) instead of an uplink with the expected payload, the TTN console shows an uplink w/o payload. In other terms, the expected uplink with payload seems to be replaced with an uplink w/o payload. When this happens, I am loosing a payload.
Can that be due to a problem in my code ? Again, the issue is intermittent.

@jreiss: my nodes are actually sending 9 bytes. I am using the code from Lopes Parentes

Here is a copy of a downlink (you asked for it but my problem is with uplinks, not downlinks):

{
  "name": "as.down.data.receive",
  "time": "2023-01-05T19:39:52.087914539Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "hso-scale03",
        "application_ids": {
          "application_id": "ardbeescale-af01"
        }
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationDownlink",
    "f_port": 100,
    "frm_payload": "RA==",
    "priority": "NORMAL",
    "correlation_ids": [
      "as:conn:01GP1Q4TVY54HXA62C70SREHZB",
      "as:downlink:01GP1Q4TWNBA5B229K7PWN2G09"
    ]
  },
  "correlation_ids": [
    "as:conn:01GP1Q4TVY54HXA62C70SREHZB",
    "as:downlink:01GP1Q4TWNBA5B229K7PWN2G09"
  ],
  "origin": "ip-10-100-12-196.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "authentication": {
    "type": "Bearer",
    "token_type": "APIKey",
    "token_id": "E5LAS7FKQAFUHNPXIDRKQOBAAFSCLGQPZIJE5SI"
  },
  "unique_id": "01GP1Q4TWQCVKR5YN223XRMRQZ"
}
7

These are MAC commands/packets, it is for LoRaWAN house keeping, no need to be concerned about them.

They have nothing to do with your application, they are there to set your node. No need for concern.

Here you can see them as well in my application.

image

8

OK, but what puzzles (and annoys) me is the fact that these “house keeping” uplinks are actually replacing some of the uplinks that my nodes are sending. Look at the picture in the beginning of this post: hso-scale02 is sending an uplink every 15mn. I actually get two successive uplinks 15mn apart but one of them doesn’t contain payload and seems to be “house keeping” instead.
Can that be a problem in my code ?

9

That is the first thing I think you should look at. Add debugging to your code to show what should be transmitted so you are sure the stack gets actual data (and what data).

10

You should look at your code… what node/software/library are you using?