Changes

What about t_0' frame? It is named correctly (<code>002424_+0.000000000.png</code>), but the timer does not display (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. 8: 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, so all the digits were affectedand this is the reason why they do not appear consistently.

In conclusion, the assessment of these frames frames—which was repeated over several recordings—was completed successfully because the discrepancies are in the order of hundreds of milliseconds, therefore much slower smaller than the size of the recording window. Nevertheless, it is also worth mentioning that this analysis does not allow us to say that the processing platform behaves like a true real-time system when it comes to acquiring the high-frame-rate flow of frames coming from the image sensor. Instead, we can draw the conclusion that it '''typically''' performs like as in the example detailed here. And this is enough to satisfy this PoC's requirements.

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