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 Link for the Protocol:
Thanks in Advance!
@Jaboop Thanks for writing in! I’m not too familiar with Linear timecode, but I took a look at the link you shared and noticed that it mentions the following:
The bits are encoded using the biphase mark code (also known as FM )
We do have a built-in Manchester analyzer as per the below image, which includes the ability to decode in Bi-Phase Mark Code mode.
Could that potentially work out for you as an “out-of-the-box” solution?
Ooh, I’ll bet this would make a good python HLA!
@Jaboop, do you have a sample capture of this data? If so, I encourage you to post it!
We could recommend a python HLA that uses the output of our Manchester analyzer. You can learn more about creating HLAs here:
Our tutorial is fairly limited, but I suggest looking at our example HLAs.
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
TimeCodewUserBitsChange.sal (77.8 KB)
Thanks for sending that over! That’s great to hear the manchester analyzer puts us at a great starting point. It certainly sounds like an HLA would be the best solution.
Or, if 80 bits/frame is all you need, then it might be fairly straightforward to modify the Manchester source as well to include it.
We’ll look into some existing HLAs to see if any of them might do the job right out of the box. I’ll let you know if we find anything!
@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:
And at the end of the capture, you can see the data has changed:
There might be an offset by 1 in there though, the sync pattern is expected to be in bits [79:64], but instead they are 1 bit lower.
@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.
