FPGA Groups

FPGA Groups (http://www.fpgacentral.com/group/index.php)
-   FPGA (http://www.fpgacentral.com/group/forumdisplay.php?f=14)
-   -   Trying to digitize video with CTT differential input, but webpack wont't cooperate...:-) (http://www.fpgacentral.com/group/showthread.php?t=50746)

Jan Panteltje 11-12-2003 07:06 PM

Trying to digitize video with CTT differential input, but webpack wont't cooperate...:-)
 
OK, now it works, problem with webpack is it so often gives wrong messages,
now it gave a correct on (I was using a pin differently) and I did not
believe a word it said anymore..
So, the 1.4 V pp input video on a CTT pin with 3.3V supply.
A r2r ladder on the comparator reference.
A 8 step successive approximation, that looks at 0 / 1 from the input (video
lower or higher then reference) gives 8 bit video.
Because I only use 1.5 of 3.3V it is now 7 bits.. this can be changed.
First thing was my DVD player, and is in color, even with 50 MHz clock.
But VERY noisy, really bad... plenty of detail RF parts.
But this noise, I think maybe the reference or comparator switch level is
affected by everything else happening in the FPGA?
I test with a second r2r ladder as DA to the output.
Anyways, will try some more later, see if this can be made noise free?
External comparator perhaps?
Will see.
I have biased the CTT at 1.5 V and AC coupled the video in.
JP

Jonathan Bromley 11-12-2003 07:34 PM

Re: Trying to digitize video with CTT differential input, but webpack wont't cooperate...:-)
 
"Jan Panteltje" <[email protected]> wrote in message
news:[email protected]

[...]
> So, the 1.4 V pp input video on a CTT pin with 3.3V supply.
> A r2r ladder on the comparator reference.
> A 8 step successive approximation, that looks at 0 / 1 from the input

(video
> lower or higher then reference) gives 8 bit video.


Cool.

[...]
> But this noise, I think maybe the reference or comparator switch level is
> affected by everything else happening in the FPGA?


Random suggestions follow - you've probably thought about
most of these already, but I'll offer them anyway :-)

Do you *know* where the ground reference is that's used for
the output pads that drive your R2R ladder? have you taken
care to use output pads all in the same bank for that?

Could you consider adding a second R2R and digitizing the
video GROUND, also AC coupled in? Then subtract VideoGnd
from VideoHot, add a suitable offset (presumably you're
getting the offset by sampling the back porch somewhere?).
This *might* help if both R2R DACs are driven from buffers
that share a common ground, i.e. are very nearby on the chip.

I've seen 7-bit SNR with very simply constructed R2R DACs
on the output of FPGAs before now, but that was at quite
low frequencies so the FPGA itself would have been much
quieter. I say this because 7-bit should be plenty to get
reasonably quiet-looking video.

Finally, are you sampling a composite NTSC or PAL video
signal? If so, what's happening about aliasing of the
colour subcarrier? Wouldn't it be a good idea to sample
at an exact multiple of Fsc?

Let us know how you progress - it sounds fun.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: [email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Jan Panteltje 11-13-2003 07:44 PM

Re: Trying to digitize video with CTT differential input, but webpack wont't cooperate...:-)
 
On a sunny day (Wed, 12 Nov 2003 18:34:09 -0000) it happened "Jonathan
Bromley" <[email protected]> wrote in
<[email protected]>:

>Random suggestions follow - you've probably thought about
>most of these already, but I'll offer them anyway :-)

Nice to get some suggestions!

>Do you *know* where the ground reference is that's used for
>the output pads that drive your R2R ladder? have you taken
>care to use output pads all in the same bank for that?

Yes, and today I used a separate bank for the DA output and the comparator,
so I could use TTL like output to the DA (and not have to use the same input
type).
I also tried all other comparator input modes.


>Could you consider adding a second R2R and digitizing the
>video GROUND, also AC coupled in? Then subtract VideoGnd
>from VideoHot, add a suitable offset (presumably you're
>getting the offset by sampling the back porch somewhere?).

Yes, this 'differential' but probably not really needed for what I want it for.

>This *might* help if both R2R DACs are driven from buffers
>that share a common ground, i.e. are very nearby on the chip.

I disabled some other circuits on the board, that improved things.
So, ground loops...

>I've seen 7-bit SNR with very simply constructed R2R DACs
>on the output of FPGAs before now, but that was at quite
>low frequencies so the FPGA itself would have been much
>quieter. I say this because 7-bit should be plenty to get
>reasonably quiet-looking video.


Yep, many, many years ago I was at a research institute in Amsterdam,
You were allowed to spend 10% of the time on your own project / idea...
Good place, was in the front of things.
Anyways I designed a digitizer with 6 bits and digitized my first video there
in 1979.
Big eurocard full of chips, people standing around it ..oooh...
Next day guy walks in, drops data sheet on my desk of 8 bit flash AD chip.
hehe



>Finally, are you sampling a composite NTSC or PAL video
>signal? If so, what's happening about aliasing of the
>colour subcarrier? Wouldn't it be a good idea to sample
>at an exact multiple of Fsc?

Good point, yes the idea is (if this works as expected) to digitize RGB
from a DVD player, then store a line in block RAM in FPGA, read it
out at twice the speed, and stick it in a normal VGA monitor (at 31kHz
50 Hz).
I have a card from Philips that does exactly that (with normal logic),
but it is an old ISA card...., not very good quality either (PCTV1000).
So I want something like that..
Then of cause the mpeg2 coding, but alas, first the digitizer.


>
>Let us know how you progress - it sounds fun.

If this code works the way I want, I will set up a webpage.
Today I played some more, but have things to do, so it will
take time.
Anyways I slowed down the clock, to be better able to see what happend
(100x slower), an it seems something strange happens in that input comparator.
I can see my algo working, but about say 1 in a 100 times or so it gets 100% the
wrong (just any) value.
Simulation is OK, and using extra registers and delays makes no difference.
What DOES make a difference is when I hold my finger on the reference input.
This points to some oscillations perhaps...
Maybe it it is picky about rise times.... these will by definition be slow on the last
steps (just add or subtract a few mV).
Then I tried to drive it with 50 Ohms, but no real difference.
So, more play later.
OK, this test is with a composite PAL signal, and if I was to use composite,
then digitizing at 3 x 4.43 MHz PAL subcarrier would be good (so no moving
interference etc..)
That gives 13.29 MHz, 8 steps = 106.32 MHz clock.
This could be a nice LC oscillator, divider in FPGA, lock to 4.43 source, use varicap to
tune 100 MHz oscillator..
With all that color and TV stuff I am in my element, no problems there.
I will try some more later, perhaps Saturday, sure I will post it here when
it is usable.
Actually I did watch part of a DVD with it... in color too.

You can wonder, why not use the flash AD chips with 4 input mux...
I have one... But this is just for fun.
And 16 resistors are cheaper then that chip?
I did DA in 1979 with 8 resistors, 1k 2k 4k 8k etc..
Ends connected together.


>Jonathan Bromley, Consultant
>
>DOULOS - Developing Design Know-how
>VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
>Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
>Tel: +44 (0)1425 471223 mail: [email protected]
>Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
>The contents of this message may contain personal views which
>are not the views of Doulos Ltd., unless specifically stated.
>
>
>
>



All times are GMT +1. The time now is 04:03 PM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved