La traccia GPS della dashcam: quattro limiti che scopri solo aprendo il file

Auto

Dashcam

Kit

Tempo

Serve

Esito

Copertina GuidaDashcam: traccia GPS della dashcam, quattro limiti che scopri aprendo il file; l'ora nel file è indietro di otto ore e una riga su cinque non ha l'ora

Questo articolo contiene link di affiliazione. GuidaDashcam partecipa al programma di affiliazione 70mai: se acquisti passando dai link presenti in questa pagina, il sito riceve una commissione senza costi aggiuntivi per te. Questo non influisce sulle valutazioni, che restano basate sui test descritti.

Se la tua dashcam ha il GPS, probabilmente ragioni come ragionavo io: oltre al video ho una seconda testimonianza. Dove ero, a che velocità andavo, a che ora. Se un giorno la mia versione dei fatti dovesse reggere contro quella di qualcun altro, sotto le immagini c’è un registro che le accompagna passo per passo.

Sulla mia 70mai T800 quel registro è un file di testo sulla scheda di memoria, si chiama GPSData000001.txt, e 70mai non ne pubblica il formato. L’ho aperto il 18 settembre per un motivo banale: durante il controllo mensile della scheda risultava modificato quella mattina, in un giorno in cui l’auto non l’avevo usata. Ho cominciato a leggerlo per capire perché, e ci ho trovato altro. A metà ottobre l’ho riaperto su una copia più recente, con accanto i video protetti ancora sulla scheda, per controllare quello che avevo dedotto: alcune cose reggevano, altre no. La risposta alla domanda da cui ero partito è arrivata per ultima, e sta nel terzo limite.

La tesi di questo articolo sta tutta qui: la traccia GPS della mia dashcam è un testimone preciso ma distratto. Misura bene la velocità, ma scrive un’ora sbagliata di otto ore mentre il video ha quella giusta, perde l’ora esatta di una riga su cinque, in sosta di solito tace ma a volte scrive per ore sotto il nome di una clip già finita, e non segna il momento in cui scatta il sensore. Nessuna di queste quattro cose si scopre dalla scheda prodotto: si scoprono solo leggendo il file riga per riga.

Prima di cominciare, i limiti di questo articolo. 70mai non pubblica il formato del file: due campi, la velocità e la direzione, li ho controllati con misure indipendenti, gli altri li ho dedotti dai valori. Tutto vale per una T800, per il file che copre poco più di due mesi, dal 7 luglio al 18 settembre 2026: su altri modelli, o sulla stessa dashcam con un altro firmware, non lo so. E non ti dirò quanto vale la traccia in una contestazione: è una domanda legale, e qui si parla solo di cosa c’è nel file e di cosa gli manca.

L’altro lato della stessa scoperta, cioè che quel file ricorda i tuoi spostamenti anche quando i video sono stati sovrascritti da settimane, l’ho raccontato nell’articolo su dashcam e privacy. Qui la domanda è un’altra: quanto ci si può contare.

Una riga ogni secondo e mezzo, e nessuno ti dice cosa c’è scritto

Se cerchi «traccia GPS dashcam» per capire dove finiscono posizione e velocità, sulla T800 la risposta è questo file. Sta nella cartella principale della scheda, accanto alle cartelle dei video (Normal, Parking, Event). Il 18 settembre, sulla mia, pesava 28,9 MB e conteneva 334.235 righe, dal 7 luglio a quella mattina. Mentre la dashcam registra ne scrive circa una ogni secondo e mezzo: una clip da un minuto ne ha, in mediana, 40. Le righe hanno quasi tutte questa forma:

1783412019,A,XX.XXXXXX,XX.XXXXXX,32800,0,-10,3,-104,NO20260707-181318-000000F.MP4,0,0,0

Le coordinate le ho sostituite con delle X: sono quelle vere di un mio tragitto, e non c’è motivo di pubblicarle. Il resto della riga è com’era. Letta da sinistra:

  • 1783412019 è l’ora, scritta come la contano i computer: i secondi passati dal 1° gennaio 1970. Si chiama ora Unix, e tienila a mente, perché è il campo del primo limite.
  • A dice che il GPS aveva un segnale valido dai satelliti. Nelle poche righe senza segnale c’è V, e l’ora vale zero.
  • Poi latitudine e longitudine.
  • 32800 è la direzione di marcia, in centesimi di grado: 328 gradi, contati da nord in senso orario.
  • 0 è la velocità, in centesimi di metro al secondo. In questa riga l’auto era ferma.
  • -10,3,-104 sono i tre assi dell’accelerometro, in centesimi di g: messi insieme fanno circa 1 g, la gravità che il sensore sente sempre.
  • Infine il nome della clip che la dashcam stava registrando in quel momento, e tre campi che valgono zero in questa riga e in tutte le altre, e che non so interpretare.

Ogni tanto, al posto di una riga di dati, c’è un’intestazione: $V02. È la prima riga del file, ma non l’unica: nel file del 18 settembre compare 206 volte, quasi sempre subito prima del primo video di un viaggio.

La velocità è precisa, ed è la cosa da sapere prima di tutto il resto. Visto che il formato non è pubblicato, le unità le ho dovute ricavare, e per velocità e direzione non mi sono accontentato di valori che sembrassero plausibili: le ho controllate in due modi che non dipendono l’uno dall’altro. Il primo è la strada fatta fra una posizione e la successiva, su migliaia di tratti di guida: la velocità che se ne ricava è quella del sesto campo, la rotta è quella del quinto. Il secondo è la velocità che la dashcam stampa in sovrimpressione sui video: nei sette video protetti di cui parlo più avanti, le righe la ripetono valore per valore. L’accelerometro invece resta una deduzione: il conto torna, ma una seconda misura non ce l’ho.

Le mie velocità non le trovi in questo articolo: per capire il file non servono.

Per guardarlo basta un editor di testo. Per contarlo, cioè per sapere quante righe hanno l’ora e quante no, serve un foglio di calcolo o poco di più.

Primo limite: l’ora nel file è indietro di otto ore, quella sul video no

Riprendi la riga d’esempio. Il numero 1783412019, convertito in ora italiana, dà le 10:13:39 del 7 luglio. È la prima riga della clip che nomina, NO20260707-181318, cominciata alle 18:13:18. Aggiungi otto ore e ottieni le 18:13:39: l’ora torna, i secondi no. Fra la riga e l’inizio della clip ci sono ventun secondi.

Sono due scarti diversi, e conviene tenerli separati.

  • Le otto ore sono fisse. Su luglio, agosto e settembre, la prima riga di ogni clip che abbia l’ora, più otto ore, cade sempre entro tre minuti dall’ora scritta nel nome della clip. E quando la dashcam non ha l’ora, al suo posto scrive -28801: otto ore e un secondo prima dell’istante zero dell’ora Unix. Lo scarto di otto ore è scritto perfino dentro il valore che significa «ora non disponibile».
  • I secondi, di solito, non tornano. Corretta delle otto ore, l’ora delle righe è comunque avanti rispetto al video: di poco più di un minuto nel caso tipico, da quasi zero a due minuti e mezzo nei casi estremi. Dentro lo stesso viaggio lo scarto di solito resta quasi fermo, da un viaggio all’altro cambia. L’ho misurato su oltre quattromila clip in cui tutte le righe hanno l’ora. Quale dei due orologi sbagli quel minuto, il file non lo dice.

Poi c’è il fatto che rende tutto più insidioso: l’ora stampata sul video e quella nel nome del file coincidono fra loro e sono quelle italiane, quindi le otto ore di errore stanno tutte nel campo dell’ora del file GPS.

Chi guarda il video vede l’ora giusta, e chi usa la traccia (tu, un programma di mappe, chiunque la riceva) si porta a casa otto ore di errore senza un segnale che qualcosa non torni. Un programma che converta quel numero in un orario, senza sapere dello scarto, ti mostrerà ogni punto otto ore prima di quando ci sei passato, e nel file non c’è niente che lo avverta.

L’app 70mai, invece, questo errore non lo fa: sui video che ho esportato con i dati di guida mostra l’ora giusta, e la velocità segue il video al secondo. Lo racconto nelle domande in fondo. Il problema è del file, quando lo apri da solo o lo dai a qualcuno.

E anche chi conosce le otto ore e le corregge sbaglia di un minuto. Se cerca nella traccia un istante del video passando dall’ora, legge la velocità e le frenate di circa un minuto prima. È l’errore che ho fatto io alla prima lettura: ho cercato gli eventi con l’ora delle righe, e su uno di questi ho letto un tratto a velocità costante, mentre il video, in quei secondi, mostra un rallentamento.

Un caso diverso è quello della Midland Street Guardian Mini, dove il fuso di fabbrica era GMT-5 e a essere sbagliata era l’ora dei video stessi: si corregge dall’app, e l’ho raccontato nella recensione sulla Sandero.

Una cosa che non so: tutto il mio file è stato scritto con l’ora legale. Se con l’ora solare lo scarto resti di otto ore o cambi, da questi dati non si può dire.

La conclusione pratica: per ritrovare nella traccia un momento del video, non passare dall’ora, passa dal nome. Quasi ogni riga porta il nome della clip, anche quelle senza ora (lo vedi nel prossimo limite; l’eccezione delle soste è nel terzo): cerchi il nome del video, prendi le sue righe e le leggi in ordine, sapendo che ne arriva una ogni secondo e mezzo circa. È così che ho rifatto i conti di questo articolo, ed è così che le righe tornano con la velocità stampata sul video.

Il nome però cercalo senza l’estensione: nel mio file quasi una riga su tre lo scrive con .MP44 al posto di .MP4, e cercando il nome completo quelle righe non le trovi.

L’ora del file serve solo se la traccia deve uscire da casa tua: in quel caso va detto, insieme al file, che è indietro di otto ore e che anche corretta non vale al secondo. Sulla tua dashcam non fidarti dei miei numeri: confronta una riga con il nome della clip che cita, costa un minuto.

Secondo limite: una riga su cinque non ha l’ora

Ho contato tutte le righe che il file aveva il 18 settembre, non un campione.

Righe del fileQuanteQuota
con l’ora valida155.10346,4%
con l’ora azzerata (-28801)38.48411,5%
senza segnale GPS (V, ora a zero)213meno dello 0,1%
sosta del 13-14 luglio, con l’ora (terzo limite)115.22534,5%
sosta del 17-18 settembre, con l’ora azzerata (terzo limite)25.0047,5%
intestazioni $V02206meno dello 0,1%
Totale334.235

Le due soste le racconto nel terzo limite. Qui contano le altre righe di dati: 193.800, e di queste 38.484 hanno l’ora azzerata, il 19,9%. Su tutto il file, sosta di settembre compresa, le righe senza ora sono 63.488, il 19,0%. In tutti e due i casi, una su cinque.

Righe rovinate non ce ne sono: tutte le righe di dati hanno lo stesso numero di campi.

Nelle righe azzerate la posizione c’è: il segnale dei satelliti è valido, le coordinate pure, e la velocità torna con quella del video. Manca solo l’ora. E c’è il nome della clip, in tutte: l’ora esatta manca, ma il minuto si recupera dal nome della clip che la riga cita, e contando le righe dentro la clip anche qualcosa di più. Visto il primo limite, anzi, il nome è l’orologio più affidabile che il file abbia, tranne che nella sosta di settembre, dove non data niente: lo vedi nel prossimo limite.

Fuori dalla sosta di settembre non stanno sparse a caso. Quasi tutte, il 94,3%, cadono in viaggi interi in cui l’ora non è mai arrivata: 36 viaggi su 190 nel periodo, dove per viaggio intendo una serie di clip di marcia una dopo l’altra, senza pause di più di un minuto fra la fine di una e l’inizio della successiva. Un viaggio parte con l’ora o senza, e di solito resta com’è partito fino a quando spegni.

Un viaggio intero può avere la traccia senza l’ora. Un programma che legga solo quel campo lo butta via, o lo colloca nel 1969; chi passa dal nome della clip lo data al minuto.

Uno dei sette video protetti di cui parlo più avanti, quello del 14 settembre, è caduto proprio in uno di questi viaggi: nessuna riga ha l’ora, ma la traccia c’è, e si ritrova dal nome.

Terzo limite: in sosta di solito tace, ma a volte scrive sotto il nome sbagliato

Nessuna riga, su 334.235, cita una clip di sosta (quelle il cui nome comincia con PA). Nessuna cita una clip protetta (EV). Alla prima lettura ne avevo concluso che il file segue la marcia e solo quella. Mi sbagliavo, e la prova era la domanda da cui ero partito: perché il file risultava modificato la mattina del 18 settembre, con l’auto ferma dalla sera prima.

Le ultime 25.004 righe citano tutte la stessa clip, l’ultima registrata la sera del 17 settembre, poco prima di mezzanotte. Nessuna ha l’ora. Le posizioni stanno quasi tutte entro cinque metri dallo stesso punto, e la velocità è zero in tutte tranne quindici: l’auto era parcheggiata. Sulla scheda, dopo quella clip, non c’è nessun video, né di marcia né di sosta. La dashcam ha passato la notte a scrivere la traccia di un’auto ferma, fino alla mattina dopo: l’ultima modifica del file è delle dieci passate, e venticinquemila righe al ritmo di una ogni secondo e mezzo fanno proprio una decina d’ore.

Non è l’unica volta. Dalla tarda sera del 13 luglio il file ha scritto per ventiquattro ore di fila, 115.225 righe, tutte sotto il nome di una sola clip, l’ultima di quella sera. Questa volta con l’ora, ma anche qui l’auto non si muove: velocità zero in 98 righe su cento, posizioni quasi tutte entro sette metri dallo stesso punto. E con una stranezza in più: le righe arrivano a gruppi che si accavallano, e ogni cinque righe circa l’ora torna indietro di qualche secondo. Succede 22.368 volte, e solo lì: nel resto del file l’ora non torna mai indietro.

Messe insieme, le due soste fanno 140.229 righe, più di quattro righe del file su dieci. Nelle altre soste del periodo il file non ha righe, e perché in queste due sì non lo so.

Non vanno confuse con l’auto ferma mentre la dashcam continua a registrare clip di marcia: lì le righe ci sono come in viaggio, con la velocità a zero e un nome nuovo a ogni clip.

Per chi usa la traccia, questo vuol dire tre cose.

Se qualcuno ti urta l’auto parcheggiata, la prova è il video. Di solito la traccia di quei minuti non esiste. Quando esiste dice solo che l’auto era ferma, e lo dice sotto il nome di una clip di ore prima: a luglio con l’ora, a settembre senza. Come funziona la sorveglianza in sosta e cosa serve per averla l’ho spiegato nell’articolo sulla modalità parcheggio.

In sosta il nome della clip non data niente. Le righe di settembre portano il nome di una clip di prima di mezzanotte e arrivano alla mattina dopo: per loro il metodo del primo limite non funziona. Si riconoscono perché sono troppe: una clip da un minuto ne ha una quarantina, quella ne ha più di venticinquemila.

Il file ricorda anche dove l’auto resta ferma, per una notte intera o per un giorno. È un motivo in più per non dare via la scheda senza pensarci.

Quanto alle clip protette, la loro assenza è solo apparente. Quando la dashcam protegge un video mentre guidi, quel video si chiama come la clip di marcia di cui prende il posto, con EV davanti invece di NO: stessa data, stessa ora, stesso numero progressivo. Nel file le righe di quei secondi ci sono, sotto il nome che comincia con NO. Per legare un video protetto alla sua traccia basta il nome: cambi due lettere e cerchi.

Quarto limite: la traccia non segna lo scatto, e un colpo breve può sparire

Fra il 19 luglio e il 17 settembre la cartella dei video protetti della mia T800 ha raccolto sette eventi, con la sensibilità del G-sensor su «Medio», il valore di fabbrica che non ho mai toccato. Ogni evento salva tre video (anteriore, posteriore e abitacolo): qui guardo quello anteriore, e lo chiamo semplicemente il video protetto. Quanto spazio si sono presi sulla scheda l’ho contato nel controllo mensile della microSD; qui conta cosa dice la traccia di quei momenti.

Ogni video protetto, sulla mia T800, è un intero spezzone di registrazione, lungo fra 41 e 84 secondi, e corrisponde alla clip di marcia con lo stesso nome. Per questa tabella ho letto la sovrimpressione dei video, cioè la velocità che la dashcam stampa in basso a sinistra, e l’ho confrontata con le righe di quella clip: tornano in tutti e sette. Perché guardo trenta secondi prima della fine lo spiego subito dopo.

Video protetto e durataCosa mostra la sovrimpressione, e trenta secondi prima della fine
19 luglio, pomeriggio
84 s
una frenata fino quasi a fermarsi, una ripartenza e poi una forte accelerazione, un lungo rallentamento fino quasi a fermarsi, una breve ripresa, poi l’auto si ferma
A 30 s dalla fine: l’auto quasi ferma che riparte; nella traccia, la variazione più forte del video
28 luglio, tarda sera
79 s
un rallentamento nei primi secondi, un lungo tratto ad andatura regolare, poi due accelerazioni separate da un tratto costante
A 30 s dalla fine: andatura regolare, alla fine di un’accelerazione; nella traccia, niente di particolare
25 agosto, sera
76 s
una lunga frenata, che si fa decisa verso la fine, una breve ripresa, un rallentamento, poi due forti accelerazioni separate da un rallentamento
A 30 s dalla fine: l’inizio di una forte accelerazione; nella traccia, la variazione più forte del video
1° settembre, sera
77 s
accelerazioni e frenate alternate, con un solo breve tratto costante
A 30 s dalla fine: una forte accelerazione; nella traccia, niente che si distingua dal resto del minuto
14 settembre, sera
52 s
un tratto costante, un’accelerazione interrotta da una frenata secca, una forte accelerazione, poi rallentamenti e riprese
A 30 s dalla fine: la forte accelerazione dopo la frenata; nella traccia, la variazione più forte del video
17 settembre, sera
60 s
una frenata fino a fermarsi, una ripartenza con una forte accelerazione, una frenata decisa, un tratto lento e costante, poi un’accelerazione e un rallentamento
A 30 s dalla fine: la fine della frenata decisa; nella traccia, la variazione più forte del video
17 settembre, subito dopo
41 s
continua il video precedente senza stacco: un tratto lento e costante, una forte accelerazione, poi una lunga frenata
A 30 s dalla fine: la forte accelerazione; nella traccia, la variazione più forte del video

In tutti e sette la traccia c’è, anche il 14 settembre, che l’ora non ce l’ha. E in tutti e sette dice con precisione come stavi guidando in quel minuto.

Quello che non dice è quale istante di quel minuto ha fatto scattare il sensore. Il nome del video segna l’inizio dello spezzone, non lo scatto, e nel file non c’è nessun segno: né una riga speciale né un campo che cambi. Un’indicazione però esiste, e viene da 70mai: sulla pagina prodotto della T800 c’è scritto che il video di emergenza contiene trenta secondi di registrazione dopo l’evento (l’avevo citata nell’articolo sul G-sensor). Se è così, lo scatto cade trenta secondi prima della fine del video, ed è il punto descritto in tabella.

In cinque video su sette, proprio lì la traccia registra la variazione più forte dell’accelerometro di tutto il video, entro pochi secondi dal punto atteso. E non è una variazione qualsiasi: fra due righe consecutive, nelle oltre quattromila clip di marcia normali da un minuto, salti così compaiono in meno di due clip su cento, e il più forte dei cinque non compare in nessuna. Che cinque volte su sette cadano per caso proprio in quel punto è difficile da sostenere. Nello stesso punto il video mostra un cambio di velocità brusco: una frenata secca, una ripartenza, un’accelerazione forte.

Negli altri due la traccia non dice niente. Il 1° settembre perché tutto il minuto è a strappi: nel punto atteso c’è un’accelerazione forte, ma l’accelerometro non la distingue dalle altre. Il 28 luglio perché lì non succede niente di visibile: l’auto procede regolare.

Il limite, quindi, è questo: la traccia può confermare che nel punto dello scatto è successo qualcosa, ma non può escludere che sia successo. Le righe arrivano una ogni secondo e mezzo circa, e non so se il valore dell’accelerometro scritto in ogni riga sia quello di un istante o il picco del periodo. Se è un istante, un colpo più breve dell’intervallo fra due righe, una buca presa di netto, può cadere nel mezzo e non comparire affatto. E la regola dei trenta secondi è del produttore: i miei sette video la rendono credibile, non la dimostrano.

Del 19 luglio ho scritto nell’articolo sul G-sensor: stavo arrivando a un raduno, e le ipotesi erano due, un colpo che l’accelerometro aveva sentito oppure il comando vocale «Registra video», a patto che in quel momento la dashcam non fosse collegata all’app. La traccia aggiunge un indizio: nel punto atteso c’è la variazione più forte di tutto il video, mentre l’auto quasi ferma riparte. Pende dalla parte del sensore, ma non chiude la questione: il comando vocale non lascia segni nel file, e una coincidenza non si può escludere del tutto.

Il 28 luglio è il caso opposto. Di quella sera avevo scritto di non ricordare niente di particolare, e che l’assenza di clip di sosta vicine era compatibile con l’auto in marcia: il video lo conferma. Ma nel punto atteso né la traccia né il video mostrano qualcosa. Le spiegazioni restano due, e il file non sa scegliere: un colpo più breve dell’intervallo fra due righe, oppure nessun colpo, cioè il comando vocale, che crea un video protetto senza che niente si muova.

La traccia non segna lo scatto, ma se sai dove cercarlo ti dice se in quel punto è successo qualcosa di forte e, con la sovrimpressione accanto, se in quel momento stavi frenando o accelerando.

Cosa farne, in pratica

  • Quando metti al sicuro una clip che ti serve, copia anche il file GPS. Le righe di quella clip le ritrovi dal nome, non dall’ora; se la dashcam l’ha protetta, cerca lo stesso nome con NO al posto di EV.
  • Non agganciare la traccia al video con l’ora delle righe. Sulla mia T800 è indietro di otto ore e, anche corretta, avanti di circa un minuto: leggeresti i secondi sbagliati. Se dai la traccia a qualcuno, lo scarto va dichiarato insieme al file.
  • Non contarci per la sosta. Con l’auto parcheggiata la traccia di solito non c’è, e quando c’è dice solo che l’auto era ferma, sotto il nome di una clip di ore prima. Se una clip ha migliaia di righe invece di una quarantina, è una di queste soste: il suo nome non data quelle righe.
  • Usala per il contesto di un evento: velocità e frenate del minuto protetto, che il file registra con precisione. Per il momento dello scatto, conta trenta secondi dalla fine del video protetto (è l’indicazione di 70mai) e guarda lì l’accelerometro: se c’è un salto netto, il sensore ha avuto un motivo; se non c’è, non è detto che non l’avesse.

Cosa non ho verificato

  • Il formato. 70mai non lo pubblica. Velocità e direzione le ho controllate contro le posizioni, e la velocità anche contro la sovrimpressione dei video; l’accelerometro è dedotto, e tre campi in coda alla riga non li so interpretare.
  • L’accelerometro. Se ogni riga scriva il valore di un istante o il picco del periodo.
  • Dove cade lo scatto. Trenta secondi prima della fine del video protetto è l’indicazione della pagina prodotto di 70mai, non del manuale, e il file da solo non la conferma: nei miei sette video la variazione più forte cade lì in cinque casi.
  • Quale orologio sbagli il minuto. Se sia l’ora del file a essere avanti o quella del video a essere indietro.
  • Il firmware di quei mesi. Il 24 settembre 2026 l’app mostrava la versione 1.4.150ww. Se fosse la stessa per tutto il periodo coperto dal file non lo so.
  • L’ora solare. Il file copre solo mesi di ora legale.
  • Perché in due soste il file abbia continuato a scrivere. Succede due volte in tutto il periodo, e non so cosa le distingua dalle altre.
  • Da dove l’app prende i dati. Che ora mostra e se i dati seguono il video l’ho controllato (lo trovi nelle domande in fondo). Che li prenda da questo file non l’ho dimostrato. E almeno un dato viene da un’altra parte: l’app mostra l’altitudine, che nel file non c’è.
  • Altri modelli. Uno solo, una T800.

Domande frequenti

Vale anche per la mia dashcam?

Non lo so. Quello che hai letto vale per una 70mai T800, per il file scritto fra il 7 luglio e il 18 settembre 2026. Altri modelli, anche della stessa marca, possono scrivere la traccia in un altro formato o in un altro modo.

L’app 70mai mostra l’ora giusta sulla mappa?

Sì. Ho esportato dall’app due dei video protetti, quello del 25 agosto e quello del 14 settembre, con la funzione «RS», che aggiunge al video i dati di guida in sovrimpressione: velocità, accelerazione, un pezzo di tracciato e altitudine. In tutti e due l’app mostra l’ora stampata dalla dashcam sul video, non quella indietro di otto ore del file.

E i dati seguono il video. Ho messo a confronto, secondo per secondo, la velocità mostrata dall’app e quella stampata dalla dashcam, anche nei tratti in cui rallento e riaccelero: fra le due c’è al massimo un secondo di scarto, non il minuto che c’è nell’ora del file.

Il video del 14 settembre è caduto in uno dei viaggi in cui nessuna riga del file ha l’ora, e l’app mostra lo stesso ora e dati giusti. Quindi l’ora non la prende da quel campo. Se i dati li prende dal file, li aggancia come ti ho consigliato di fare: dal nome della clip.

In pratica, se vuoi sapere a che velocità andavi in un momento del video, l’app te lo mostra già allineato. L’attenzione serve quando apri il file da solo, o quando lo dai a qualcuno.

Posso cancellare quel file?

Cancellarlo dal PC si può, è un file di testo come un altro; cosa faccia la dashcam dopo non l’ho provato. Tieni presente cosa perdi: è l’unico posto dove restano velocità e posizione dei viaggi i cui video sono già stati sovrascritti. Se invece il motivo è che la scheda cambia proprietario, cancellare non basta: nell’articolo su dashcam e privacy spiego perché le strade sicure sono la formattazione completa, oppure tenersi la scheda.

Conclusione

La traccia GPS è un testimone in più, a patto di sapere dove non guarda. Sulla mia T800 misura bene la velocità, ma ha l’ora indietro di otto ore mentre il video ha quella giusta (e anche corretta resta avanti di circa un minuto), una riga su cinque senza l’ora esatta, una sosta che di solito non registra e a volte registra sotto il nome di una clip già finita, e nessun segno del momento in cui scatta il sensore, che va cercato partendo dal video. Nessuna di queste quattro cose la rende inutile: dice a che velocità andavi e se stavi frenando, purché le righe le cerchi dal nome della clip e non dall’ora.

Quello che la traccia non risolve è la parte che conta di più dopo un contatto: cosa mettere al sicuro, e in che ordine, mentre il loop sta già sovrascrivendo i video. È una procedura a parte, e ci sto scrivendo un articolo.


I dati di questo articolo vengono dal file GPSData000001.txt della scheda della 70mai T800 raccontata qui, letto su PC in sola lettura il 18 settembre 2026 e riletto il 15 ottobre 2026 su una copia più recente dello stesso file, con accanto i video protetti ancora presenti sulla scheda. Conti e percentuali riguardano le righe che il file aveva il 18 settembre, contate tutte e non a campione. Le due soste sono le righe che citano la clip della sera del 13 luglio e quella della sera del 17 settembre (140.229 in tutto): che l’auto fosse ferma lo dicono velocità e posizioni, guardate solo in forma aggregata. I viaggi del secondo limite sono contati sulle altre clip. La velocità è stata controllata con le distanze fra posizioni successive e con la sovrimpressione dei sette video protetti, la direzione con le distanze; l’accelerometro è dedotto dai valori. Lo scarto fra l’ora delle righe e il nome delle clip è misurato sulle clip in cui tutte le righe hanno l’ora. Il punto dello scatto è quello indicato da 70mai, trenta secondi prima della fine del video protetto; la variazione dell’accelerometro è quella fra righe consecutive, confrontata con le clip di marcia normali da un minuto. Nella riga d’esempio le coordinate sono state sostituite con delle X, il resto è com’era. Le velocità non sono riportate di proposito, e gli orari degli eventi sono indicati per fascia. La coincidenza fra l’ora stampata sui video e quella nel nome dei file è stata verificata sui video stessi. Ora e allineamento dei dati nell’app sono stati controllati il 16 ottobre 2026 su due video protetti esportati dall’app con i dati di guida, confrontando secondo per secondo la velocità dell’app con quella stampata dalla dashcam; che l’altitudine manchi dal file è verificato su tutte le righe. La versione del firmware è quella mostrata dall’app il 24 settembre 2026. La sensibilità del G-sensor è quella di fabbrica, «Medio», mai modificata.