
# TODOs
# owner: team-ris
# conventions: - use tags #tag, owner @user, prio:<low|med|high>, est:<time>


- [x] Inserire dati di navigazione dell'ownship nel file di salvataggio della simulazione
- [x] muovere il ppi in base al movimento dell'ownship
- [x] Aggiungere tabella dei dati cinematici dell'ownship nella schermata della simulazione
- [x] Implementare il comando ping con numero indentificativo per verificare i tempi di risposta
- [ ] Mettere configurazione cifre decimali inviate nei json al server
- [ ] Se lat/lon passato dal server non è valido posso fare come fa mcs, integrare sul tempo e simulare il movimente dell'ownship
- [x] poter scegliere se visualizzare la mappa ppi fissa a nord o fissa con l'heading dell'ownship
- [x] salvare nei file delle simulazione i dati in lat/lon dei target così da poter piazzare su mappa oepnstreetmap le traiettorie e vedere come si è mosso lo scenario durante la simulazione
- [ ] vedere anche la simulazione in 3d usando le mappe dem e le mappe operstreetmap.
- [ ] Scrivere test unitari
- [ ] creare repository su git aziendale, usando codice PJ40906 come progetto  
- [x] aprire l'analisi direttamente cliccando sulla riga della tabella
- [x] creare una procedura di allineamento tra server e client usando il comando di ping da implementare anche sul server

- [x] funzione di sincronizzazione: è stato aggiunto al server la possibilità di gestire dei messaggi che sono di tipo SY (tag) che sono fatti per gestire il sincronismo tra client e server. In questa nuova tipologia di messaggi io invio un mio timetag che poi il server mi restituirà subito appena lo riceve, facendo così sappiamo in quanto tempo il messaggio che spedisco è arrivato al server, viene letto, e viene risposto il mio numero con anche il timetag del server. Facendo così misurando i delta posso scroprire esattamente il tempo che intercorre tra inviare un messaggio al server e ricevere una risposta. Per come è fatto il server il tempo di applicazione dei nuovi valori per i target sarà al massimo di 1 batch, che può essere variabile, ma a quel punto lo potremmo calibrare in altro modo. Con l'analisi sui sync possiamo sapere come allineare gli orologi. 
- [x] cercare di capire come inserire il comando di sync per allineare gli orologi

- [x] Aggiungere un tasto per duplicare uno scenario da uno già presente e dargli un nome diverso
- [ ] aggiungere una funzione automatica durante il salvataggio dello scenario che cancelli quelli più vecchi di 10 salvataggi fa, per evitare che aumentino in numero senza controllo

- [x] Aggiungere comunicazione con simulatore mathlab. Invece di mandare informazioni al server devo salvare in locale in una cartella un file csv con dentro le informazioni dei target da simulare.
<timetag>_<nome_scenario>.csv

- [x] aggiungere all'analisi di performance tutti i campioni e non solo gli ultimi 20
- [x] cambiare il modo con cui interpreto i dati del server, la X è l'asse verticale diritto avanti a me, la Y è l'asse orizzontale ed è positiva verso sinistra. Quindi quando mi arrivano i dati dal server che sono espressi in x, y e z devo tener conto di questa convenzione per fare in modo che i target sul client siano uguali a quelli visualizzati sul server.

- [x] aggiungere dati di target nella struttura json per modellizzare meglio i target.
            "\"VV\": 10.0," //Vertical Velocity
            "\"TR\": 2,"    //Turn Rate deg
            "\"TD\": 10,"   //turn duration
            "\"AMP:\": 0,"  //amplitude. ==0 use default. <:
            "\"RCS:\": 0,"  //radar cross section

- [ ] quando parte una nuova simulazione, fare automaticamente il dismiss del messaggio di quella precedente oppure scrivere inizio simulazione con nome scenario
- [ ] quando seleziono dalla combobox lo scenario, si deve vedere subito oltre l'anteprima delle traiettorie anche il tempo totale della simulazione
- [ ] fare un software a parte che prende le posizioni di target ed owhship e le disegna su una mappa georeferenziata per vedere le traiettorie nello spazio
- [ ] poter vedee i dati di differenze delle traiettorie e poter vedere per ogni punto sulla traiettoria la direzione dell'heading se richiesta dall'utente
- [ ] poter fare un playback dei risultati per poter apprezzare le differenze puntualmente
- [ ] poter fare degli zoom sulla traiettoria disegnata per apprezzare le differenze sulle manovre precise
- [ ] fare in modo di creare un editor grafico di traiettorie, dove poter posizionare punti sulla mappa ppi e potergli dare tutte le caratteristiche per disegnare la traiettoria
- [ ] sistemare il problema della previe delle tracce con virate a 9 g e oltre che il disegne viene sbagliato
- [ ] poter clonare un target modificando uno o più parametri per permettere di fare delle copie di traiettorie spostate o ruotate, per facilitare l'editor delle traiettorie.
- [ ] alungare la coda del trail per poter vedere le differenze di traiettorie già sulla mappa ppi
- [ ] allungare l'heading in base alla velocità così da capire quando il target sta andando forte oppure no.



# FIXME List

- [x] sistemare la visualizzazione nella tabe simulator, per poter vedere quale scenario è stato selezionato
- [x] sistemare l'animazione della antenna che adesso non si muove più
- [x] rivedere la visualizzazione della combobox per scegliere lo scenario da usare.
- [x] quando è finita la simulazione i target nella tabella si devono fermare all'ultima posizione scambiata.
- [x] quando la traiettoria si ferma deve comparire la x gialla e non deve sparire a fine simulazione
- [x] IMPORTANTE: verificare la rotazione dei target quando durante la simulazione ruota l'aereo, in questo caso se ruota l'aereo ed i target sono parttiti con un certo angolo rispetto allo 0, poi la traiettoria dei target deve essere aggiornata rispetto al momento iniziale e non calcolata ad ogni step di rotazione. Al momento dello start, devo memorizzare l'angolo di rotazione dell'aereo e quindi quello è l'angolo con cui dovranno essere aggiornate sempre le traiettorie dei target e non quella corrente dell'aereo che potrà girare dove vuole ma a quel punto le tracce sono partite e quindi seguiranno la loro strada. 
- [x] salvare i dati di perfomance della simulazione in altro file per evitare di appesantire file di salvataggio simulazione
- [x] caricare solo i dati dei file ce ci interessano quando passo all'analisi
- [x] verificare nel caso di simulazione su server come mai le talenze ballano così tanto.
- [x] al posto di mettere il timestamp, nei grafici mettiamo il tempo relativo al punto di partenza della simulazione visualizzata, così da avere un riferimento effettico tra il tempo del punto in oggetto e l'inizio della simulazione (poter dire "dopo 10 secondi succede questo", con i timetag la cosa non è immediata) 
- [x] sistemare la lentenza intrinseca della interfaccia su pc poco performanti 
- [x] evitare compensazione posizione dei target reali

- [ ] capire come mai su simulazioni lunghe l'interfaccia si blocca, rallenta e non fa vedere più l'antenna che si muove 
esce un messaggio 

15:20:15 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:15 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.
15:20:16 [ERROR   ] target_simulator.gui.payload_router : Payload processing queue is full! A RIS packet was dropped.