g-sensor (and OK button) locked recordings

[Gary D]

On the GC, assuming that "loop recording" is set to the default 3 minutes... and it's automatically recording...

then the G-Sensor activates (or OK button is pressed), a video file is locked. This is documented as "the recording at the time of the accident" and "the current recording" being locked (moved to another directory.)

I'm trying to better understand what this means when combining the loop recording (3 minute segments) with "the current recording."

If, due to loop recording, the current video file has only 1 second of data, and the g-sensor locks a file, is only that one second of video locked? (If so, what happens to the rest of the 3 minutes of the file that hasn't been recorded yet?) If only 1 second of the past is locked, is this really very useful?

If the above explanation is correct, wouldn't it be better to "lock" both the current and the most recent video files iff the current file contains less than a configurable (or hard-coded) amount of time?

For example (if configured to 60 seconds):

If the current file contains less than 60 seconds of video footage, the "lock" would lock both the current file and the most recent previous file.

If the current file contains >=60 seconds of video footage, the "lock" would only lock the current file.

 

[Street Guardian USA]

Right now it's just the segment being recorded but we have plans to improve this further via firmware update.

The following response hints at it a bit more https://dashcamtalk.com/forum/threa...-pre-release-access.16310/page-23#post-255232

 

[niko]

You have quite logical proposal and I also support this, but I guess it all comes to SDK if can be applied to present chipset or not.

 

[Gary D]

At the very least, if figuring out the amount of time in the current recording isn't feasible (nothing is impossible), just ALWAYS lock two files - the current and most recent. I'm not familiar with the SDK's involved (however I'm extremely familiar with embedded development), but this should be a trivial change.

I suspect most people would rather waste a little space on a memory card if the alternative is possibly overwriting critical video footage.

 

[Street Guardian USA]

We'll see what our developer can accomplish assuming the SDK supports it. If it's possible we will try. In the mean time, If something is that important best to remove the card and maybe even have a backup card ready. You have 5 hours with 32GB and 10 with 64GB (and can go up to 200GB)

 

[jokiin]

On the GC, assuming that "loop recording" is set to the default 3 minutes... and it's automatically recording...

then the G-Sensor activates (or OK button is pressed), a video file is locked. This is documented as "the recording at the time of the accident" and "the current recording" being locked (moved to another directory.)

I'm trying to better understand what this means when combining the loop recording (3 minute segments) with "the current recording."

If, due to loop recording, the current video file has only 1 second of data, and the g-sensor locks a file, is only that one second of video locked? (If so, what happens to the rest of the 3 minutes of the file that hasn't been recorded yet?) If only 1 second of the past is locked, is this really very useful?

If the above explanation is correct, wouldn't it be better to "lock" both the current and the most recent video files iff the current file contains less than a configurable (or hard-coded) amount of time?

For example (if configured to 60 seconds):

If the current file contains less than 60 seconds of video footage, the "lock" would lock both the current file and the most recent previous file.

If the current file contains >=60 seconds of video footage, the "lock" would only lock the current file.

we are working on changes to the file lock process still

currently it will lock the entire segment it is currently recording, 1 minute, 3 minute etc as per the recycle value chosen, that's all the current SDK supports, we have to write our own process for this which is going to take some time, at the moment we're working on some bugs that need fixing which are the bigger priority right now, it is on the dev roadmap though