Has anyone looked into or interested in developing a SMPTE Linear Time Code Analyzer? The protocol is well documented but I have no experience in creating analyzers. Is there a good tutorial on how to create custom analyzers. Looking for an estimate on the development time it would take to create this analyzer.
Here is a sample capture of the timecode data over 10 seconds. (there is a small blip after 10 seconds where the Timecode device was disconnected). I attached the Manchester Analyzer that @timreyes suggested and used a bits/frame of 40 since LTC uses 80 bits/frame but the analyzer doesn’t have that option. I also changed the User Bits on the TimeCode Generator from 00:00:00:00 to FF:FF:FF:FF right aroung the 9.14 second mark on the Logic Capture. Currently working on decoding the hex to see if this analyzer will work as a stepping stone to a LTC analyzer
@Jaboop Unfortunately, I’m not having much success using some of the available HLAs, such as “Text Messages” and “Concatenator.” These look like they were designed to chunk multiple frames together via a time delimiter (i.e. it looks for time gaps between frames to know which ones to chunk).
Your data doesn’t seem to have any gaps, and therefore, it’s likely that modifying the Manchester analyzer itself to include support for 80 bits/frame might be the best approach, or perhaps a brand new HLA that combines frames based on bit count rather than time gaps between frames.
I’ll get some input from the software team here to see if they have additional thoughts or suggestion and will let you know if so.
@Jaboop do you know why there is a gap here? It’s fairly early in the capture, at about 479ms in.
I think it’s because this gap is either too long or too short. The pulses in this data should all be either 250 us or 500 us, and this one is 655 us, which is much too long. I’m pretty sure that’s why this is resetting here.
Writing a new HLA which joins 40 bit frames into 80 bit frames and then decodes the included fields should be pretty easy, as long as the Manchester decoder is aligned correctly and doesn’t have any errors like this one.
If the data isn’t perfect, or it does get misaligned, this can be corrected in the HLA by re-synchronizing to the sync word, by decoding one bit at a time instead of one 40 or 80 bit word at a time, but that makes the HLA more complicated.
A quick test suggests the data is OK though. I switched the data table to binary and searched for the sync word, and as you can see, it shows up quite well:
@markgarrison Yes I noticed that in my analysis too and seems to be consistent on power on. At about ~.45-.5 seconds the device resets creating a bit shift of 1. On the reset it also is resetting the Frames, Seconds, Minutes and Hours portions of the TimeCode. To account for this I have been searching for the sync word in binary and starting analysis after the reset.
@timreyes Thank you sounds good. And yeah as @markgarrison also noted not only is there no gaps in this protocol there is also a reset after power on that misaligns the data on the manchester analyzer when trying to group things in HEX. Looking at the binary bits you can see the reset happening at ~.45-.5s into the capture. Not sure the best approach on handling this in an analyzer but I would guess that some method of syncing on the sync word will be necessary since other TimeCode generator probably also have this reset (after power on) and/or assuming a capture is started after power on the sync word will need to be found to align the analyzer anyway.