View source for MISC-TN-015: Proof-of-Concept of an industrial, high-frame-rate video recording/streaming system

===Alarm detection latency verification===
The following diagram shows how the specific testbed used for this verification looks like.


[[File:MISC-TN-015-latency-testbed.png|thumb|center|600px|Fig. 6: Testbed used to verify the alarm detection latency]]


In essence, the idea consists of shooting a 5-digit 7-segment-display timer with 1ms resolution. The timer cycles repeatedly from 00.000s to 99.999s and also provides a digital signal that is used to emulate the alarm signal. Whenever the timer reaches 50.000s, this signal is raised for 1 second. In other words, the timer triggers an emulated alarm that is synchronized with the visualization of the 50th second on the displays. Referring to the Fig.2, istants t<sub>B</sub>, t<sub>0</sub>, and t<sub>A</sub> can be easily associated with the time visualized by the timer as follows:
*t<sub>B</sub> = 50.000-8.000 = 42.000s
*t<sub>0</sub> = 50.000s
*t<sub>A</sub> = 50.000+3.000 = 53.000s

Once the recording is saved on the SSD, the verification consists of checking the first frame, the last frame, and the alarm frame (<code>n_+0.000000000.bmp</code>). They should show respectively:
*The timer displaying 42.000
*The timer displaying 53.000
*The timer displaying 50.000.

Let's analyze one of the recording buffers that were captured this way. It refers to the alarm recorded on Agust 8, 2020 at 12.09.51 CEST. The following images show the frame associated with t<sub>B'</sub>, t<sub>A'</sub>, and t<sub>0'</sub> respectively.


[[File:000000 -8.133780480.png|thumb|center|600px|Fig. 7: Frame associated with t<sub>B'</sub>]]


[[File:003332 +3.046812160.png|thumb|center|600px|Fig. 8: Frame associated with t<sub>A'</sub>]]


[[File:002424 +0.000000000.png|thumb|center|600px|Fig. 9: Frame associated with t<sub>0'</sub>]]


First of all, we notice that the timer's last digit always appears as "8". This is due to the fact that 7-segment displays are refreshed every millisecond, but the acquisition rate of the image sensor is slower (*). Therefore, the last digit is not meaningful and can be ignored. 

That said, frames t<sub>B'</sub> and t<sub>A'</sub> are pretty close to what we expected:
*t<sub>B'</sub> frame
**This frame is named <code>000000_-8.133780480.png</code>
**The timer displays 41.86x (expected 42.000)
*t<sub>A'</sub> frame
**This frame is named <code>003332_+3.046812160.png</code>
**The timer displays 53.04x (expected 53.000)
What about t<sub>0'</sub> frame? It is named correctly (<code>002424_+0.000000000.png</code>), but the timer displays 98.88x, which is not what we expected at all. Why? To find the answer, let's have a look at the subsequent frame:


[[File:002425 +0.003355520.png|thumb|center|600px|Fig. 10: Frame following the alarm frame]]


Timer displays 50.00x. This means that, in the middle of the exposure window associated with the alarm frame, the timer refreshed all the 7-segment displays from something like 49.xyz to 50.abc. Thus, all the digits were affected by a change during the acquisition and this is the reason why they do not appear consistently.

In conclusion, the number of stored frames is correct (3333) and the assessment of the aforementioned specific frames was completed successfully because the discrepancies are in the order of hundreds of milliseconds, therefore much smaller than the size of the recording window. These checks were repeated over several recordings and similar results were found. Nevertheless, it is worth mentioning that this analysis does not allow to say that the processing platform behaves like a true real-time system with regard to capturing the high-frame-rate flow of frames and processing the alarm signal. As such, we can not determine the upper bound of alarm detection latency, for example. Rather we can say that the system '''typically''' performs as in the example detailed here. This result is enough to satisfy the PoC's requirements.



(*) The major factor determining the acquisition rate is the [https://en.wikipedia.org/wiki/Shutter_speed exposure time], which was set to 3300us in this case.