Support #545
closedSend TIMECODE without TC_LFR_UPDATE_TIME after SYNCHRONISATION
0%
Description
Voici le scenario effectué dans le test SVS-0012
0- Reset de LFR
1- Synchronisation de LFR sur reception d'une TC_LFR_UPDATE_TIME + time code compatible (6bits of least bytes of coarse time
2- Send during 60s a time code valid
--> Ce que l on observe
14:00:30.509906, TM_LFR_HK, TIME=0x8000000431ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0
14:00:31.461884, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5447c6010000
14:00:31.509805, TM_LFR_HK, TIME=0x8000000531ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0
14:00:32.509786, TM_LFR_HK, TIME=0x5447c601bd68, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIME_TIMECODE_CTR=0
14:00:33.509884, TM_LFR_HK, TIME=0x5447c602ba29, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIME_TIMECODE_CTR=1
Cette derniere ligne correspond à l'envoi de time-code sans la TC_LFR_UPDATE_TIME.
On voit que le soft a positionné HK_LFR_TIME_TIMECODE_CTR à 1 car le temps demandé(CP_RPW_TIME) dans TC_LFR_UPDATE_TIME = 0x5447c6010000
ne correspond pas au time-code = 2.
Il faut donc documenter ce point concernant le compteur HK_LFR_TIME_TIMECODE_CTR. Paul utilise le registre coarse_time_load
qui contient la valeur du CP_RPW_TIME de la TC_LFR_UPDATE_TIME.
Related issues