Stack v3 sends unrequested downlink data for new ABP device

TTN Network and Services The Things Stack v3
8

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

9

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

10

Does the node receive and process the MAC command?

11

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

12

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.

13

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.

2 Likes
14

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?

15

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!

16

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.

17

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

18

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.

19

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

20

Sorry about that. Few steps:

  1. Install and configure CLI: https://www.thethingsindustries.com/docs/the-things-stack/interact/cli/installing-cli/
  2. 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
  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 \
    --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.

2 Likes
21

Yeah, about that, how long have you got …

I think you should aspire to compliant stacks - as I don’t think me using LoRa-node on an STM based device (GNSE anyone, or Dragino LoRaST) makes it certified.

Whereas I believe using a SAMR34 is certified try as I might to break in to the closed source library, whatever I may add to the outside and whatever Semtech think about the lack of NVM making it incompatible going forward with LoRa-node.

As you can see above, we are aware of the state of the Arduino LMIC, as is Terry and I’m sure it can only get better.

22

Once I change one line in the application code the stack isn’t certified anymore. As you are well aware the cost of compliance testing (Lora Alliance membership + test house fees for every revision of the code) are steep and the process is time consuming. Even large vendors like Microchip don’t release new firmware often with good reason…

So I read your message as we should use a ‘LoRaWAN compatible’, potentially certifiable stack.

23

Not to be nitpicking or starting a discussion but i.m.o. the term compatible is too weak (and prone to discussions). Compliant would approach better what is actually meant here, especially for the maker community (even though true compliance requires that the compliancy has to be verified). It is stronger than compatible and weaker than certified.

24

Technically, yes. Practically, not really. Your end device as a whole will get more easily certified by similarity. But I’m not asking everyone to only use LoRa Alliance certified end devices on The Things Network, but mostly to use LoRaWAN certified stacks.

1 Like
25

To my understanding (assumptions included) this means the following:

  1. current-parameters are the parameter values that were configured (either explicitly specified or default values) when the device was added (created) in the Console or via CLI.

  2. Above values can be updated via the console or CLI.

  3. Current value means ‘as known by the NS’ (which in practice can be different from the actual value used by the node e.g. when a non-compliant node does not handle MAC commands and values defined during addition of the device and what is currently used in firmware do not match).

  4. The value of (some of) the above current-parameters can be overridden by a response (from the device) to a DevStatusReq MAC-command request, with the actual values on the device.

  5. If the DevStatusReq frequency is set to 0 (i.e. no status requests will be sent) current-parameters will allways be the values as described above at 1. and 2.

  6. desired-parameters are the parameter values that the NS wants the node to use.
    Those values are configured/determined independently at the NS level.

    • If the current value of parameters matches the desired value then no MAC commands for setting/adjusting the parameters will be sent by the NS.

    • If current and desired values do not match the NS will send appropriate MAC command(s) to request the node to set/adjust the parameter value(s).

Questions

  • Are above interpretations / assumptions correct?

  • Is there an overview of which parameters can be updated/modified after initial addition (creation) of the device and be made effective and which not?

  • When is the first DevStatusReq request sent by the NS, is this always directly after the first uplink? In case of OTAA, is it sent directly after the join response or after the first uplink thereafter?

  • Is all of the above identical for LoRaWAN versions v1.0.2, v1.0.3, v1.0.4 and v1.1.x?
    (or may choosing a different LoRaWAN version when adding the device impact this behavior?)

26

Have you checked the specification to see the wealth of information that is returned in the DevStatusAns? Spoiler: battery status and link margin.

So there is not a lot that will adjusted based on the response.

The current-parameters are based on the device settings, the desired-parameters are calculated based on the LoRaWAN and MAC version, the regional parameters and the TTN frequency plan with some TTN specific setting (RX1 timing etc) mixed in.

27

I have months ago, but apparently have forgotten about the underwhelming ‘wealth of information’ (and overestimated what it can report).