Time synchronization method and device of vehicle event data recorder, vehicle and storage medium

Abstract

The application provides a time synchronization method and device of a driving recorder, a vehicle and a storage medium. The method is applied to the field of vehicles. The method comprises the following steps: acquiring a first time on a controller area network bus when the driving recorder is powered on; comparing the first time with a second time on a memory of the driving recorder, the second time being a time of the last update on the memory; and sending the later time between the first time and the second time to a system-level chip of the driving recorder, so that the system-level chip updates a local time of the driving recorder. In the case that the local time of the driving recorder is far earlier than the time of generating a video file by the driving recorder, the local time of the driving recorder is updated based on the later time between the first time on the controller area network bus and the second time on the memory, so as to bring a better experience to users.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a time synchronization method, apparatus, vehicle, and storage medium for a dashcam in the field of vehicles. Background Technology

[0002] A car dashcam is a crucial component that records video and audio of a vehicle's driving process. In the event of a traffic accident, the dashcam's recordings provide immediate evidence, protecting the user's rights. Therefore, the accuracy of the video or photo information stored in the dashcam is paramount.

[0003] In related technologies, if a vehicle's battery is disconnected for an extended period, the dashcam's built-in capacitor will be completely depleted. If the dashcam's system-on-a-chip cannot directly obtain the vehicle's time information, the dashcam will record video using its factory time, resulting in a discrepancy in the video recording time. In this case, the dashcam's factory time will be much earlier than the video file's recording time, meaning the video file's recording time will be much earlier than the time the user purchased the vehicle, leading to a poor user experience. Summary of the Invention

[0004] This application provides a time synchronization method for a dashcam. This method can update the dashcam's local time based on the later of a first time on the controller local area network bus and a second time on the memory, even when the dashcam's local time is much earlier than the time when the dashcam generates the video file, in order to provide users with a better experience.

[0005] Firstly, a time synchronization method for a vehicle dashcam is provided, the method comprising:

[0006] When the dashcam is powered on, the first time on the controller local area network bus is acquired;

[0007] The first time is compared with the second time stored in the memory of the dashcam, where the second time is the last time the memory was updated.

[0008] The later of the first time and the second time is sent to the system-on-a-chip of the dashcam so that the system-on-a-chip updates the local time of the dashcam.

[0009] Using the above technical solution, this method can obtain the first time on the controller local area network (CLAN) bus when the dashcam is powered on. If the dashcam's local time is updated directly based on this first time in the event of a CLAN bus data transmission timeout, the recorded video file's time will be much earlier than its creation time. Therefore, the first time is compared with a second time stored in the dashcam's memory (the last update time in the memory). The later time is sent to the dashcam's system-on-a-chip (SoC) so that the SoC updates the dashcam's local time, making the recorded video file's time closer to its creation time.

[0010] In conjunction with the first aspect, in some possible implementations, after sending the first time to the system-on-a-chip of the dashcam, the following steps are included:

[0011] When the dashcam is powered off, the power-off time on the controller local area network bus is acquired again;

[0012] Compare the power-off time with the second time;

[0013] The later of the power-off time and the second time is updated in the memory.

[0014] Through the above technical solution, when the dashcam is powered off, the power-off time on the controller local area network bus is obtained again, and the power-off time is updated to the memory along with the later time in the second time. This ensures that the time stored in the memory is always the latest time before the dashcam is powered off, so that the local time of the dashcam is closer to the real time.

[0015] In conjunction with the first aspect, in some possible implementations, prior to obtaining the first moment on the controller LAN bus, including:

[0016] Obtain the local time of the dashcam;

[0017] If the local time is the vehicle's default time, begin acquiring the first time on the controller area network bus.

[0018] The above technical solution obtains the local time of the dashcam. If the local time is the vehicle's default time, it means that the time on the dashcam is far from the real time. Therefore, the system starts to obtain the first time on the controller local area network bus so as to update the dashcam's time based on the first time.

[0019] Secondly, a time synchronization method for a dashcam is provided, applied to a system-on-a-chip of the dashcam, the method comprising:

[0020] When the dash cam is powered on and at least one video file exists in the dash cam, the local time of the dash cam is obtained, and the local time is the latest time in the system-on-a-chip.

[0021] The first time received on the controller local area network bus is compared with the local time, wherein the first time is the time received at a preset frequency during the power-on period of the dashcam.

[0022] If the first time is later than the local time, the local time of the dashcam is updated based on the first time.

[0023] Using the above technical solution, when the dashcam is powered on and contains at least one video file, the dashcam's local time is acquired. This local time is the latest time among all system-on-a-chip (SoC) records. The received first time from the controller's local area network (CAN) bus is compared with the local time. If the first time is later than the local time, the dashcam's local time is updated based on the first time, thus making the dashcam's local time closer to the actual time. In other words, the recording time of the video file is closer to the time when the events in the video file occurred.

[0024] In conjunction with the second aspect, in some possible implementations, obtaining the local time of the dashcam when at least one video file exists in the dashcam includes:

[0025] If at least one video file exists in the dashcam, the generation time of each video file is obtained.

[0026] The latest generation time of each video file is compared with a second time stored in the memory of the dash cam, which is the time when the dash cam is powered off and the data is updated in the memory.

[0027] The latest generation time and the later time in the second time are determined as the local time of the dashcam.

[0028] With the above technical solution, since there are multiple video files on the dashcam, and each video file corresponds to a different generation time, the local time of the dashcam can be determined based on the generation time of each video file and the second time, so that the local time of the dashcam is closer to the real time.

[0029] In conjunction with the second aspect, in some possible implementations, the method further includes:

[0030] If no video file exists in the dashcam, the time stored in the dashcam's memory is determined as the local time.

[0031] By using the above technical solution, since there are no video files in the dashcam, determining the time stored in the dashcam's memory as the local time can make the dashcam's local time closer to the real time.

[0032] Thirdly, a time synchronization device for a vehicle dashcam is provided, the device being applied to a microcontroller unit, characterized in that the device comprises:

[0033] The first time acquisition module is used to acquire the first time on the controller local area network bus when the dash cam is powered on.

[0034] The comparison module is used to compare the first time with the second time stored in the memory of the dashcam, wherein the second time is the time of the last update of the memory;

[0035] A sending module is used to send the later of the first time and the second time to the system-on-chip of the dashcam, so that the system-on-chip updates the local time of the dashcam.

[0036] Fourthly, a time synchronization device for a dashcam is provided, the device being applied to a system-on-a-chip, characterized in that the device comprises:

[0037] The local time acquisition module is used to acquire the local time of the dash cam when it is powered on and there is at least one video file in the dash cam. The local time is the later of the generation time of the latest video file among the at least one video files and the time stored in the memory of the dash cam.

[0038] The comparison module is used to compare the first time received on the controller local area network bus with the local time;

[0039] An update module is used to update the local time of the dashcam based on the first time if the first time is later than the local time.

[0040] Fifthly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the time synchronization method of the dashcam to perform a certain method.

[0041] Sixthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to execute the method performed by the time synchronization method of the aforementioned dashcam.

[0042] In a seventh aspect, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the method described above for time synchronization of a dashcam. Attached Figure Description

[0043] Figure 1 This is a schematic flowchart illustrating a time synchronization method for a dashcam provided in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram illustrating the implementation environment of a time synchronization method for a dashcam provided in an embodiment of this application;

[0045] Figure 3 This is a schematic flowchart illustrating another time synchronization method for a dashcam provided in an embodiment of this application;

[0046] Figure 4 This is a schematic flowchart illustrating another time synchronization method for a dashcam provided in an embodiment of this application;

[0047] Figure 5 This is a schematic diagram of the structure of a time synchronization device for a dashcam provided in an embodiment of this application;

[0048] Figure 6 This is a schematic diagram of the structure of another time synchronization device for a dashcam provided in an embodiment of this application;

[0049] Figure 7 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0051] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0052] Currently, in the automotive industry, dashcams are standard equipment in vehicles to protect user rights. Dashcams record video and audio of the vehicle's movement. In the event of an accident, the dashcam can provide evidence. However, if the vehicle's battery is disconnected for an extended period, the dashcam's built-in capacitor will be depleted. In this situation, the time displayed on the dashcam will become the vehicle's manufacturing date, meaning the recorded video footage will be from a time earlier than the original video was generated, resulting in a poor user experience.

[0053] In related technologies, such as Figure 1 As shown, after the dashcam is powered on, its microcontroller unit (MCU) obtains the time via the Controller Area Network (CAN) bus and sends this time to the dashcam's system-on-a-chip (SoC). The SoC then updates the dashcam's time based on this time. However, if the CAN bus data transmission times out, it will cause a timeout delay in sending the time to the MCU via the CAN bus. In this case, the time received by the MCU will be much earlier than the video recording time. If the dashcam's time is updated based on the time sent via the CAN bus in this situation, the dashcam's time will be significantly earlier than the video recording time.

[0054] Figure 2 This is a schematic diagram illustrating the implementation environment of a time synchronization method for a dashcam provided in this application embodiment.

[0055] For example, such as Figure 2 As shown, the implementation environment includes a microcontroller unit (MCU) 210, a system on chip (SoC) 220, and a controller area network bus 230.

[0056] The microcontroller unit 210 is an important control unit in the dashcam. It can acquire relevant data from the dashcam and control the dashcam to perform corresponding operations based on this data. For example, the microcontroller unit 210 can acquire the time of the controller local area network bus 230 and update the dashcam's time based on this time.

[0057] The system-on-a-chip (SoC) 220 is a chip that integrates multiple processor cores, memory, and processing units. SoCs are commonly used in in-vehicle infotainment systems. In some embodiments, the SoC can store and encode video.

[0058] The controller area network (CLAN) bus 230 serves as the interface for the dashcam to read vehicle information. In some embodiments, information such as the vehicle's in-vehicle time can be obtained through the CLAN bus 230. For example, the vehicle's in-vehicle time can be sent to the dashcam's microcontroller unit 210 via the CLAN bus 230.

[0059] Figure 3 This is a schematic flowchart illustrating a time synchronization method for a dashcam provided in an embodiment of this application.

[0060] For example, such as Figure 3 As shown, taking the microcontroller unit as the executing entity as an example, the method 300 includes steps 301-303.

[0061] Step 301: With the dashcam powered on, acquire the first time on the controller LAN bus.

[0062] It should be understood that if the vehicle's battery is disconnected for an extended period, the dashcam's built-in capacitor will be completely depleted. In this case, upon powering back on, the dashcam's internal time will revert to the vehicle's default time, which is typically the vehicle's factory date. The dashcam's internal time is used to record the chronological order of events occurring during vehicle operation. If the dashcam's internal time reverts to the vehicle's default time, events recorded based on this default time will be recorded at times significantly earlier than the actual events, resulting in a poor user experience. In this situation, the first time recorded on the controller's local area network (LAN) bus is obtained.

[0063] The controller area network bus is the communication interface through which the microcontroller reads the first time. The first time is either the time displayed on the vehicle's central control screen or the clock time inside the telematics box (T-BOX).

[0064] Step 302: Compare the first time with the second time stored in the dashcam's memory. The second time is the last time the memory was updated.

[0065] The dashcam's memory is used to store video files, audio, and various vehicle information data during vehicle operation. In some embodiments, the dashcam's memory is an electrically erasable programmable read-only memory (EEPROM).

[0066] The second time is the time when the memory was last updated. Since EEPROM is a type of storage chip that does not lose data after power failure, the second time stored in the EEPROM will not be lost even when the battery of the dashcam's built-in capacitor is depleted.

[0067] It should be understood that after the vehicle is powered on, multiple controllers in the vehicle are obtaining vehicle information through the Controller Area Network (CLAN) bus. Therefore, the CLAN bus experiences a heavy network load, which can lead to data transmission timeouts. For example, the vehicle's overall controller obtains the vehicle's speed or fuel level through the CLAN bus. In this situation, if the dashcam's internal time settings are updated based on the CLAN bus's immediate updates, the recorded video file's time will be significantly earlier than the actual time the events occurred. To avoid this, a second timer stored in the dashcam's memory is used for comparison.

[0068] For example, if the first time is March 1, 2021, and the second time on the memory is May 3, 2022, then directly updating the internal time setting of the dashcam based on the first time would result in the recorded video file being recorded much earlier than 2022. Therefore, it is necessary to compare the first time with the second time.

[0069] Step 303: Send the later of the first and second times to the system-on-a-chip of the dashcam so that the system-on-a-chip updates the local time of the dashcam.

[0070] The system-on-a-chip in the dashcam is used to generate video files during vehicle operation and update the dashcam's local time.

[0071] The local time of a dashcam is the time set internally by the dashcam. In other words, the local time of the dashcam is the time when the video file is generated while the vehicle is in motion.

[0072] It should be understood that since the second time is the time of the last update of the memory and the first time is the time of the controller's local area network bus, in order to avoid the time of the recorded video file being much earlier than the actual time of the event generated in the video file after the local time of the dashcam is updated, the later time between the first time and the second time is sent to the dashcam's system-on-a-chip.

[0073] For example, if the first time is March 1, 2022, and the second time on the memory is May 3, 2021, then the later of the first and second times will be sent to the system-on-a-chip of the dashcam.

[0074] This application provides a time synchronization method for a dashcam. This method acquires the first time on the controller local area network (CLAN) bus when the dashcam is powered on. If the dashcam's local time is updated directly based on this first time in the event of a CLAN bus data transmission timeout, the recorded video file's time will be significantly earlier than its creation time. Therefore, the first time is compared with a second time stored in the dashcam's memory (the last update time in the memory). The later time is sent to the dashcam's system-on-a-chip (SoC) so that the SoC updates the dashcam's local time, making the recorded video file's time closer to its creation time.

[0075] Figure 4 This is a schematic flowchart illustrating another time synchronization method for a dashcam provided in an embodiment of this application.

[0076] It should be noted that steps 301-303 above are a simplified description of a time synchronization method for a dashcam provided in the embodiments of this application. The following will provide a more detailed description of the time synchronization method for a dashcam provided in the embodiments of this application, using some examples.

[0077] See Figure 4 The execution entities include microcontrollers and system-on-a-chip, and the method includes the following steps 401-407.

[0078] Step 401: When the dash cam is powered on and there is at least one video file in the dash cam, the dash cam's system-on-a-chip obtains the dash cam's local time.

[0079] After a vehicle's battery has been disconnected for an extended period, the supercapacitor inside the dashcam will be depleted. When the dashcam is powered on, its local time may freeze. However, the dashcam's local time is crucial evidence of the recording order of video files; therefore, it's necessary to obtain the dashcam's local time to determine whether it needs to be updated.

[0080] The video files in a dashcam are used to record video data of events that occur while the vehicle is in motion. Since multiple emergency situations may occur during vehicle operation, and multiple emergency situations will correspond to multiple video files, the dashcam may store multiple video files.

[0081] The system-on-a-chip (SoC) in a dashcam is used for encoding, decoding, and compressing video images to ensure video clarity and smoothness. The dashcam's local time records the exact moment an emergency occurs. The dashcam's local time is the latest time displayed on the SoC.

[0082] For example, if a vehicle collision occurs and the video file was generated at 19:57 on October 8, 2021, then the dashcam's local time will be 19:57 on October 8, 2021. This local time can help traffic police determine liability for the accident.

[0083] It should be understood that since there are multiple video files in a dashcam, and these multiple video files correspond to multiple video times, in order to accurately obtain the local time of the dashcam, the latest time in the system and chip must be determined.

[0084] The following explains how to obtain the local time of a dashcam when there is at least one video file in the dashcam.

[0085] In one possible implementation, if at least one video file exists in the dashcam, the generation time of each video file is obtained; the latest generation time of each video file is compared with a second time stored in the dashcam's memory; and the later of the latest generation time and the second time is determined as the dashcam's local time.

[0086] The second time is the time updated in the memory when the dashcam is powered off.

[0087] In this possible implementation, since the dashcam contains multiple video files with different generation times, the latest generation time among these video files is compared with a second time stored in the dashcam's memory. The latest generation time compared to the second time is determined as the dashcam's local time. In other words, the latest local time in the dashcam is determined so that subsequent video recordings are recorded with a generation time closer to the actual time of the event.

[0088] To provide a more detailed explanation of the above embodiments, the following description is divided into several parts.

[0089] The first part explains how to obtain the generation time of each video file when there is at least one video file in the dashcam.

[0090] In some embodiments, the naming time of the dashcam's video file is the same as the video file's creation time, so as to facilitate the protection of the user's rights based on the video file in the future.

[0091] For example, if the video file is named on October 8, 2021 at 19:57, it means that the video file was created on October 8, 2021 at 19:57.

[0092] In some embodiments, video images of the vehicle during its movement are acquired using an image sensor. For example, video images of the vehicle during its movement are acquired using a camera.

[0093] In some embodiments, since the generation time of a video file is the naming time of the video file, reading the naming time of each video file can obtain the generation time of each video file.

[0094] The second part explains how to compare the latest generation time of each video file with the second time stored in the dashcam's memory.

[0095] It should be understood that multiple video files in a dashcam correspond to multiple generation times. In order to calibrate the dashcam's local time to the latest time, it is necessary to determine the latest generation time among the generation times of each video file.

[0096] For example, if video file 1 was generated on October 8, 2021 at 19:57, video file 2 was generated on November 18, 2021 at 14:34, and video file 3 was generated on January 5, 2022 at 12:32, then the generation time of video file 3 is determined to be the latest generation time.

[0097] It should be understood that since the second time is the time updated in memory when the dashcam is powered off, it can also calibrate the dashcam's local time. In this case, to calibrate the dashcam's local time to the latest time, the latest generation time of each video file is compared with the second time stored in the dashcam's memory.

[0098] In some embodiments, when the dashcam is powered off, the system-on-a-chip can obtain the power-off time on the controller local area network bus, and the power-off time is closer to the actual time when the event occurred, and update the power-off time to the memory.

[0099] The power-off time is the second time updated in the memory when the dashcam is powered off.

[0100] In some embodiments, the latest generation time among the generation times of the various video files is compared with the power-off time stored in the dashcam's memory.

[0101] For example, if video file 3 was generated at 12:32 on January 5, 2022, and the power-off time stored in the dashcam's memory is 14:50 on March 6, 2023, then the power-off time stored in the dashcam's memory is later, meaning that the power-off time is closer to the actual time.

[0102] The third part determines the latest generation time and the later time in the second time frame as the local time of the dashcam.

[0103] In some embodiments, if the latest generation time is later than the second time, the latest generation time of the video file is determined as the local time of the dashcam.

[0104] For example, if video file 3 was generated at 15:00 on March 6, 2022, and this is the latest generation time, and the second time stored in the dashcam's memory is 14:50 on March 6, 2022, then the generation time of video file 3 will be determined as the dashcam's local time.

[0105] In some embodiments, if the second time is later than the latest generation time, the second time is determined as the local time of the dashcam.

[0106] For example, if video file 3 was generated at 12:32 on January 5, 2022, and this is the latest generation time, and the second time stored in the dashcam's memory is 14:50 on March 6, 2023, then the second time will be determined as the dashcam's local time.

[0107] Alternatively, the following steps may also be performed.

[0108] In one possible implementation, if there are no video files in the dashcam, the time stored in the dashcam's memory is determined as the local time.

[0109] It should be understood that if there is no video file in the dashcam, there is no corresponding generation time for the video file in the dashcam. Therefore, the local time of the dashcam can be obtained based on the time stored in the dashcam's memory.

[0110] In this implementation, when there are no video files in the dashcam, the time stored in the dashcam's memory is the power-off time of the dashcam. Since this power-off time is more accurate than the vehicle's default time, the time stored in the dashcam's memory is determined as the local time, making the local time closer to the time when the video file was recorded.

[0111] Step 402: When the dashcam is powered on, the dashcam's microcontroller unit obtains the first time on the controller local area network bus.

[0112] It should be understood that when a dashcam loses power, its local time will stop. Therefore, after the dashcam is powered on, its local time needs to be updated.

[0113] Since the system-on-a-chip (SoC) of the dashcam is used to update the local time of the dashcam, and the SoC does not have an interface for communicating with the controller local area network (Controller Area Network) bus, it is necessary to obtain the first time on the Controller Area Network bus based on the microcontroller unit of the dashcam.

[0114] The microcontroller unit is used to acquire the first time from the controller area network (CAN) bus. The CAN bus is used to receive information such as the vehicle's infotainment system time. The first time is the vehicle's infotainment system time or the T-BOX time acquired based on the CAN bus.

[0115] In some embodiments, the microcontroller unit collects the vehicle time or T-BOX time based on the controller local area network (LAN). That is, the first time on the LAN is the vehicle time or T-BOX time.

[0116] In some embodiments, the in-vehicle T-BOX system has a built-in Global Positioning System (GPS) module, which obtains accurate time information by receiving GPS signals. GPS time is based on satellite systems.

[0117] In some embodiments, the in-vehicle T-BOX system connects to a remote server via a wireless communication module to obtain network time.

[0118] In some embodiments, the vehicle infotainment system has an internal time setting for displaying and recording time.

[0119] In some embodiments, the microcontroller unit collects the vehicle time or the T-BOX time based on the controller local area network.

[0120] Optionally, the following steps may also be performed before performing step 402 above.

[0121] In one possible implementation, the local time of the dashcam is obtained, and if the local time is the vehicle's default time, the first time on the controller area network bus is acquired.

[0122] It should be understood that after the dashcam is powered on again, it can determine whether it needs to obtain the first time on the controller LAN bus based on the local time on the dashcam.

[0123] In some embodiments, the local time of the dashcam is obtained from the dashcam's display screen.

[0124] In this implementation, the local time of the dashcam is acquired. If the local time is the vehicle's default time, the acquisition of the first time on the controller area network bus is initiated. That is, the first time is acquired promptly to allow for quick calibration of the dashcam's local time based on that first time.

[0125] Step 403: The microcontroller compares the first time with the second time stored in the dashcam's memory. The second time is the last time the memory was updated.

[0126] It should be understood that the Controller Area Network (CAN) needs to process data during transmission, such as decoding or verification. If the data volume is large and cannot be processed in a timely manner, a delay will occur during CAN transmission. In this case, if a delay occurs during transmission, the initial time will be significantly earlier than the actual time. If the local time on the dashcam is updated based on this initial time, the recorded video file's time will be significantly earlier than the actual time in the video file. To avoid this, the microcontroller compares the initial time with a second time stored in the dashcam's memory.

[0127] The second time is the time when the memory was last updated. When the dashcam is powered off, the microcontroller determines the later time between the dashcam's power-off time and the time in the memory as the second time, so that the time in the memory is closer to the actual time.

[0128] In some embodiments, the microcontroller uses an automated script to convert the timestamps of a first time and a second time into the same format to compare the time difference between the first time and the second time.

[0129] For example, the first time's timestamp is a Unix timestamp (in seconds), and the second time's timestamp is a Python datetime object. Therefore, you can convert the first time's timestamp from a Unix timestamp to a datetime object, or the second time's timestamp from a datetime object to a Unix time.

[0130] In step 404, the microcontroller sends the later of the first and second times to the system-on-a-chip of the dashcam so that the system-on-a-chip updates the local time of the dashcam.

[0131] It should be understood that since the second time is the time of the last update of the memory and the first time is the time of the controller's local area network bus, in order to avoid the time of recording the video file being much earlier than the time of the event in the video file after the local time of the dashcam is updated, the later time between the first time and the second time is sent to the dashcam's system-on-a-chip.

[0132] In some embodiments, if the first time is later than the first time, the microcontroller will send the information to the system-on-a-chip (SoC) of the dashcam so that the SoC updates the local time of the dashcam.

[0133] For example, if the first time is 15:00 on March 6, 2022, and the second time stored in the dashcam's memory is 14:50 on March 6, 2022, then the first time will be sent to the dashcam's system-on-a-chip.

[0134] In some embodiments, when the second time is later, the microcontroller sends the second time to the dashcam's system-on-a-chip (SoC) so that the SoC updates the dashcam's local time.

[0135] For example, if the first time is 15:00 on March 6, 2022, and the second time stored in the dashcam's memory is 14:50 on May 6, 2022, then the second time will be sent to the dashcam's system-on-a-chip.

[0136] It should be understood that communication between the microcontroller unit and the system-on-a-chip is usually used to handle more complex tasks. Therefore, in order to ensure that the communication link between the microcontroller unit and the system-on-a-chip is stable and reliable, a "heartbeat" mechanism can be established.

[0137] Optionally, the following steps may be performed before the microcontroller sends the later of the first and second times to the system-on-a-chip of the dashcam.

[0138] In one possible implementation, the heartbeat packets between the microcontroller and the system-on-a-chip are determined based on a universal asynchronous transceiver.

[0139] Among them, heartbeat packets are small data packets sent periodically to confirm the connection status and responsiveness of the communicating parties.

[0140] A heartbeat packet includes an identifier, a sequence number, a timestamp, and a checksum. The identifier is used to identify the heartbeat packet. The sequence number is used to detect packet loss or duplicate packets. The timestamp is used to calculate the delay. The checksum is used to verify data integrity.

[0141] In some embodiments, the microcontroller unit and the system-on-a-chip (SoC) initialize the asynchronous transceiver. A timer is configured in the microcontroller unit to trigger a heartbeat packet transmission function at preset intervals. The microcontroller unit periodically sends heartbeat packets to the SoC, which receives the heartbeat packets and verifies them based on a checksum.

[0142] The preset time is automatically determined by the microcontroller unit or set by technicians according to actual conditions; this application embodiment does not limit this. For example, the preset time can be 500 milliseconds (ms) to 1000 ms.

[0143] Step 405: The system-on-a-chip compares the first time received on the controller local area network bus with the local time. The first time is the time received at a preset frequency during the power-on period of the dashcam.

[0144] Local time is the latest time in the system-on-a-chip.

[0145] In some embodiments, the system-on-a-chip parses the first-time message received on the controller local area network and extracts the first-time timestamp.

[0146] In some embodiments, the system-on-a-chip reads the timestamp of the local time via the RTC register.

[0147] In some embodiments, the system-on-a-chip compares the timestamp of the first time received on the controller area network bus with the timestamp of the local time to obtain the difference between the two timestamps.

[0148] For example, if the first time is 15:00 on August 6, 2022, and the local time stored in the dashcam's memory is 14:50 on May 6, 2022, then it is determined that there is a difference between the first time and the local time.

[0149] Understandably, after the dashcam is powered on, it can obtain the first time from the controller's local area network (LAN). However, the LAN may have latency, meaning the first time will be much earlier than the actual time during vehicle movement. Therefore, calibrating the dashcam's local time based on the first time will also cause it to be earlier than the actual time during vehicle movement. To make the local time on the dashcam closer to the actual time during vehicle movement, the first time can be received at a preset frequency during the dashcam's power-on period, allowing for multiple calibrations of the dashcam's local time using multiple first times.

[0150] In some embodiments, when the dashcam is powered on, the first time on the controller local area network bus is received at a preset frequency.

[0151] The preset frequency is automatically determined by the microcontroller unit or set by technicians according to actual conditions; this application embodiment does not limit this. For example, the preset frequency can be 5 times.

[0152] Step 406: If the system-on-a-chip is later than the local time in the first time, it updates the local time of the dashcam based on the first time.

[0153] It should be understood that updating the local time of the dashcam immediately means that each functional module in the dashcam will use that time as its local time.

[0154] In some embodiments, if the first time is later than the local time, the system-on-chip deletes the local time from the memory and stores the first time in the memory.

[0155] In some embodiments, if the system chip's time is later than the local time, it will synchronize to the various functional modules of the dashcam immediately.

[0156] The functional modules include a video encoding module, an image sensor module, an audio module, and a display module.

[0157] The video encoding module compresses and encodes the raw video signal captured by the camera, reducing storage space and improving transmission efficiency. The image sensor module captures video images and typically includes one or more cameras. The audio module acquires and processes audio signals and records sound synchronously. The display module shows the real-time video feed, settings menus, status information, etc.

[0158] For example, if the system-on-a-chip is later than the local time, it will synchronize the video encoding module immediately so that the video encoding module can start encoding immediately.

[0159] It should be understood that since the system-on-a-chip needs time to receive the first time and compare it with the local time, the local time of the dashcam is updated based on the first time after the dashcam has been powered on for a period of time.

[0160] For example, 1800ms after the dashcam is powered on, the local time of the dashcam is updated based on the first time.

[0161] Step 407: When the dashcam is powered off, the microcontroller updates the second time in the memory based on the power-off time on the controller area network bus.

[0162] It should be understood that after the dashcam is powered on, time passes while the vehicle is in motion, but the initial time on the controller area network (CLAN) remains unchanged. If the initial time on the CLAN bus is directly stored in memory, there will be an error between the initial time and the actual time during vehicle movement. To prevent the second time in memory from being closer to the actual time, the microcontroller unit updates the second time in memory based on the power-off time on the CLAN bus.

[0163] In one possible implementation, the microcontroller acquires the power-down time on the controller area network bus again; compares the power-down time with a second time; and updates the memory with the later of the two times.

[0164] Among them, when the dashcam is powered off, the power-off time on the controller's local area network bus is obtained, and this power-off time is closest to the actual time.

[0165] It is understood that the specific implementation of comparing the power-off time with the second time can be found in the relevant description of comparing the first time with the second time in step 403 above, and will not be repeated here.

[0166] In some embodiments, if the power-down time is later, the power-down time is updated in the memory.

[0167] For example, if the power-off time is 15:00 on March 6, 2022, and the second time stored in the dashcam's memory is 14:50 on March 6, 2022, then the power-off time will be updated in the memory.

[0168] In some embodiments, if the second time is later, the time in memory is maintained at the second time.

[0169] For example, if the power-off time is 14:50 on March 6, 2022, the second time stored in the dashcam's memory is 15:00 on March 6, 2022, and the time in the memory is maintained at the second time.

[0170] In this implementation, when the dashcam is powered off, the power-off time on the controller LAN bus is obtained again, and the power-off time is updated to the memory along with the later time in the second time. This ensures that the time stored in the memory is always the latest time before the dashcam is powered off, so that the local time of the dashcam is closer to the real time.

[0171] This application provides a time synchronization method for a dashcam. This method allows the dashcam's system-on-a-chip (SoC) to acquire the dashcam's local time when the dashcam is powered on and contains at least one video file. If the dashcam is powered off for an extended period, its local time will be significantly earlier than the actual time. Therefore, the dashcam's microcontroller unit (MCU) acquires a first time from the controller local area network (CLAN) bus. If the MCU data transmission times out, directly updating the dashcam's local time based on this first time would result in the recorded video file's time being significantly earlier than its creation time. Therefore, the MCU compares the first time with a second time stored in the dashcam's memory, where the second time is the last update time in the memory. The MCU sends the later of the first and second times to the dashcam's SoC, causing the MCU to update the dashcam's local time. The MCU compares the received first time from the CLAN bus with its local time, where the first time is the time received at a preset frequency during the dashcam's power-on period. When the first timeout is later than the local time, the system-on-a-chip updates the dashcam's local time based on the first timeout, thus making the recorded video file's time closer to the video file's creation time. When the dashcam is powered off, the microcontroller updates the second time in memory based on the power-off time on the controller area network bus to reduce the error between the second time in memory and the real time, thereby making the dashcam's local time closer to the real time.

[0172] Figure 5This is a schematic diagram of the structure of a time synchronization device for a dashcam provided in an embodiment of this application.

[0173] For example, such as Figure 5 As shown, the device 500 includes:

[0174] The first time acquisition module 501 is used to acquire the first time on the controller local area network bus when the dashcam is powered on.

[0175] The comparison module 502 is used to compare the first time with the second time stored in the memory of the dashcam, where the second time is the time when the memory was last updated.

[0176] The sending module 503 is used to send the later of the first time and the second time to the system-on-chip of the dash cam, so that the system-on-chip can update the local time of the dash cam.

[0177] In one possible implementation, the device 500 further includes:

[0178] The first time acquisition module 501 is used to acquire the power-down time on the controller local area network bus again when the dashcam is powered off;

[0179] The comparison module 502 is used to compare the power-off time with the second time.

[0180] An update module is used to update the memory with the later of the power-off time and the second time.

[0181] In one possible implementation, the device 500 further includes:

[0182] The local time acquisition module is used to acquire the local time of the dashcam.

[0183] The first time acquisition module 501 is used to acquire the first time on the controller area network bus when the local time is the vehicle's default time.

[0184] Figure 6 This is a schematic diagram of the structure of another time synchronization device for a dashcam provided in an embodiment of this application.

[0185] For example, such as Figure 6 As shown, the device 600 includes:

[0186] The local time acquisition module 601 is used to acquire the local time of the dash cam when it is powered on and when there is at least one video file in the dash cam. The local time is the latest time in the system-on-a-chip.

[0187] The comparison module 602 is used to compare the first time received on the controller local area network bus with the local time. The first time is the time received at a preset frequency during the power-on period of the dashcam.

[0188] The update module 603 is used to update the local time of the dashcam based on the first time if the first time is later than the local time.

[0189] In one possible implementation, the device 600 further includes:

[0190] The local time acquisition module 601 is used to acquire the generation time of each video file when there is at least one video file in the dashcam.

[0191] The comparison module 602 is used to compare the latest generation time of each video file with the second time stored in the memory of the dash cam. The second time is the time updated in the memory when the dash cam is powered off.

[0192] The determination module is used to determine the latest generation time and the later time among the second time as the local time of the dashcam.

[0193] In one possible implementation, the device 600 further includes:

[0194] The determination module is used to determine the time stored in the dashcam's memory as the local time when there is no video file in the dashcam.

[0195] Figure 7 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0196] For example, such as Figure 7 As shown, the vehicle 700 includes a memory 701 and a processor 702. The memory 701 stores executable program code 703, and the processor 702 is used to call and execute the executable program code 703 to perform a time synchronization method for a dashcam.

[0197] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a time synchronization method for a dashcam provided in embodiments of this application.

[0198] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0199] When each functional module is divided according to its corresponding function, the device may also include an update module and a determination module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0200] It should be understood that the device provided in this embodiment is used to execute the above-described time synchronization method for a dashcam, and therefore can achieve the same effect as the above-described implementation method.

[0201] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0202] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.

[0203] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute the time synchronization method of a dashcam provided in the above embodiments.

[0204] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the time synchronization method for a dashcam provided in the above embodiment.

[0205] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to achieve the time synchronization method for a dashcam provided in the above embodiment.

[0206] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0207] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0208] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0209] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A time synchronization method for a dashcam, characterized in that, The method, applied to the microcontroller unit of the dashcam, includes: When the dashcam is powered on, the first time on the controller local area network bus is acquired; The first time is compared with the second time stored in the memory of the dashcam, where the second time is the last time the memory was updated. The later of the first time and the second time is sent to the system-on-a-chip of the dashcam so that the system-on-a-chip updates the local time of the dashcam.

2. The method according to claim 1, characterized in that, After sending the first time to the system-on-a-chip of the dashcam, the process includes: When the dashcam is powered off, the power-off time on the controller local area network bus is acquired again; Compare the power-off time with the second time; The later of the power-off time and the second time is updated in the memory.

3. The method according to claim 1, characterized in that, Prior to obtaining the first time on the controller local area network bus, the following is included: Obtain the local time of the dashcam; If the local time is the vehicle's default time, begin acquiring the first time on the controller area network bus.

4. A time synchronization method for a dashcam, characterized in that, The method, applied to the system-on-a-chip of the dashcam, includes: When the dash cam is powered on and at least one video file exists in the dash cam, the local time of the dash cam is obtained, and the local time is the latest time in the system-on-a-chip. The first time received on the controller local area network bus is compared with the local time, wherein the first time is the time received at a preset frequency during the power-on period of the dashcam. If the first time is later than the local time, the local time of the dashcam is updated based on the first time.

5. The method according to claim 4, characterized in that, When at least one video file exists in the dashcam, obtaining the local time of the dashcam includes: If at least one video file exists in the dashcam, the generation time of each video file is obtained. The latest generation time of each video file is compared with a second time stored in the memory of the dash cam, which is the time when the dash cam is powered off and the data is updated in the memory. The latest generation time and the later time in the second time are determined as the local time of the dashcam.

6. The method according to claim 4, characterized in that, The method further includes: If no video file exists in the dashcam, the time stored in the dashcam's memory is determined as the local time.

7. A time synchronization device for a vehicle dashcam, characterized in that, The device includes: The first time acquisition module is used to acquire the first time on the controller local area network bus when the dash cam is powered on. The comparison module is used to compare the first time with the second time stored in the memory of the dashcam, wherein the second time is the time of the last update of the memory; A sending module is used to send the later of the first time and the second time to the system-on-chip of the dashcam, so that the system-on-chip updates the local time of the dashcam.

8. A time synchronization device for a vehicle dashcam, characterized in that, The device includes: A local time acquisition module is used to acquire the local time of the dashcam when there is at least one video file in the dashcam. The local time is the later of the generation time of the latest video file among the at least one video files and the time stored in the memory of the dashcam. The comparison module is used to compare the first time received on the controller local area network bus with the local time; An update module is used to update the local time of the dashcam based on the first time if the first time is later than the local time.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 6.

Images