Radiocomandi modificati

[Archi]

Noi che a Genova voliamo (soprattutto volavamo) tra i ripetitori, conosciamo bene questo problema.


Una volta durante una prova radio ho visto un aliante muovere un flap a seconda di come si muoveva il modello.


Quello non era sicuramente un problema legato alla ricevente, ma ai servocomandi.


Gli alianti in particolare hanno fili molto lunghi che possono funzionare come antenne e portare eventuali disturbi sull'elettronica dei servi (o anche della ricevente è difficile dirlo).


In ogni caso, per volare sui nostri monti e consigliabile far passare i cavi dei servi dentro anelli di ferrite, per schermarli da eventuali interferenze radio di varia natura.


Un'interferenza sul link digitale invece provoca il passaggio in failsafe della ricevente e qui il comportamento dipende da come è impostato il filesafe.
Se è previsto che i servi rimangano fermi in failsafe, questi non si muoveranno.


Se invece il failsafe è stato impostato per portare i servi in una determinata posizione, allora potrebbe anche accadere che in caso di disturbi ripetuti, i servi passino dalla posizione imposta dalla radio a quella di failsafe e viceversa.


In ogni caso il link digitale (vale anche per il PCM) non consente il movimento casuale dei servi, se questo accade, allora le cause sono da cercare altrove.


Ciao.

[rovermer]

"In ogni caso il link digitale (vale anche per il PCM) non consente il movimento casuale dei servi, se questo accade, allora le cause sono da cercare altrove."


Ciao.[/QUOTE]

Pensavo anche io fosse così, ma a me è capitato con una Aurora 9 prima serie, in un modello old time, dove di servi ce ne sono solo due, e molto vicini alla Rx, quindi niente fili lunghi, e toroide antidisturbo sul filo di pilotaggio del regolatore di vedere il modello fare un looping d'ala per un improvviso colpo a fondo corsa del direzionale e a motore in palla scendere in verticale a velocità folle fuori controllo fino ad una 50.ina di metri dove la ricevente ha ripreso a funzionare correttamente. Addirittura FrSky ha modificato la codifica ACCST originale emettendo la release 2.1.0 che dovrebbe risolvere il problema obbligando tutti a flashare a questa ultima release tutte le riceventi per saltuari movimenti indesiderati dei servi. Evidentemente ci possono essere dei problemi che ci sfuggono.

[dpl]

Originalmente inviato da Archi

Noi che a Genova voliamo (soprattutto volavamo) tra i ripetitori, conosciamo bene questo problema.


Una volta durante una prova radio ho visto un aliante muovere un flap a seconda di come si muoveva il modello.


Quello non era sicuramente un problema legato alla ricevente, ma ai servocomandi.


Gli alianti in particolare hanno fili molto lunghi che possono funzionare come antenne e portare eventuali disturbi sull'elettronica dei servi (o anche della ricevente è difficile dirlo).


In ogni caso, per volare sui nostri monti e consigliabile far passare i cavi dei servi dentro anelli di ferrite, per schermarli da eventuali interferenze radio di varia natura.


Un'interferenza sul link digitale invece provoca il passaggio in failsafe della ricevente e qui il comportamento dipende da come è impostato il filesafe.
Se è previsto che i servi rimangano fermi in failsafe, questi non si muoveranno.


Se invece il failsafe è stato impostato per portare i servi in una determinata posizione, allora potrebbe anche accadere che in caso di disturbi ripetuti, i servi passino dalla posizione imposta dalla radio a quella di failsafe e viceversa.


In ogni caso il link digitale (vale anche per il PCM) non consente il movimento casuale dei servi, se questo accade, allora le cause sono da cercare altrove.


Ciao.

Confermo, senza adeguate schermature e ferriti i cavi dei servi vengono indotti ad una variazione del segnale. Purtroppo il segnale sui cavi a meno di usare il s bus non è digitale e una variazione per induzione in micro volts sul segnale di posizione, su un cavo di una certa lunghezza è frequente se esposto ad onde elettromagnetiche come nel caso del volo vicino a ripetitori.
Sostanzialmente la ricevente e la trasmissione tx rx non c'entrano nulla. Il segnale è alterato sul cavo, dove viaggia decodificato in analogico per poi nel caso di servi digitali essere riconvertito dal servo in digitale.
Ripeto, solo il sistema s bus garantisce un segnale digitale accettato o non accettato (se corrotto) e nessun movimento casuale (o black out/ failsafe)

[rovermer]

Originalmente inviato da dpl

Confermo, senza adeguate schermature e ferriti i cavi dei servi vengono indotti ad una variazione del segnale. Purtroppo il segnale sui cavi a meno di usare il s bus non è digitale e una variazione per induzione in micro volts sul segnale di posizione, su un cavo di una certa lunghezza è frequente se esposto ad onde elettromagnetiche come nel caso del volo vicino a ripetitori.
Sostanzialmente la ricevente e la trasmissione tx rx non c'entrano nulla. Il segnale è alterato sul cavo, dove viaggia decodificato in analogico per poi nel caso di servi digitali essere riconvertito dal servo in digitale.
Ripeto, solo il sistema s bus garantisce un segnale digitale accettato o non accettato (se corrotto) e nessun movimento casuale (o black out/ failsafe)

Ripeto che DOVREBBE essere così ma, tu sai come avviene il controllo di parità o di conformità all'interno della elettronica della ricevente e come vengono ricostruite le stringhe di comando in caso di interferenza esterna? Per quanto riguarda FrSky pare che il problema del movimento indesiderato dei servi derivi da un mancato controllo del numero dei bit che compongono la stringa di comando, per cui si verificava una errata decodifica della posizione dei servi perchè mancavano due bit sull'intera stringa e ovviamente questo falsava tutto. La radio non andava in filesafe o in hold ma interpretava queste stringhe sbagliate come comandi e i servi andavano per i fatti loro. Se il sistema fosse così perfetto non si spiegherebbe il proliferare di codifiche, basta vedere la Futaba che ne ha sfornate quante, 5? 6? in sequenza e tutte incompatibili tra loro, FrSkY al momento ne ha tre diverse, ACCST, ACCST 2.1.0 e ACCESS, il modulo 4in1 in uso sui Tx Jumper e Radiomaster può dialogare con circa 70 codifiche differenti. Se un cellulare perde la codifica al massimo non capisci chi ti sta parlando, se un radiocomando interpreta la codifica scambiando fischi per fiaschi precipiti. A me sinceramente non pare un sistema così affidabile.... Adesso sto volando con Jeti, spero di non avere problemi, perchè altrimenti torno davvero ai 35 Mhz in PCM! Almeno con la vecchia MC20 andava in Hold ma non mi ha mai mosso alla ca..o di cane i servi neanche con prolunghe senza toroidi di un paio di metri! Ho inseguito un modello per un paio di km perchè la rx si era bloccata in hold e non si resettava, ma i servi almeno restavano al loro posto se in hold, o si posizionavano dove decidevo io col filesafe inserito....

[pikemax]

Originalmente inviato da rovermer

. Se il sistema fosse così perfetto non si spiegherebbe il proliferare di codifiche, basta vedere la Futaba che ne ha sfornate quante, 5? 6

Rover,

o non ho capito o non mi risulta.
Fasst è il primo uscito ed è tutt'ora compatibile e funzionante con le nuove norme euroepee;
Fasstest è quello telemetrico che può essere a 12 o 18 canali;
Fhss è quello low cost che usa il chip non proprietario Fuataba.
Per quanto a mia conoscenza sono usciti come aggiunta di prestazioni e prodotti differenti, all'inizio non c'era la telemetria, poi è arrivata, poi hanno deciso di offrire delle rx meno costose e limitare l'uso dei cloni.
Che ci siano protocolli Futaba con dei bug non mi risulta.
In gara vedo usare con successo ancora delle T12 e delle rx 6008 del 2007/2008 senza alcun problema.
Mi spiace che tu abbia perso tanto tempo dietro ai cinesi e mi fa piacere che tu abbia trovato un prodotto che ti soddisfa nella Jeti.
Conoscendo le tue capacità e caparbietà son certo che se hai fatto tu questa scelta sia davvero un disastro utilizzare con profitto determinati prodotti e che i cinesi dovrebbero riflettere un momento sulla loro politica di prodotto.
Per fortuna accendo la radio e funziona senza esitazioni e non ne so nulla di nulla di come funziona la parte codifica, la accendo e volo.

[BBC25185]

Originalmente inviato da rovermer

Ripeto che DOVREBBE essere così ma, tu sai come avviene il controllo di parità o di conformità all'interno della elettronica della ricevente e come vengono ricostruite le stringhe di comando in caso di interferenza esterna? Per quanto riguarda FrSky pare che il problema del movimento indesiderato dei servi derivi da un mancato controllo del numero dei bit che compongono la stringa di comando, per cui si verificava una errata decodifica della posizione dei servi perchè mancavano due bit sull'intera stringa e ovviamente questo falsava tutto. La radio non andava in filesafe o in hold ma interpretava queste stringhe sbagliate come comandi e i servi andavano per i fatti loro. Se il sistema fosse così perfetto non si spiegherebbe il proliferare di codifiche, basta vedere la Futaba che ne ha sfornate quante, 5? 6? in sequenza e tutte incompatibili tra loro, FrSkY al momento ne ha tre diverse, ACCST, ACCST 2.1.0 e ACCESS, il modulo 4in1 in uso sui Tx Jumper e Radiomaster può dialogare con circa 70 codifiche differenti. Se un cellulare perde la codifica al massimo non capisci chi ti sta parlando, se un radiocomando interpreta la codifica scambiando fischi per fiaschi precipiti. A me sinceramente non pare un sistema così affidabile.... Adesso sto volando con Jeti, spero di non avere problemi, perchè altrimenti torno davvero ai 35 Mhz in PCM! Almeno con la vecchia MC20 andava in Hold ma non mi ha mai mosso alla ca..o di cane i servi neanche con prolunghe senza toroidi di un paio di metri! Ho inseguito un modello per un paio di km perchè la rx si era bloccata in hold e non si resettava, ma i servi almeno restavano al loro posto se in hold, o si posizionavano dove decidevo io col filesafe inserito....

Dunque... NON esiste nessun sistema IMMUNE ai disturbi... cascano i razzi della NASA figurati i nostri modelli.
Ora parlando piú seriamente, i protocolli digitali hanno tutti un controllo del segnale... quindi un segnale generato da un'altra radio viene magari ricevuta ma scartata perché errata. quindi l'unico problema che puó essere realistico é la saturazione della banda disponibile... cosa che mi é successo a Verona con le DSM2 (troppe radio accese, DSM2 senza Hopping, dopo 10 metri perso il segnale radio e modello in failsafe).
Ora, a parte bug presenti nel software (il bug di FRSKY accade molto raramente), in tutte le RX, se non riceve correttamente il segnale radio, esegue il failsafe (quindi una dei 3 sistemi: Hold, NoPulse o Position).
NON E POSSIBILE CHE 1 SOLO SERVO FACCIA QUELLO CHE VUOLE... se cé un problema é un problema su tutti i servi, non solo su 1.
Se il problema é su un solo servo o, comunque, non su tutti i servi, 2 casi: la ricevente dá di matto oppure problema ai servi.
Occhio che quando parlo di ricevente dá di matto non vuol dire che é difettosa... puó essere per BUG ma, decisamente piú spesso, é causato da alimentazioni schifose.
Per i servi, invece, é decisamente piú facile dar di matto in quanto sono analogici quindi un disturbo sul cavo del segnale del servo basta a metterlo nella posizione sbagliata!
In conclusione: per esperienza personale posso dire che al 99,9%, i problemi sono causati da una alimentazione pessima o non sufficiente oppure da falsi contatti. Sempre personalmente, dopo circa 30-40 riceventi di vario tipo usati in varie tipologie di modelli, l'unico problema causato dal protocollo radio lo ho avuto tra 2 radio Turnigy che, per qualche assurdo motivo, interferivano tra loro (solo tra loro 2, con le altre Turnigy nessun problema). E, ovviamente, a Verona con il DSM2 (risolto usando altri protocolli piú moderni e tenendo le riceventi DSM2 per luoghi poco popolati come al campo volo)

[giocavik]

Ho letto da qualche parte che la
soluzione ai segnali 'strani' che si
immettono o viaggiano nei cavi,
(molto) meglio che i toroidi, e' di
intrecciare i (tre) cavi, tipo i cavi
Futaba anni 70...
E' così...?..per prolunghe anche
lunghe metri, basterebbe fare una
buona treccia per ottenere risultati
a prova di interferenza, almeno per
quel che riguarda collegamenti tra
servi e ricevente..?
(..non e' che si debbano intrecciare
i cavi dei servi tra loro...ma se ci ho
un servo anche a tre metri dalla rx,
se 'mescolo' accuratamente i tre fili
di collegamento, quel servo non
dovrebbe raccogliere 'sporco'...
Può essere vero..?..)

[seengapoor]

Originalmente inviato da giocavik

..
Può essere vero..?..)

E' un trucchetto che usavo (ma credo sia ancora attuale) in elettroencefalografia, dove i cavi sono lunghi e sottili e il segnale è debolissimo. Costo zero ma efficacissimo!

[pikemax]

Originalmente inviato da seengapoor

E' un trucchetto che usavo (ma credo sia ancora attuale) in elettroencefalografia, dove i cavi sono lunghi e sottili e il segnale è debolissimo. Costo zero ma efficacissimo!

Le prolunghe trecciate funzionano per eliminare le interferenze che entrano dai cavi, confermo.

[AdrianOK]

Genova, ma non solo: io sono nato dall'altra parte, a Muggia (TS) e le nostre alture sono impestate di antenne solo che non ci sono prati o luoghi su cui volare (per vari motivi geopolitici che non è il caso di tirar su adesso) Ma grazie per le informazioni preziose sull'assorbimento elettromagnetico dei cavi dei servi.
C'è solo un problema di incasellamento: io NON volo sotto le antenne perchè quassù sopra Vittorio Veneto non ce ne sono, anche se a un paio di chilometri ci sono quelle del Col Visentin che irrora la pianura.
Ho pensato addirittura a problemi di interferenze con aerei, ho visto 4 (dico quattro) F35 della base di Aviano passarmi sotto e vicinissimi ma non ho avuto problemi. Mi hanno detto che se attivano le contromisure elettroniche sono cavoli ma non mi è mai successo.
Però l'ultima volta, come ho scritto, ho annusato che il problema era la radio modificata del mio amico, mi sono allontanato una quindicina di metri e ho volato senza altri problemi.