Slight flaw in parking mode impact detection announcment feature

glowstix047

New Member
Joined
Apr 18, 2014
Messages
20
Reaction score
5
Country
Australia
So I noticed that there might be a slight flaw in the parking mode impact detection announcement feature today.

Quick recap, the parking mode impact detection announcement is the announcement your camera makes after exiting parking mode if your camera has detected any impact while you are away from the car and your camera is in parking mode.

So when you return to your car, enter your car, close the door/boot, it detects this as an impact. When you drive off and the car exits parking mode, it will announce that there was an impact detected.

This means that every time you enter your car, drive off, it exits parking mode, it will always tell you there's an impact, even though it's just you closing your door. This renders the parking mode impact detection announcement feature a little less useful than i originally thought as it's always detecting "false positives".

Just thought I would point this out, at the end of the day it's still best to do a quick inspection of your car and not rely too much on this feature.
 
Definitely agree, the concept is flawed. Can't blame the camera for not knowing the difference between a hit and run and a door slam though.
Luckily you can turn off this feature in the settings.
Thinkware does it a bit better by announcing exactly how many events were detected so you can filter out the one you know is just you closing the door/trunk.
 
The simple solution to this is for them to just have it announce the number of parking mode impact events it detected during that particular parking mode session.
 
Agreed, how do we put forward this feedback to blackvue so it can be implemented in a firmware update?

Sent from my XT1635-02 using Tapatalk
 
Mine has been going off with the impact detected in park mode - every time - and I check the footage and the event stamp is the time in which I close the door. Yup!!
Hoping a firmware update might fix it! I've turned off the notification for now, unfortunately.
 
Mine has been going off with the impact detected in park mode - every time - and I check the footage and the event stamp is the time in which I close the door. Yup!!
Hoping a firmware update might fix it! I've turned off the notification for now, unfortunately.


It probably won't be a firmware "fix." As BBMC states above, this is more of a conceptual problem.

From and end user standpoint for this particular product, there are two primary inputs relative to this one logical output: Time and Expectation. The timeline for the expected output begins when the driver enters the vehicle and drives off. That starts the expectancy clock in the mind of the driver. The driver then expects to be notified whether or not there has been an impact in "Parking Mode" prior to the initiation of "Normal Mode." However, that impact would by definition had to have taken place in a previous "Parking Mode," which cannot become "previous" until a new "Normal Mode" becomes state. Thus, the conundrum of issuing a real-time audible alert to a driver having an expectation about a prior event along a different timeline. This explanation also contains the solution (if Blackvue were paying attention).

As a creative design engineer, you will run into these conceptual contradictions all the time in your work. You have to creatively solve the problem and that could entail everything from a simple logic revision to an entire redesign of the subsystem, function or sub-function depending on how deep the logic tree goes.

This is not a software or coding issue. This is a creative logic design issue - but I'm sure Blackvue could care less about hearing from me on how to solve this problem - which actually has a very simple solution that does not require a change in underling output design logic. But, like I said - Blackvue keeps ignoring my emails - so I'm positive that would not want to hear from me on how to solve this problem. In fact, based on my experience with Blackvue, I'm fairly confident that they don't even see this as being a "problem" at all.

This is not coding problem. This is an issue having to do with Engineers being thorough and complete in their input/output algorithms such that end users are allowed to maintain a consistent expectancy model absent logical lurches and speed bumps.

I solve problems like this all day long in my business. I would love to solve this one - but I'm not going to unless Blackvue calls me on the phone and apologies for ignoring my emails. (y) Big hint by the way, Blackvue.
 
I know closing the door cause the Dashcam to record it as an impact, how I fixed this issu is when I get in to my truck, I start the engine before closing the door to remove the dashcam from park mode. Took some time to built this habit, but that was the only way I could fix this issue.

BTW I really like this forum, I learned a lot from this forum just by reading posts.

Cheers
 
I know closing the door cause the Dashcam to record it as an impact, how I fixed this issu is when I get in to my truck, I start the engine before closing the door to remove the dashcam from park mode. Took some time to built this habit, but that was the only way I could fix this issue.

BTW I really like this forum, I learned a lot from this forum just by reading posts.

Cheers

That gets the audible warning taken care of - but what if the audible warning were not a false positive.

Along these lines (I don't know if this will help you), I turned G-Sensor settings for all three axis up to 10 in Parked Mode and Motion Detection down to 1. Yes, that does give me more false positives for Motion, but I'd rather have more FPM than not and miss an opportunity to catch a side impact that does not show up on either front or rear cam.

I then use the camera system different than I have in the past.

First, I visually scan the vehicle upon initial approach and before entering (checking for damage in my absence). If I don't see any issues, I know I'm in the clear for physical damage to the exterior of the vehicle. However, I realize that other kinds of nefarious activity could have taken place around or under the vehicle in my absence for which the protocols below should detect.

If I detect physical issues on the exterior of the vehicle, I immediately run the following protocol below:

- Connect to cam via Wifi (Cloud connection will be useless for this purpose)
- Deselect all "Normal" videos
- Refresh video list
- Scroll to first Parking Mode Video just above last Normal Mode Video
- Quick visual scan for the color Green
-- > If Green tap icon to load Thumbnail Image.
- Quick visual scan for the color Black.
-- > If Black tap icon to load Thumbnail Image.

If I see anything inside a Thumbnail Image that indicates activity around the vehicle, then I know I've got a target video to review. This saves time filtering and playing through every single video looking for evidence.

Note1: There might be some Parking Mode Videos that do not show anything inside the Thumbnail Image. This happens from time-to-time. If you do not find the evidence you are looking for in those videos that did show something inside the Thumbnail Image, then checking the empty Thumbnail Images makes sense (those Parking Mode Thumbnail Images that do not show activity around the vehicle).

Note2: I also include the last 5 minutes of Normal Mode Videos once I scroll to the first Parking Mode Video. I do this because it takes 5 minutes for the cam to switch out of Normal Mode and into Parking Mode.

I would prefer an preemptive Parking Mode Button. This would still put the camera in Parking Mode if you forget to press the Parking Mode Button in 5 minutes. Else, pressing the button would place the camera in Parking Mode immediately. Of course, Blackvue has not bothered to include this feature.

I use a 128GB Micro SD Card. This gives me anywhere from 4-8 days of storage capacity in my typical parking environments. So, if I visually scan the vehicle for trouble every 24hrs, I can narrow the search window greatly and speed up the evidence identification process using the protocol above.
 
Thread starter Similar threads Forum Replies Date
W DR750S (1CH or 2CH) 8
Back
Top