Stack v3 sends unrequested downlink data for new ABP device

I migrated my existing devices (OTAA and ABP) from v2 to v3 and these work fine.

Today I created a new ABP device (OTAA works fine for new devices) but for some reason the stack always sends a lot (about 50 bytes) of downlink data:

11:39:23.223 → Data Received: 0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500351FF00030805

This is not visible in the application console, only the uplink data is shown, but the downlink counter is increasing.

Also my gateway shows the unwanted downlink:


I made the node configurable for both OTAA and ABP.

So it is running the same (LMIC) code in both modes and only ABP shows this behaviour.

Have you setup the frequencies that your node may use in the console - if you don’t, then TTS will try and send them to the device which won’t understand. If you do, it assumes the device knows.

Ahh, thanks, I did not.

I will fix that.

Looks something like this:

Screenshot 2021-06-01 at 11.18.15

If you are able to reprogram your device, it would benefit from having Rx1 set to 5s - which you have to change here:

If you can’t, then set the RX1 Delay to 1s and keep your fingers crossed.

I’m working on scripts to help with migration with ABP devices but need input from @Jeff-UK to move forward.

1 Like

Thanks, it works OK now!

Only picked up message this evening will call you in morning :wink:

Encountered the same thing, defined MAC settings but the issue of the unrequested downlink is persistent.
Any other ideas?

Hard to say as we don’t know what the “unrequested downlink” is.

Does the node receive and process the MAC command?

Sometimes one should just wait a moment.
Defining factory preset frequencies helped. Changed nothing else and it is working ok now.

Back to this problem.
there are some times when downlinks are not sent and some when it is.
I am using MCCI_LoRaWAN_LMIC library for my ABP node, library docs say it can handle MAC commands, really don’t know where to look how it does it and what command is received.
I have Atmega328P as MCU, so not a lot of space and setting debugging to 1 pushes sketch over the size limit.
I have tried setting the Advanced setting on device registration but it doesn’t help.
Downlinks don’t show up in application consol, they can be seen only from the gateway console but note downlink counter increases.

I know ABP is bad and etc. but I have old hardware from 2018 that uses TPL5111 as a system timer and doing join requests each time isn’t a good idea in my opinion. currently working on the next node design and it will use over the air activation.

Enable verbose events in the end device live data view. You’ll see which MAC commands NS is scheduling.

You can disable this by making sure that desired-parameters are the same as current-parameters. Also you can tune the DevStatusReq periodicity and interval. This currently only is configurable per device with the CLI.


Which version?

If you go in to config.h you can un-comment the DISABLE_JOIN, DISABLE_PING and DISABLE_BEACONS which will free up a fair amount of Flash & RAM

For the device registration it’s important you setup the different frequencies for the region so that the network server doesn’t try to set them up needlessly.

Which region are you?

Will check the version once I am at the table.

Yes, indeed I tried to disable OTAA and B, C class features to get some extra space to run debugging (only mode 1)

All I got was stream of “?” in seral port and node that fails to send uplinks.

I am in EU
Thanks for the help!

IIRC you should use at least MCCI LMIC version 3.3.0 (or was it 3.0.99?). In older versions MAC commands were much less supported.

Can you be more explicit about ‘this’ and what are/where to find desired-parameters and current-parameters?

Terry publicly says that it is 3.2.0 that really gets MAC commands working but there isn’t much extra in 3.3.0 so that would be preferable. 4.0.0 seems to be paving the way with the new event / callback system.

That is what I thought but did only find 3.0.99 and 3.3.0 under Releases.

Sorry about that. Few steps:

  1. Install and configure CLI:
  2. See how the ttn-lw-cli end-devices get command works:
  3. Compare the current-parameters with desired-parameters by doing a:
$ ttn-lw-cli end-devices get <app-id> <device-id> \
    --mac-state.current-parameters \
    --mac-state.desired-parameters \
    --mac-settings.status-count-periodicity \

Generally speaking, the difference between current and desired parameters trigger the generation of MAC commands. Could be channels, data rates, timing, duty cycle, etc etc. You can change desired parameters to reflect current parameters to avoid MAC command generation. You can also configure mac-settings so that there’s no gap between current and desired parameters, i.e. by configuring factory preset frequencies and RX1 delay. In the case of ABP, this then also need to be configured on the end device.

Besides all of this, NS by default requests the device status with DevStatusReq. You can tune how often this happens by the count periodicity (requests per number of downlink messages) or time periodicity (requests on an interval). Setting them to 0 stops NS from sending DevStatusReq.

In any case, please please please make sure you guys use certified LoRaWAN stacks.