Data logger semplice

Originalmente inviato da mah!!

a me sembra proprio che ve la stiate menando di brutto..
premetto che non conosco assolutamente la formula pelizza, ma da quello che ho capito dalla discussione, si tratta di calcolare il tempo di volo dal momento dello sgancio fino a quando il modello non è fermo immobile a terra...
se lo sgancio come dite non è un problema, e il calcolo dei dati di volo compreso il tempo e dato ad un logger, credo che ricavare il momento di "modello fermo" sia una cacatina... se e dico SE il logger calcola quota 0 a tempo t... quota 0 a tempo t+1,... quota 0 a tempo t+5.... ecc.. allora il modello è fermo.

o sbaglio?

un modello puo' essere a quota zero, ma non fermo. Inoltre non esiste lo 0, ma un valore che, anche a quota costante, non è mai perfettamente costante.

[andreis]

Originalmente inviato da simone76

un modello puo' essere a quota zero, ma non fermo. Inoltre non esiste lo 0, ma un valore che, anche a quota costante, non è mai perfettamente costante.

In realtà non importa se segna zero o qualsiasi altro valore....
Ciò che conta è se sta fermo, inchiodato attorno ad un valore per un ragionevole intervallo di tempo.
Appena lo prendi in mano, è giusto che il valore di quota cambi continuamente.
Poi in volo non sta fermo MAIII, è preaticamente impossibile farlo stare fermo anche solo per una frazione di secondo.

Anche se ho "impunemete" convinto MAH che la cosa non è affatto complicata, ciò che in realtà non è banale del tutto, è appunto il riconoscimento tra Variabile ed Inchiodato attorno ad un valore.
Risolto tale punto, risplto pure il problema delo stop.
Ma di riffa o di raffa, prima o poi, MAH o qualcun'altro, sapranno tirar fuori il modo per estrarre il tempo di volo ESATTO dall'UniLog.

Antonio.

[mah!!]

Ri-premetto che non conosco la Pelizza e nemmeno i vari logger... percui posso essermi espresso male per coloro che invece con i vari logger hanno a che fare quotidianamente... quello che intendevo dire io è che se un logger è fatto decentemente, nel momento in cui un modello è in volo, a qualunque quota, sia essa 1000, 100 o 0... registra dei dati e i parametri variano.. (o sbaglio?).. mentre nel momento in cui un modello è fermo immobile i dati che vengono registrati nel tempo dovrebbero essere comunque costanti.. o quantomeno con minime variazioni del tutto trascurabili... non so poi se questi vari logger dispongano anche di un moduletto GPS... se così fosse sarebbe ancora più semplice individuare il punto di STOP del modello interpolando i dati del logger e il tracciato rilevato dal gps... cioè, se si analizzano il tracciato del gps e i dati di volo del logger, si dovrebbe riuscire a determinare il punto in cui al tempo t il tracciato è a x, nel tempo t+1 è sempre a x ... ecc..
o no?

[dtruffo]

purtroppo, essendo la quota rilevata barometricamente, e' sufficiente una minima brezza a causare all'interno delle nostre fusoliere pressioni/depressini che fanno oscillare la misurazione.

I test da me fatti con Zlog Mod3, Alti2 e Picolario evidenziano una profonda instabilita' al suolo (parliamo anche di +/- 3 mt), data dalla sensibilita' degli stumenti (che hanno una risoluzione di circa 30 cm, dato che leggono in piedi !!)

Se provi adappoggiarlo su un superficie in casa, oscilla relativamente poco, ma se solo apri o chiudi una porta, magari anche distante, leggerai una variazione.

Lasci immaginare cosa puoi leggere con lo strumneto in una fusoliera appoggiata al terreno, investita dal venticello e in balia delle turbolenze dell'erba. Non parliamo poi di cosa legge quando il modello e' attacato (a terra) dietro il trainatore, anche se a 20 e piu' metri di distanza, ma investito dal flusso dell'elica.

Le fusoliere non possono essere stagne (lo strumento non leggerebbe) e quindi risentono di qualsiasi variazione esterna

[gattodistrada]

Originalmente inviato da mah!!

Ri-premetto che non conosco la Pelizza e nemmeno i vari logger... percui posso essermi espresso male per coloro che invece con i vari logger hanno a che fare quotidianamente... quello che intendevo dire io è che se un logger è fatto decentemente, nel momento in cui un modello è in volo, a qualunque quota, sia essa 1000, 100 o 0... registra dei dati e i parametri variano.. (o sbaglio?).. mentre nel momento in cui un modello è fermo immobile i dati che vengono registrati nel tempo dovrebbero essere comunque costanti.. o quantomeno con minime variazioni del tutto trascurabili... non so poi se questi vari logger dispongano anche di un moduletto GPS... se così fosse sarebbe ancora più semplice individuare il punto di STOP del modello interpolando i dati del logger e il tracciato rilevato dal gps... cioè, se si analizzano il tracciato del gps e i dati di volo del logger, si dovrebbe riuscire a determinare il punto in cui al tempo t il tracciato è a x, nel tempo t+1 è sempre a x ... ecc..
o no?

le tue teorie son valide, ma e' la messa in pratica che e' costosa.. sia in denaro che in tempo...
un GPS costa da solo piu di 50 euro, poi biogna interfacciarlo ad un microprocessore, che ne elabora i dati come dici te.. quindi bisogna scrivere un software che sia capace di leggere sti dati ed interpretarli..
il discorso della quota fissa e' giusto ma non praticabile, perche come han detto in precedenza le variazioni possono essere anche di quelche metro, ed un aliante in costante discesa..potrebbe riuscire a perdere 1 metro al secondo.. ma anche molto meno.. e questa perdita di quota diventa costante se il pilota e bravo.. quindi che succede?? il datalogger vede che la variazione di quota e' costante.. sotto al metro al secondo..e .. stoppa il timer...
contrariamente se la tolleranza e' troppo bassa, il timer non si ferma...

senza contare che poi il GPS e armamentario vario pesano...
e temo che senza sensori esterni, sarà difficile trovare la soluzione...

[mah!!]

sicuramente è costoso, ma questo logger GPS non mi sembra sia enorme è pesantissimo... Set Basis Skynavigator V3 Bluetooth - TUN modellbau

e comunque se il logger la calcola la velocità del modello (ma eventualmente si può anche ricavare manualmente dato che lo spostamento e il tempo sono registrati (???)) dovrebbe aiutare non poco a trovare il punto d'arresto del modello no?
E interfacciato ad un software come questo: SeeYou - Software di analisi e pianificazione voli sarebbe davvero potente...

[CantZ506]

Si sta girando intorno alla soluzione del problema, ma nessuno sembra allungare il braccio per afferrarsi al palo per non scappare dal centro! Che vena letteraria, oggi!
Provo ad allungare il braccio.
Visto che è stata presa in considerazione la possibilità di modificare il regolamento, anche se con qualche difficoltà, la cosa dovrebbe essere possibile, soprattutto se giustificata da contingenti motivi tecnici.
Se si decidesse di fissare il termine del volo quando il modello si trova sotto una certa quota da stabilire (1) e al disotto di una certa velocità (2), mi sembra che ci siano i mezzi per determinare questa situazione, che può verificarsi solo all'atterraggio.
Se il logger è già in grado di rilevare detto momento o se è necessaria solo una modifica del SW, basta imporsi per cambiare il regolamento... che comporterebbe anche l'obbligo d'acquisto/installazione del logger.
Ho afferrato il palo?
Note:
(1) Se l'errore massimo rilevato per lo strumento sono 3mt, questa potrebbe essere la quota di soglia.
(2) Nessun modello riesce a volare sotto la sua velocità di stallo; qual è la minima velocità di stallo per la categoria di modelli in gara? Quella sarà la soglia.

[claudio476]

Originalmente inviato da CantZ506

Visto che è stata presa in considerazione la possibilità di modificare il regolamento, anche se con qualche difficoltà, la cosa dovrebbe essere possibile, soprattutto se giustificata da contingenti motivi tecnici.

eeee... allora è semplice!!

..a questo punto basta imporre da regolamento di mettere un bel tasto rosso di quelli per le emergenze sul modello. quando il modello atterra, il pilota deve correre a schiacchiare il tasto così il contatore si ferma. anzi, se lo si mette sotto il modello si schiaccia da solo!

Scherzi e mega tasti rossi a parte, è più semplice ed economico capire quando un modello tocca terra che capire quando è completamente fermo.

[andreis]

Originalmente inviato da dtruffo

purtroppo, essendo la quota rilevata barometricamente, e' sufficiente una minima brezza a causare all'interno delle nostre fusoliere pressioni/depressini che fanno oscillare la misurazione.

I test da me fatti con Zlog Mod3, Alti2 e Picolario evidenziano una profonda instabilita' al suolo (parliamo anche di +/- 3 mt), data dalla sensibilita' degli stumenti (che hanno una risoluzione di circa 30 cm, dato che leggono in piedi !!)

Se provi adappoggiarlo su un superficie in casa, oscilla relativamente poco, ma se solo apri o chiudi una porta, magari anche distante, leggerai una variazione.

Lasci immaginare cosa puoi leggere con lo strumneto in una fusoliera appoggiata al terreno, investita dal venticello e in balia delle turbolenze dell'erba. Non parliamo poi di cosa legge quando il modello e' attacato (a terra) dietro il trainatore, anche se a 20 e piu' metri di distanza, ma investito dal flusso dell'elica.

Le fusoliere non possono essere stagne (lo strumento non leggerebbe) e quindi risentono di qualsiasi variazione esterna

Facc... u' cazz.... della variazione !!!!

Non avrei mai pensato che fossero così "Ballerini" tutti sti ultrablasonati ....
OT: sarà mica na qestione di timing ??? OT chiuso.

L'UniLog legge con risoluzione di 0,1m !!!
Le misure sono ovviamente sovra-capionate, tanto da tenerlo mooooooolto più inchiodato ai valori misurati, allego una traccia (foglio Excel), che come puoi vedere, è stata misurata in presenza di vento anche al suolo, quando il mudel sta fermo, e quando il vento viene ancora rivelato dallo SpeedMeter anche se il mudel sta coricato nell'erba.
Ma quando il mudel sta fermo nell'erba (rasata del campo volo..) le variazioni sono sempre entro 0,1m !!!!!

Se avete pazienza, e come promesso oggi farò delle prove di + facile lettura/interpretazione.

Poi magari mi spentiscoco neeh...., ma almeno aspettate.....

Originalmente inviato da gattodistrada

le tue teorie son valide, ma e' la messa in pratica che e' costosa.. sia in denaro che in tempo...
un GPS costa da solo piu di 50 euro, poi biogna interfacciarlo ad un microprocessore, che ne elabora i dati come dici te.. quindi bisogna scrivere un software che sia capace di leggere sti dati ed interpretarli..
il discorso della quota fissa e' giusto ma non praticabile, perche come han detto in precedenza le variazioni possono essere anche di quelche metro, ed un aliante in costante discesa..potrebbe riuscire a perdere 1 metro al secondo.. ma anche molto meno.. e questa perdita di quota diventa costante se il pilota e bravo.. quindi che succede?? il datalogger vede che la variazione di quota e' costante.. sotto al metro al secondo..e .. stoppa il timer...
contrariamente se la tolleranza e' troppo bassa, il timer non si ferma...

senza contare che poi il GPS e armamentario vario pesano...
e temo che senza sensori esterni, sarà difficile trovare la soluzione...

Ebbene si, modulini GPS commerciali con tanto di Patch Antenna PreAmplificata, BlueTooth, USB interface, LiPo Battery e Caricatore, anche se costano sempre moolto meno, un minimo da soli costano anche loro.
Ma al loro interno hanno tutto ciò che serve: ChipSet GPS, Microcontrollore, Memoria, Interfacce di Comunicazione con PC ed altri dispositivi.
In realtà, potendo accedere al Firmware integrato ed al SW di controllo dedicato e fornito in boundle, questi modulini potrebbero fare tutto da soli tranne l'output Visivo mediante Display.
In tal caso ne andrebero dotati a parte, e qui i costi salirebbero non poco, specie per l'implementazione di quanto necessario per tirar fuori i dati dal modulino per ppoterli rappresentare sul display.

Occhio che il BlueTooth è un sistema Punto Punto..., e quindi per poter essere usato da un'eventuale cronometrista per i rilevamenti all'atterraggio, è necessario predisporre di una sorta di Router BlueTooth, che sapia riconoscere un certo numero di modulini/modelli, ed interconettersi individualmente a ciascuno di loro, nulla d'impossibile neehh...., magari ne esistono già anche di commerciali, ma io non ne ho mai visti, e pensavo che andrebbbe fatto aposta per la direzionei di gara.

Di più facile implementazione ci sono i sistemi tipo ZigBee compatibili e similari (sempre a 2,4GHz..), sia perchè ci sono già parecchi micro con ZigBee Like/Compatible integrato, con tanto di demo board miniaturizzata LowCost da dedicare a lato Modello, e di sistemi di Sviluppo un po' meno economici, ma ancora abbordabili per il lago gestione Gara, e la qual cosa eliminerebbe in toto la necessità di sviluppare ad hoc circuiti dedicati alla nostra applicazione, si comprano le demo board, gli si carica il SW (questo è ineviabile farlo apposta neehhh...), lo si monta nei modelli in fianco al modulino GPS, e si connette al PC il SdS, e la gara può partire.

Meglio ancora se il sistema è WiFi, ma i costi sia dei micro che lo supportano, che dei relativi SdS ed eventuali DemoBard salgono parecchio !

Originalmente inviato da mah!!

Ri-premetto che non conosco la Pelizza e nemmeno i vari logger... percui posso essermi espresso male per coloro che invece con i vari logger hanno a che fare quotidianamente... quello che intendevo dire io è che se un logger è fatto decentemente, nel momento in cui un modello è in volo, a qualunque quota, sia essa 1000, 100 o 0... registra dei dati e i parametri variano.. (o sbaglio?).. mentre nel momento in cui un modello è fermo immobile i dati che vengono registrati nel tempo dovrebbero essere comunque costanti.. o quantomeno con minime variazioni del tutto trascurabili... non so poi se questi vari logger dispongano anche di un moduletto GPS... se così fosse sarebbe ancora più semplice individuare il punto di STOP del modello interpolando i dati del logger e il tracciato rilevato dal gps... cioè, se si analizzano il tracciato del gps e i dati di volo del logger, si dovrebbe riuscire a determinare il punto in cui al tempo t il tracciato è a x, nel tempo t+1 è sempre a x ... ecc..
o no?

Quindi ciò che ho espresso in precedenti post, qualcuno l'ha capito, BENE !!

Si, sia con il Logger Barometrico, che il modulino GPS, necessitano si un SW in grado di riconoscere la posizione di FERMO da quella di MOBILE, e di controlare il cronometro e l'Output verso PC, Palmare, Display....
In tal caso L'uniLog mi sembra essere un'ottima scelta, sia per lo svolgimento della gara in se, che per utte le funzioni accessorie che fornirebbe all'aliantista coe se lo compra !!

Per inciso l'UniLog pesa solo 6grammi cavetteria compresa, dimostra un Alta Stabilità di misura, Costa sui 90€, gode di notevole flessibilità operativa, con circa 30€ può essere dotato di Ampio Display, può interfacciarsi con molti altri sensori accessori, compresi il GPS !!!!!
E tutto "da catalogo" già bell'e fatto !

Per inciso, ino non vendo l'UniLog, per questo dovete chiedere a Shaller, che se non sbaglio, dovrebbe preaticare gli stessi prezzi della SM-Modellbau .

Antonio.