TheThingsArchive / ttn

The Things Network Stack V2
https://www.thethingsnetwork.org
MIT License
461 stars 276 forks source link

Actively send LinkADRReq to devices that don't get downlink #655

Closed htdvisser closed 7 years ago

htdvisser commented 7 years ago

The NetworkServer currently piggybacks the LinkADRReq on downlinks that are sent when the device requests an Ack/ADRAck or when the application sends a downlink. However, when neither of this happens, the device will never receive an LinkADRReq.

Related to #622

htdvisser commented 7 years ago

Copy from Slack:

Our current version of the network server sends ADR messages only if the device asks for it (AdrAckReq), or by piggy-backing on an application downlink (or Ack). Some devices do not send AdrAckReq messages when they are on SF12 (because they can't fallback to a higher SF), so when you then only send unconfirmed uplink and your application does not send downlink from time to time, it is indeed possible that your device stays on SF12.

dbrgn commented 7 years ago

Could that be the issue why I can't get ADR to work with the LoPy? Do you know whether it sends those AdrAckReq messages? (I don't use downlinks or confirmed messages so far.)

htdvisser commented 7 years ago

We can force the Handler to send a downlink by informing it that we want to send a DevStatusReq. This should trigger an empty application downlink.

atoy40 commented 6 years ago

@dbrgn I've the same issue with the LoPy. I received ACK, and they contain ADR command, but the lopy Lora stack doesn't seem to use it (so every ACK repeat the LinkADRReq command again and again). It looks like a bug in the Lora stack included in the LoPy.

atoy40 commented 6 years ago

@htdvisser I'm testing ADR on a stm nucleo node (EU868 bands) with a sx1272 shield, and I note something strange. (i'm using the Semtech demo app to test different lora parameters) If I send confirmed uplink : no problem,LinkADRReq is included in the first ACK, and my device update his rate. if I send unconfirmed uplink, and send some downlink (from a node-red network) : downlinks never include LinkADRReq (I've check it on the online lora packet decoder), even after more than 20 frame sent (so the history queue on the server is full). I'm absolutly sure the downlink come to the end-device because it's log by my gateway and the payload is printed by the device through his serial port.

Any idea ?

Question : Can I know which version (or git commit) is currently running on the TTN EU server ?

Thankss Anthony.

htdvisser commented 6 years ago

You could check the gateway traffic view in the console and see what's in the "Trace" of the downlink message that you expect to contain the LinkADRReq.

The public community network is usually running the latest tagged version of this repository, you can use ttnctl discover to find the exact tag and commit that is running on the router, broker and handler.

atoy40 commented 6 years ago

@htdvisser , I've checked the gateway trace on the console, and downlinks never include the LinkADRReq command. They are included only in the case I send confirmed frame (so in the "ack" downlink).

Thanks for the ttnctl tips.