|
I Logs sono grafici basati sul dominio del tempo.
Viene rappresentato graficamente l’andamento del valore di una variabile durante il trascorrere del tempo. Sull’asse verticale (ordinate) viene indicato il valore della variabile e sull’asse orizzontale (ascisse) viene indicato il trascorrere del tempo.
In questo modo è possibile ad esempio visualizzare i valore della tensione del ServoBus delle centraline di volo che alimenta la ricevente, i servi e la centralina di volo per capire se la tensione è stabile oppure oscilla nel tempo e cala quando i servi si muovono perché la corrente erogata dalla sorgente d’alimentazione (batteria / BEC) non è sufficiente e di conseguenza si “sporca” anche l’alimentazione della ricevente causando una riduzione della portata della ricevente a causa del peggioramento del rapporto segnale/ rumore oppure se c'è il rischio di un reset della centrlaina di volo.
Oppure per fare un altro esempio, è possibile visualizzare il valore degli RPM (rotazioni per minuto) del rotore principale e sapere se la velocità è costante nel tempo e quindi la velocità di reazione del modello ai comandi è costante o continua a variare rendendo il pilotaggio estremamente difficile oppure se si stanno usando contemporaneamente i governor degli ESC e quello delle centraline di volo (oscillazioni costanti a causa degli inevitabilmente diversi tempi di risposta dei due governor), oppure se l’unidirezionale slitta è c’è un improvviso aumento dei giri.
Visto che le centraline di volo come tutti i prodotti elettronici hanno dei segnali in ingresso che vengono elaborati all’interno dalla centralina di volo e dei conseguenti segnali d’uscita, è anche possibile confrontare i segnali in ingresso ricevuti dalla ricevente con i segnali in uscita verso i servi 4 per capire se ci sono problemi nell’elaborazione dei dati, nei guadagni o altro.
I parametri loggabili dagli utenti sono più di 50 e consentono una facile analisi degli eventuali problemi o dei possibili miglioramenti del setup e nella qualità del segnale radio ricevuto.
Abbiamo realizzato questa complessa ed impegnativa parte del firmware delle nostre centraline di volo per tre differenti ragioni:
1) Riuscire a fornire assistenza remota agli utenti molto più velocemente e con maggior sicurezza nell’analisi delle cause. Prima, con le vecchie centraline di volo che non avevano la sezione DIAGNOSTIC, quando un utente ci segnalava un problema non avendo in mano la trasmittente con il modello degli utenti che ci scrivevano, eravamo completamente ciechi e dovevamo ogni volta fare centinaia di ipotesi, teorie, supposizioni, dovevamo chiedere agli utenti chiarimenti, chiedere di fare a casaccio tutte le prove possibili e risponderci per comunicare i risultati. La conseguenza era che le richieste d’assistenza duravano anche delle settimane e dovevamo scrivere decine di emali e leggere decine di risposte priam di poter arrivare ad un risultato. Era difficile riuscire a fornire assistenza a più di un utente alla volta senza rischiare di confondersi con le e-mail di altri utenti.
Ora invece quando gli utenti chiedendoci assistenza allegano fin da subito il file di configurazione della centralina di volo il file degli Eventi e un Flight logs, siamo in grado di dare subito la risposta corretta o al massimo in due/tre e-mail di chiarimento.
Infatti, ora agli utenti che non ci inviano fin da subito questi files, fino a quando non ce li inviano non iniziamo neanche a rispondere. Purtroppo, ci sono utenti che anche dopo tre/quattro nostre e-mail di richiesta dei files non ce li inviano impedendoci di poter fare un analisi e non consentendoci di aiutarli.
2) Fornire agli utenti più esperti e smaliziati di poter ottimizzare il comportamento dei loro ESC, dei loro servi, delle loro riceventi e della loro meccanica basandosi su valori certi e non più su “sensazioni”.
3) Ottimizzare lo sviluppo delle varie routine usate nelle nostre centraline di volo potendo loggare noi in volo a differenza degli utenti finali l'andamento di più di 500 parametri e variabili interne.
Per quanto riguarda “Crossfire”, questo è uno dei tanti protocolli di comunicazione seriale tra riceventi e centraline di volo usati dai recenti sistemi radio TBS (proprietario) e/o ELRS (Open Source).
I sistemi radio TBS e ELRS sono nati e pensati soprattutto per l’uso con Droni perché hanno una portata radio (distanza) di funzionamento molto più elevata dei precedenti sistemi di controllo remoto.
Con gli ELI RC questo potrebbe essere del tutto inutile visto che essendo gli ELI RC molto più instabili dei droni bisogna mantenere i modelli abbastanza vicini per poterne continuamente controllare l’assetto.
Però questi sistemi radio oltre ad offrire una maggior stabilità del segnale anche da vicino, usano un flusso dati (bps) molto più elevato degli altri sistemi e anche un frame rate molto più elevato. Questo consente di ridurre la latenza e avere una ancor maggior sensazione di connessione diretta tra trasmittente e modello (per chi è in grado di sentire questa differenza).
Abbiamo però aggiunto la decodifica di questo protocollo seriale (Crossfire), in primis perché abbiamo da sempre detto che le nostre centraline di volo funzionano e funzioneranno con tutti i protocolli radio presenti sul mercato ma anche per “facilitare” i tanti utenti di droni che sempre più si stanno stufando di far volare da soli i loro droni e che vogliono iniziare a provare gli eli RC senza dover necessariamente cambiare le loro trasmittenti e riceventi.
Puoi trovare maggiori informazioni sui protocolli ELRS e TBS cercando in rete.
|