Logo dati nmea navmonpc e tracce

[acquafredda]

Vorrei sottoporvi una stranezza con la speranza che qualche esperto sappia come risolvere.
Con il software navmonpc c’è la possibilitá di registrare il log dei dati nmea e poi all’abbisogna rimandare in play il file e rivedere istante dopo istante tutti i valori registrati. Il software emula una porta seriale usata da opencpn e quindi mentre il file nmea viene letto rivedo la posizione sulla carta della barca e la sua rotta, le barche attorno ricevute dal segnale ais, e tutti i vari dati di bussola vento profonditá etc.. come se si stesse rivivendo quel dato momento.
La trovò una cosa molto utile che va ben oltre il normale log dei dati o la semplice registrazione della traccia sulla mappa.
A volte mi capita che una traccia da opencpn mi si cancelli per errore e rimandando in playback il file nmea posso ricrearmi la traccia identica all’originale, con una stranezza però....anzi due!
La prima è che quando rimando il file in play c’è la possibilitá di decidere se mandarlo in 1X 5x o 10X ma ho notato che se va in 1X va comunque un pelo piú accelerato, diciamo che dopo 4 ore che va è avanti di un ora rispetto all’ora effettiva. La seconda, che a questo punto penso sia collegata alla prima, è che visualizzando i dettagli della traccia registrata su opencpn risulta una velocitá nei vari istanti molto più alta di quella reale effettiva..

Qualcuno ha per caso bisticciato con queste funzionalitá di navmonpc e opencpn e ha potuto verificare queste stranezze e magari risolverle con qualche impostazione che non conosco?

Grazie


Inviato dal mio iPad utilizzando Tapatalk

[AndreaB72]

Le sentenze NMEA non hanno un timestamp quindi è difficile che il software possa riprodurre lo stream esattamente come è arrivato, a meno di non aggiungere il timestamp in fase di creazione del log.
Se vedo il log ti dico subito se può funzionare o no - hai un esempio?

[AndreaB72]

Questo sotto è un esempio di un stream NMEA arricchito con timestamp e altre informazione che il mio software aggiunge per essere in grado di riprodurre il tutto fedelmente.

[1494938987296][**] $GPRMC,124946,A,5907.4750,N,01014.1000,E,0.1000,358.000,160517,,*22
[1494938987364][**] $GPRSA,222.00,A,,,*26
[1494938987423][**] $GPDBT,14.30,f,4.36,M,,*59
[1494938987483][**] $GPVHW,,,321.50,M,0.00,N,0.00,K*0D
[1494938987543][**] $GPMTW,50.00,C*31
[1494938987605][**] $GPVHW,,,321.50,M,0.00,N,0.00,K*0D
[1494938987662][**] $GPMTW,-1.00,C*28

[IanSolo]

Il file prodotto in formato NMEA da NavmonPC e' affetto da alcune imperfezioni poiche' si osserva che non solo non tutti i dati sono espressi nell'unita' di misura scelta per la presentazione sullo schermo ma anche che le coordinate sono scritte spesso (non tutte ma talune si) in modo "strano" ovvero talora non sono scritte con la corretta separazione prevista per le corrispondenti stringhe NMEA o in qualche altro caso il checksum della stringa e' errato.
Questo fa' produrre talora dei "salti" non previsti in quanto altri sistemi (non ho provato con OpenPCN ma ho traslato i log files per altri usi) scartano le strighe anomale e quei dati vengono banalmente ignorati.

[AndreaB72]

A parte questo (che è gia un problema), solo lo stream senza timestamping di ogni traccia non è abbastanza per riprodurre fedelmente quello che succede.
Magari è possibile fare assunzioni "ragionevoli" sulla frequenza tipica di alcune tracce (spesso è 1 secondo) o sincronizzarsi sulle info del GPS (che hanno il timestamp UTC) ma è comunque euristica e non è detto che navmonpc la implementi.
La dimostrazione è che acquafredda ha verificato che c'è divergenza.

Comunque, ho fatto una prova veloce e NavMonPC non fa enrichment dello stream.

(04-04-2018 10:39)IanSolo Ha scritto:  Il file prodotto in formato NMEA da NavmonPC e' affetto da alcune imperfezioni poiche' si osserva che non solo non tutti i dati sono espressi nell'unita' di misura scelta per la presentazione sullo schermo ma anche che le coordinate sono scritte spesso (non tutte ma talune si) in modo "strano" ovvero talora non sono scritte con la corretta separazione prevista per le corrispondenti stringhe NMEA o in qualche altro caso il checksum della stringa e' errato.
Questo fa' produrre talora dei "salti" non previsti in quanto altri sistemi (non ho provato con OpenPCN ma ho traslato i log files per altri usi) scartano le strighe anomale e quei dati vengono banalmente ignorati.

[acquafredda]

Intanto grazie per le risposte, pensavo che il problema non interessasse a nessuno ed invece c'è sempre qualcuno pronto a dare una mano!
Di Log ne ho una montagna, anche perchè ogni volta che mi muovo in automatico registra sia il log Nmea che un file CSV con una serie di campi parametrizzabili.
Questo è il link per un file di esempio

https://drive.google.com/open?id=1bz2q09...M1F8zGcJN-

Grazie per il supporto

[acquafredda]

In ogni caso faccio questo ragionamento molto banale e sicuramente troppo semplificato. Le stringhe NMEA hanno le info di data e ora del GPS (UTC). In base alle coordinate è semplice capire qual'è l'ora locale. Già la prima stranezza è che Navmonpc ti mostri l'ora locale del PC e non anche quella locale calcolata dal GPS...poi aggiungiamo che OpenCPN registra la traccia con cadenza parametrizzabile (bassa, media, alta) ma la data e l'ora anche qui sono quelle del PC. Anche cambiando date e ora del PC e sincronizzandola con quella UTC dei dati NMEA, mandando in Play dopo un pò succede che quella UTC è molto più avanti a quella del PC. Da qui mi sono accorto che OpenCPN non visualizza nei log della traccia nè SOG nè STW, ma la velocità media calcolata tra due punti successivi della traccia ed il tempo trascorso ....ed è per questo che risulta più alta!

[AndreaB72]

Quello che proponi è teoricamente possibile (e si fa) ma ha delle limitazioni. Alcuni GPS più vecchi per esempio mandano i timestamps con la precisioni dei 10 secondi (es: raymarine 120) quindi non funzionerebbe.
Il software (opencpn in questo caso) assume che uno stream NMEA sia in "real time" quindi due tracce RMC (o equivalente) consecutive arrivino con una differenza di tempi uguale alla differenza dei loro timestamp - e funziona a meno di ritardi significativi nel processo (molto difficile, i sistemi embedded non hanno questi problemi).

Fare il replay di uno stream per rigenerare una traccia funziona ma o lo stream deve essere riprodotto nei tempi corretti oppure il software ricevente si aspetta di ricevere i messaggi de-sincronizzati.
Esempio: se due stringhe sono arrivate a 0.6 secondi di distanza l'una dall'altra il replay deve fare in modo da mandarle a 0.6 secondi una dall'altra.
Una conseguenza è che nel caso generale una traccia di due ore non puoi farla girare in 10 secondi e peggio ancora, solo alcune stringhe hanno il timestamp (RMC e poco altro) quindi non c'e' modo di fare il replay affidabile di uno stream generico.

La soluzione che uso io per estrarre una traccia è di convertire usare un file GPX intermedio - mi sono fato un piccolo script che legge le tracce RMC e scrive il GPX, poi importo il GPX dove voglio, ad esempio in OpenCPN.
Se hai un minimo di manualità anche un editor avanzato ti consente di farlo con un po' di sostituzioni.

[acquafredda]

AndreaB72 alcuni passaggi di quanto scrivi non mi sono chiarissimi. In ogni caso la questione é questa:

Vorrei ricostruire una traccia su opencpn mandando in play il log nmea con navmonpc ma:

1) la data e l’ora dei vari punti della traccia opencpn sono sbagliati perchè riportano data e ora del pc
2) la velocitá istantanea dei vari punti della traccia opencpn è sbagliata perché troppo alta per conseguenza che il play dei dati nmea é troppo accelerato (evidentemente la velocitá è una media calcolata e non quella istantanea del momento)

Nulla di drammatico ma mi piaceva capire se e come fosse possibile risolvere la cosa.

Ho capito dalle tue risposte che molto dipende dal modo di registrare i dati nmea di navmonpc e mi dispiace perché ho la sensazione che il sw non sia piú sviluppato da tempo.. e il codice è chiuso. Non sarebbe male fare un plugin di opencpn che faccia la stessa cosa che fa navmonpc ma meglio...ma questo è un altro discorso...


Inviato dal mio iPad utilizzando Tapatalk

[AndreaB72]

Se ti basta importare le tracce in OpenCPN ti mando un programmino che legge il log di NavMonPC e produce un file GPX (il formato garmin per salvare le tracce gps).
Il file GPX lo puoi importare direttamente in OpenCPN (tools, route & mark manager, tracks, import GPX).

Magari un giorno mi avanza tempo e scrivo un plugin di OpenCPN che lo fa...

(04-04-2018 23:22)acquafredda Ha scritto:  AndreaB72 alcuni passaggi di quanto scrivi non mi sono chiarissimi. In ogni caso la questione é questa:

Vorrei ricostruire una traccia su opencpn mandando in play il log nmea con navmonpc ma:

1) la data e l’ora dei vari punti della traccia opencpn sono sbagliati perchè riportano data e ora del pc
2) la velocitá istantanea dei vari punti della traccia opencpn è sbagliata perché troppo alta per conseguenza che il play dei dati nmea é troppo accelerato (evidentemente la velocitá è una media calcolata e non quella istantanea del momento)

Nulla di drammatico ma mi piaceva capire se e come fosse possibile risolvere la cosa.

Ho capito dalle tue risposte che molto dipende dal modo di registrare i dati nmea di navmonpc e mi dispiace perché ho la sensazione che il sw non sia piú sviluppato da tempo.. e il codice è chiuso. Non sarebbe male fare un plugin di opencpn che faccia la stessa cosa che fa navmonpc ma meglio...ma questo è un altro discorso...


Inviato dal mio iPad utilizzando Tapatalk

[AndreaB72]

Magari interessa anche ad altri... ho trovato questo programmino Questo contenuto non e' visualizzabile da te Ospite. Se vuoi vederlo, REGISTRATI QUI . che sembra fare quello che serve ed è più user-friendly del mio

Per convertire un log di NavMonPC in un GPX importabile in OpenCPN selezionare come formato di input NMEA 018 Sentence e come output GPX XML

BV