Duplicate Date Times / Bad Sample Data

[itsonlyjames]

Got a weird one here and it's random in that it's happened only in 1 video stream after processing many others.

The CTS timestamps all move forward correctly, but the date timestamps are duplicate even though the actual lat/lng values are different.

I wouldn't be surprised if this is a GoPro issue and not relevant to your – absolutely awesome – module.

I am simply logging the current sample and next sample here (functionally in an attempt to increment laps based on crossing start/finish line) and you can see the CTS, lat/lng values update ok but the date timestamps are the same across 6 samples...

Also for visualisation sake, here's a graph based on speed. You will notice that it drops to 0km/h consistently, which made me think it was accuracy based initially however after much debugging I'm not certain...

(A speed based graph that is correct)

Looking forward to hearing your thoughts @JuanIrache, and thanks for an awesome suite of work mate!

[JuanIrache]

Hi James,

Thank you for your kind words.

The cts and datetimes values come from different places. You might see repeated datetimes if the camera failed to record good GPS data, but your coordinates are updating, so that's strange.

What options are you parsing this with?

What camera model is this happening with? Are you parsing GPS5 or GPS9 data?

[itsonlyjames]

Thanks for your prompt response @JuanIrache!

Interesting... I did have a theory overnight that maybe the battery was low and so the GoPro prioritised filming over GPS data recording., which aligns with what you say about it recording bad data.

const data = await goproTelemetry(extractedVideo, {
  GPS5Fix: 3,
  GPS5Precision: 750,
  stream: ['GPS5'],
});

I have also tried processing the video with a GPS5Fix of 2, however the results don't change.

I'm using a GoPro Hero 7, which records GPS data in GPS5.

[JuanIrache]

The HERO7 can record out of order GPS samples in some cases. Not sure why. There might be some "failsafe" in our code that prevents GPS dates from going backwards, hence the repeated dates (I don't remember if this is the case, just speculating).

See if using the strict GPS times option helps. CTS will be based on GPS dates, so the samples should get in the right order. Know that this option can be very problematic if your GPS dates are really bad.

I would also suggest removing the precision and fix filters while debugging, so you see all the samples and not just good ones.

[itsonlyjames]

Yeah so from all the debugging and testing I've done over the last 2 days I think this boils down to bad/corrupt GPS data, no amount of work can change any results (which highlights the great work you've done on the module) and so I have to just drop this now and say it's a faulty recording!

Thank you kindly for your assistance @JuanIrache, and know that I am a big fan of your work.

I would love to discuss the project I am utilising your modules in should you be interested, as I feel some of the features I'm implementing might be beneficial to the core module itself. Let me know!