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.
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.
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.
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.