It would really help if you could capture a series of actual uplink (and ideally corresponding downlink) packets showing this.
oh look - what iām getting now 
(this being with the same code as before, just updating the mcci lmic library after the fixes discussed in this thread)
22 bytes with SF12, in cycles of 5 minutes - iām wondering that TTN backend does forward this to the gateway, since i assume this is far beyond TTNās fair limit policy, and probably beyond duty cycle of the gateway?
Whatās needed are a sequence of packets where the ADR related bits can be seen. If it looks like thereās still a firmware issue then the next step is to put debug logging in the related code paths.
i guess you intended to say iām surprised, as iām wondering rather means iām asking myself (sorry fĆ¼r den englisch-unterricht 
)
but yes, it does work, and i have no idea why this node actually went up to SF12 again as itās still at the same place and distance from the gateway as it was when i started it after updating with the latest library - and where it went down to from 10 to 7 automatcially before.
there seem to be suspiciouns that itās related to the gateway - judging from the thread @BoRRoZ linked - will have to verify this the coming days by bringing a different gateway close to the node or vice versa before blaming the lmic-libraryā¦ (also in reply to @cslorabox)
That would be a misunderstanding. Gatewayās donāt invent traffic in either direction, they are just transparent translators between LoRa and IP backhaul. Whatever the problem is, itās an issue of the contract between the node and the servers being disagreed upon or mis-implemented at at least one end.
There does appear to be a duplication issue in displayed downlinks somewhere, but as itās not physically possible for a gateway to transmit three messages on the same frequency at the same time that cannot be a practical cause of this issue.
Further, even if duplicates did somehow get through, they would be immediately dropped as they contain already used sequence counter values.
If the node is not receiving the downlink, that could be an issue, regardless if it is caused by radio range, interference, or a gateway choking on an impossible combination of downlink requests. But the key to debugging that would be to monitor the node behavior - really, until your system is working 100% you want your nodes giving serial debug output on each transmission, and on each receive window, regardless if they find anything or not and if what they do find decodes as valid or not.
This ātripleā downlink/join issue is TTIG related and not LMIC I am sure, I can replicate it here - there are still issues with LMIC and ADR
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ā¦
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
I have two lmic nodes that receive a downlink at every uplink now. Any solution to solve this?
Switching off ADR?
I see that as an acceptable workaround but not for permanent use. ADR is an essential part of LoRaWAN.
1 Like
@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?
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)
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.
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. 
Until further notice I use the downlink command to disable ADR.
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.
Use the version in development branch. This is using current mcci lib.
1 Like