I'm looking for a 'reference clock' to validate my own little LTC project (pico-timecode), and this might be just the ticket.
One thing I have been wondering about is the alignment of LTC time to real/world time. Presumably at the "stroke of midnight" alignment is perfect, but with a fractional frame rate the alignment will cycle out of time. Drop frame will mean that the missing count values will bring the alignment back every 10mins.
Your code has a note 'Ensure perfect alignment - frame 0 must start exactly at second boundary', but surely that's not always the case:
https://github.com/HannahRy/ltc_timecode_pi/blob/main/ltc_timecode.c#L192C41-L192C42
Did you do any experimentation with the alignment to a GPS receiver's 1PPS, also noting the GPS-UTC misalignment of (currently) 18s?
BTW I am consider the start of the LTC '00:00:00:00' frame (ie just after the sync pattern) to be reference point, is that correct?
I'm looking for a 'reference clock' to validate my own little LTC project (pico-timecode), and this might be just the ticket.
One thing I have been wondering about is the alignment of LTC time to real/world time. Presumably at the "stroke of midnight" alignment is perfect, but with a fractional frame rate the alignment will cycle out of time. Drop frame will mean that the missing count values will bring the alignment back every 10mins.
Your code has a note 'Ensure perfect alignment - frame 0 must start exactly at second boundary', but surely that's not always the case:
https://github.com/HannahRy/ltc_timecode_pi/blob/main/ltc_timecode.c#L192C41-L192C42
Did you do any experimentation with the alignment to a GPS receiver's 1PPS, also noting the GPS-UTC misalignment of (currently) 18s?
BTW I am consider the start of the LTC '00:00:00:00' frame (ie just after the sync pattern) to be reference point, is that correct?