[time-nuts] GPS->audio interface

[Magnus Danielson]

Lux, James P skrev:
> 
> 
> On 5/10/09 11:21 AM, "Magnus Danielson" <magnus at rubidium.dyndns.org> wrote:
> 
>> Lux, James P skrev:
>>> I'm looking for a way to take GPS time and generate a signal that can
>>> be recorded on the audio track of a video recording to time stamp it.
>>> This is so it can be aligned with other data that's collected with GPS
>>> based time.  It needs to be portable/small (i.e. Something you could
>>> attach to a small camcorder, or such).
>> Traditionally SMPTE 12M LTC is being used for this purpose. For most
>> cases it is only known as LTC but SMPTE/EBU time code is among other
>> names fairly common name.
>>
> Yes.. But most consumer recorders (e.g. The cheap AIPtek) don't do timecode
> (or genlock, or other useful stuff)..

They should be hackable thought.

> So what they're really looking for is someway to time align after the fact.

This does not prohibit you from just recording the LTC onto the 
soundtrack anyway.

>> I actually have a GPS with IRIG-B output in about the same size of a
>> Thunderbolt.
> 
> Is that an off the shelf, not hideously expensive, widget?  (There are other
> applications...)

I bought one of those Brandywine GPS4 devices as announced available on 
the list not too long ago. Not hideously expensive IMHO.

>>> Another alternate is if something like a iPhone records accurate time
>>> with the video stream. (another of the data sources is an iPhone
>>> recording something else)
>>>
>>> I think the basic requirement is accuracy to some few milliseconds
>>> (e.g. Frame rate of the video)..
>> SMPTE LTC encodes the frame numbers.
>>
>>> (It's for a high school science project, where they want to record
>>> various things, and line them up.. I think they could deal with
>>> looking at the timestamps over many frames to do interpolation)
>> SMPTE LTC should be preferred in that case, as it is something that
>> editing equipment understands.
> 
> I don't think "real" editing gear is in the cards.  Probably more like
> iMovie or something on a PC.

There should be editing gear that chews LTC over audio-interface. We did 
frame-grabbing tricks with a cheap video-recorder, LTC on audio track 
and an SGI Indy back in the days... and a remote hacked with CMOS 
switches steered by a DTMF decoder so the Indy played DTMF tone-pairs on 
the port, real-time decoded LTC and frame-grabbed 10 frames at the time, 
rewinded, played again etc. Some of the cheap/free programmes would be 
able to decode LTC and tag the pictures accordingly.

> As a model for what they're trying to do, say you were going to measure the
> acceleration due to gravity by videotaping a falling object against a scale
> in the background. Except that the motion is more complex.. Maybe imagine
> putting an accelerometer in the "payload" of a trebuchet... And you want to
> time align the position of the trebuchet components (from the video) with
> the forces on the payload. That's not what they're doing, but now that I
> describe it, that WOULD be a cool science project.  And get away from the
> "here, I built a trebuchet and launched a projectile X meters" which is kind
> of tired.  (get one of those analog devices 3 axis accelerometers, hook it
> to a suitable datalogger..)

In that case you want the line-frequency locked or traceable by other 
means. You have more use for the frequency aspect than time-notation 
actually, which is more handy for a matter logging which event. Still, 
LTC should be easier to get locked to the phase attached to the frames, 
as the infrastructure is expected to be there for some apps, but the 
IRIG-B support is not expected to be there.

If you do not hack the camera to accept a reference signal (hacking the 
crystal oscillator may be all you need to do), after the fact frequency 
calibration can be done with either IRIG-B, LTC or just a 1 kHz sine.

>>> Anyway, cheap and cheerful consumer gear is what is sought. (so no
>>> suggestions of synthesizing SMPTE from the output of my Z3801 and
>>> feeding it to a RED camera.. We're talking AIPtek and iPhone here..)
>> Locking the camera with a black burst GENLOCK signal with VITC does need
>> to be done, but the LTC may very well be practical for the purpose.
>>
>> BTW. Cameras lacking GENLOCK is highly annoying, especially when they
>> have el cheapo crystals... el cheapo crystals is fine, as long as they
>> lock up to a GENLOCK when needed.
> 
> 
> That pretty well describes just about everything they'll have available.

Well, the two initial strategies is to either hack the cameras and 
replace the XO with a VCXO which locks to a 10 Mhz. Usually it is 27 MHz 
  and relationship to 10 MHz is fairly trivial. After the fact 
synchronisation using a 1 kHz signal (such as given by TADD-2, tvb 
PIC-div or something) into the audio signal would also do, if only the 
audio sample rate and the video rate is locked in the el cheapo camera, 
which one can hope for at least.

Cheers,
Magnus