Hi, the LMIC_setChannel() APIs all still work. Which region are you using, because things differ a little based on region.
In the US/AU bandplans, you cannot change anything on a per-channel basis. In EU/AS/IN/KR, you can. However, default channels have restrictions on what you can change (no changing the frequency, for example). This really hasn’t changed since the older IBM LMIC days, except for error checking.
In both US-like and EU-like regions, you can always control the SF (DR) of the next transmission using
LMIC_setDrTxPow(). This is what I would do; in a class A device, ADR and link integrity only take effect at the end of a transmission cycle. So if you first call
LMIC_queryTxReady(), and then do your update only if the result is non-zero, things should work as you want.
To answer #1: no, ADR mode is not controlled by
LMIC_setLinkCheckMode(). It is controlled by
LMIC_setAdrMode(). But they both end up adjusting your uplink data rate. ADR mode causes the LoRaWAN MAC ADR bit to be set in uplinks; this causes/allows the network to adjust the datarate of your device dynamically based on the network’s best guess of what to do. LinkCheckMode causes the device to monitor the downlink from the network; if no downlinks arrive after 96 uplinks, the LMIC starts lowering the datarate (repeating after every 64 further lonely uplinks). After a much larger number of uplinks, the device will decide that it’s keys are likely bad, and will attempt to rejoin the network. These are independent knobs. If you have a mobile device for testing coverage, you should certainly turn off ADR mode; you might also want to turn off Link Integrity Check, as this is more useful for unattended devices.
To answer #2: see above; and the procedure is no different, use
Hope this helps,