VIOFO A139 Pro - Testing / Review Info

@VIOFO-Support
Hello Viofo,
I have model A139 Pro and I am happy about it, but I have one request if possible.
Whenever Parking mode is in "Auto event detection", there are 2 settings : Parking G-sensor and Parking Motion Detection (options: Low, Medium, High).
Is it possible to have also option "Off" for Parking Motion Detection so that only G-sensor to trigger ?
I always have not very useful videos from motion detection and I am only interested if someone hit my car.
Thank you in advance!
Thank you for using our camera.
Enabling this off option may bring the risk of not locking some important videos, while we have forwarded your suggestion to our team, we shall let you know if it is possible.
 
Does anyone have an issue where the camera gives the recording voice prompt but doesn't record? Even the app showed recording, but when trying to retrieve footage, it was from the day before. I'm using the VIOFO card that was bundled with the camera.
 
Does anyone have an issue where the camera gives the recording voice prompt but doesn't record? Even the app showed recording, but when trying to retrieve footage, it was from the day before. I'm using the VIOFO card that was bundled with the camera.
Have you turned on the voice? generally, the camera will beep when it is not recording.
How is contacting us directly by TICKET?
 
Have you turned on the voice? generally, the camera will beep when it is not recording.
How is contacting us directly by TICKET?
Hi, I do have voice prompts enabled. I've been in contact with support and still trying to fix it, I was just seeing If anyone had any ideas. I was just given a firmware to try, so I'll see if this helps.
 
  • Problem
    • A139 Pro v1.0_1217 firmware
    • HDR = Auto
    • HDR Time = On 18:00, Off 08:00
    • A139 Pro freezes or fails to boot successfully (beep-beep)
This morning, VIOFO stated they were able to reproduce the issue I show in my video. VIOFO is working on a fix and hopefully it will be in the next firmware release for the A139 Pro.
One month on, I hope we will see this Auto HDR fix in a FW update soon
 
One month on, I hope we will see this Auto HDR fix in a FW update soon
On 10-Feb-2023, I was provided a test firmware (1.0_0206) for the A139 Pro to test the HDR "Auto" bug I reported to VIOFO. I ran an overnight test to see if the HDR Auto feature worked as expected and it did work without the dash camera failing to record video. I reported my successful test run findings to VIOFO on 11-Feb-2023.
  • Configuration
    • A139 Pro 3-Channel
    • Test Firmware 1.0_0206
    • Resolution = 4K 2160 24fps + 1080p 24fps + 1080p 24fps
    • Parking Mode = Low bitrate
    • HDR = Auto
    • HDR Timer
      • On = 18:00
      • Off = 08:00
  • Test
    • 13:13:21
      • I powered up the A139 Pro and it start normal recording mode
    • 13:19:24
      • Turned off ACC power to have the A139 Pro 3-channel enter low bitrate parking mode
    • 18:00:01
      • Parking mode recording stopped as it transitioned to HDR On mode.
    • 18:00:06
      • Parking mode Low Bitrate recording resumed (filename for this file is 2023_0210_180010_PF)
        • Filename timestamp is four seconds after the first timestamp in the video
      • No audio announcement was made during the transition - that I recall
    • Test ran overnight with A139 Pro 3-channel in low bitrate parking mode
    • 07:28:24
      • I restored ACC power to have the A139 Pro resuming normal recording mode
    • 07:28:29
      • Normal mode recording resumed (filename 2023_0211_073830_F)
      • Five second video gap during the transition from low bitrate parking mode to normal recording mode
    • 08:00:00
      • HDR transition from On to Off
    • 08:00:05
      • Normal mode recording restarted with HDR Off
      • Announcement was heard as it restarted normal mode recording
      • Five second video gap during the transition from HDR On to HDR Off
 
On 10-Feb-2023, I was provided a test firmware (1.0_0206) for the A139 Pro to test the HDR "Auto" bug I reported to VIOFO. I ran an overnight test to see if the HDR Auto feature worked as expected and it did work without the dash camera failing to record video. I reported my successful test run findings to VIOFO on 11-Feb-2023.
  • Configuration
    • A139 Pro 3-Channel
    • Test Firmware 1.0_0206
    • Resolution = 4K 2160 24fps + 1080p 24fps + 1080p 24fps
    • Parking Mode = Low bitrate
    • HDR = Auto
    • HDR Timer
      • On = 18:00
      • Off = 08:00
  • Test
    • 13:13:21
      • I powered up the A139 Pro and it start normal recording mode
    • 13:19:24
      • Turned off ACC power to have the A139 Pro 3-channel enter low bitrate parking mode
    • 18:00:01
      • Parking mode recording stopped as it transitioned to HDR On mode.
    • 18:00:06
      • Parking mode Low Bitrate recording resumed (filename for this file is 2023_0210_180010_PF)
        • Filename timestamp is four seconds after the first timestamp in the video
      • No audio announcement was made during the transition - that I recall
    • Test ran overnight with A139 Pro 3-channel in low bitrate parking mode
    • 07:28:24
      • I restored ACC power to have the A139 Pro resuming normal recording mode
    • 07:28:29
      • Normal mode recording resumed (filename 2023_0211_073830_F)
      • Five second video gap during the transition from low bitrate parking mode to normal recording mode
    • 08:00:00
      • HDR transition from On to Off
    • 08:00:05
      • Normal mode recording restarted with HDR Off
      • Announcement was heard as it restarted normal mode recording
      • Five second video gap during the transition from HDR On to HDR Off

Thank you for your service.
 
I’m currently testing that new fixed fw too, 0206, and so far (knock on wood) I haven’t had any failures to record either. I’m running one with HDR on and the second with it off. I haven’t been using Auto HDR at all. (The failure to record bug doesn’t seem to be limited to just Auto HDR.)
 
Hello.

Just a thought: For a camera technically being a (fine-grained) light-sensor, it might make sense to use it as such for making the ON/OFFing of the HDR-functionality more situational dependent, means: the camera (as a light-sensor) is/should be able to measure the overall amount of light reaching the sensor and additionally the contrast-ratio dark to bright across the sensor-surface which would provide data for an automatic transparent ON/OFF-switching process of the HDR-functionality while the camera being at work, but ... maybe that making things 1.) too complicated and 2.) the VIOFO-team too worried regarding negative customer feedback because ... where to set the threshold for switching from one state to the other? Adjustable threshold? -> Complicated³? People just want to dashcam ... ^^
 
Hello.

Just a thought: For a camera technically being a (fine-grained) light-sensor, it might make sense to use it as such for making the ON/OFFing of the HDR-functionality more situational dependent, means: the camera (as a light-sensor) is/should be able to measure the overall amount of light reaching the sensor and additionally the contrast-ratio dark to bright across the sensor-surface which would provide data for an automatic transparent ON/OFF-switching process of the HDR-functionality while the camera being at work, but ... maybe that making things 1.) too complicated and 2.) the VIOFO-team too worried regarding negative customer feedback because ... where to set the threshold for switching from one state to the other? Adjustable threshold? -> Complicated³? People just want to dashcam ... ^^

This idea has come up before on the forum but there are questions about whether the processor can handle such a function. One issue is whether the DSP has the additional processing power available to handle these calculations and the other is whether the manufacturer of the chip-set might need to enable this functionality in the SDK before a dash cam manufacturer could implement it.

At one time, (7 years ago) dash cam manufacturer SeeZeus introduced the Shadow 1S which used a photo-diode to switch the camera into a "night mode" with limited success. I think this idea could be developed further and could possibly be a simple, straightforward method for triggering HDR at night.

Shadow 1.jpg
 
Really hoping Viofo rebalance the bitrates in the A139pro. I'm running a 3 channel setup with the rear and internal channels pointing out the left and right sides of my vehicle. The main unit is running in 1600p @30fps mode but max bitrate is only 27mbps, which seems low for a 6MP image...

Contrast to the rear and internal channels running at @ 15mbps which seems a little high for 1080p (2MP), properly balanced bitrate for the front would be around 45mbps or drop the rear and internal to 11mpbs (blackvue & thinkware are around this @ 1080p) and run the front at 38mbps (if the limit is 60mpbs combined).
 
Hello Dashmellow.

Dashmellow: This idea has come up before [...] but [...] processor [...] the DSP [...] processing power [...] calculations [...] chip-set [...]

Technical rabbit hole vs commercial efficiency. Team VIOFO´s call will assumingly be the latter.

And: The whole HDR/non-HDR switchology wouldn´t eventually be a thing if the HDR-ON wouldn´t hand out a more or less less quality videomaterial than HDR-OFF so HDR could be left ON permanently. And: as i said/wrote whereelse, think it was on Mr. McCoys yt-home, i still think implementing a flat- (log-) profile might be more suitable for keeping information in the highlights and shadows of high-contrast environments than HDR (log doesn´t do two-exposures), downside of log only (?) being colors appearing washed out where HDR keeps those saturated/crisp looking, but me personally don´t care about cinema-quality traffic-footage, just looking for information. I can easily produce better/more usable traffic-footage with my phone and the Hedge-cam app with activated Gamma 2.8-profile under `tone-mapping` than the A139 with HDR-ON. Downside of the phone is that small sensor thwarting that gain by exponentially losing grip on details with every additional baby-step into the dark. And (me) not being able to pry out that phone-cams IR-cut ... Oo
 
Hello Dashmellow.



Technical rabbit hole vs commercial efficiency. Team VIOFO´s call will assumingly be the latter.

And: The whole HDR/non-HDR switchology wouldn´t eventually be a thing if the HDR-ON wouldn´t hand out a more or less less quality videomaterial than HDR-OFF so HDR could be left ON permanently. And: as i said/wrote whereelse, think it was on Mr. McCoys yt-home, i still think implementing a flat- (log-) profile might be more suitable for keeping information in the highlights and shadows of high-contrast environments than HDR (log doesn´t do two-exposures), downside of log only (?) being colors appearing washed out where HDR keeps those saturated/crisp looking, but me personally don´t care about cinema-quality traffic-footage, just looking for information. I can easily produce better/more usable traffic-footage with my phone and the Hedge-cam app with activated Gamma 2.8-profile under `tone-mapping` than the A139 with HDR-ON. Downside of the phone is that small sensor thwarting that gain by exponentially losing grip on details with every additional baby-step into the dark. And (me) not being able to pry out that phone-cams IR-cut ... Oo

While what you have to say here is certainly valid and interesting, the fact of the matter is that for the time being we are left to deal with HDR in the way it is currently implemented in dash cams, so the question is how to turn HDR on and off at the most appropriate times. So, for now that will likely be the internal camera sensor, if that can be made to work, an external light sensor, or a timer.

At some point dash cam HDR will improve but I believe it will take more powerful SoCs, perhaps more memory as well as larger imaging sensors such as we see in higher end video cameras.
 
I was testing the beta firmware as well but it stopped embedding time, gps and speed data in the image and instead had seemingly random numbers across the top of the image. Did anyone else experience that? Reset didn't help so I went back to the old firmware.
 
I would assume you could code it so when the exposure drop to a pretty low level indicating its dark that would toggle HDR on /off.
but i am unsure if light on on coming cars ASO will mean exposure fluctuate too wildly for this to be a viable approach.
That would not need any upgrade to hardware of housing, and i think it can be done ( mind you i am very good at oversimplifying things in my head )
 
Hello Dashmellow.

Dashmellow: [...] dash cam HDR will improve but [...] it will take more powerful SoCs, [...] more memory [...] larger imaging sensors [...] as [...] in higher end video cameras.

Not necessarily (that standard) higher-end but maybe "bleeding" from a niche into the mainstream ...
 
Not necessarily (that standard) higher-end but maybe "bleeding" from a niche into the mainstream ...

The technology is impressive but I notice the SIONYX OPSIN night vision monocular you linked uses a 1280 X 1024 sensor with a 1980 x 1080 eyepiece display and sells for $2,495.00 USD, so even technology at that level would not be suitable for dash cam use, plus it is rather noisy.

I doubt we will see that kind of night vision implemented in a dash cam any time soon, especially in light of the "commercial efficiency" you were talking about. Maybe one day in the distant future some form of this technology might "bleed" into the mainstream, but dash cams are essentially lower end consumer gadgets.
 
Hello Dashmellow.

Dashmellow: [...] the SIONYX OPSIN [...] sells for $2,495.00 USD [...]

Hey, they (Sionyx) are young and they need the money ... :)

Dashmellow: I doubt we will see that kind of night vision implemented in a dash cam any time soon, especially in light of the "commercial efficiency" you were talking about. Maybe one day in the distant future some form of this technology might "bleed" into the mainstream, but dash cams are essentially lower end consumer gadgets.

Those proprietary black-silicone sensors might be more interested in military/federal contracts in the first place and not so much consumer-level products. At least the 1"-sensors. But smaller versions will still have the ability to look further into the IR than standard sensors which, for example, means better punch through mist/fog (automotive! Thermal is struggling in high humidity environments with low temperature-contrasts while VIS/NIR-NV is not (and many more aspects one can think of (security-cam industry (more stealthy active illumination))). And, look at how broad former unobtainable thermal bled into the consumer-market in a time-window of only about 8y. And while thermal is somewhat crippled regarding consumer-enthusiasm because glass being opaque to LWIR, VIS/NIR-NV/low-light devices certainly will be, so one will see where this comes out, at least interesting times on the (low light)-imaging-front.
 
I was testing the beta firmware as well but it stopped embedding time, gps and speed data in the image and instead had seemingly random numbers across the top of the image. Did anyone else experience that? Reset didn't help so I went back to the old firmware.
Sometimes beta FW has different OSD text which the engineers can use for reviewing test footage. It is not intended for public use, so the lack of time, speed, GPS data in the OSD text is not an issue.
 
Back
Top