Permettetemi due parole da programmatore... fesserie del genere bug ogni 3 righe di codice ci sarebbe da spararsi a livello professionale. I bug non sono "codici scritti con qualche carattere sbagliato", lungi da quello. I bug sono per lo più dead lock (richiesta di risorse costantemente bloccate da una mal programmazione), cicli che ci mettono troppo tempo perché non ottimizzati, logica incorretta (ma qui il programmatore dovrebbe testarlo prima di mandarlo in produzione).
Ovvio poi che sulla grande distribuzione funzioni particolarmente complesse il bug possa presentarsi, subdolamente, solo sotto alcune particolari circostanze. Se invece il bug si presenta di continuo, allora vuol dire che la società ha assunto programmatori alle prime armi / sottopagati / quel che volete.
Gli errori di stampo continuo, detti anche sistematici, sarebbero cmq. una fortuna nella sfortuna giacchè sarebbero i più visibili e quindi migliormente risolvibili, il problema vero sono invece quelli casuali che ovviamente sono passati indenni le prove delle case produttrici. 
Detto questo, il programma esente da bug esiste, è fattibile, specialmente nei sistemi embedded come quelli del radiocomando / ricevente (cosa stupida: il frigorifero ha un sistema embedded, altrimenti continuerebbe a raffreddare senza posa... non credo che un giorno abbiate mai trovato ghiaccioli al posto di creme!).
Un piccolo appunto: senza ombra di dubbio, oggi specialmente, i frigoriferi hanno un sistemino embedded a processore ma certo il frigorifero base non ne avrebbe bisogno: basta utilizzare un termostato ... 
Ora, il trend delle ricetrasmittenti è "avere qualche bug", allora le società lanciano sul mercato prodotti insoddisfacenti. Essendo che tutte le major house lo fanno, son tutte contente, perché possono sempre ritirare ed aggiornare senza il rischio di perdere il cliente ("lo fanno tutti!"). Qui la tecnologia dei 2.4 Ghz c'entra poco o nulla (alla fin fine FHSS, FASST e le altre tecnologie sono letteralmente stampate su circuiti "che vanno" e che probabilmente sono gli stessi per le più disparate case produttrici), qui si parla di software di alto livello progettato male (ossia le varie opzioni di miscelazione etc), il quale manda in crisi il sistema che, per evitare il blocco permanente, si riavvia.
Il riavvio non è una costante proprio perchè cmq. non cercato.
E siete fortunati che il sistema si riavvii, perché se non l'avessero progettato così, semplicemente i vostri aerei cadrebbero senza possibilità di recupero.
Anche con eventuale riavvio del sistema, il problema resterebbe non risolto e nemmeno "pezzato" giacchè il tempo di riavvio, il più delle volte è troppo grande, specie nel caso che il riavvio interessi la radio.
Sorge quindi spontanea una domanda: perché hanno PROGETTATO il sistema per andare in failsafe?
Il failsafe è una modalità opzionale che da la possibilità al pilota di porre quello specifivo comando in un determinato stato qualora si perda il segnale di controllo o questo arrivi corrotto. L'uso del fs a volte è anche condizionato dal fatto che in assenza di segnale si cerchi il male minore e, quindi, si preferisca far precipitare il più lentamente possibile il modello.
Evidentemente sanno di avere qualche problema di logica del software, ma preferiscono inserire codici controllo piuttosto che debuggare (tempo?).
Affatto! Il motivo vero è che ogni buon sistema di controllo deve prevedere e quindi curare la condizione di sconnessione.