Stack v3 sends unrequested downlink data for new ABP device

tomtor · June 1, 2021, 9:45am

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.

descartes · June 1, 2021, 10:14am

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.

tomtor · June 1, 2021, 10:15am

Ahh, thanks, I did not.

I will fix that.

descartes · June 1, 2021, 10:22am

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:

github.com

mcci-catena/arduino-lmic/blob/c3e32beffdaa0bc37b4b6a3b8474eab84b7f66c3/src/lmic/lorabase.h#L68




enum { ILLEGAL_RPS = 0xFF };


// Global maximum frame length
enum { STD_PREAMBLE_LEN  =  8 };
enum { MAX_LEN_FRAME     =  LMIC_MAX_FRAME_LENGTH };
enum { LEN_DEVNONCE      =  2 };
enum { LEN_ARTNONCE      =  3 };
enum { LEN_NETID         =  3 };
enum { DELAY_JACC1       =  5 }; // in secs
enum { DELAY_DNW1        =  1 }; // in secs down window #1
enum { DELAY_EXTDNW2     =  1 }; // in secs
enum { DELAY_JACC2       =  DELAY_JACC1+(int)DELAY_EXTDNW2 }; // in secs
enum { DELAY_DNW2        =  DELAY_DNW1 +(int)DELAY_EXTDNW2 }; // in secs down window #1
enum { BCN_INTV_exp      = 7 };
enum { BCN_INTV_sec      = 1<<BCN_INTV_exp };
enum { BCN_INTV_ms       = BCN_INTV_sec*1000L };
enum { BCN_INTV_us       = BCN_INTV_ms*1000L };
enum { BCN_RESERVE_ms    = 2120 };   // space reserved for beacon and NWK management
enum { BCN_GUARD_ms      = 3000 };   // end of beacon period to prevent interference with beacon
enum { BCN_SLOT_SPAN_ms  =   30 };   // 2^12 reception slots a this span

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

descartes · June 1, 2021, 10:22am

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

tomtor · June 1, 2021, 10:32am

Thanks, it works OK now!

Jeff-UK · June 1, 2021, 7:34pm

Only picked up message this evening will call you in morning

jenertsA · June 29, 2021, 8:59am

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

descartes · June 29, 2021, 9:13am

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

kersing · June 29, 2021, 9:30am

Does the node receive and process the MAC command?

jenertsA · June 29, 2021, 8:58pm

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

jenertsA · July 14, 2021, 7:20pm

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.

johan · July 14, 2021, 8:46pm

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.

descartes · July 14, 2021, 9:56pm

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?

jenertsA · July 15, 2021, 5:39am

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!

bluejedi · July 15, 2021, 7:09am

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.

bluejedi · July 15, 2021, 7:20am

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

descartes · July 15, 2021, 7:45am

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.

bluejedi · July 15, 2021, 7:50am

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

johan · July 15, 2021, 9:04am

Sorry about that. Few steps:

Install and configure CLI: https://www.thethingsindustries.com/docs/the-things-stack/interact/cli/installing-cli/
See how the ttn-lw-cli end-devices get command works: https://www.thethingsindustries.com/docs/reference/cli/end_devices/#command-ttn-lw-cli-end-devices-get
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 \
    --mac-settings.status-time-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.