Call me back | My basket | Checkout | Add to email list

     You are here: Website » Knowledge base

« back to website

RTConfiguringVIDEO4Unit / EventBasedRecording

Event based recording

IMPORTANT: Event based recording is a specialist recording mode designed for industrial and driving study application, it is not included in the standard VIDEO4 firmware.

The event recording, also referred to as VEDR mode (VIDEO EVENT DATA RECORDING), is a specialist mode of recording which is used to capture special triggered events on video and data. The special thing about this mode compared with the normal recording mode is that it is possible to capture data and video BEFORE and after a trigger event. This recording mode is completely separate from the regular recording mode and is intended for specialist applications.

This mode is ideal for checking what happened in the time leading up to the event. A typical example might be to trigger recording based on a very high acceleration typical of the vehicle crash, in this case it would be desirable to see what happened before the impact, not just afterwards. To achieve this, the system is always recording video/audio/data but deleting all but the last (example) 10 seconds.

To use the event recording mode on the VIDEO4 then it needs to be loaded with the VGT file from the configuration software. The VIDEO4 needs to be “started” and “stopped” in the normal way, either manually using the button on the front of the unit, or using autostart and autostop. Once the VIDEO has been started then the event based recording becomes active, and it will capture any configured events.

This section only describes the set up of the event recording mode, for information about how to use the event mode then please refer to the VIDEO4 section of the help file or knowledge base.

This special mode is enabled and set up under the “configuration” menu of the video configuration software:

Once the form loads, select the tick box at the top/left of configuration form to enable “Event recording mode”:

Once this option is enabled then more options are shown in the form and it looks something like the example below:

There options along the top are “general options” that apply to all the recordings generated in the event mode. In addition there is a table of configuration options, each line of which corresponds to a different set of trigger conditions.

The general options are:

  • pre-trigger time, this can be set from 0 to 10 seconds:
This is the amount of data/video/audio that is stored before the trigger condition. So for the example of triggering on an impact as above, this is the time that is recorded and available for playback before the impact. To put it another way, if a pre trigger time of 10 seconds, there will be 10 seconds of data/video/audio played back before the vehicle impact takes place.

  • VEDR2, this can be enabled or disabled:
While the event mode recording is in progress, the system is continuously recording, but deleting all but the most recent “x seconds” of data/video/audio. In addition to these event based recordings, it is also possible to record a 2nd data only stream to the memory card. This second stream is DATA ONLY, it doesn’t contain any video or audio.

  • Recording mode
This sets what is recorded to the event trigger recordings; this can be almost any combination of audio/video and data.

  • Loop mode file deletion, this can be enabled or disabled:
This mode is not currently available and has no effect.

For each triggered event recordings there are the following specific options:

  • General options:
    • Chapter: This is simply the number of the trigger, from 1 to 20 and for the user’s reference.
    • Name: This is the name of the trigger event and again is simply included for the users reference.
    • Priority: This is the priority of the trigger, 9 being the highest priority and 1 being the lowest priority. A higher priority can extend the recording time of the lower priority, however if there is a trigger from a lower priority trigger whilst a higher priority recording is in progress, then it has no effect.
  • Trigger conditions:
This configures exactly what conditions triggers the system to generate an event recording. For each event there can be up to a maximum of 3 variables that can be checked. The variables used can be any of the system variables that are available, including user defined variables. Note that the variable is checked based on the setup in the variable manager, so before the variables are checked the variable is scaled to the specifed units, and filtered before they are checked against the thresholds. All conditions have to be true to trigger a recording.
  • Variable: This is simple they variable that is checked.
  • >=<: This is the logical condition that is checked and can be either “greater than”, “less than” or “equal to”. Note that for most variables using equal to is not a suitable trigger condition. For example if the system is set to trigger on “speed=10mph” it would not trigger if the measured speed was 9.999mph, or 10.001mph. The chances of ever seeing any particular exact speed is very low. The “equal to” condition should only be used with variables that can only take discrete values, for example “gear” which is always 0,1,2,3,4,5,6 or 7.
  • Limit: This is the first limit value that the system uses to compare against.
  • >=<: This is the second logical condition.
  • Limit: This is the second limit comparison value.
For example, if the trigger is set up using the following:
Then this would trigger an event when:
If (speed > 0) and (speed < 10) and (long accel > -100) and (long accel < -1.8) then impact triggered
Note that singe longitudinal acceleration is always >-100, then this has no practical effect – so this can be simplified to:
If (speed > 0) and (speed < 10) and (long accel < -1.8) then impact triggered
This can be written in words as:
“Trigger the impact event when speed is between 0 and 10, and longitudinal acceleration is less than -1.8. So this would trigger at low speed when there is a high braking force.”
  • Event and recording options:
    • VEDR status: This is used to enable and disable the event trigger, when it is disabled then the event is completely disabled and the rest of the configuration on this line is ignored and has no effect.
    • Post-trigger time: This is how long after the triggered event recording will continue for.
    • Minimum time of trigger to start recording: This is how long the particular set of trigger conditions has to be true for before the event is triggered.
    • Blanking time: This is to limit how many recordings the system generates for a particular event type. For example if this is set to 60 seconds, then the system will record an absolute maximum or 1 event of this type every minute, even if the trigger conditions are valid more often.
    • Maximum recording time: In the situation where the same trigger event is matched while the system is already recording an event then the event recording is extended, this sets an absolute limit to how long the even recording can be, so even if the trigger conditions remain true, then after this time the recording will stop.

The final field of user notes is for the user to make a note about the trigger for their own records; this has no effect on the system behaviour.

Note that overlay files for event based recording have a different extension. For “normal” non-event overlay files, the extension is “VGL” (Video Graphics Layout), for “event” overlay files the extension is “VGT” (Video Graphics Triggered). Apart from the extra event options, both the normal and the event based configuration is handled in exactly the same way with regards graphics and layout etc.

Behaviour of the event triggers.

The event based recording is a powerful system with a large number of options; the behaviour of the system can become quite complicated. This section is intended to clarify how the different trigger conditions are handled and what the system does when there are multiple triggers.

“triggers” are cause by the transition of the logic becoming “true. For example, with a simple trigger condition of “speed > 10” the trigger event would appear:

This shows the simplest case for a single isolated trigger, in this case the system records for the specified pre-trigger time and post-trigger time, resulting in a total recording length of pre-trigger + post-trigger time.

The diagram below is the more complicated case with 2 of the same trigger arriving in quick succession. In this case recording is triggered on the first trigger event, and before the post trigger time is completed for the first trigger a 2nd trigger is received. This causes the recording time to be extended. In this case the total recording length is of pre-trigger + post-trigger + time between the 2 triggers.

Similar to the case before, the diagram below show what happens when a trigger is followed by a matched trigger condition of a lower priority. In this case since the 2nd trigger is a lower priority compared with the first it has no effect and is disregarded.

In contrast, if a 2nd trigger occurs that is a higher (or equal) priority than the first then the recording time is extended, just as it would have been for a trigger from the same source. Note that in this case the post-trigger time is taken from the configuration of the 2nd trigger.

In the situation where there are a number of triggers (either from the same source or same/increasing priority) the event recording length will continue to be increased until the maximum recording time for the last trigger is reached. In the diagram below the post-trigger recording time for the final trigger is not completed as the maximum recording time has been reached and this takes priority.

If no blanking time is specified, or triggers are from different channels then it is possible to have events recorded with no or only a small gap. This is shown in the diagram below. In this case a simple triggered recording completes in the normal way and results in a recording of pre-trigger time + post-trigger time as expected. A short time after this, another trigger condition is met and this starts a 2nd recording. In this case the gap between the first and second trigger was less then pre-trigger time + post-trigger time and as a result the 2nd event recording is shorter than the target specified.

Finally the effect of blanking time is considered. A typical case is shown in the diagram below. Recording is started by a simple trigger, which results in a recording of the expected length. Once this first recording is completed the blanking timer begins, and any triggers of the same type in this period have no effect. Once the blanking time has passed, triggers are used in the normal way. Note that the blanking time only affect the one channel they are configured to, so if blanking time is set on channel 1, and this is triggered, this will have no effect on how soon a subsequent trigger can occur on channel 2.

Page last modified on January 11, 2019, at 02:40 PM