Два устройства, с завода настроены на , скажем 10-ый канал по частоте. В протоколе обмена есть ask - подтверждения приема. Поскольку это таки радио, примем как должное, что пакеты могут теряться.
Одно устройство Master, второе Slave
Мастер видит, что 10 канал хреновый. Шлет слейву "перейди на 23 - ий канал"
Слэйв получает такой приказ, и шлет ask. Шлет еще на 10 ом канале, и частоту пока что не меняет.
Поскольку база ask могла не получить, она будет долбить и далее приказ о переходе на 23 канал, до тех пор пока не получит ask, причем ask на этом самом 10-ом канале.
Получила наконец, только вот слейв не знает, получила она ask или нет, а без этого знания перейти на канал 23 он не может. То есть ему как бы неплохо получить ask уже на свой ask, и только тогда реально перейти на канал 23. Только вот он не может получить этот ask на ask гарантированно, надеюсь уже понятно почему. Потому что для гарантии ему потребуется снова ask.. из этого порочного круга не понимаю как выйти.
Идею слейву слушать и 10 и 23 канал хоть одновременно, хоть по очереди не предлагайте. Что то ерундовая проблема, и 100% решена , но как-то непонятно даже что гуглить.

Слэйву лучше сразу перейти на новый канал. Мастер на новом канале несколько раз запрашивает подверждение от слэйва, не получив ответа - еше раз шлет команду на старом канале. Слэйв, не получив запроса подтверждения от мастера (или не пройдя процедуру некого хэндшэйка с мастером) на новом канале, после тайм-аута возвращается на старый. Как-то так примерно.

Да кстати, логично. Ппц мозги к 40 черствеют, на поверхности ведь лежит, а мудрит чего то..

У меня лет 20 назад был проект радиоуправления светофорами. Там были 2 разных команды: программирование № резервного канала и собственно перехода на резервный канал. И то, и другое можно было долбить по нескольку раз. Таймаутов не делали. Даже если плохой канал, и проходит 1 команда из 10, то на 10 раз она пройдет. Автоматизировать не стали: при плохом канале сам оператор давал команду, слушал ответ, переводил мастера туда-сюда...

По теории если приходит с вероятностью 0.1 то вероятность получения после 10 попыток 35 процентов что так и не придет. Не, не вариант.

А от куда мастер знает что 23 канал хороший? ведь пока не поговоришь не поймешь. Тут мне кажется мастер назначает канал, и по нему спрашивает у ведомого, для проверки качества канала и заодно убедится, что он туда перешел. Если ответа не то, возвращаться на старый канал, для передачи данных, если таковые сейчас есть и пытаться переводить ведомого на другой канал. Да и еще может получится, если ведомый перешел, а канал еще хуже, и мастер уже не может перевести его обратно, тогда тут как с настройками дисплея, в течении 15 секунд если нет подтверждения, то возврат на старый канал ведомого.

Проще сразу договориться, что раз в сколько то времени канал менять или перебирать по списку. Еще вариант, для таких транзакций использовать более стойкую к шумам, но более медленную модуляцию. В серьезных системах есть командный режим, в которых BPSK с ШПС, а более плотные модуляции пристегиваются после командной части. Часть трафика теряется, но зато вероятность потери управления ниже.