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: 123456[7]89 ]


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

Date Posted: 11:23:38 03/07/02 Thu
Author: Jain
Subject: Re: Rev7t1a
In reply to: Jain 's message, "Re: Rev7t1a" on 11:05:06 03/07/02 Thu

And what's the difference between Clamp and Normal signals from PIC?
Why?
J

>Not related to burst: I heve the 3 chip conected to a
>cable box. The output goes to the Video input of the
>TV. The RF imput of the TV is fed with the normal
>signal from cable (there is a splitter); so, I can
>switch between 3 chip and cable on the same channel
>(unscrambled). I noticed there is a shift of the
>immage (the one comming from 3 chip is half an inch or
>something like that -- would depend on TV screen size
>-- to the left of the real one). When I had a scope, I
>saw that there is a difference between the way the
>code treats scrambled and unscrambled channels. Wasn't
>it possible to make it act in the same way? And
>comming back to my old question, why unscrambled
>channels were not let to pass, as there it was no need
>to do something with them? Code too much complicated?
>J
>Questions most for Tom, seems he (and Phil) knows
>better at this time the NTSC code... (where from
>everything originated)
>
>
>
>>Still fighting at the hardware level: is Rev7t1a
>>trying to decode any kind of information about burst
>>durring VBI? Who can tell me?
>>There is no burst inversion here, but the picture is
>>greenish, sometimes loosing synchronization, colours
>>not natural. I presume the original signal has that
>>burst tampered with, but the cable company, not having
>>appropriate decoders in the field, is decoding it and
>>sending it normal... still, the information is there,
>>and if Rev7t1a is trying to decode it...
>>J

[ 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.