Citazione:
Originalmente inviato da merengue  nessuna confusione: è vero, cambia la frequenza, la codifica ecc ma la "teoria" che ci sta sotto è sempre la stessa, ovvero:
un "tot" di posizioni di servi (codificate come un treno di duty-cicles) devono essere trasmessi via radio. Ogni duty-cicle ha una sua risoluzione, che tanto più è alta tanto più "costa" larghezza di banda, così come il numero dei canali.
L'applicazione è real-time, questi dati devono essere trasmessi in maniera rapida e predicibile, quindi non possiamo prenderci banda "a sbafo" e consegnare pacchetti "quando capita", come fanno gli apparati wi-fi. Così come è difficile implementare algoritmi di compressione, che renderebbero il data stream molto poco resistente a "buchi" (=interferenze), quindi bisogna rimanere sul "semplice" e alleggerire i protocolli.
Sull'effettiva capacità sfruttabile dalle nostre radio, della banda dei 2,4, non posso dire di più, non sono un ingegnere della futaba. Comunque i conti da fare sono quelli, con i loro limiti. |
Occhio che in questo caso si parla di bits ...
... per definire 2048 passi occorrono 11 bits che moltiplicati per 18 canali fanno 198 bits calcolati per difetto giacchè un payload potrebbe portare un fattore N di questi 198 bits ma, cmq., sempre un'inezia rispetto alla banda di un singolo canale in 2.4Ghz ...
... insomma i dati di comando rc sono davvero pochi in relazione alle possibilità della banda in GHz ...
