The overall trend I’ve seen is that there are virtually no modifications available to many aspects of the data formats - not unsurprising given that TTN processes ~1000 uplinks a second (which is where the gateway data would be present) and that gets consolidated down to ~200 uplinks processed through the application server. Any parameters to modify the packets would have to be held in memory and then an extra process to apply them.
I can understand somewhat why we have an include filter on the outgoing web hooks - the hot mess users have generated with the Payload Formatter made it almost trivial to extend that.
My feeling is that we tend to get everything, even if it takes time to understand how it all pieces together - the meta data with the correlation_ids & many timestamps allow a level of audit that I can’t see anyone needing to use given the reality of overall packet loss.
So you can see a complete unredacted but some elements truncated for brevity, here’s a uplink:
{
"name": "as.up.data.forward",
"time": "2024-10-09T09:53:04.788975701Z",
"identifiers": [
{
"device_ids": {
"device_id": "noder-loradio32-1",
"application_ids": {
"application_id": "ttc2024demo"
},
"dev_eui": "70B3D57ED80035E6",
"join_eui": "DE5CA70000000000",
"dev_addr": "27FDD9B8"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
"end_device_ids": {
"device_id": "noder-loradio32-1",
"application_ids": {
"application_id": "ttc2024demo"
},
"dev_eui": "70B3D57ED80035E6",
"join_eui": "DE5CA70000000000",
"dev_addr": "27FDD9B8"
},
"correlation_ids": [
"pba:uplink:01J9RB4HHHKY4B026D5GEF33AW"
],
"received_at": "2024-10-09T09:53:04.784043652Z",
"uplink_message": {
"session_key_id": "AZJwi+FwnymyEfCkhJzhTQ==",
"f_port": 1,
"f_cnt": 9,
"frm_payload": "IzAwMDA4",
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "packetbroker"
},
"packet_broker": {
"message_id": "01J9RB4HHHKY4B026D5GEF33AW",
"forwarder_net_id": "000013",
"forwarder_tenant_id": "ttn",
"forwarder_cluster_id": "eu1.cloud.thethings.network",
"forwarder_gateway_eui": "DE5CA70000000001",
"forwarder_gateway_id": "descartes-m2m-tele-2",
"home_network_net_id": "000013",
"home_network_tenant_id": "relay",
"home_network_cluster_id": "eu2.cloud.thethings.industries"
},
"rssi": -78,
"channel_rssi": -78,
"snr": 9.2,
"location": {
"latitude": 53.57020214072325,
"longitude": -2.460822713267241,
"altitude": 191
},
"uplink_token": "C--snip--w==",
"received_at": "2024-10-09T09:53:04.558686389Z"
},
{
"gateway_ids": {
"gateway_id": "packetbroker"
},
"packet_broker": {
"message_id": "01J9RB4HHTBEM6YG7QFQHTRK9F",
"forwarder_net_id": "000013",
"forwarder_tenant_id": "ttnv2",
"forwarder_cluster_id": "ttn-v2-legacy-eu",
"forwarder_gateway_eui": "DE5CA70000000000",
"forwarder_gateway_id": "eui-de5ca70000000000",
"home_network_net_id": "000013",
"home_network_tenant_id": "relay",
"home_network_cluster_id": "eu2.cloud.thethings.industries"
},
"rssi": -90,
"channel_rssi": -90,
"snr": 9,
"location": {
"latitude": 53.57029618,
"longitude": -2.46078611,
"altitude": 134
},
"uplink_token": "CC--snip--r=",
"received_at": "2024-10-09T09:53:04.565339273Z"
},
{
"gateway_ids": {
"gateway_id": "loradio1302-relay-demo-pf",
"eui": "70B3D57ED80035E8"
},
"timestamp": 270001085,
"rssi": -65,
"channel_rssi": -65,
"snr": 13.5,
"frequency_offset": "-146",
"uplink_token": "CiC--snip--rc=",
"channel_index": 7,
"received_at": "2024-10-09T09:53:04.585007973Z"
},
{
"gateway_ids": {
"gateway_id": "packetbroker"
},
"packet_broker": {
"message_id": "01J9RB4HJF3A2JSQ7MBJ8ZV897",
"forwarder_net_id": "000013",
"forwarder_tenant_id": "ttn",
"forwarder_cluster_id": "eu1.cloud.thethings.network",
"forwarder_gateway_eui": "EC656EFFFE000208",
"forwarder_gateway_id": "top-secret-product",
"home_network_net_id": "000013",
"home_network_tenant_id": "relay",
"home_network_cluster_id": "eu2.cloud.thethings.industries"
},
"rssi": -82.399994,
"signal_rssi": -82.399994,
"channel_rssi": -82.399994,
"snr": 12,
"location": {
"latitude": 53.570311,
"longitude": -2.4606596,
"altitude": 124,
"accuracy": 13
},
"uplink_token": "C--snip--r",
"received_at": "2024-10-09T09:53:04.589182532Z"
}
],
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7,
"coding_rate": "4/5"
}
},
"frequency": "867900000"
},
"received_at": "2024-10-09T09:53:04.577765171Z",
"consumed_airtime": "0.051456s",
"network_ids": {
"net_id": "000013",
"ns_id": "EC656E0000103598",
"tenant_id": "relay",
"cluster_id": "eu2",
"cluster_address": "eu2.cloud.thethings.industries",
"tenant_address": "relay.eu2.cloud.thethings.industries"
}
}
},
"correlation_ids": [
"pba:uplink:01J9RB4HHHKY4B026D5GEF33AW"
],
"origin": "ip-10-24-15-176.eu-west-2.compute.internal",
"context": {
"tenant-id": "CgVyZWxheQ=="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01J9RB4HRMJ5WKEGSKMC7W05ZP"
}
This device noder-loradio32-1 is on a Discovery instance to test out some new LW functionality. That instance has a gateway on it - loradio1302-relay-demo-pf. There are two gateways on TTN - descartes-m2m-tele-2 and top-secret-product. There is also a gateway on the old v2 cluster (for testing/monitoring) - eui-de5ca70000000000.
I think this provides a pretty comprehensive example of what you are likely to pickup - other combinations may exist and I haven’t cross referenced with your JSON so you may see other details.
All that said, what are you hoping to achieve. For me the “ultimate” monitoring logs lines for each gateway for an uplink with the signal quality, plus update the gateway record with last heard. I can then run scripts to check for devices only heard by one or two gateways and/or gateway overlap/coverage plus the obvious, missing gateway - which can either by just on a periodic check against last heard or for the more paranoid, when devices that are normally heard uplink but the gateway isn’t in the meta data.
So, what do you need?
. However I don’t think there are a lot of settings available however I am not an expert on the TTI offerings and what can be configured, may-be 