A119 Firmware

if you do something with sound level, have a global setting for low/medium/high sound output.
 
A119 Beta firmware A119_170606_V3.1B Test...Event button.
Confirmed that pressing !Event button at about 10 seconds after the start of a new file while loop recording, moved the current and the previous file to the RO folder. Pressing the !Event button at about 20 seconds into a new file moved only the current file to the RO folder. The change over point is suppose to be about 15 seconds into the new file I think. Loop Recording was set to 2 minutes in this test. Number of data points, 1 of each case.
 
A119 Beta firmware A119_170606_V3.1B - Basic Observations... Motion Detection Mode.
Not experienced on Motion Detection (MD), but did some testing more or less for subjective evaluation. Testing done with NO CPL, Resolution 1080P60, Loop Recording 3 Minutes, EV Exposure 0.0, WDR ON, Motion Detection ON, GPS ON, G-Sensor Middle Sensitivity, LED ON mostly... OFF before sunset and later, Screensaver 15 Seconds, indoors morning to mid-afternoon, in car - driving and parked afterwards. No log of events was made to compare with videos, so no objective analysis of detection capability versus false triggers could be made.

- Easy set up a static scene that would not continuously trigger the MD, as happened previously with an A119S.

- Easy to trigger MD in that static scene.

- The MD recording cycle is about 1 minute. If a new trigger occurs during the one minute MD recording cycle, it appears to reset the 1 minute MD recording cycle clock so that the camera continues recording for another minute. If the triggers continue to occur within successive MD record cycles, a file will be generated with a duration of up to the full Loop Recording time (3 minutes in this case). {Edit: Otherwise, if no new triggers happened in the most recent 1 minute MD recording cycle, then the A119 stops recording, ends the file, and awaits a new trigger. Files were consistently a few seconds to 3 minutes in duration.}

- Appears that screensaver operates normally in MD mode, i.e., once screensaver turns off the LCD screen in the MD mode, it stays off unless manually activated with a short-press of the Power button. This was one of the issues listed in the change log as fixed. Confirmed.

- While making 5 short drives with MD mode ON (4 day and 1 night), files were recorded normally as they would be with MD mode OFF.

- Parking Lot observations... Ran MD mode in a car parked in a busy Mall parking lot looking across several rows of cars toward a part of the Mall building. Cars passing up the next aisle over about 2 car lengths away in front triggered MD recording most of the time. Pedestrians also triggered MD recording, especially when passing within 2-3 feet of the front bumper. Sometimes the trigger sources were not obvious by looking at the video. Overall, the MD mode was tested in the parking lot for 2.55 hours, and recorded 54 files for a total record time of 1.63 hours. Unable to make judgements on the detection capability versus false triggers because of the subjective nature and short duration of these tests, and lack of experience with MD. In general, performance did exceed my expectations, for whatever that's worth. The trigger sensitivity seemed to be in the "just right" ballpark for a one-size-fits-all single sensitivity setting.

- Presuming my understanding of how the MD works is correct, by watching the beginning and the last minute of each file recorded, even without a written log, events that trigger, re-trigger, or fail to trigger the MD record cycle can sometimes be identified. {Edit: The source of the initial trigger event (if captured) of a given file will be at the beginning of the file, unless the previous file was terminated by the Loop Recording function, in which case the trigger probably occurred during the last minute of the previous file and the current file is just a continuation of the previous file.} If the file duration is less than the Loop Record time, 1) the last re-triggering event should be observable at close to the 1 minute to go point in the video, and 2) events occurring during the last minute of the file that failed to re-trigger MD recording should also be observable. {Edit: If Loop Recording times out before the last 1 minute MD recording cycle is completed, the current file ends, and the A119 carries the remaining MD record cycle time forward and starts recording a new file immediately. Consequently, files can be generated whose initial trigger actually occurred in the previous file, and a file of less that 1 minute duration is possible.}

- I saw nothing to indicate that any pre-buffered video was incorporated into the recorded files.

- I found no new Menu setting that allows the user to select the MD trigger sensitivity, an enhancement that has been previously suggested.

Regards,
 
Last edited:
Just tested the v3.1b firmware and motion detect feature. I parked my car near the entrance of a rather busy car park. There are a lot of cars moving in and out. When I check the recorded files timing, there's isn't any significant gap in between. So I guess the motion detect kept triggering and has no chance to stop recording. Every clip is a long as 3 mins. I might need to do more test.

I powered the A119 using a 10000mAh powerbank for the test. The current consumption during recording is approx 450mA. During the test, it only consumed 1729mAh for the duration of about 4 hours, with continuous recording. Not too bad.

I noticed some artefacts in the video which I didn't notice last time. There are many white dots which looks like dead pixels all over the image in dark scene or low light shots. I circled them in attached image. The white dots disappear in brighter scene shots. I'm not sure if it is caused by the new firmware. I check my videos from v2.02 firmware and didn't notice such artefacts.

Viofo A119 v3.1b firmware artifact.jpg
 
Every clip is a long as 3 mins.
This is consistent with what I saw on several occasions with the Loop Record set to 3 minutes. Try a more static scene and do some deliberate actions to trigger the Motion Detection recording at different times. Watch the REC button light (LED setting ON) to indicate whether the camera is recording or not in real-time (steady ON - recording, blinking - not recording). The Motion Detection trigger function seems to be related to changes in the light that the camera sees. The reflections from a flickering TV off objects in the camera field of view are enough to sometimes trigger Motion Detection recording indoors.
I powered the A119 using a 10000mAh powerbank for the test. The current consumption during recording is approx 450mA. During the test, it only consumed 1729mAh for the duration of about 4 hours, with continuous recording. Not too bad.
That's about what I measured for the 1440P30 Resolution/fps in this post. A measurement at 1080P60 resolution/fps in the Motion Detection mode is posted here. Mode (particularly recording or not), Resolution/frames per second, and LCD on/off seem to be the variables that most affect A119 power consumption.
I noticed some artefacts in the video which I didn't notice last time.
I didn't notice artifacts but they don't show up well on my 15 inch Laptop screen.
 
I noticed some artefacts in the video which I didn't notice last time. There are many white dots which looks like dead pixels all over the image in dark scene or low light shots. I circled them in attached image. The white dots disappear in brighter scene shots. I'm not sure if it is caused by the new firmware. I check my videos from v2.02 firmware and didn't notice such artefacts.

have a look in a completely dark scene, how does it look then?
 
This is consistent with what I saw on several occasions with the Loop Record set to 3 minutes. Try a more static scene and do some deliberate actions to trigger the Motion Detection recording at different times. Watch the REC button light (LED setting ON) to indicate whether the camera is recording or not in real-time (steady ON - recording, blinking - not recording). The Motion Detection trigger function seems to be related to changes in the light that the camera sees. The reflections from a flickering TV off objects in the camera field of view are enough to sometimes trigger Motion Detection recording indoors.
I'm not too sure exactly how Motion Detect works in this firmware, but I believe it's an algorithm to compare the current frame to previous frame for changes. If changes is detected, it will trigger recording.

That's about what I measured for the 1440P30 Resolution/fps in this post. A measurement at 1080P60 resolution/fps in the Motion Detection mode is posted here. Mode (particularly recording or not), Resolution/frames per second, and LCD on/off seem to be the variables that most affect A119 power consumption.
I'm using USB power capacity meter which also record the total mAh used. This is quite handy for measuring total energy consumed for a period of time.

I didn't notice artifacts but they don't show up well on my 15 inch Laptop screen.
I'll have to do more test in different situation and environment.
 
have a look in a completely dark scene, how does it look then?
Yeah, I only manage to test once after updating the beta firmware. I'll need to test more. Good suggestion of recording a completely dark scene. I'll try to cover the dash cam and let it record a few seconds. Maybe I'll compare dark scene recording from v3.1b and v2.06 too if I have time.
 
Manage to test firmware v3.1b Motion Detect again and here are my observations:
  1. It works better in less busy car park because it has less trigger events. Else it will keep triggering the motion sensing and at the end it is as if full recording in loop mode.
  2. The start of a motion triggered recording doesn't always coincide with the start of the motion entering the frame or being detected. Sometimes it is 1 or 2 seconds delayed. Eg. In some clips, the first frame of the clip shows a car is already into 1/3 of the frame. There are other clips where the first frame shows a car almost exit the frame.
  3. It is really hard to guess the sensitivity of the motion sensing algorithm. Cars or people passing right in front of my car will trigger motion recording. But sometimes, people walking pass at a few lanes away (approx. the size of 5% of the screen height.) will trigger motion recording. Strangely, some faulty LED ceiling lights which keep blinking the whole time at a few lanes away won't keep triggering the motion detection. Changing ambience light (eg. sunlight or car headlight) will trigger motion recording.
  4. When motion is detected it will start recording (with 1 or 2 seconds delay after first motion is detected). It will continue to record as long as there is still motion. When the motion stopped, the recording will continue for another minute. But this might not be always the case. There are some clips that are slightly less than 1 minute (58s and 59s). Maybe this is caused by the slight delay in recording start after a motion is detected.
  5. I noticed there is one video clip with just 11s of recording. See the red circle in attached image. I checked the video clip before this and it is a full 3 mins clip and it contains a lot of motion. So my theory is if the motion activity is longer than the duration of loop recording duration (ie.3 mins), it will continue the recording with a new clip but stop recording as soon as motion has stopped. It won't record the extra minute after motion has stopped.
  6. The white pixels I noticed from yesterday's test are still there in low light situations at exactly the same spots with some plus/minus new spots. These white pixels are not static. They will blink like stars. See attached picture where I overlaid screenshot from yesterday's recording to today's recording. I believe these are not artefacts from recording, but due to the issues with some pixels on the image sensor when the sensitivity is being pushed up for low light situation. I also noticed that this only happens when I have run the dashcam for a period of time, maybe due to heat. I didn't noticed any blinking pixels when I first start up my car. I followed jokiin's suggestion to record a dark scene to observe the white pixels issue. I cover up the lens with a black cloth and I did not notice any blinking pixels.
Suggestion:
  1. Is it possible to record 10s before when a motion event is triggered and stop recording 10s-20s after the last motion event? It is important to know where the motion is coming from or what causes the motion. And I think 1 minute of motionless recording is not really useful. This can help to save memory space too.
  2. It would be nice to be able to adjust the sensitivity of the motion sensing algorithm to avoid false alarm or unimportant motion recording.
  3. It would be extra nice if we can define the motion sensing area in the frame to ignore certain motion eg. moving trees or blinking/flickering light. But I know this will be really hard with the small screen size and limited buttons to use to control the UI.
Question:
  1. Is Motion Detect feature safe or practical for car dash cam that is not designed for continuous operation under harsh environment? I live in a hot country with 35C average temperature. Will it shorten the lifespan of the dash cam or memory card when the dash cam is running continuously in this condition? It might not be too much of an issue in colder countries. The 2 tests I've done were in indoor car park. I do not dare to let the dash cam run continuously if I park under hot sun for a long period of time. Don't get me wrong. I think Motion Detect or Car Park mode are very nice features that I would love to have, but I think it has to work together with a well designed hardware with proper thermal management and components reliability design in mind.
Viofo A119 hot pixels.jpg
Composite screenshots from yesterday and today.

Viofo A119 cover up lens.jpg
Dark scene test to detect blinking white pixels. No white pixels detected. This is maybe because the dash cam is not overly hot because I did the test right after I start up the dash cam in the morning.

Viofo A119 v3.1b Motion Detect 1b.jpg
Motion detect recording. Observe the time gap between recordings and duration of each recording. They are not continuous full 3 mins/clip recording as in yesterday's test. The video clip circled in red is just 11s long. I believe this is the 'overflow' recording from a very busy period of time.
 
Dark scene test to detect blinking white pixels. No white pixels detected. This is maybe because the dash cam is not overly hot because I did the test right after I start up the dash cam in the morning.
.

the previous scene had enough lighting for the auto calibration function not to work, it is currently set to only work in darker environments so it's working as expected


The video clip circled in red is just 11s long. I believe this is the 'overflow' recording from a very busy period of time.

correct
 

  • I noticed there is one video clip with just 11s of recording. See the red circle in attached image. I checked the video clip before this and it is a full 3 mins clip and it contains a lot of motion. So my theory is if the motion activity is longer than the duration of loop recording duration (ie.3 mins), it will continue the recording with a new clip but stop recording as soon as motion has stopped. It won't record the extra minute after motion has stopped.
    The video clip circled in red is just 11s long. I believe this is the 'overflow' recording from a very busy period of time.

This makes sense and a re-look at the files from my previous tests confirmed it. I checked short files of less than or equal to 57 seconds (4 cases) and found them all to be preceded by a 3 minute file (Loop Record setting). If I looked back at the previous file at a time about one minute prior to the end of the short file, I found a trigger source (car passing), whereas there was no apparent trigger source at the start of the short file. So the bottom line is that when the current file ends because the Loop Record function times out, any time remaining in the last 1 minute Motion Detection (MD) record cycle will carry over to the next file. If no more triggers occur while the A119 records the carry over time period, recording stops resulting in a file of less than one minute duration. That answers questions {now edited out} in my previous post about files occurring in MD mode that were less than 1 minute.
 
Last edited:
New firmware for A119. Have a try of the new parking mode
1f600.png
1f600.png

https://dl.dropboxusercontent.com/…/firmw…/FW_A119_V3.1B.zip

Change log:
...
Please, make a sound notification when the selected speed limit is reached!

We have GPS and it shows the current speed, but it does nothing.
GPS can, at least, monitor the speed of the car and warn the driver of exceeding the limit (Without speedcam)!
 
You can use "On" or "Off"...

PS New beta firmware requires update bootloader?
My DVR (A119 v.1) ignores file "FWBA119.bin" from FW_A119_V3.1B.zip
 
Please, make a sound notification when the selected speed limit is reached!

We have GPS and it shows the current speed, but it does nothing.
GPS can, at least, monitor the speed of the car and warn the driver of exceeding the limit (Without speedcam)!

No thank you.

I have a Garmin that shows me exceeded Speed Limit and Waze will tell me as well. Both of these actually track actual speed versus POSTED SPEED LIMIT. There's no way for the camera to do anything except indicate that a specific speed threshold has been crossed, and that's generally not useful (IMHO).
 
You can use "On" or "Off"...

PS New beta firmware requires update bootloader?
My DVR (A119 v.1) ignores file "FWBA119.bin" from FW_A119_V3.1B.zip
If your A119 is on version 1, then yes, you need the bootloader file.
 
If your A119 is on version 1, then yes, you need the bootloader file.
Thx bro! Yes v.1!
Where can I get the new bootloader file?
Or maybe you know the release date of the new firmware version?
 
When connected to a computer, the video file is recorded for 1 second. And turning on the flash memory . A119_V3.1B
 
When connected to a computer, the video file is recorded for 1 second. And turning on the flash memory . A119_V3.1B
не совсем понятно.
подсоединённая к компьютеру камера не должна писать вовсе, она должна переходить сразу в режим "Mass Storage", и распознаваться компьютером как дополнительный накопитель.
 
Back
Top