Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Appendix A
In this appendix, the log indicated in section [[#Real-timeness, frame loss, and alarm detection latency|''Real-timeness, frame loss, and alarm detection latency'']] will be further analyzed to provide more details about the application software.
During normal operation, if the alarm detection functionality is enabled, the application waits indefenitely indefinitely for an alarm to be raised:
<pre class="board-terminal">
[2020-08-10 10:48:53,674][INFO][main_logger.main] SAVING_ALARM_BUFFER -> STREAM_ONLY
</pre>
When this such an event occurs
<pre class="board-terminal">
[2020-08-10 10:49:22,570][DEBUG][main_logger.main] Alarm signal asserted
</pre>
, the application changes state and completes filling the alarm buffer:
<pre class="board-terminal">
[2020-08-10 10:49:22,571][INFO][main_logger.main] WAITING_FOR_ALARM -> FILLING_ALARM_BUFFER
</pre>.
As per system requirements, it takes 3 seconds to fill the buffer after the alarm occurrence (from 10:49:22,570 to 10:49:25,631 , in this example). Right after filling process is completed, a specific thread is resumed to store the buffer on the disk:<pre class="board-terminal">
[2020-08-10 10:49:23,571][DEBUG][main_logger.main] Alarm signal deasserted
[2020-08-10 10:49:25,631][INFO][main_logger.alarmbuffersaverthread] Starting AlarmBufferSaverThread ...
[2020-08-10 10:49:25,631][INFO][main_logger.main] FILLING_ALARM_BUFFER -> SAVING_ALARM_BUFFER
</pre>.
Interestingly, while the PP is saving the recording buffer on the disk, some frames from the image sensor are lost due the non real-time nature of the system. This results in an temporary frame rate drop. As explained previously, this is tolerable.
<pre class="board-terminal">
[2020-08-10 10:49:25,678][ERROR][main_logger.main] Abnormal frame rate (42.6 fps)
