Unwanted huge downlink message for each uplink message

End Devices (Nodes)
1

Hi all

I just set up another node and registered it as new device with TTN as ABP node.
It’s just a simple hardware test to send 1 small message/minute.

In the live data console, I can see the messages arriving.
But surprisingly for each received uplink message, a huge (1392 bit, 87 Hex) downlink message is scheduled and also sent by the corresponding gateway (my own).

The downlink messages have RX1, Delay: 1.
MAC payload: 68B601A40E49C1C4BF21A62DC8A04102006C82BEFB0959C93AB7CCD3C1D8B3A484C72E60430520646EB13F

  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
    "raw_payload": "YLypCyYAEQAAaLYBpA5JwcS/IaYtyKBBAgBsgr77CVnJOrfM08HYs6SExy5gQwUgZG6xP7/s4yc=",
    "payload": {
      "m_hdr": {
        "m_type": "UNCONFIRMED_DOWN"
      },
      "mic": "v+zjJw==",
      "mac_payload": {
        "f_hdr": {
          "dev_addr": "260BA9BC",
          "f_ctrl": {},
          "f_cnt": 17
        },
        "frm_payload": "aLYBpA5JwcS/IaYtyKBBAgBsgr77CVnJOrfM08HYs6SExy5gQwUgZG6xPw==",
        "full_f_cnt": 17
      }
    },
    "request": {
      "downlink_paths": [
        {
          "uplink_token": "ChUKEwoHaG9ydy1nMRIIuCfr//4MpKQQm6W6ywMaDAjpjaCYBhDjtLivAyD42rK/hdNBKgwI6Y2gmAYQ2In/pQM="
        }
      ],
      "rx1_delay": 1,
      "rx1_data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 7
        }
      },
      "rx1_frequency": "868500000",
      "rx2_data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 12
        }
      },
      "rx2_frequency": "869525000",
      "priority": "HIGHEST",
      "frequency_plan_id": "EU_863_870_TTN"
    },

The uplink messages are unconfirmed messages, SF7BW125

Can someone explain where these huge downlink messages come from?
It does not seem to be LoraWAN MAC commands.

Thanks for any help. Let me know if can provide more data.

2

The packet is using port 0 which indicates that it is a packet of MAC commands. What does your device uplink in response?

https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=YLypCyYAEQAAaLYBpA5JwcS%2FIaYtyKBBAgBsgr77CVnJOrfM08HYs6SExy5gQwUgZG6xP7%2Fs4yc%3D&nwkskey=&appskey=

3

Thanks Jason

The device does not reply to the downlink message. It seems it does not receive it. Serial output does not mention the downlink.

I was looking for the mac commands, but at the wrong location.

I decoded the message now, but I cannot understand the mac commands:

0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500300FF00010805

05 → RXParamSetupReq, data=03D (4 byte length I think)

But then 2AD8… What mac command is that?

Or is it

05 → RXParamSetupReq, no data,
03 → LinkADRReq, data = D2A
but then D8 is no valid mac command?

4

Did you look up the spec?
RxParamSetupReq 0x05 + 4 bytes is 0x03D2AD84

0x05, 0x06, 0x07 and 0x03 commands are present.

Bonus points for reading reference stack.

1 Like
5

Yes, I looked up the spec here All About LoRa and LoRaWAN: LoRaWAN MAC Commands
Ah stupid me: 4 Bytes = 8 hex chars. (it’s late here).

After stopping the node for a minute, the downlink messages have stopped.

6

Then if your device stack can’t handle them sufficiently.

7

Then if your device stack can’t handle them sufficiently.

Mhh. It should. I have seen MCCI LMIC handle this kind of downlink messages.

8

Have you set the RX1 window in the node firmware to 5 seconds? By default the node will listen at 1 second after transmitting, not at 5 seconds as used by TTN v3. (Or you can tell TTN to use 1 second for this node, however because of possible delays in downlink communication that is not recommended)

9

I have set the RX1 window to 5 secs in firmware

LMIC.rxDelay = 5;

as well as in the console settings
RX1

Thus in theory the device should not receive commands for changing the settings and should be able to receive the commands within the rx1 window.

10

When testing it’s best to do it via a push button to send so you don’t end up with a blizzard of entries on your serial & web logs. Also 1/minute is in breach of the Fair Use Policy and may well be illegal (policeman illegal).

That’s a shame, having TTI CE continue to send downlinks would definitely rank as a great Github issue :wink:

Assuming this also means you are using LMIC, which version? What device / MCU? What radio?

LMIC ships with a buffer of 200+ bytes, so its got plenty of space for a downlink of this size.

Where in the code?

To ensure it’s set like concrete, in lorabase.h, line 68, I change DELAY_DNW1 so it says 5 - that way it’s running from the beginning and a bit non-negotiable.

However the console clearly hasn’t got the message about Rx1 being on 1 second as you are saying in your first post it is coming on 1s. So it may be worth changing LMIC to 1s as a way of checking if the device can hear OK, along with other ideas below.

You need to explicitly tell the stack which frequencies your device is using so that it doesn’t try and set those which is what RXParamSetupReq & LinkADRReq is doing. The ADR command arrives regardless of the setting on the console as it’s the official way of delivering the required details, it doesn’t necessary change the DR. This is a paraphrase of my UIP (understanding-in-progress) as @adrianmares is slowly drilling through the outer layers of my very dense skull to hook up a direct feed.

Additionally (look away now Adrian), ABP setups are still a dark art, I use the CLI to ensure I’ve “told” the stack what I want. I’ve already used up my “Unravel MAC downlinks” allocation for this week for @Ichthus_College_Info, so this is a bonus reply. When we get a quiet week I shall try to be a bit more rigorous with figuring it out.


As an LMIC juggler, the primary symptom is that the device isn’t hearing the downlink, once it is getting the message, the second issue may be getting the settings aligned

So I’d actually start out treating this as a deaf device. First make sure you have the downlink serial log still turned on in the event case statement so you can see it (sounds like you already do) and you can try to queue a downlink with the device off to see if the stack gives you a chance, but it does tend to amalgamate / take priority but it’s worth a try.

Apart from the questions above:

  • How far apart is the gateway from the device?
  • Can you try OTAA?
  • Why not OTAA? The preferred beverage of all TTSv3 users.
  • Do you have a different device you can try the same firmware on?
  • Do you have different hardware you can try the same firmware (albeit with potential pin changes) on?

My latest test board (a new model from RocketScream) in front of me is on OTAA and has sent 4,610 uplinks and in that time had 207 downlinks, only one from me, so you are not alone.

1 Like