-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPSU Invalid Timestamp information #162
Comments
Is there any significance that the string (spacing for clarity) is "22 255 255 254 255 25" - looks like some kind of uninitialised buffer write? |
I have never seen this error. I expect you are correct in that there was some invalid data delivered from the GPS chip, or empty payload. We do have any error signalling for this, as we didn't know it could happen. Have you seen this error more than once? |
Hiya - Yes - this is the second time that it has been reported to me (although it is a defect reported against my parsing software, its not my actual device) - The end user has supplied the MP4 file in the linked issue above if you'd like the whole thing. |
Yes please to the sample clip. |
Sure. The MP4 is in the linked issue above, along with a bit of narrative, but I'll duplicate it here: https://s3.amazonaws.com/s3.voneicken.com/GH010359.MP4 |
This seems to happen when I use my Hero 7 black without having the date set, i.e., it's set to some date in 2016. This in turn happens 'cause I run the camera with a USB-C power source and no internal battery: it looses the date after some hours without having any power when I remove the USB-C power to recharge the power pack. Basically: remove battery from Hero 7 black, wait long enough for it to loose date&time (a few hours?), plug in USB-C power, switch to prefs and see that date is in 2016, start recording, observe the issue described here. |
That is surprising as that time and date field is not from real time clock, it is the value reported from GPS. |
It's not unbelievable though. This capture is from right at the start of the trace. It could be that after a few packets with a GPS time after a hard boot with loss of RTC, the firmware decides to do some extra work, which misses a deadline, so the output isn't captured for that timeslice. I have no idea how the gopro firmware is written, so this is pure conjecture!! |
In the look at the number of samples per payload of GPS5, the GPS chip is behaving eratically. Instead of 17-19 samples per payload (averaging around 18.1Hz), the stream (linked above) has payloads of 13, 9, 0, 4, 5, 0, 3.., averaging 4.6Hz. The GPS chip is not behaving ideally. This camera likely needs a factory reset. |
I'm not sure the problem is reproducible. I just took a look at the recordings I have since the first one without date&time set:
I'm concluding that if the date&time are lost there is a chance that the GPS track ends up messed-up, but it's not systematic. Presumably some race condition. I'm not sure this can be pursued productively at this point. |
We also don't have any firmware releases planned for HERO7. This should not come up on more recent cameras. |
Hi @dnewman-gpsw - Just FYI - I had another user report of invalid data in GPSU. time4tea/gopro-dashboard-overlay#141 |
I look forward to knowing the camera model this was. |
Hi - The Camera was Hero 9 Black - HD9.01.01.52.00 I can see the same sort of behaviour as before, where the number of samples from the GPS chip is erratic for the whole file.
As you can see, the GPSU values are incorrect for a few samples:
I don't have permission to share the file - is there any more information that would be useful for you? I'm guessing that this is probably happening quite a lot, as my software doesn't have that many users, and we have seen a couple of incidences now. Thanks! |
I hadn't previously noticed, but the timings of the samples are also very erratic, sometimes multiple packets at exact same time (hence 0 size, i guess) |
Filtering is likely the only solution for these older camera sources. HERO11 deprecated GPS5 and GSPU, adding GSP9 as cleaner way to sync time and location. |
I can filter the invalid GPSU, but incorrect values are correlated with loss of sync with GPS chip or something, as can be seen by the erratic readings. |
Correct, new firmware is not likely. |
I am trying to parse data stream from HERO7 Black.
However, in the data stream there appears to be a corrupt data item:
GPSU type 'U' size 16 data: "2225525525425525",
It seems unlikely that this is due to storage device data corruption, as the rest of the stream is totally fine. I guess I'm asking if there is a known issue with GPSU timestamps being emitted incorrectly from the device, or if this is a known value to indicate some kind of error condition.
I do know that in some cases the first GPS5 with a GPSF of 2 or 3 is actually invalid - seems that if the lock is acquired part way through a packet, the entrie packet is marked with a lock, but some samples correspond to a non-locked period, but here the GPSF is 0
The previous and subsequent timestamps in the data stream are just fine, however the previous GPS5 sample looks odd:
Really appreciate any insights! - Thank you!
The text was updated successfully, but these errors were encountered: