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