Interesting, not related to your OTAA problems, but:
7. Lora ACKAdrReq management
Default data transmission period on our devices are 6 hours, so it means that it is 4 times per day. In order to guarantee the connection with the server ACKAdrReq bit is set every 8th telegram, and the delay for the ACK to get is 4 telegrams. After this, SF is reduced by 1. It is possible to change after how many telegrams ACKAdrReq bit is selected using downlink command which is described in chapter 5.
Assuming they mean ADRACKReq, not ACKAdrReq:
LoRaWAN 1.0.x defines fixed values; ADR_ACK_LIMIT is 64, and ADR_ACK_DELAY is 32. I guess TTN will respond to an impatient device that sends an early ADRACKReq, but there is no guarantee that TTN (or any network) will respond within only 4 uplinks. Even more, unless the device is using the worst possible data rate (DR0, SF12 for most regions), TTN needs about 20 uplinks to even calculate optimized network settings:
To determine the optimal data rate, the network needs some measurements (uplink messages). Currently TTN takes the 20 most recent uplinks, starting at the moment the ADR bit is set. These measurements contains the frame counter, signal-to-noise ratio (SNR) and number of gateways that received each uplink.
The code is open source, so if things go south maybe one can check what happens when fewer than 20 uplinks have been received.
The good thing: at least we now know the device supports ADR, so will hopefully move from SF12 (that it uses for the OTAA join) to a much better data rate. On the other hand: if TTN takes more than 4 uplinks to respond, then the device may actually choose a worse data rate…
Another heads up, as the device seems to use wall clock time: the TTN community network is currently running V2, which uses LoRaWAN 1.0.2. This does not support DeviceTimeReq and TTN will silently drop uplinks that request that. Your manual does not mention this command, so hopefully it has other means to determine the time. Also, hopefully not all devices transmit simultaniously… 