RE: [Discuss-gnuradio] Hardware costs

[Mike Turvey]

My comments below...

--Mike

> -----Original Message-----
> From: address@hidden [mailto:discuss-
> address@hidden On Behalf Of Hermann
Gausterer
> Sent: Friday, March 14, 2003 5:53 AM
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Hardware costs
> 
> On Thu, Mar 13, 2003 at 08:15:54PM -0700, Mike wrote:
> > I haven't written any code using the BT848/878 chips, but I did
spend
> > some time going over the spec sheets with the idea of raw analog
> > sampling in mind.
> 
> what do you think about the "Vertical Blanking Interval Data Capture"
> 

This certainly looks like the best way around the UltraLock stuff.  

> -----------------------from the datasheet----------------------
> The Bt879 provides a complete solution for capturing and decoding VBI
> data. The Bt879 can operate in a VBI Line Output Mode, in which the
> VBI data is only captured during select lines. This mode of operation
> enables concurrent capture of VBI lines containing ancillary data and
> normal video image data. In addition, the Bt879 supports a VBI Frame
> Output Mode in which every line in the video frame is treated as if
> it was a VBI line. This mode of operation is designed for use with
> still frame capture/processing applications.
> 
> The captured data stream is continuous and not aligned with HSYNC.
> ----------------------------------------------------------------
> 
> looks like a capture mode for every line of a frame,
> should also work with Y/C :-)
> 
> > There might be some tricks that could be played with, say, the
svideo
> > input by putting the RF signal on the chroma channel and putting the
> > appropriate sync pulses on the luminance channel.
> 
> i think this "could" work, but the problem with the VBI capture will
> be that this is disigned for a "single shot" of one frame, after this
> frame the capture is automaticaly stoped ( in my opinion ), a restart
> will result in gaps with no sampling data

I noticed the comment about its intended use for single frame grabbing,
but I didn't see anything in the spec that said this mode turns itself
off after two fields/ one frame.  You bring up a very good point about
needing to avoid holes in the data.  The VBI frame output mode looks
good because it doesn't appear to depend on the HSYNC signal at all.
The one sentence that really concerned me was: "VDELAY must also be set
to its minimum value of 2."  What this sounds like to me is that two
whole lines worth of video data get lost here.  For video, this is no
problem because it's in the middle of the vertical sync signal, but it
could pose quite a hole for us.  

If this is a hole as it appears to be, and there's no way around it, one
possible option would be to use two cards in a computer and feed them
different sync signals so their "holes" don't overlap, then merge the
samples from each in software (could be messy).

> 
> hermann
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/discuss-gnuradio