Error reading telemetry: month out of range (GH6, GH7)

[dlisin]

Some files recorded on GH6/GH7 camera cannot be processed by gopro2gpx utility.
Following error occurs:

Error reading telemetry file parsing time "5457900081260100": month out of range

In the same time GoPro Quick app successfully reads GPS data from these files.
May be it just ignores corrupted records.

GH010245.ZIP
GH020245.ZIP

[robertdolca]

Another example for Hero 7
GH010021.zip

[dlisin]

I have made some tests - and it is seems that it is safe to ignore GPSU parse errors.
I have prepared a PR with quick fix for this.
Refer to #34

[stilldavid]

There are four extra bytes in the updated timestamps, it looks like. Rather than ignore the errors, let's see if we can figure out what the extra data is and either parse or selectively ignore it from there. I'm headed out for the day, but will pick this up again this evening.

[tri34habo]

It looks like the examples in the code show "060102150405". But what I see in the sample file given GH010021.zip and on my Hero Black 7 is a "3" instead, not a "0". I would see "363132353435" instead of "060102150405". So if you remove the 3 at every other position, you are left with the time.

Then the 4 extra bytes seem to be the milliseconds, starting with "." (ASCII code of "." in hexa is "2e")

Example, found in one of my files, but match the file above as well:
4750 5355 5510 0001 3139 3033 3230 3136 3534 3033 2e37 3930

header is 4750 5355 5510 0001

date time:
3139 3033 3230 3136 3534 3033
removes the 3s, becomes
19 03 20 16 54 03
which is UTC date / time YY MM DD HH mm SS

Then probably milliseconds:
2e30 3635
is . 065 by removing the 3s here too.

[jlevers]

I'm noticing what I think is a related error, which is that in gopro2json, all the UTC timestamps have 3 extraneous 0's tacked on the end. If you remove those 3 0's, the timestamp is a correct Unix timestamp in milliseconds.

I believe this is because ts.UnixNano() / 1000 in telemetry.go should actually be ts.UnixNano() / 1000000, because there are 1,000,000 nanoseconds per millisecond. It looks like that idea is supported by Golang's Time type constants.