Get current ADR datarate?

Is there a function to access the current TX DataRate calculated by the ADR algorithm?

Thank you

Set in the Arduino IDE the LoRaWAN Debug-Level or, look at the traffic in the TTN-Console (live-data)!

Thank you, but what I meant was internally during runtime, some function in C++ code to retrieve the dr value.
Im using the LoRaWAN example with a de board

Thank you for your time

This is based on “my” understanding, buyer beware. And applies to the “asr650x” branch. Perhaps to master as well but I’ve not played there at all.

There are two layers to the asr650x code, a library interface layer intended to be accessible by your device application and a cores/asr650x/loramac/mac layer that the library calls.

As you have found current implementation of the API has no “get” counter part to the set API.
To set data rate within your app: LoRaWanClass::setDataRateForNoADR(int8_t dataRate)

Unfortunately the set passes the new value to the cores layer via a global rather using an API call.

Perhaps the simplest thing to try is like this within your application (I’m not positive it works, but should I’ve used it to check the ADR flag, give it a shot)

     // check value of the  Data Rate
          MibRequestConfirm_t mibReq;
          mibReq.Type = MIB_CHANNELS_DATARATE;

          if( LoRaMacMibGetRequestConfirm( &mibReq ) == LORAMAC_STATUS_OK )
            Serial.print("Data rate results from MibGet: ");

Failing that another possibility is to modify the code, create another global within the cores layer in asr650x/cores/asr650x/loramac/mac/LoRaMac.c that would hold the current data rate.
You would need to set it appropriately somewhere upon startup and then update it where the network ADR change is processed,
within ProcessMacCommands() where SRV_MAC_LINK_ADR_REQ is being processed, after the call to RegionLinkAdrReq().

RegionLinkAdrReq() attempts to verify the suggested data rate is valid for the current region configuration.

That’s just a couple possibilities hopefully the first will work.

Thank you, I will think about this approach.