Searching \ for 'A challenging PIC problem...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'A challenging PIC problem...'.

Truncated match.
PICList Thread
'A challenging PIC problem...'
1997\01\13@072618 by Oyvind Kaurstad

flavicon
face
Hi, All!

Before Christmas I asked you all for ideas and suggestions
on a video capture device I was planning to design.

Within the holiday I had a working design. At least almost working.

In short this is how the design works:

An AD converter gets the videosignal (continually)
The AD's output is connected to a 1 Mbit SRAM.
The board has a 10 MHz crystal oscillator. This is fed directly
to the 16C84 and a counter which divides it to 5 MHz.
The 5 MHz signal clocks the AD and two ripple counters that address
the RAM.

There is also a videosyncseparator that is connected to the PIC.
One signal is the vertical sync and the other is the horizontal sync.
(Horizontal sync is connected to RB0)
Horiz sync has a frequency of 15625 Hz and vertical sync is at 50 Hz.

The PIC controls everything via buffers since speed is important.
When the PIC starts a capture it enables the different IC's via buffers, and
this works ok.

The sequence is as follows:

The PIC gets a start signal from the PC (via the parallell port)
Then it waits for a vertical sync pulse (frame start)
When this occurs the RB0 interrupt is enabled.
The ISR then waits a couple of uS and then it enables
sampling and RAM addressing. Then it waits until the line
is finished (approx 50 uS, this is a fixed delay) before
it disables sampling and RAM addressing.

The main program runs in a waiting loop that checks
for the next vertical sync pulse. When this happens
the interrupt is disabled.

Data is then transferred to the PC over the parallell port.

Now I can get to the problem.... (After a rather lengthy explanation..)

The resulting picture is almost ok....
Starting at some random line the next 134 lines is left-adjusted
exactly two pixels. Then the next 134 lines is left-adjusted two pixels,
and so on. The spacing between the errors is always 134 lines...

Two pixels translates into 400 nS (in this case) and this is also
the PIC's instruction cycle time....

It would seem that the time from the horiz sync pulse occurs
to the ISR starts executing is varying. This must be related to
interrupt latency and some relationship between the 15625 Hz signal
and the 2.5 MHz "sampling rate" of the INTF flag in the PIC.

How can I make sure that the interrupt latency is constant throughout
the entire frame?


-Oyvind     spam_OUToyvind.kaurstadTakeThisOuTspamnofac.abb.no

1997\01\13@133528 by Luigi Rizzo

flavicon
face
> Hi, All!
>
> Before Christmas I asked you all for ideas and suggestions
> on a video capture device I was planning to design.
>
> Within the holiday I had a working design. At least almost working.
>
> In short this is how the design works:

... interesting details on a video sampler omitted ...

one thing which comes to mind is why you don't just get the whole field
between two VSYNC, leaving HSYNC processing to the PC (you just have to
make the HSYNC/VSYNC pulses store an "invalid" value into the RAM, e.g.
0 or 255 (or, if you also have a parity bit...). That might simplify
the hardware, and make the design less critical (you would then
just use the PIC to drive the transfer to the PC I guess...) so that
you could use a slower PIC.

As for your drift problem: isn't it just an effect of the tolerance of
the transmitter and your xtal ? you drift 400ns every 134 lines or
8576us, which is approx 45 ppm -- maybe you can put a variable
capacitor in the oscillator and tune it so as to reduce the drift.

In any event, would you like to make schematics & sources available ?
sounds like an interesting project.

       Luigi
-----------------------------+--------------------------------------
Luigi Rizzo                  |  Dip. di Ingegneria dell'Informazione
email: .....luigiKILLspamspam@spam@iet.unipi.it    |  Universita' di Pisa
tel: +39-50-568533           |  via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522           |  http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________

1997\01\14@023825 by Oyvind Kaurstad

flavicon
face
>> Hi, All!
>>
>> Before Christmas I asked you all for ideas and suggestions
>> on a video capture device I was planning to design.
>>
>> Within the holiday I had a working design. At least almost working.
>>
>> In short this is how the design works:

>... interesting details on a video sampler omitted ...

Yes, but I said "in short"..   :-)

>one thing which comes to mind is why you don't just get the whole field
>between two VSYNC, leaving HSYNC processing to the PC (you just have to
>make the HSYNC/VSYNC pulses store an "invalid" value into the RAM, e.g.
>0 or 255 (or, if you also have a parity bit...). That might simplify
>the hardware, and make the design less critical (you would then
>just use the PIC to drive the transfer to the PC I guess...) so that
>you could use a slower PIC.

I thought of this, but I have a possible application for this device which
needs all the speed I can get, and therefore to save space (in RAM) and
time (on the PC and the datatransfer) I went with this solution.
Of course I can make some SW on the PC to correct for the drift but I'd prefer
to get it right from the start.

>As for your drift problem: isn't it just an effect of the tolerance of
>the transmitter and your xtal ? you drift 400ns every 134 lines or
>8576us, which is approx 45 ppm -- maybe you can put a variable
>capacitor in the oscillator and tune it so as to reduce the drift.

That's an interesting thought... I didn't think of that.
However, after some thinking I don't think this is the problem either.
The 10 MHz xtal oscillator is probably (worst case) of the 100 ppm type and
when divided down to 5 MHz I suppose it will be approx 50 ppm.

If I'm not totally mistaken the 100 ppm figure of the oscillator
is the maximum deviation from its frequency. Over time (and temperature)
it might vary up to 100 ppm. In my application it would have to drift
approx 90 ppm in 20 mS, and that's not very likely, I think.

Please correct me if I'm wrong here. I'm not a crystal osc expert....

>In any event, would you like to make schematics & sources available ?
>sounds like an interesting project.

I might do this when the project is finished. I have some SW to make
first, and I don't have much time....

But remember, it does not sample colors (my CCD camera is B/W)
and the resolution is not very high. (approx 270x300)

In my application it's sufficient.


-Oyvind         oyvind.kaurstadspamKILLspamnofac.abb.no

1997\01\14@032820 by Clyde Smith-Stubbs

flavicon
face
Thus spake Oyvind Kaurstad (.....oyvind.kaurstadKILLspamspam.....NOFAC.ABB.NO):

> The 10 MHz xtal oscillator is probably (worst case) of the 100 ppm type and
> when divided down to 5 MHz I suppose it will be approx 50 ppm.

You suppose wrong - think about it. PPM is parts PER million.
Don't forget that an oscillator will have an initial inaccuracy, plus
a time and temperature drift. Instead of using a crystal oscillator,
why not phase lock an oscillator to the horizontal sync pulses? Start
with 10MHz or whatever, divide down to horizontal frequency, phase
compare with the HSYNC, and feed the difference back to the 10MHz
oscillator. There should be no problem making it stable over one frame
period (TV sync should be stable to begin with). That's what TV sets
do (only they phase lock directly at line and frame frequencies).

I didn't read the original posting, so perhaps you're ahead of me, but
talk of a crystal oscillator makes me think not.


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
EraseMEclydespam_OUTspamTakeThisOuThtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\14@034728 by Kalle Pihlajasaari
flavicon
face
Hi,

> >As for your drift problem: isn't it just an effect of the tolerance of
> >the transmitter and your xtal ? you drift 400ns every 134 lines or
> >8576us, which is approx 45 ppm -- maybe you can put a variable
> >capacitor in the oscillator and tune it so as to reduce the drift.
>
> That's an interesting thought... I didn't think of that.
> However, after some thinking I don't think this is the problem either.
> The 10 MHz xtal oscillator is probably (worst case) of the 100 ppm type and
> when divided down to 5 MHz I suppose it will be approx 50 ppm.
>
> If I'm not totally mistaken the 100 ppm figure of the oscillator
> is the maximum deviation from its frequency. Over time (and temperature)
> it might vary up to 100 ppm. In my application it would have to drift
> approx 90 ppm in 20 mS, and that's not very likely, I think.
>
> Please correct me if I'm wrong here. I'm not a crystal osc expert....

The ppm does not change if you divide the frequency.  Just the
absolute time error.  It does sound like the problem and you can check
by putting an extra load capacitor on your Xtal circuit and checking
if you have a different number of lines before the step.

The professional units Phaselock onto the line frequency and sample
at the exact same time each line but this requires you pay Brooktree money
for an integrated video sampling IC (there may be others).

Cheers
--
Kalle Pihlajasaari   kallespamspam_OUTip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

1997\01\14@034736 by Wolfram Liebchen

flavicon
face
At 08:42 14.01.97 +0100, you wrote:
>That's an interesting thought... I didn't think of that.
>However, after some thinking I don't think this is the problem either.
>The 10 MHz xtal oscillator is probably (worst case) of the 100 ppm type and
>when divided down to 5 MHz I suppose it will be approx 50 ppm.

No!
The relative error will remain always the same, regardless of any
multiplicative operation.

regards

Wolfram


+-----------------------------------------------------+
| Wolfram Liebchen                                    |
| Forschungsinstitut fŸr Optik, TŸbingen, Deutschland |
| @spam@liebchenKILLspamspamffo.fgan.de                         |
+-----------------------------------------------------+

1997\01\14@040630 by Oyvind Kaurstad

flavicon
face
>At 08:42 14.01.97 +0100, you wrote:
>>That's an interesting thought... I didn't think of that.
>>However, after some thinking I don't think this is the problem either.
>>The 10 MHz xtal oscillator is probably (worst case) of the 100 ppm type and
>>when divided down to 5 MHz I suppose it will be approx 50 ppm.

>No!
>The relative error will remain always the same, regardless of any
>multiplicative operation.

Ok, as several of you has pointed out, I'm mistaken on this one.

Thanks to those of you who pointed this out for me.


-Oyvind          KILLspamoyvind.kaurstadKILLspamspamnofac.abb.no

1997\01\15@135039 by aab

flavicon
face
In mail.pic you write:

>An AD converter gets the videosignal (continually)
>The AD's output is connected to a 1 Mbit SRAM.
>The board has a 10 MHz crystal oscillator. This is fed directly
>to the 16C84 and a counter which divides it to 5 MHz.
>The 5 MHz signal clocks the AD and two ripple counters that address
>the RAM.

I am suprised that you get a good picture sampling at 5Mhz. I would
think you would have to sample at twice the video bandwidth
(4.5Mhz I believe) to avoid aliasing. I would think especially
the 3.whatever Mhz colorburst would be screwed up.

Is this monochrome (in which case I would think you would
still need a lowpass filter, is there a cap hanging on the
video input?) or am I confused?

1997\01\16@015309 by Oyvind Kaurstad

flavicon
face
>>An AD converter gets the videosignal (continually)
>>The AD's output is connected to a 1 Mbit SRAM.
>>The board has a 10 MHz crystal oscillator. This is fed directly
>>to the 16C84 and a counter which divides it to 5 MHz.
>>The 5 MHz signal clocks the AD and two ripple counters that address
>>the RAM.

>I am suprised that you get a good picture sampling at 5Mhz. I would
>think you would have to sample at twice the video bandwidth
>(4.5Mhz I believe) to avoid aliasing. I would think especially
>the 3.whatever Mhz colorburst would be screwed up.

>Is this monochrome (in which case I would think you would
>still need a lowpass filter, is there a cap hanging on the
>video input?) or am I confused?

First of all the camera I'm using is monochrome, so there is no color
burst. If there had been, it wouldn't have mattered anyway, since
I'm just ignoring this part of the videosignal.

How good the picture is depends on how you define "good"..... :-)
I get a resolution of approx 260x300. (8 bit greyscale).

I'm planning on using the camera in an application where I'm going
to take real close up pictures of some small objects and for this the
resolution is sufficient.

There is some conditioning of the videosignal before it reaches the AD.
Firstly it is terminated into 75 ohm and then it is amplified and level shifted
in a small transistor stage after which it is fed to the AD.
There is no intentional low-pass filtering in here.

-Oyvind          RemoveMEoyvind.kaurstadTakeThisOuTspamnofac.abb.no

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...