Is there a setting in ChirpStack that ‘controls the time window’ that ChirpStack responds to a confirmed uplink? Our devices are running the 1.0.2 stack, US915. I’m having issues where our device is sending a confirmed uplink but not getting the acknowledge from ChirpStack. The symptom seen is that the spreading factor goes from 7 to 10 and back again in less than 5 minutes (1 minute uplinks). It appears to be a turnaround time issue from the cellular side. I have tested this with ChirpStack in a gateway and I don’t see the same issue.
I’m a newbie so I don’t know much 
- I have been reading a ton and trying to learn.
Check out the MAC Commands and Duty Cycle info in the LoRaWAN Tech Specs You may have to check your Regional Parameters as well*
So until someone who knows what they are doing responds, that I would at least try to help with information. Hopefully it’s useful.
LoRaWAN Link Layer Specifications
Chirpstack Docs
https://www.chirpstack.io/docs/chirpstack/features/rx-parameters-configuration.html
Semtech Example for SX1262 AN1200.36 RxDutyCycle
https://www.semtech.com/products/wireless-rf/lora-connect/sx1262#documentation
MAC Command Table
Just to add on to before, I’m trying to learn/figure out how to make my sensor work and I saw this in one of the Arduino Examples… Thought I would share incase it helps. If not, just ignore me 
/* Indicates if the node is sending confirmed or unconfirmed messages */
bool isTxConfirmed = true;
/* Application port */
uint8_t appPort = 2;
/*!
*Number of trials to transmit the frame, if the LoRaMAC layer did not
* receive an acknowledgment. The MAC performs a datarate adaptation,
* according to the LoRaWAN Specification V1.0.2, chapter 18.4, according
* to the following table:
*
* Transmission nb | Data Rate
* ----------------|-----------
* 1 (first) | DR
* 2 | DR
* 3 | max(DR-1,0)
* 4 | max(DR-1,0)
* 5 | max(DR-2,0)
* 6 | max(DR-2,0)
* 7 | max(DR-3,0)
* 8 | max(DR-3,0)
*
* Note, that if NbTrials is set to 1 or 2, the MAC will not decrease
* the datarate, in case the LoRaMAC layer did not receive an acknowledgment
*/
uint8_t confirmedNbTrials = 2;
It will respond with an ACK in either RX1 or RX2 related to the uplink.
I probably asked the question wrong so here’s another try with a picture. The left-hand side shows the confirmed packet with the SF ‘bouncing’. The right side is after I changed it to an unconfirmed packet. So, unconfirmed packets work fine and confirmed packet lose up to 75% of the packets. It appears that the issue is the receipt of the acknowledgement from ChirpStack. My testing suggests that it is the delay in the turnaround caused by network latency. (ChirpStack on a gateway - no latency - works fine with confirmed packets.) Is there a setting in ChirpStack (or the device - V1.0.2) that can ‘tune’ the acknowledgement for network latency?
One setting you can change is the rx1_delay in the region_XXXXX.toml configuration. By default, this is 1, but if you are experiencing a high network latency, you could set this to 3 for example.
Thanks! We’ll give this a try when we get some bandwidth and I’ll post the results.