MIOFIVE S1 Ultra - 4K Front / 4K Rear - Review/Testing - RCG

[rcg530]

I contacted my MIOFIVE rep and inquired about the new S1 Ultra 4K front and 4K rear 2-channel dash camera. MIOFIVE decided to send me a S1 Ultra dash camera, a USB-C HWK2 hardwire kit and a CPL filter that will fit the front camera. The S1 Ultra includes as 64 GB MIOFIVE branded memory card. I will get my unboxing pics and start my power consumption testing this week.

 

[rcg530]

Reserved - Unboxing pics

 

[rcg530]

Power Consumption Test Results - 20240704

 

[rcg530]

I powered up the S1 Ultra 2-channel dash camera just to see what type of video files it created on the memory card. The front and rear video file resolution is 3840x2160. The front is recorded at 30 fps while the rear is recorded at 25 fps.

 

[rcg530]

Initial Camera Focus Check

The S1 Ultra’s rear camera is out of focus on the left half of the field of view. The front camera’s focus quality is very good. The focus check I run every dash camera through when I first receive them involves mounting the cameras to a test rig and placing the test rig on the trunk lid of my car with the cameras facing to the outside of my garage. I place a ladder in my driveway with two real license plates to see how those appear in the video. This test removes any influence a vehicle’s window glass might add to the focus clarity testing.

The S1 Ultra’s rear camera also has upside down labeling on the rear camera case. I say that because I had to mount the camera with the labeling upside down to get a right side up video image.

(click on thumbnails)


The area outlined in red is out of focus. Compare it with the frame grab from the front camera.

Rear Frame Grab (click on thumbnail)


Front Frame Grab (click on thumbnail) – in focus across the entire field of view


Power Saving Collision Detection Parking Mode – Reaction Time To Impact Event

I performed a quick test of the collision detection parking mode feature of the S1 Ultra. When I tested the older “Dash Cam Dual” this was a major problem with that dash camera because it took so long to power up the front and rear cameras and start recording. The reason I was told back then that caused the long delay was that it took a long time to power up and mount the eMMC based file system.

The S1 Ultra appears to suffer from the same sluggish performance reacting to an impact event, even though it’s using a microSD card based file system rather than the eMMC file system in the older Dash Cam Dual dash camera. I measure my times by performing an impact event to the test rig the dash cameras are mounted to at the top of the minute (00 seconds) as noted by a clock being displayed full screen on my Android tablet which is positioned in front of the cameras. The “time” value observed when each camera starts writing video to the parking event video files is how I measure the reaction time.

It takes 11 seconds for the front camera to start recording to its video file. It takes 14 seconds for the rear camera to start recording to its video file. Because of the additional delay for the rear camera to start writing to its video file, the rear camera video file is only 55 seconds in length while the front camera’s video file is 60 seconds in length.

Timeline

• 10:58:00 – Impact Event
• 10:58:11 – Front camera starts recording
• 10:58:14 – Rear camera starts recording
• 10:59:10 – Rear camera stops recording
• 10:59:11 – Front camera stops recording

Front


Rear


Documented Front / Rear Video vs Actual Front Rear Video

Page 30 of the S1 Ultra’s English user manual documents the rear camera video footage as 3840x2160 30fps. The actual video is recorded at 25 fps, not 30 fps.

 

[Vortex Radar]

Excellent testing so far! With the parking mode reaction time, try testing the collision detection in timelapse mode. I've been told that is much faster (2-3 sec) because they don't have to wait for the dashcam to boot up first.

 

[rcg530]

Excellent testing so far! With the parking mode reaction time, try testing the collision detection in timelapse mode. I've been told that is much faster (2-3 sec) because they don't have to wait for the dashcam to boot up first.

I usually test all of the parking mode configuration during my full power consumption test suite. I'll likely run my power consumption tests this week.

Time-lapse parking mode consumes 349 mA @ 12.6V (4.4W). There's a limitation on how long time-lapse parking mode can last in the firmware settings (4 hours, 8 hours, 16 hours, 24 hours [max] or disabled).

I did run a "quick" test of the time-lapse parking mode with an impact event occurring during parking mode. The transition time from time-lapse videos to emergency videos is about two seconds.

Transition from time-lapse parking mode to "emergency" video due to impact event in parking mode:



Start of emergency video due to impact event (about 2 seconds):



Switching back to time-lapse recording after emergency videos are completed:



Resumption of time-lapse video recording after emergency recording finishes:

There's a huge time gap resuming the rear time-lapse video recording after the emergency recording video finishes. There's a 32 second time gap of lost video. You can see the "B" (rear) video file has a timestamp in the filename that is much later than the one for the front camera file.

 

[rcg530]

I completed my power consumption testing for the MIOFIVE S1 Ultra 2-channel dash camera. I posted the results in post #3 of this thread.

Here some additional info from my power consumption testing....

Dash Camera Configuration

• S1 Ultra 2-Channel
  • Resolution
    • Front 3840x2160 30 fps
    • Rear 3840x2160 25 fps
  • Firmware
    • Front S1_PUS_1.0.1.0429
    • Rear S1_P_1.2.1.0428
  • Memory Card
    • MIOFIVE 64 GB microSD Card

Time-Lapse Parking Mode – Rear Camera – Does not start recording for 31 seconds

As part of my power consumption testing, I document the video file attributes (bitrate, FPS, length) for all the various parking modes the dash camera supports. I also monitor the transition times when switching recording modes.

The abbreviations I use in my power consumption spreadsheet are:

• NR = Normal Recording Mode (driving recording)
• Parking Modes
  • PM TL = Time-Lapse Parking Mode
  • PM PG = Parking Guard Parking Mode
• EMER = Emergency Recording
• PARK = Parking Mode Impact Event Recording

While testing the S1 Ultra time-lapse parking mode (PM TL), I found that the transition time from normal recording (NR) mode to time-lapse parking mode (PM TL) is acceptable for the front camera. The transition time from NR to PM TL for the rear camera is very bad because it takes 31 seconds before the rear camera starts recording video in PM TL. That entire 31 second period has nothing being recorded for the rear camera. I determine the time gap by placing an Android tablet in front of both cameras with the current time being displayed (hour:min:sec).

I found that impact events are detected while in time-lapse parking mode, but they are emergency impact event recordings (stored in “CarDV\Movie\Emr” directory). It’s my understanding that the “EMER Video Sensitivity” setting is intended for use during normal recording (NR) mode. With it set to the default of “Medium”, the harshness of the impact required in time-lapse parking mode (PM TL) is on the level of an earthquake shaking your vehicle.

It would seem more appropriate for the time-lapse parking mode (PM TL) to use the sensitivity setting for the “Parking Guard Sensitivity” setting and to generate “PARK” videos in the “CarDV\Movie\Park” directory (just like parking guard mode).

The second instance of the long delay to resume the rear camera time-lapse parking mode recording (PM TL) is when a severe enough impact occurs to trigger an emergency recording (EMER) and when that completes and the S1 Ultra transitions back to time-lapse parking mode recording (PM TL), it takes 31 seconds again to have the rear camera start recording time-lapse video.

This appears to be a bug in how the rear camera time-lapse recording is handled (starting in time-lapse parking mode or resuming time-lapse parking mode after an emergency recording event).



MIOFIVE HWK2 3-Wire Hardwire Kit – Low Voltage Cutoff Thresholds

Another test I perform is to verify the low voltage cutoff settings for any hardwire kit. I configured the two dip switches on the HWK2 through the various settings documented on the label on the HWK2 (11.4V to 12.0V). I use a DC power supply to provide the 12V power to the hardwire kit and I set the DC power supply’s output voltage to a level of 12.6V to start the test. I place the dash camera into time-lapse parking mode by turning off power to the HWK2 ACC wire. I leave the DC power supply voltage at the selected voltage level for at least 5-minutes. If the hardwire kit does not turn off the power to the dash camera, I drop the DC power supply output voltage by 0.05V and let the dash camera run at that voltage. I repeat that pattern until I find the voltage that results in the HWK2 to turn off the 5V power to the S1 Ultra.



The HWK2 hardwire kit I have either deviates from the documented low voltage values due to a problem in the HWK2 or the label on the HWK2 is incorrect.

 

[Agie]

Nice testing, presuming it's using an older Sony sensor and not Starvis 2? Nice having front and rear 4K, but would have been better to use newer sensors....