Recent change in ADR handling in TNN and LMIC generate downlink loop

End Devices (Nodes) LMIC
29

Right, these are separate issues with different symptoms.

I have no TTIG in my area, and I experience the same issue since quite some time - that is: one downlink for every uplink in ADR mode.

I have disabled ADR on my nodes for now, as I don’t care too much; my setup is stable and I have good connectivity with SF7 anyway…

30

Yes, two different issues.

The maybe TTN backend and/or LMiC related issue with ADR acks for each downlink is definately new. This did not happend a month ago. So this must be caused by a change somewhere.

1 Like
31

@htdvisser any insights on this issue?

1 Like
32

I have two lmic nodes that receive a downlink at every uplink now. Any solution to solve this?

33

Switching off ADR?

34

I see that as an acceptable workaround but not for permanent use. ADR is an essential part of LoRaWAN.

1 Like
35

@Verkehrsrot in PAX counter I tried to set it with defaultConfig() but without success:

// populate cfg vars with factory settings
void defaultConfig() {
  cfg.lorasf = LORASFDEFAULT; // 7-12, initial lora sf, see paxcounter.conf
  cfg.txpower = 15;           // 2-15, lora tx power
  cfg.adrmode = 1;            // 0=disabled, 1=enabled**

Setting cfg.adrmode = 0; does not make a change.
Probably I have to configure it elsewhere in PAX counter?

36

For the PAX Counter you can easily switch it off with a downstream command

0x07 0x00 on port 2 (if you didn’t change the port mapping)

37

Can you try the following fix in mcci-catena/arduino-lmic on top of master version : https://github.com/mcci-catena/arduino-lmic/pull/303

It should finish to fix the problem.

38

Currently PAX counter is using MCCI LoRaWAN LMIC library ( https://github.com/mcci-catena/arduino-lmic/releases/tag/v2.3.2) that does not contain the fix. I cannot find a function similar to the one you refer to so I cannot repair it now. :frowning: Until further notice I use the downlink command to disable ADR.

39

The settings from configmanager.cpp are “factory settings” and only used on fresh devices which have no config stored in NVRAM. So if you make changes here and flash it on a previously used device which already has a stored config in NVRAM nothing happenes, because device uses settings from NVRAM. You can enforce a reset to factory settings in flash by up- or downgradig the software version number in platformio.ini.

Yes i know, this is weird. The whole configmanager.cpp is crap (but works). I’m waiting for someone who delivers a pull request with a refactoring.

40

Use the version in development branch. This is using current mcci lib.

1 Like
41

I just tested that but the problem is not solved with the development branch. sorry.

afbeelding

42

That’s as expected, since the pull request which may solve the issue is not yet merged in mcci lmic. I will keep my eyes on this.

43

Ah, ok, I went too fast and assumed… sorry. Thanks for replying. W’ll follow this topic

44

No, i was too slow, i just see the pull request was merged 4 hours ago. Paxcounter software in development branch is ready now for testing. You can rebuild now from development repo and test, i will do so either.

45

Tested. No more ADR downlinks. The fix seems to work.

2 Likes
46

and ADR does work?

47

I’ll test tomorrow too - cross fingers on this

48

Yes, ADR now is working again with TTN, as it did before.
Tested with latest paxcounter development version.

2 Likes