nel menu' HARDWARE dalla 2.1.9 c'è la nuova opzione per disabilitare l'ADC filter

http://www.baronerosso.it/forum/atta...2&d=1478510060

Grazie
 

Lo cercavo su companion, pensando che fosse un'opzione di compilazione.

....in effetti il piano di sviluppo era di metterlo in una opzione di compilazione (così aveva detto kilrah) poi hanno messo l'opzione nell'hardware della radio (meglio).

Ciao Luciano,

il jitter che misuravo io (sia con oscilloscopio, che molto semplicemente guardando sulla mappa segnali di un programmino tipo cleanflight...) cambia sostanzialmente, il problema e' che non c'e' solo al centro (io ho i gimbal modificati con i bilanceri in alluminio e le molle dure futaba..) ma in tutte le posizioni degli stick.

Ai tempi ci avevo guardato abbastanza e purtroppo non c'e soluzione, ci sono solo delle patch che limitano il problema creandone altri... anche' l'idea di mettere una dead band al centro non mi piace molto: aggiungerebbe latenza e non so come diventerebbe il feeling dei comandi (il 3% mi sembra anche piuttosto alto), senza contare che non risolverebbe il problema in tutte le altre posizioni degli stick.
Ora, il problema non e' poi cosi' grande, ma se uno investe in servi molto precisi e veloci su modelli importanti, e poi si perde in precisione e in consume dei servi, questo e' un dealbreaker per me. Poi qui si discute su risoluzione di 1024 o di 4096, di servi digitali superveloci e poi il limite diventa la radio... francamente non mi piace.

questa solo la mia opinione

forse un po OT...
 

ma tanto vale parlarne.
Qesto problema del jitter quando si è "palesato"?
Da una versione di OpenTx in poi o c'è sempre stato?
Ho avuto per le mani la Taranis sin da quando è uscita nel 2013 e non me ne sono mai accorto.
Può essere che io sia un po troppo "dummy" per accorgermene :wacko:, ma mi piacerebbe capire.
:D

il problema si e' manifestato dalla versione OpenTX 2.1.
Se cerchi sul tubo trovi molti video che lo mostrano, la questione fu che la 2.1 era stata progettata per avere piena compatibilita' con la X9E che utilizza encoder ottici invece dei potenziometri sugli stick, il FW che permette di leggere entrambi introduce il problema sulla X9D con i potenziometri, ci sono molte discussioni anche su github: purtroppo non e' risolvibile a meno di patch che introducono altri problemi (vedi ritorno al centro etc..). Ripeto: per me e' un problema che limita la "qualita'" della radio nelle sue funzioni piu' importanti che sono la precisione, la risoluzione dei servi e la latenza. Se queste magari possono essere considerate cose soggettive, in realta' pongono un problema che con servi digitali e di buona qualita' sono avvertibili anche senza essere un pilota dai sensi sopraffini e puo' causare un consumo maggiore degli stessi. Purtroppo penso che le versioni di OpenTX che ora dovranno garantire la compatibilita' con sempre piu' modelli diversi (turnigy, X9D, X9E e Horus) diventeranno sempre piu' complicate da gestire perche' le piattaforme HW sono parecchio diverse...

Il discorso del jitter è interessante (non mi ero accorto che non è solo al centro) ma in effetti (anche se ahimè qui l'ho introdotto io) in questo thread sui LUA script non è molto in topic. Si potrebbe aprire un thread apposito e chiedere ai moderatori di spostare qualche post in modo da proseguire sul nuovo thread. Da parte mia devo dire che non ho modelli particolarmente sofisticati come quelli che usa MarcoDef (che ringrazio per gli interventi e per la bellissima guida sulla programmazione alianti che consiglio sempre a tutti) e quindi probabilmente non riesco a rilevare in concreto questo problema che indubbiamente è presente e rilevabile in modelli con elettronica più sofisticata. Presto o tardi comunque vorrei passare alla 9E che, se ho capito bene, è esente da questo problema del jitter ed è più adatta al pilotaggio a pulpito che utilizzo, mantenendo tutte le opportunità offerte da OPENTX e dai LUA script.

LUA script per 2.1
 

Sempre a scopo didattico ho provato a realizzare con LUA script un paio di semplici pagine di telemetria utilizzando le nuove modalità di utilizzo dei sensori. In particolare ho giocato un po' con il sensore di tensione delle LIPO (FLVSS) utilizzando anche i valori calcolati dalla nuova versione 2.1 per avere la tensione della cella con valore minimo, la tensione delle singole celle e il valore minimo di tensione raggiunto dalle singole celle sotto carico durante il volo che ho ritenuto utile per verificare lo stato di bilanciamento delle celle a carico.

Il primo script (motor1.lua) realizza la pagina di telemetria da usare durante il volo. Vengono visualizzati in grande il tempo motore e la tensione totale della batteria. Viene anche visualizzata con una barra la tensione della cella con valore minore che utilizzo per decidere quando la batteria è scarica (cerco di non far andare la cella più bassa sotto i 3,3-3,5V sotto carico). A motore spento (solitamente a terra) viene anche indicata una stima della percentuale di carica residua (sempre nella cella più scarsa) utilizzando una curva derivata da alcune tabelle che ho trovato in diversi siti che stimano appunto la percentuale di carica residua in base alla tensione della cella a vuoto.

http://www.baronerosso.it/forum/atta...1&d=1479328542

Il secondo script (lipocel.lua) realizza la pagina di telemetria da usare a terra dopo l'atterraggio per vedere lo stato delle singole celle a riposo e la tensione minima raggiunta dalle singole celle sotto carico durante il volo (quando non si ha tempo di guardare la radio). Lo script si adatta al numero di celle LIPO rilevate dal sensore.

http://www.baronerosso.it/forum/atta...9&d=1479328269

Gli script sono realizzati in modo molto elementare, evitando cicli complessi che, seppur eleganti, renderebbero poco leggibile lo script. Sono stati utilizzati solo i pochi statement descritti nei primi post di questo thread. Tutto è commentato in italiano per consentire eventuali modifiche ed adattamenti.

...sicuramente anche questi script non sono certo la fine del mondo e faranno sorridere gli esperti di programmazione ma io mi ci sono divertito e ho voluto condividere questa esperienza per stimolare anche voi a provare queste interessanti funzionalità che richiedono un minimo di studio ma permettono di personalizzare in modo sorprendente la propria radio per accedere a dati ed informazioni che rendono più completa la nostra esperienza di volo RC.

Luciano

.

Ciao TermicOne, non conosco bene il Lua anche se un linguaggio procedurale (specie nelle basi) è sempre simile ad altrettanti linguaggi. Notando pertanto l'attributo LOCAL mi è venuto in mente un piccolo ma vantaggioso suggerimento. Premettendo che la prima qualità di un codice è l'efficienza, intesa come rapporto tra costo di processo e risultato, se ti va, vedi se esiste anche l'attributo STATIC (o equivalente) che dovrebbe offrire il mantenimento del valore di una variabile dentro una funzione. Se esiste, al costo di sei variabili in più (una per cella), invece di confrontare con 0 il valore di ciascuna cella appena letto, lo puoi confrontare con la relativa variabile aggiunta. In questo modo, stamperai sullo schermo un valore solo se questo non è già stampato con evidente minor costo di processo, visto che la variazione del dato letto è certamente più lenta della frequenza di lettura.

Buoni voli.

PS. Se il suggerimento è apprezzato, allora dovrai porre a 0 le variabile nuove appena dichiarate cosicché la prima volta tutti gli if saranno eseguiti ed all'interno di ciascuno if, appena leggi la cella, il valore lo copi anche nella variabile aggiunta.

Grazie LONGFLYER. Non sono certo di aver capito bene ma non mi sembra che nel nostro LUA sia disponibile l'attributo STATIC

"2.3 – Variables
Variables are places that store values. There are three kinds of variables in Lua: global variables, local variables, and table fields.
A single name can denote a global variable or a local variable (or a function's formal parameter, which is a particular kind of local variable):
var ::= Name
Name denotes identifiers, as defined in §2.1.
Any variable is assumed to be global unless explicitly declared as a local (see §2.4.7). Local variables are lexically scoped: local variables can be freely accessed by functions defined inside their scope (see §2.6)."

Ciao, da ciò che riporti si comprende che potresti ottenere il medesimo risultato esecutivo usando Global al posto di Static perdendo lo scope a livello di funzione (lo scope è il campo di utilizzo, cioè in quale pezzo di codice quella variabile opera). Essendo però uno script, percio' tendenzialmente corto (e magari anche il solo) c'e' poco da confondersi prediligendo pertanto l'efficienza funzionale. Se vuoi provare, leggo che una variabile se non specificata diversamente è sempre Global, basterà quindi non usare Static per le variabili da aggiungere (se vuoi puoi anteporre a ciascun nome una g minuscola così da evidenziare ulteriormente la globalità della variabile). Può darsi inoltre che si debba dichiarerà le variabili global fuori dalla funzione (nel caso non funzionasse definirle dentro la funzione).

Buone cose.

..si avevo visto anch'io questa possibilità (che viene consigliata nei forum LUA quanto fosse necessario avere una funzionalità analoga alle variabili static del C) che ho utilizzato in alcuni casi nei primi script per altre ragioni. E' però riportato che la lettura delle variabili global è assai più lenta della lettura delle variabili local e quindi ero preoccupato che l'utilizzo estensivo di variabili global non andasse poi a detrimento dell'efficienza complessiva dello script....ci farò un approfondimento. Grazie ancora.

scusate ragazzi ma io faccio una domanda proprio base...

sulla radio ho il firmware 2.1.9
ho scaricato gli ultimi due script ma in che cartella li devo mettere sulla sd? continua a dirmi "no script su sd"
ho provato a metterli sotto /script... niente
sotto /script/nome modello... niente

bho ditemi voi
grz

EDIT: ho trovato... nella cartella /script/telemetry giusto? almeno su companion funziona cosi

Si devi metterli in SCRIPT/TELEMETRY

Naturalmente dopo aver messo gli script nella directory TELEMETRY devi assegnare ogni script a una pagina di telemetria nella sezione telemetria di companion. Devi definire i sensori come da screeshot allegato e infine definire il timer1 come tempo motore o come tempo volo a seconda di cosa vuoi visualizzare in grande nella pagina.

grz TermicOne

si ho controllato i nomi delle variabili e come timer ho il tempo di volo (Mot) ma adesso mi ritrovo questa schermata

che cosa significa?

Confermo che anche a me da lo stesso risultato, mentre nel simulatore funziona.
Più tardi provo a smanettarci un pochino, sempre che nel frattempo Luciano non dia la soluzione :D :D :D

Inviato dal mio GT-P7500 utilizzando Tapatalk

ti dico io come ho risolto!

1 - cancella il sensore cels dalla pagina telemetria
2 - vai su aggiungi sensore
3 - definisci manualmente il sensore per la batteria come nell'immagine allegata al post

puoi fare anche tutto da opentx e po copiare il modello sulla radio. da me ora funziona

Sì approfondisci perché generalmente una variabile globale costa meno in termini di processo: una variabile locale viene creata (istanziata) ed inizializzata all'inizio di funzione/script e poi anche distrutta prima di uscire. Una variabile globale invece è creata ed inizializzata una volta solo. Peraltro come ti dicevo, la variazione di valore di una cella avviene in un tempo notevolmente superiore a quello ciclico dello script, pertanto quest'ultimo passerebbe la maggior parte del tempo a riscrivere il medesimo valore su schermo.

una domanda tecnica

quali sono i limiti in punti del display? i valori x,y vanno da 0,0 a?
per quanto riguarda i widget esiste una guida? una lista...

"(1) When I declare an ordinary global variable in a file outside of a function, it will be global and visible in all other files, too.

(2) When I declare a local variable in a file outside of a function, it will be global (and static) in that specific file, but is not visible in other files."

Questo sembra promettente. Nei prossimi giorni provo...

"Taranis has an LCD display width of 212 pixels and height of 64 pixels. Position (0,0) is at top left. Y axis is negative, top line is 0, bottom line is 63"

Non so cosa siano i "widget"....

Ma questo e il testo di una guida...
Puoi mettere il link?

E' la guida alla programmazione LUA di OPENTX

versione on-line

https://opentx.gitbooks.io/opentx-lu...guide/content/

versione pdf

https://www.gitbook.com/download/pdf...eference-guide

Funziona tutto eccetto la cell min:azz:

Devi definire Celm come da screenshot allegato al post. Se vuoi posta o mandami il tuo .eepe del modello che stai usando e verifico

sei sempre gentilissimo Luciano, allego la eepe............poi dimmi la soluzione però:clap::clap:

Andrea

Nello script è previsto che la tensione della cella con valore minimo deve chiamarsi "Celm" con la C maiuscola. I nomi delle variabili sono case sensitive e devono essere immessi rispettando maiuscole e minuscole. :D

Nel tuo caso avevi definito "celm" invece che "Celm"....:wink:

come al solito mi sono perso in un bicchier d'acqua:azz:
Come posso stampo la guida.......ormai è una sfida personale