Downlink on each unconfirmed uplink (ABP)

Sorry, I took the data from the gateway live data view.

In the devices live data I only see the uplink messages.
This is one of them:

{
  "name": "as.up.data.forward",
  "time": "2022-07-20T11:21:45.007710507Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "delbo-weather1",
        "application_ids": {
          "application_id": "espeasy-controller-tder2"
        },
        "dev_addr": "260B5C77"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "delbo-weather1",
      "application_ids": {
        "application_id": "espeasy-controller-tder2"
      },
      "dev_addr": "260B5C77"
    },
    "correlation_ids": [
      "as:up:01G8DNF998AXRPB0PDWWNZ1GGV",
      "gs:conn:01G88BR7CJQKR0MRK9TE4VX7GW",
      "gs:up:host:01G88BR7CYTEEK0HDHBBWA1CR8",
      "gs:uplink:01G8DNF92SQKXJBG1M3SGRDKE2",
      "ns:uplink:01G8DNF92TE32FSZ0ACQ4PNEVF",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01G8DNF92T4GTRF6264Z2FEXWY",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01G8DNF997HXBQW0873YQ75PY3"
    ],
    "received_at": "2022-07-20T11:21:45.000862923Z",
    "uplink_message": {
      "f_port": 1,
      "f_cnt": 12,
      "frm_payload": "AgAAAAFg5AIA",
      "decoded_payload": {
        "analog": 18.9536,
        "bytes": [
          2,
          0,
          0,
          0,
          1,
          96,
          228,
          2,
          0
        ],
        "header": {
          "IDX": 0,
          "plugin_id": 2,
          "samplesetcount": 0,
          "valuecount": 1
        },
        "name": "ADC",
        "port": 1
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "tbdev-ten-boer"
          },
          "time": "2022-07-20T11:21:44Z",
          "timestamp": 2612986171,
          "rssi": -79,
          "channel_rssi": -79,
          "snr": 7.25,
          "location": {
            "latitude": 53.278207181133865,
            "longitude": 6.687773903683085,
            "altitude": 12,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChIKEAoOdGJkZXYtdGVuLWJvZXIQu4L83QkaDAjIyt+WBhCZy636AiD4nPOQhtEo"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7
          }
        },
        "coding_rate": "4/5",
        "frequency": "868500000",
        "timestamp": 2612986171
      },
      "received_at": "2022-07-20T11:21:44.794157230Z",
      "consumed_airtime": "0.056576s",
      "version_ids": {
        "brand_id": "espeasy",
        "model_id": "espeasy-rn2483-node-class-a-abp",
        "hardware_version": "_unknown_hw_version_",
        "firmware_version": "1.0.3",
        "band_id": "EU_863_870"
      },
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "eu1",
        "cluster_address": "eu1.cloud.thethings.network"
      }
    }
  },
  "correlation_ids": [
    "as:up:01G8DNF998AXRPB0PDWWNZ1GGV",
    "gs:conn:01G88BR7CJQKR0MRK9TE4VX7GW",
    "gs:up:host:01G88BR7CYTEEK0HDHBBWA1CR8",
    "gs:uplink:01G8DNF92SQKXJBG1M3SGRDKE2",
    "ns:uplink:01G8DNF92TE32FSZ0ACQ4PNEVF",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01G8DNF92T4GTRF6264Z2FEXWY",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01G8DNF997HXBQW0873YQ75PY3"
  ],
  "origin": "ip-10-100-6-190.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01G8DNF99FN97ZYVVHFR3N0NFX"
}
  1. That’s JSON, see above
  2. It’s not a downlink, which is what we need to see, in verbose mode
  3. The problem is about the device, not the gateway …

That’s why I want to make sure these units will behave as they’re supposed to do before I let them free in the wild.
Right now these units are only sending data from my desk to debug this situation.
If they can’t be made to behave using ABP, I will not deliver them configured to use ABP.

I also found one with 1.0.5 firmware, which I will try later to make sure it is (or isn’t) a firmware issue.
Right now, I still leave the option open that I’m the one making the mistakes in any config or code.

Sorry, misunderstood the actual data I needed to grab…

Hopefully this is more useful.

RX parameter setup request:

{
  "name": "ns.mac.rx_param_setup.request",
  "time": "2022-07-20T11:31:45.211635658Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "delbo-weather1",
        "application_ids": {
          "application_id": "espeasy-controller-tder2"
        },
        "dev_addr": "260B5C77"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.RxParamSetupReq",
    "rx2_data_rate_index": 3,
    "rx2_frequency": "869525000"
  },
  "correlation_ids": [
    "gs:conn:01G88BR7CJQKR0MRK9TE4VX7GW",
    "gs:up:host:01G88BR7CYTEEK0HDHBBWA1CR8",
    "gs:uplink:01G8DP1K0XJ3MQ3S8803F61EWQ",
    "ns:downlink:01G8DP1KDTF2K6D7DAN6MVKFJR",
    "ns:transmission:01G8DP1KDTFS02CQR433GC5R7Y",
    "ns:uplink:01G8DP1K0YMS4Z6C9T4QB30M5F",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01G8DP1K0XYSR97YK78B9ZX7K0"
  ],
  "origin": "ip-10-100-7-211.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01G8DP1KDVXRG6BBNPF91002BX"
}

Link ADR request enqueued:

{
  "name": "ns.mac.link_adr.request",
  "time": "2022-07-20T11:31:45.211639135Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "delbo-weather1",
        "application_ids": {
          "application_id": "espeasy-controller-tder2"
        },
        "dev_addr": "260B5C77"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq",
    "channel_mask": [
      true,
      true,
      true,
      true,
      true,
      true,
      true,
      true,
      false,
      false,
      false,
      false,
      false,
      false,
      false,
      false
    ],
    "nb_trans": 1
  },
  "correlation_ids": [
    "gs:conn:01G88BR7CJQKR0MRK9TE4VX7GW",
    "gs:up:host:01G88BR7CYTEEK0HDHBBWA1CR8",
    "gs:uplink:01G8DP1K0XJ3MQ3S8803F61EWQ",
    "ns:downlink:01G8DP1KDTF2K6D7DAN6MVKFJR",
    "ns:transmission:01G8DP1KDTFS02CQR433GC5R7Y",
    "ns:uplink:01G8DP1K0YMS4Z6C9T4QB30M5F",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01G8DP1K0XYSR97YK78B9ZX7K0"
  ],
  "origin": "ip-10-100-7-211.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01G8DP1KDVPV95ZQP6ZJFW4AD7"
}

What I don’t get is that ADR is unchecked for this device
but apparently I do see ADR related data.

It seems to suggest to use a data rate of 3 for RX2 and a frequency of 869.525 MHz.
That’s what I have set here.
But when looking at the device profile, it seems to be set to a data rate of 0 and 868.525 MHz with desired set to 3 and 869…
Should I configure my device to use “0” and 868 MHz and then see if it accepts the packet from the gateway?
In other words, is my device template wrong?

N.B. I have tried using 868,525 MHz too, but not yet tried changing the RX2 data rate.

I’d fix one thing at a time and concentrate on the Rx2 issue as it isn’t entangled with channel plans.

The NS starts out with DR3 which will compete with your setting of DR0 (the Regional Parameter setting) and whatever you have on the device.

You need to program the device to match what you have set. So what are you telling the device for Rx2?

@adrianmares will explain the ADR as he’s already explained it twice to me and I’m just about grasping the details.

Not sure what happened here, but I now have seen several “Update end device” entries where flags are turned on and off without me changing anything in the devices settings.

{
  "name": "ns.end_device.update",
  "time": "2022-07-20T12:02:39.507783557Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "delbo-weather1",
        "application_ids": {
          "application_id": "espeasy-controller-tder2"
        }
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/google.protobuf.Value",
    "value": [
      "mac_settings.status_count_periodicity",
      "mac_settings.status_time_periodicity",
      "mac_settings.use_adr",
      "mac_settings.desired_max_duty_cycle",
      "mac_settings.max_duty_cycle",
      "mac_settings.supports_32_bit_f_cnt",
      "mac_settings.factory_preset_frequencies",
      "mac_settings.desired_rx2_frequency",
      "mac_settings.rx2_frequency",
      "mac_settings.desired_rx2_data_rate_index",
      "mac_settings.rx2_data_rate_index",
      "mac_settings.resets_f_cnt",
      "mac_settings.desired_rx1_data_rate_offset",
      "mac_settings.rx1_data_rate_offset",
      "mac_settings.desired_rx1_delay",
      "mac_settings.rx1_delay",
      "session.keys.f_nwk_s_int_key.key",
      "supports_class_c",
      "supports_class_b"
    ]
  },
...

I also stopped seeing the downlinks.
image

Did someone else change some settings for me?

I set it to DR3 and 869.525 MHz (that’s what it is set to now)
This is how it shows up in my device settings in the console:
image

The downlink is caused by two drifts and a quirk:

  • The difference in Desired Rx2 data rate index and Rx2 data rate index (3 vs 0) cause the NS to try to change the RX2 data rate index of the end device from 0 to 3 (SF12 to SF9).
    You can fix this by changing the end device MAC settings (setting the desired to 0, which seems to match your end device settings) then resetting the MAC state.
  • The difference in Desired Rx2 frequency and Rx2 frequency causes the NS to try to change the RX2 frequency from 868.525 to 869.525 MHz.
    Changing the (current) RX2 frequency from 868.525 to 869.525 should suffice. 869.525 is the default in the EU868 band (and I expect this device to use it as ‘default’) then resetting the MAC state.

I did the two fixes to the end device for which you posted the logs.

You don’t see this in OTAA because the RX2 data rate index and frequency are part of the JoinAccept message of the join procedure, and the end device does not reject it there.

I wouldn’t recommend using this end device stack given that it is very old and doesn’t seem to be compliant. It will cause headaches down the road.

Regarding the LinkADRReq - this is a mix of two things:

  • LinkADRReq has double use - enable/disable channels in bulk and change the data rate index + transmission power index + number of retransmissions. Disabling ADR disables the later part of the functionality, but the bulk channel enable / disable is still kept, because it is very useful in bands with 72 channels (US-like bands).
  • Disabling ADR via the Console right now has unintended effects (it accidentally enables the manual-ADR mode instead of really disabling it). This will be fixed in a future release.
1 Like

OK, so this is mainly an issue with the ESPEasy template?

What should I do now? (apart from upgrading the FW)
I guess the preferred settings are: RX2 freq. at 869.525 and Rx2 data rate at DR3
The rest is OK I guess?

Just to be sure, I will also call out all mac get command on an OTAA node to see what is set during OTAA and compare it with the settings I am now using to make sure I don’t miss anything.

I took a bit more time to look at your device and actually it seems that the problematic part is the RX1 delay at boot time. Your device actually never received downlinks because of this mismatch.

If you look at the original picture of your MAC settings that you have posted above, both RX1 delay and Desired RX1 delay were set to 5 seconds, but your firmware I think actually has at boot time RX1 delay set to 1.

After I have edited out your RX1 delay to 1 (second) and resetted the MAC state I finally got responses to the RxTimingSetupReq and RxParamSetupReq, so the end device really is capable of answering these, provided that it hears them out at the right time.

I think that the current settings that are set on your end device should be good. In general I recommend trying to get the boot MAC state of the end device and compare it with the MAC settings - if the parameters don’t match, you get issues like these where the downlinks are sent too late because the end device expects them to arrive 1 second after the uplink, while the Network Server schedules them 5 seconds afterwards.

OK, and what are the “current” settings? After your post I noticed you have made some more changes to them.

So I need to double check that I am setting the correct RX1 delay (code seems to suggest it though) to 5 sec.
RX2 should be DR3 for sure as we want to use SF9 for RX2.
RX2 freq. should be 869.525 MHz (I noticed it is wrong in the ESPEasy template as is (was?) in many others due to an error in the sample config back when the vendor templates were introduced)

Anything else?

I’m not sure the mac state is actually saved on the RN2483 module, so I’m not sure if the module will return in the current state if I power cycle it.
So better to make sure the correct values are set to the module at boot by my software.

N.B. I already made a PR for updating the RX2 frequency for the ESPEasy vendor template.
I will tomorrow look at my code to see why the RX1 delay apparently is not being set at 5 seconds.

I’m also receiving a downlink message on the device when I send an “UNCONFIRMED_UP” message. Some notes:

  • the “UNCONFIRMED_UP” type is noted in the uplink json viewer on the gateway and device
  • my device live data does NOT show this downlink message
  • my gateway shows this downlink message is sent 0.4s after receiving the unconfirmed uplink message as “gs.down.send” and it looks like it’s an unconfirmed down message (starts with 60 in the payload):
    60 6a f1 0e 22 8b 00 00 03 30 00 00 71 03 30 00 ff 01 06 ae 80 c9 cb
  • I get the same behavior when I send a unconfirmed message to the helium network.
    It seems to be some kind of complaint response but not sure.

These are most likely requests from the server for your device (what is it, what firmware) to adjust it’s settings.

We recommend OTAA as that is more able to set settings.

Further reading available here:

Commands from the server in section 5 …

They seem to be LINK_ADR_REQ downlinks from the gateway. Apparently for > v1.0.4 the device needs to answer the request even if ADR has been disabled on the device. Odd though esp when trying to minimize downlinks.

Link ADR Req has other uses.

Totally impossible to comment as you’ve not said what the device is beyond to say that there aren’t that many devices around with 1.0.4 and virtually none >1.0.4

To recap:

  • my device silences ADR Req downlinks by sending ADR Ans (works on Helium but TTN ignores it).
  • I hadn’t seen that the repeated ADR downlinks requires a work around per:

ADR features recently introduced to TTS March 2022

Whereby the one work-around suggestion of “setting the DR before each uplink” seems a bit ambiguous or is it assumed to require TXParamSetupReq, RXParamSetupReq and various DR offsets etc.

To recap:

How so ambiguous? You use a function call to the MAC to set the DR you want before each uplink.

Since TTN currently ignores ADR=0 and ADRACKAns 0, and continues to spawn a bunch of downlinks on every message send – it would be worthwhile to confirm the various data rate mac commands patches required by network prior to every uplink message. This seems to apply across all devices & lorawan v.
For now I’ll assume it’s a refresh to the data rate transmit and receive parameters: TXParamSetupReq & RXParamSetupReq.