but re-reading your post - if you’re getting a downlink right from the start, then you’re probably still using an older version of the mcci-library. if you check the issue on github linked in the first post you’ll see there’s been done quite a lot of fixing.
haven’t tested yet how it behaves when starting with SF7, but starting with SF10 i again end up (way later than with the prior version) getting downlinks as response to each packet…
Even with the latest version the paxcounter will get a downlink after the 65. packet which never ends.
i’m using HEAD of mcci lmic in paxcounter software, currently 1432ba0, with EU868.
Meanwhile found: If i switch off ADR, then those spurious downlinks disappear.
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.
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.
@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.