BaroneRosso.it - Forum Modellismo

BaroneRosso.it - Forum Modellismo (https://www.baronerosso.it/forum/)
-   Radiocomandi (https://www.baronerosso.it/forum/radiocomandi/)
-   -   Radio Devention 8/8S - firmware OpenSource (https://www.baronerosso.it/forum/radiocomandi/261836-radio-devention-8-8s-firmware-opensource.html)

system450 06 agosto 13 17:37

Provati walkera cb100 col protocollo wk2401 e Blade MSR col protocollo dsm2.
L'ho tenuta accesa parecchio tra settaggi, mix, dual rate, curve varie e 4 lipo in tutto e non ho avuto alcun problema di riavvii o bloccaggi o perdite di controllo.
Sto usando la nights revision del 7 luglio 2013.
Per il momento tutto ok. Persino il bind lento senza id fixed walkera del cb100 è molto più veloce che col firmware walkera originale.
Quello dell'msr è velocissimo e funziona con l'id fixed.

Farò altre lipo coi piccolini prima di decidere se usarlo in modo definitivo o no, ma per il momento sono soddisfatto ! :approved:

eriskio 06 agosto 13 19:05

Citazione:

Originalmente inviato da romoloman (Messaggio 3892837)
Scusa perchè non sbacare l'esistente ?
I fork senza introdurre modifiche sono generalmente quanto più dannoso e dispendioso possa esistere per un progetto opensource.

Quando Bertrand ed io abbiamo fatto il fork di opentx (all'epoca open9x) era per aggiungere feature e modifiche che non erano ben accette nel progetto originale.
Se era solo per fare debugging saremmo rimasti in gruvin9x.

No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display... :rolleyes: :D
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao
:)

romoloman 06 agosto 13 22:35

Citazione:

Originalmente inviato da eriskio (Messaggio 3893805)
No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display... :rolleyes: :D
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao
:)

Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

matrixFLYER 06 agosto 13 22:59

Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :D:cool:

klamath 06 agosto 13 23:13

Citazione:

Originalmente inviato da matrixFLYER (Messaggio 3894144)
Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :D:cool:

le devention gliele paghi tu?

romoloman 07 agosto 13 09:31

Citazione:

Originalmente inviato da matrixFLYER (Messaggio 3894144)
Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :D:cool:

Già ora sarebbe impossibile,
1) pur essendo in un numero rilevante di persone lo sviluppo di opentx/companion assorbe gran parte del tempo libero e delle nottate.
2) anche se quelli di devention dicono di essersi ispirati come codice a er9x/open9x il codice è talmente diverso che ristudiarlo tutto richiederebbe del gran tempo
3) l'idea di portare opentx anche sulle devo ci era pure balenata nel cervello, ma:
a) quale devo ? Sono profondamente diverse fra loro e ogni port richiede del gran tempo.
b) chi ci paga l'hardware ? Anche prendendo i 4 core developers (Bertrand, Romolo, Mike , André) e pensando a due tipologie di Devo non partono meno di 2000€ di materiale.

ce n'est pa possible... (come direbbe il mio amico Bertrand)

matrixFLYER 07 agosto 13 19:51

Ok raga, era una mezza battuta :D

Io sto per ricevere la Devo 10. Posso fare per lo meno da beta tester!

eriskio 07 agosto 13 22:34

Citazione:

Originalmente inviato da romoloman (Messaggio 3894100)
Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

Primo neretto: sarà un mio problema, ma ho girato un po' il codice di OpenTX ma di Suite di Test automatici, - ma che dico Suite? test! - non ne ho visto neanche l'ombra.
Dove sono i programmi di test (ovviamente da fare girare sul buildato) per evidenziare eventuali regressioni? Quale tool è stato usato?
Fammi sapere.

Secondo neretto: Linux più che supportare "pasticcia" la funzionalità di un'infinità di periferiche.
E' per quello che - persa la voglia di smanettare - Linux lo si abbandona. Perchè?
Potrei anche spiegarlo ma non è il posto per scrivere un trattato.
Il PC è un utensile come lo sono il coltello e la forchetta: per usarli non bisogna conoscere la teoria degli acciai speciali e della tempra. :lol:

Vero che le famiglie BSD sono meno aggiornate, ma sono infinitamente piu' concrete e solide. E quando viene rilasciata una versione è quella, è una e le cose si fanno ad UN SOLO modo (non n-mila modi diversi). La sicurezza del sistema è dichiarata, consolidata e provata, non è chiaccherata (e se devi mettere su qualcosa che stia in piedi per anni facendo un servizio serio...)
Poi per carità hai ragione: ognuno fa' quello che vuole.
E non sono certo io a criticare qualcuno, per carità.
Tieni però presente che il bello (e il primo desiderata di Stallman) era proprio il fork e non il branch :rolleyes: :lol: :D

Ciao

-c3po- 17 agosto 13 00:47

ordinata la devo10.
:wink:
presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

system450 17 agosto 13 15:03

Citazione:

Originalmente inviato da -c3po- (Messaggio 3904063)
ordinata la devo10.
:wink:
presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

Mi raccomando ! Installa l'ultima nightly build che è derivata dalla 3.00, ma ne corregge i bug/riavvii.

matrixFLYER 17 agosto 13 15:09

Citazione:

Originalmente inviato da system450 (Messaggio 3904408)
Mi raccomando ! Installa l'ultima nightly build che è derivata dalla 3.00, ma ne corregge i bug/riavvii.

Non è che è meglio la 2.1 per quanto riguarda la stabilità? È in arrivo anche a me la devo 10...

-c3po- 17 agosto 13 16:00

Citazione:

Originalmente inviato da system450 (Messaggio 3904408)
Mi raccomando ! Installa l'ultima nightly build che è derivata dalla 3.00, ma ne corregge i bug/riavvii.

grazie,
ma per gli stick che mi dite?
nessuno l'ha aperta?

-c3po- 21 settembre 13 01:31

devo10 arrivata,
domenica la opero.

:)

-c3po- 22 settembre 13 22:59

ok,
installata la nightly 3.00.
B)
ora dovrò studiare un pò,
ma la radio mi piace ed anche il nuovo firmware.
ha delle soluzioni oserei dire geniali,
e la versatilità e programmabilità sono eccellenti.

tre domande (per ora :rolleyes:):

- si può impostare la potenza della trasmittente,
a quanto la devo settare diciamo per i miei micro elicotteri uso indoor?
...e per gli aerei che invece arrivano a diverse centinaia di metri?
non esiste una scala di riferimento?

- mi sembra che di default siano già attivi dei mix, possibile??
sulla schermata "monitor" muovendo lo stick del gas si azionano ben tre canali, e con altri stick si azionano due canali per volta...

- come si fa il bind con i bladini?

matrixFLYER 24 settembre 13 12:39

_____________________________________________
ok,
installata la nightly 3.00.
B)
ora dovrò studiare un pò,
ma la radio mi piace ed anche il nuovo firmware.
ha delle soluzioni oserei dire geniali,
e la versatilità e programmabilità sono eccellenti.

tre domande (per ora :rolleyes:):

- si può impostare la potenza della trasmittente,
SI
a quanto la devo settare diciamo per i miei micro elicotteri uso indoor?
Direi non più di 10 mW indoor...
...e per gli aerei che invece arrivano a diverse centinaia di metri?
Al massimo 150mW
non esiste una scala di riferimento?
Fai delle prove e stabilisci tu la scala no?? Parti dal minimo e 100uW e vai avanti con le prove
- mi sembra che di default siano già attivi dei mix, possibile??
sulla schermata "monitor" muovendo lo stick del gas si azionano ben tre canali, e con altri stick si azionano due canali per volta...
Se è impostato un profilo con elicottero a passo variabile è normale che muovendo il gas si muovano 3 servi quindi tutto nella norma
- come si fa il bind con i bladini?
imposti la radio su DSM2 come protocollo (o dsmx) poi accendi il modello che andrà in binding mode e allora spingi il tasto BIND sulla radio. Ricordati prima di questo di scrivere un FIXED id. Di default è 123456. Metti un valore a caso
________________________________________

C'è qualcuno che mi spiega come viene implementato il throttle hold? L'ho trovato già bello e fatto in alcuni profili ed ho trovato anche una spiegazione in inglese, ma se qualcuno me lo spiegasse in italiano lo capirei prima :D

dtruffo 24 settembre 13 12:59

Citazione:

Originalmente inviato da matrixFLYER (Messaggio 3955299)
...e per gli aerei che invece arrivano a diverse centinaia di metri?
Al massimo 150mW
non esiste una scala di riferimento?
Fai delle prove e stabilisci tu la scala no?? Parti dal minimo e 100uW e vai avanti con le prove

Ricordo che utilizzare potenze superiori a 100mW rende l'utilizzo della radio illegale.

romoloman 24 settembre 13 13:27

Citazione:

Originalmente inviato da dtruffo (Messaggio 3955319)
Ricordo che utilizzare potenze superiori a 100mW rende l'utilizzo della radio illegale.

Aggiungerei che considerato il guadagno di 2Db dell'antenna la massima potenza emessa dal modulo dovrebbe attestarsi a 63mW...
Infatti si parla di 100mW EIRP... (ovvero 100mW dati in pancia ad un dipolo isotropico con guadagno unitario)

matrixFLYER 24 settembre 13 14:53

Citazione:

Originalmente inviato da romoloman (Messaggio 3955363)
Aggiungerei che considerato il guadagno di 2Db dell'antenna la massima potenza emessa dal modulo dovrebbe attestarsi a 63mW...
Infatti si parla di 100mW EIRP... (ovvero 100mW dati in pancia ad un dipolo isotropico con guadagno unitario)

Romolo ma quindi, quello che vuoi dire è che i 100mW di una walkera equivalgono a 63mW di una spektrum? Se fosse così 150mW walkera quanti sarebbero ?

Questo spiegherebbe il range ridotto che ottengo...rispetto alla dx6i...a parità di mW in modalità range test mode che dovrebbero equivalere a 100uW e dare secondo la spektrum 30 passi di range mentre con la Devo10 ottengo meno passi che però non ho quantificato. (Credo nell'ordine della decina e passa...)

romoloman 24 settembre 13 15:12

Citazione:

Originalmente inviato da matrixFLYER (Messaggio 3955459)
Romolo ma quindi, quello che vuoi dire è che i 100mW di una walkera equivalgono a 63mW di una spektrum? Se fosse così 150mW walkera quanti sarebbero ?

Questo spiegherebbe il range ridotto che ottengo...rispetto alla dx6i...a parità di mW in modalità range test mode che dovrebbero equivalere a 100uW e dare secondo la spektrum 30 passi di range mentre con la Devo10 ottengo meno passi che però non ho quantificato. (Credo nell'ordine della decina e passa...)

se i 150mW sono reali corrispondono oltre 200mW EIRP

Non so come siano quantificati dal firmware opensource, ma di sicuro in Europa non si può eccedere i 100, questo nell'ipotesi che siano già comprensivi del guadagno dell'antenna.

Se invece sono i mW buttati in antenna non si può eccedere i 63 perché per calcolare l'EIRP c'è appunto da tener conto del guadagno della antenna stessa.

Magari sarebbe giusto chiedere all'autore sul forum di devention.

eriskio 24 settembre 13 19:45

La scala delle potenze di uscita del firmware Devention (originale Walkera) è espressa in dBm:

+20 (cioè 100 mW)
+15 (cioè 31,6 mW)
+10 (cioè 10 mW)
+5 (cioè 3,1 mW)
0 (cioè 1 mW)
-5 (cioè 0,32 mW)

Il firmware OpenSource Deviation propone una "scalatura" diversa ed espressa in mW aggiungendo due valori uno in basso (0,1 mW) e uno in alto (150 mW).
Personalmente con il software originale ho provato al campo (pianura, senza ostacoli e in zona non abitata, quindi suppongo con relativamente pochi disturbi radio) che la penultima "tacca" (+15 dBm, 31,6 mW) permette di avere una portata di oltre 900 metri a livello suolo (TX e RX tenute a circa 1.5 metri da terra).
Quindi con i +20 dBm dichiarati (o 100mW) si ha tutta la portata necessaria per condurre praticamente qualunque modello.
Così come il test di portata analogo alle Spektrum andrebbe fatto usando i -5 dBm (sul firmware DeviationTX la penultima tacca da 0,3 mW e non l'ultima da 0,1 mW).

In ogni modo per micro elicotteri uso al massimo i 10 mW (+10); solitamente il +5 dBm (3 mW) è sufficiente.
Elicotteri di classe superiori (fino ai 700) ed aerei (ultimamente mi sto divertendo con un Cessna 182 elettrico da 1.90 metri di AA) viaggio usualmente con +15 dBm.
Il +20 dBm l'ho usato l'anno scorso con un motoveleggiatore (Arcus Sport della Robbe) per tranquillità.
Francamente il 150mW (corrispondente a 21.7 dBm), oltre a non essere permesso non mi sembra nemmeno necessario (ma bisognerebbe sapere se lo sviluppatore ha indicato questo valore sulla base di sue misurazioni o di deduzioni e calcoli).

Ciao
:)

romoloman 24 settembre 13 19:59

Citazione:

Originalmente inviato da eriskio (Messaggio 3955806)
La scala delle potenze di uscita del firmware Devention (originale Walkera) è espressa in dBm:

+20 (cioè 100 mW)
+15 (cioè 31,6 mW)
+10 (cioè 10 mW)
+5 (cioè 3,1 mW)
0 (cioè 1 mW)
-5 (cioè 0,32 mW)
....

Ciao
:)

quindi immagino che i 20dBm (100mW) siano calcolati come quelli emessi con l'antenna standard

eriskio 24 settembre 13 20:04

Citazione:

Originalmente inviato da romoloman (Messaggio 3955822)
quindi immagino che i 20dBm (100mW) siano calcolati come quelli emessi con l'antenna standard

direi di sì.

matrixFLYER 24 settembre 13 21:09

Citazione:

Originalmente inviato da eriskio (Messaggio 3955806)
La scala delle potenze di uscita del firmware Devention (originale Walkera) è espressa in dBm:

+20 (cioè 100 mW)
+15 (cioè 31,6 mW)
+10 (cioè 10 mW)
+5 (cioè 3,1 mW)
0 (cioè 1 mW)
-5 (cioè 0,32 mW)

Il firmware OpenSource Deviation propone una "scalatura" diversa ed espressa in mW aggiungendo due valori uno in basso (0,1 mW) e uno in alto (150 mW).
Personalmente con il software originale ho provato al campo (pianura, senza ostacoli e in zona non abitata, quindi suppongo con relativamente pochi disturbi radio) che la penultima "tacca" (+15 dBm, 31,6 mW) permette di avere una portata di oltre 900 metri a livello suolo (TX e RX tenute a circa 1.5 metri da terra).
Quindi con i +20 dBm dichiarati (o 100mW) si ha tutta la portata necessaria per condurre praticamente qualunque modello.
Così come il test di portata analogo alle Spektrum andrebbe fatto usando i -5 dBm (sul firmware DeviationTX la penultima tacca da 0,3 mW e non l'ultima da 0,1 mW).

In ogni modo per micro elicotteri uso al massimo i 10 mW (+10); solitamente il +5 dBm (3 mW) è sufficiente.
Elicotteri di classe superiori (fino ai 700) ed aerei (ultimamente mi sto divertendo con un Cessna 182 elettrico da 1.90 metri di AA) viaggio usualmente con +15 dBm.
Il +20 dBm l'ho usato l'anno scorso con un motoveleggiatore (Arcus Sport della Robbe) per tranquillità.
Francamente il 150mW (corrispondente a 21.7 dBm), oltre a non essere permesso non mi sembra nemmeno necessario (ma bisognerebbe sapere se lo sviluppatore ha indicato questo valore sulla base di sue misurazioni o di deduzioni e calcoli).

Ciao
:)

Adesso mi ritrovo con i famosi 30 passi...finalmente è stata fatta luce :)

-c3po- 26 settembre 13 22:21

molto interessante.
grazie a tutti per le informazioni.
:)

matrixFLYER 09 ottobre 13 00:07

Ciao eriskio ho installato il modulo flysky A701 nella Devo 10 e funziona alla grande.

Non capisco però se l'output power funziona o no con questo modulo nel senso che anche se metto 1uW mi sembra che la potenza non sia ridotta perché riesco a prendere a distanze alle quali normalmente perdo il segnale con riceventi dsm2 o devo con 1uW di potenza della TX.

Sai qualcosa a riguardo?

eriskio 09 ottobre 13 10:31

Citazione:

Originalmente inviato da matrixFLYER (Messaggio 3975909)
Ciao eriskio ho installato il modulo flysky A701 nella Devo 10 e funziona alla grande.

Non capisco però se l'output power funziona o no con questo modulo nel senso che anche se metto 1uW mi sembra che la potenza non sia ridotta perché riesco a prendere a distanze alle quali normalmente perdo il segnale con riceventi dsm2 o devo con 1uW di potenza della TX.

Sai qualcosa a riguardo?

Non conosco il modulo flysky A701 non saprei esserti utile nello specifico.
Ho dato un'occhiata al forum e ho visto tra l'altro che c'erano problemi di range con i moduli flysky e la Devo10 DEVIATION Forum :: Topic: Devo 10 with A7105 range problem (1/1) (necessità di saldare a massa un piedino a quanto ho letto).
Detto questo è molto probabile che su moduli aggiuntivi la regolazione di potenza non funzioni. Direi che l'unica soluzione che hai è provare direttamente il range sul campo di volo.

Ciao
:)

matrixFLYER 09 ottobre 13 19:25

Citazione:

Originalmente inviato da eriskio (Messaggio 3976182)
Non conosco il modulo flysky A701 non saprei esserti utile nello specifico.
Ho dato un'occhiata al forum e ho visto tra l'altro che c'erano problemi di range con i moduli flysky e la Devo10 DEVIATION Forum :: Topic: Devo 10 with A7105 range problem (1/1) (necessità di saldare a massa un piedino a quanto ho letto).
Detto questo è molto probabile che su moduli aggiuntivi la regolazione di potenza non funzioni. Direi che l'unica soluzione che hai è provare direttamente il range sul campo di volo.

Ciao
:)

Ah ok peccato se non dovesse essere regolabile per risparmiare batterie e per ridurre l'inquinamento elettromagnetico. Ma se non è selezionato è spento per lo meno?

Grazie comunque per l'interessamento.


Io ho postato già da un po' sul forum la guida aggiornata con l'immagine corretta riguardo a ciò che va ponticellato. Dovrebbero aggiornare quella ufficiale quanto prima!

-c3po- 16 ottobre 13 01:11

ok,
anche se forse questo non è il tread giusto,
chi mi spiega (sulla devo10 deviata) come far andare il segnale del rudder tutto a sinistra (e anche di più),
quando tiro l'hold?
:)
ho spulciato un pò il menu "advanced" ma parecchie cose proprio non le capisco...
:wacko:

matrixFLYER 16 ottobre 13 08:23

Citazione:

Originalmente inviato da -c3po- (Messaggio 3985032)
ok,
anche se forse questo non è il tread giusto,
chi mi spiega (sulla devo10 deviata) come far andare il segnale del rudder tutto a sinistra (e anche di più),
quando tiro l'hold?
:)
ho spulciato un pò il menu "advanced" ma parecchie cose proprio non le capisco...
:wacko:

Se vuoi che si muova il canale del rudder devi fare la programmazione nel canale del rudder.
Imposti un mix complex che si attiva con lo switch rudd1 o il contrario rud0 in base a come hai impostato l'hold e poi imposti una curva fixed che so a -100 se con meno cento ti va a sinistra.
Se imposti altri mix sul canale coda è importante che questo mix sia l'ultimo.

Ricordati di fare save!

-c3po- 16 ottobre 13 09:07

ti ringrazio per la sollecitudine,
ora provo.
anche se penso che dovrò disturbarti ancora...
:rolleyes:


Tutti gli orari sono GMT +2. Adesso sono le 14:41.

Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002