La nuova T18 Futaba

[merengue]

Originalmente inviato da Archi

Quoto in pieno.

Il numero di canali oramai, soprattutto con la nascita dell'S-Bus, non è altro che un dettaglio software da modificare a piacimento.

In realtà mica tanto: più canali = più larghezza di banda richiesta. Se si è al limite (come già dimostrato ai tempi del disastro delle PCM G3) è necessario ridurre la correzione d'errore o la sensibilità in db oppure aumentare il lag per via del maggior numero di frames richiesti per la trasmissione. In tutti i casi ci sono grossi scotti da pagare.

[LONGFLYER]

Originalmente inviato da merengue

In realtà mica tanto: più canali = più larghezza di banda richiesta. Se si è al limite (come già dimostrato ai tempi del disastro delle PCM G3) è necessario ridurre la correzione d'errore o la sensibilità in db oppure aumentare il lag per via del maggior numero di frames richiesti per la trasmissione. In tutti i casi ci sono grossi scotti da pagare.

Occhio a non confondere la cioccolata con la ... ... nel caso del PCM si è in banda 35/40 MHz contro i circa 2400 MHz ...

[merengue]

Originalmente inviato da LONGFLYER

Occhio a non confondere la cioccolata con la ... ... nel caso del PCM si è in banda 35/40 MHz contro i circa 2400 MHz ...

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.

[LONGFLYER]

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 ...

[merengue]

Originalmente inviato da LONGFLYER

Occhio che in questo caso si parla di bits ... ...

Proprio perchè si parla di "bits".... c'è molto di più (che non rientra nel mero calcolo che hai fatto tu) che fa parte del protocollo di trasmissione, che in genere viene chiamato "overhead", cioè tutto quello che è "in più". Handshake, header "pacchetti" (anche se non sono pacchetti), ECC (correzione errori), bisogna conoscere il protocollo (chiuso).

[LONGFLYER]

Originalmente inviato da merengue

Proprio perchè si parla di "bits".... c'è molto di più (che non rientra nel mero calcolo che hai fatto tu) che fa parte del protocollo di trasmissione, che in genere viene chiamato "overhead", cioè tutto quello che è "in più". Handshake, header "pacchetti" (anche se non sono pacchetti), ECC (correzione errori), bisogna conoscere il protocollo (chiuso).

Difatti ho parlato di payload (dovuto all'incapsulazione dell'informazione ...) che potrebbe moltiplicare per N i circa 200 bits necessari ai 18 canali, ma per quanto si possa moltiplicare (quand'anche fosse di un fattore elevato pari a 10), rispetto alla potenzialità della banda restano un'inezia ...

[bresaola]

Originalmente inviato da LONGFLYER

Difatti ho parlato di payload (dovuto all'incapsulazione dell'informazione ...) che potrebbe moltiplicare per N i circa 200 bits necessari ai 18 canali, ma per quanto si possa moltiplicare (quand'anche fosse di un fattore elevato pari a 10), rispetto alla potenzialità della banda restano un'inezia ...

Ma che ghezz.........??????!!!!:wack o:

[merengue]

Originalmente inviato da LONGFLYER

Difatti ho parlato di payload (dovuto all'incapsulazione dell'informazione ...) che potrebbe moltiplicare per N i circa 200 bits necessari ai 18 canali, ma per quanto si possa moltiplicare (quand'anche fosse di un fattore elevato pari a 10), rispetto alla potenzialità della banda restano un'inezia ...

No, non è assolutamente vero. Ripeto: non hai disponibilità di banda "piena" come i router, mai hai piuttosto dei vincoli stringenti per ciò che riguarda la latenza e il numero di frames (UNO, a fare le cose per bene) per ogni treno di impulsi, come dettano le ultime mode di marketing in fatto di latenza. Di certo una radio del genere non si può permettere il lusso di andare lenta nelle risposte. Inoltre, è impossibile quantificare a priori l'overhead di un protocollo digitale che mette la robustezza del link al primo posto. Di solito in queste applicazioni l'ECC può avere un overhead enorme, anche parecchie volte più voluminoso dello stesso data stream.

[rillo75]

Originalmente inviato da merengue

nessuna confusione: è vero, cambia la frequenza, la codifica ecc ma la "teoria" che ci sta sotto è sempre la stessa, ovvero:

assolutamente no!!! La teoria è ben diversa dato che la trasmissione è in digitale e non analogico.....

[brunart]

mi sono letto tutta questa discussione
...............
..........
???????????????

mi sa che per ora
la mia JR PCM9X II con le riceventi jr e graupner a 35 MH
me li tengo strette