VoyForums
[ Show ]
Support VoyForums
[ Shrink ]
VoyForums Announcement: Programming and providing support for this service has been a labor of love since 1997. We are one of the few services online who values our users' privacy, and have never sold your information. We have even fought hard to defend your privacy in legal cases; however, we've done it with almost no financial support -- paying out of pocket to continue providing the service. Due to the issues imposed on us by advertisers, we also stopped hosting most ads on the forums many years ago. We hope you appreciate our efforts.

Show your support by donating any amount. (Note: We are still technically a for-profit company, so your contribution is not tax-deductible.) PayPal Acct: Feedback:

Donate to VoyForums (PayPal):

[ Login ] [ Contact Forum Admin ] [ Main index ] [ Post a new message ] [ Search | Check update time | Archives: 1, 2, 3, 4, 5, 6, [7], 8, 9 ]

[ Next Thread | Previous Thread | Next Message | Previous Message ]

Date Posted: 06:29:47 03/10/02 Sun
Author: Potter
Subject: Re: Potter, Why 64?
In reply to: Tom 's message, "Potter, Why 64?" on 13:19:33 03/09/02 Sat

I probably explained that one badly
In my case the blanking interval is normal so the tailend of the hsyncs produce a ped (rising) on the first 23 lines per frame. If the rest of the frame is normal, every hsync produces a ped at its tailend so the total for PAL should be about 312 per frame. If the visible lines have inverted hsync the tailend of the hsync produces a ned so the total peds per frame should only be about 23 (in my case). As I use the end of the hsync for locking, it was a simple matter to determine whether it was a ped or a ned and count the peds only even though the code will lock to either polarity - and that was the problem that needed a solution ie a way to kick the decoder out of lock when a normal signal was going through.
Why 64? to prevent noisy signals causing instability and I only need to check 1 bit of the counter (bit 5). Originally used 32 (bit 4) but had an occasional glitch.
This feature is in the code on Sakman's page

>>I was able to detect normal video by counting the
>>number of peds/frame preceding the burst IE if more
>>than 64 (to rule out random noise/gremlins etc) then
>
>I am curious as to why there are more than 64 PEDs for
>a normal signal but not for a scrambled signal. How
>big of a window are you looking for PEDs in? Are you
>looking from the start of the line until the burst?
>There is a PED at the end of the sync just before the
>burst on scrambled and unscrambled signals and a PED
>at the start of the HBI in scrambled signals only.
>Either one should give over 500 PEDs per frame.
>Please send me the code so I can see what you are
>doing, Thanks
>
>>Also had much trouble with the very long ped at the
>>start of the sync (caused by the excessively tall
>>leading edge) and all was fixed by locking to the ned
>>at the end of the sync as its duration was more
>>suitable.
>>
>>>If your picture is shifted to the left then the
>>>scrambled sync from your system is delayed or the
>>>3chip is locking to the wrong edge. In a scrambled
>>>signal, there is a PED at the start of the HBI (where
>>>the signal becomes raised), a NED at the start of the
>>>sync, a PED at the end of the sync, and a NED at the
>>>end of the HBI. Rev7t1a locks to the NED at the
>start
>>>of the sync. Some PAL versions lock to the PED at
>the
>>>end of the sync. It is possible that the 3chip is
>>>locking to the NED at the end of the HBI instead of
>>>the NED at the start of the sync. If the lock check
>>>in MakeVBI has been disabled or modified, then it can
>>>lock on any repeating NED.
>>>
>>>The clamp signal from the PIC was used in old 3chips
>>>to provide voltage to the clamp diodes during the
>>>video, both inverted and normal. The normal signal
>>>from the PIC is not on during inverted video.
>>>
>>>The 3chip has never detected normal video because
>>>nobody thought it was important enough to incorporate
>>>into the design and write code for it. It should be
>>>fairly simple and I believe jpb did it but nobody
>>>expressed any interest at the time.

[ Next Thread | Previous Thread | Next Message | Previous Message ]

Replies:

[ Contact Forum Admin ]

Forum timezone: GMT-8
VF Version: 3.00b, ConfDB:
Before posting please read our privacy policy.
VoyForums(tm) is a Free Service from Voyager Info-Systems.
Copyright © 1998-2019 Voyager Info-Systems. All Rights Reserved.