Perhaps you could share the source on GitHub - if you look around you’ll find that’s where almost everyone else puts their code. Lots of Python for semi-command line stuff, PHP / Go / node.js / Python for web stuff, C for embedded …
Also I’m not a habitual Windows user so I’d have to power up a machine, sand box it, update anti-virus etc etc.
And what do the ADR bytes say?
When you have time you can give it a try. Doesn’t promise much but might help rather than going to lorawan specification pdf for each adr. It might help as the current experiment is on ADR
06030500FF01 - fopts field
06 - requesting status from node
030500ff01 - adr command which says 0 order power (max power), 5 order ADR (SF7), LSB 8 channel usable, no masking of frequency so on, if thats what you asked.
Why not extend the excellent lorawan packet decoder so we have one solution that does it all?
I had two days so thought to of some help for this problem. lorawan packet decoder is so professional. I might take months to get merge to that code. But an excellent suggestion. Will definitely try the repository 
Just dug out the ATmega4808 + RFM95 breadboard for the first test. Debug set to level 2 with printf so I can see the details.
Using LMIC 4.1.1 with a pre-existing device setup on the console that has ADR turned on, the uplink is at SF7 from the start, quickly receives some MAC commands but none that are changing the SF.
I’ll create a new device later to see if that makes a difference, but at present both LMIC & TTS are working together nicely.
The question here should also be:
Radio spectrum - what is the local conditions like?
SNR values?
Node Settings - ADR margin setting?
Just started to read about it, there is a bit to understand here.
There is no way a device that can be heard at SF7 should be commanded to jump to SF12.
Looking at the LMIC source it occurs to me I can use the MAC processing function to print what’s going on for debugging - which will be educational - and abstract it as a standalone. And do the same with the LoRaMAC-node. And ask for the TDD source because surely the unit tests will be very informative …
The SF12 request was seen when ADR was disabled. When I enable ADR from console, the server never ask to go to SF12 but the request are for SF7 only as mentioned in post 36
And this makes 50.
Where - console or device or both?
Just observed the same problem; being forced to switch fromSF7 to SF12 after join. Taking the hint of switching ADR on console (The Things stack) it did not force me to SF12. I have now ADR enabled both sides. Next step is to disable ADR on device and see if it gets honored by network by not sending ADRREQ with SF12
This cost me some airtime and now it is down from 1100 to 46ms as the payload is 4 bytes only
The NS won’t know it’s turned off on the device so it’s not got anything to honour as such.
As this is the third, possibly the fourth, I’ll complete my tests this morning so we can collectively raise an issue if need be.
Hmmm, I can see that upstream packets have in header ADR = true/false, so isn’t this the way to tell upstream that the device does not support ADR like it started to move in a vehicle after being stationary.
My fresh out the box LMIC 4.1.1 with ADR turned off in the firmware and on the console, starting out at SF10 is commanded to SF12.
But what I don’t know if this is a bug in LMIC as I haven’t yet decoded the downlink.
If I start at SF10 with ADR on it gets set to SF7.
What I see on my GW packetmonitor is an ADRREq coming from NS and requesting for SF12. LMIC responds with ADRAnsw and ACKs the DataRate. When LMIC has ADR off and NS has ADR off (my starting point) NS sends ADRRReq with SF12 after join and LMIC duly acts accordingly. If I then set DR back to SF7 on LMIC manually and SF7-packet goes upstream, comes immediately ADRREq with SF12 - so for me it seems that it gets triggered by upstream SF7-packet.
Since this is a local setup I have RSSI -70 and SNR +7.
What is this?
Is this happening on OTAA as well?
GW packetmonitor: I have locally RAK7258 LoraWAN gateway and it has a “LoRaWAN Packer logger” meaning that it is able to show received/transmitted packets and also disassemble them and showing i.e. header and payload. The payload remains encrypted, but frame header info like ADR, Datarate and TXpower in an ADRReq are shown - helps to see what is happening.
OTAA: Yes, I am using OTAA and this happens after succesfull join.
Some more info:
LoRaWAN server: eu1.cloud.thethings.network
Protocol: Semtech UDP
Device: TTGO V1
LMIC: MCCI LoRaWAN LMIC library 4.1.1
Sorry it was not in post 36 it was in 37. I should have quote it rather than making scroll back.
Anyway seems I am not the only one who is experiencing the problem, which I think inference it might not be a simple mistake from my side.
I have tried spending much time decoding the uplink and downlink, I have found that its the server asking to move to SF12 if in “ADR disable” mode.
To check if its because of anything hidden in the first message send from node ( but I have tried decoding and found nothing wrong in the first message), I disable the gateway for first few messages from node and this makes gateway to receive the higher frames as start frames.
As soon as server finds the message is in SF7 it request SF12.
Out of the box query: Is there anyway to mark two post as solutions, like a two partial solutions to make the complete solutions?
What is is the SNR?
Hold the presses, almost everything here isn’t applicable.
Between -55dBm to -90dBm RSSI, SNR between 6-10