Synchronizing camcorder with telemetry

You might want to consider writing SMPTE timecode to an audio channel. The technology is ancient, robust, and well documented. In particular, it is self-clocking in such a way that it's readable over a wide range of playback speeds.

If you implement the standard frames/seconds/minutes/ hours/ fields, you have 32 user bits left. And that's at 30 times a second. If SMPTE compatability is not an issue you could just use the modulation scheme and get 68+ bits per field.

Hi Lewin,

For more than 30 years already we write IRIG-B time code (a modulated 1kHz carrier) to any audio recorder or the audio track of any video recorer you could imagine. We used to record telemetry data in some NRZ modulation to another audio track. Time tragging data is done during play-back.

Sam

snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) wrote in news: snipped-for-privacy@posting.google.com:

Camcorders I have seen put some time information down onto the tape during recording. Sorry Lewin, I do not know what format this is in but it must be part of the coding scheme. It is, though, visible to the edit suites and video players.

Yes, that's the time code. Most non-consumer analog video equipment will have some type of support for this. Even some consumer VCRs use time code for the display counter instead of mechanical feet or reel revolutions or whatever.

However, I assume it is recorded at some variation on the NTSC (or PAL) field frequency, ie 30 Hz or so. This may well be an inconvenient precision for fleet telemetry, and it requires equipment that supports it.

The audio channel, or one of the "two", if stereo. Record your telemetry data right on the videotape as the sound. This makes synchronization more or less a non-issue, and may lower the cost of your playback equipment.

How about SMPTE?

Bob

_Analog_ camcorders? I know DV bitstreams have a timecode embedded, but I wasn't aware there were any standards for doing similar magic on analog (well, except for SMPTE of course).

I really only have access to the audio in this application - hacking into the video signal path is just way beyond my capabilities (and also it's too much work to do over again for a different camcorder).

I like the reflected LED idea, but rather than flash a single LED, why not arrange a smarter icon scheme. That saves any special decoder. This could be as simple as a kids watch with just the right illumination to merge into the image, or how about a phosphor analog watch illuminated with a BLUE led, to get the watch arms to 'hang in space'. Mirroring would be a challenge....

-jg

SMPTE/EBU Timecoding in longtidunal form is a standard, and if you can put a standard timecode insertion, you can use standard timecode readers at the remote/playback end to extract the timcode often to a serial port or other I/O. Many have the ability to overlay this information onto the video signal being played back to be viewed on a preview monitor.

To hack into the video signal to have an machine extractable time signal you would have to use the version of the timecode Vertically Inserted Time Signal (VITS), which is placed on TV lines in machine readable format during vertical blanking.

Hacking the video signal to place human readable characters is not too difficult, and requires OSD (On Screen Display) chips of which many exist, most notably Philips. This can be controlled by any micro, but may not update fast enough for your needs, or could possibly obscure part of the image you want to view/record/analyse.

Beware of using VITS that copying the signal or even recording it could be problematic as many VCRs/Camcorders do not actually allow recording of information other than syncs during veryical blanking so the time information may be lost. Using longtidunal methods is easier to duplicate and record.

In article , Lewin A.R.W. Edwards writes

Higher priced analog camcorders used to do this before DV came along. The standard for VHS and VHS-C is called VITC. You can sometimes see this at the top of the screen as binary-counting dots if the screen is underscanned because it's transmitted in the vertical blanking period. A lot of professional kit uses VITC as well.

The standard for 8mm and Hi-8 is called RCTC and is recorded in with the video data.

What camcorder are you using?

AFAICS from the references I've read, LTC occupies all the bandwidth of an audio channel with no room for normal audio data, so I don't see how analog camcorders could be storing it on the tape. The counters shown by VCRs count vertical syncs, they don't show an absolute timecode. Only DV camcorders (to my knowledge anyway) put a real timestamp in the data stream.

It involves getting VERY invasive with the camcorder, and it is a non-trivial task to understand these darn disposable appliances (with no schematics, and no datasheets for the major parts inside). Anyways, I don't think this approach would be time well spent for me.

It looks as if I will wind up using the audio channel, with a similar encoding format and bit rate as for the SMPTE code. I'll first write a piece of software that can display the metered data alongside the captured video stream, and then I'll probably also make a little box with an LCD that can plug into the line-out of a VCR so I can play the original tape and watch the data at the same time.

I haven't yet decided if there is anything to be gained by actually implementing SMPTE. Although it gives me enough user bits for the bit-rate I need to embed my actual data, I don't want to use a drop-frame format, I want simple incrementing timecode. Also I'm still trying to wrap my head around a simple algorithm for decoding SMPTE; I can't understand why the sync word is at the _end_ of the packet.

I'm thinking it's easier to decode the signal if I start each packet with, say, 16 bits of alternating 1s and 0s to establish the bit cell, and have a guaranteed silence period between packets that the decoder can use to reset itself. But I need to play with some code and circuits, and determine just what my camcorder will do if I clip off the mic and start feeding in my own signal.

Thanks for all the responses, people. I've got some great directions to follow now!

The only VHS equipment that were semi-useful for SMTPE was the type with two longitudinal audio tracks. Haven't been any consumer grade stuff built like that for 15 years or so. The SMTPE code is quite annoying to listen to and with tracks so close crosstalk was inevitable. The only analog camcorder used to any extent for professional use was Betacam and it had a separate timecode track at the opposite edge of the tape, adjacent to the control track. If the camcorder didn't support this you would add the timecode when the material was transferred to the format used for editing.

Theoretically you could get three audio tracks on "HiFi" stuff if you use the FM audio tracks for sound and the longitudinal track for the time code. Don't think there are any consumer grade camcorders that support anything like that so I suspect you will have to give up audio.

And it's not entirely unlikely that all the signals you need to get at only exists inside some ASIC or such. These are dark time for tinkerers.

Since you won't get it synced with the frame rate anyway I think there may be easier methods. Two FSK applications could perhaps serve as a starting point. The casette interfaces in the home computers of the early eighties gave you up to 1200 bps and they were often quite simple designs. Then you have modem circuits, a decoder for V.23 at

This SMTPE stuff was often implemented using large boards of 74LSxx type devices. My guess is that by having the sync word last they didn't have to use a bit counter for the decoders. Just shift in everything and clock it into the output registers when the sync word is detected.

/Henrik

You mean, a HUD on the window in front of the camera :) That would interfere with the camera's automatic exposure and possibly autofocus too, methinks. The LED solution would be a onetime or periodic event, it wouldn't have to be in focus because just the presence or absence of a color patch at frame [n] would be enough to sync it to a known point in the vehicle log.

The reflector for the lamp that illuminates external objects has a separate window, so it can't spill light onto the back of the camera window. In the LED-flashing scenario the camera would be set back from its window a little, and the LED would be out of direct view, but aimed at the top edge of the window. Nothing else would be spilling light into that area, so unwanted internal reflections wouldn't be a problem.

FM data stripe on the audio track still looks like the way to go, though.

Non drop-frame would be just fine for your app. All it would mean is a very small indicated vs real error of the time displayed.

I've seen timecode readers done on old 8748's so there must be some fairly efficient ways of doing it.

Virtually all timecode readers that are used in pro video applications have to be able to read the code both forward and backward. So from that standpoint, it doesn't really help to put the sync burst on the front.

If you imagine that you're a video editor, the most time-critical piece of info that the reader is going to send you is the frame number, which is the first field of data off the tape. Since a good cameraman gave you at least 10 seconds of preroll before the edit point, you've had plenty of time to sync up so it doesn't matter that the sync is written to the end of the packet.

I'm currently tinkering with an RCA CC1100, which is a small VHS-C camcorder. I bought four of them on eBay for $30 apiece in good working order. It has only an optical viewfinder, which is a bonus because it reduces power consumption.

VHS-C is preferable to me because I think I'll be doing a lot of playback, and I don't want either to invest in an 8mm or DV VCR or wear out the tape transport on the camcorder itself. With VHS-C I can use a $40 Wal-Mart VCR for playback and replace it when it breaks.

I have a couple of DV camcorders as well (JVC models rebadged by RCA, I forget the exact model#) but I'm only going to hack those about if I have to. It would probably be better to use FireWire control on those anyway.

Here, in the UK, we get to see several camcorder shows (my son likes them) and most of the clips feature a time of recording within the picture. This time is probably recorded on the tape by the camera as part of the VITS coding system. I went on a bit of a search for you and these may be helpful in identifying whether or not the Camcorders you have chuck this code out of the video output as well.

I have only had the merest glance over these (nowhere neare a thorough read) but they may help you when you attach and synchronise your scope so that you can see the few interval lines where such stuff is recorded.

The information recorded is Date and Time plus Frame number. I put up a few links in an earlier post that leads to a few interesting articles on the topics. You will probably find that the time code is output via the composite/S-Video ports of the camera and some simple-ish circuitry and a reasonable speed micro might be able to do the decoding of those few lines in each frame and present the time-stamp information to the data stream (assuming that the data is to be synchronised with each video frame. Some probing with a scope should show what the Camcorder is outputting and whether or not the is part of the signal (I don't see why the manufacturers would get rid of it from the video outputs).

Best of luck Lewin.

One issue to be aware of (we all know mr Murphy don't we??) If you are putting the time code on an audio track and editing the video on a PC later, be aware a number of people in the video editing world have discovered slow drift problems between the video and audio (using the audio board to capture the audio). The most common problem has been loss of sync between speech and lip movement and you didn't say how critical your timing was. Just thought I would mention it.

-- Mike "mikey" Fields

Linux users brag on how long their system stays up, Window users assume it's a temporary condition ...

during

Actually, I did mention it briefly - I will accept 2.5 seconds drift over 120 minutes recording time. As you can see, I don't care about getting the data synced with a specific frame.

The info that would be going in this track (assuming I put actual data in there as well as a timestamp) is sampled at all sorts of different rates according to the individual sensor characteristics, and the micro we're talking about here only gets to see an infrequent periodic snapshot of the sampled data anyway.

As long as the data stream can be recovered reliably (which was my major concern), I think timing issues are not really a problem. If the tape speed varies, the data and video will vary at the same time, right? For archival purposes I'll capture in MJPEG with a 22.05kHz uncompressed mono audio track so there shouldn't be playback sync issues on that end either. Empirically, I can tell you that my capture card and playback software (with the aforementioned settings) keeps A-V sync very tight over 120 minutes continuous recording time; certainly close enough to keep lip sync appearing OK.