Re: Motorola DCT2000 - RF Return Path working?

"Captain America" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Greetings everyone:
>
> I have a question on the RF Return on the Motorola DCT2000
> (DCT2244/ABCDEFG) which has both the StarVue II RF Return as well as a
> telco return option. I remember before this monday when the network was
> rebuilt on Comcast (former AT&T/TCI/Viacom) area, the setup menu
> configuration shows the return path as Telco, now it shows up as RF Return
> after the new network is launched. However, on the DCT 2000 Diagnostics
> screen - 09 Upstream Modem shows the following:
>
> STARVUE II DIAGNOSTICS
>
> STATUS : -
> FREQUENCY : 11.552Mhz
> LEVEL : 25
> IPPV : ENABLED
>
> LAST POLL REQ : 48
> 11-25-2003 07:43:11
> LAST POLL ACK : 75
> 11-27-2003 09:26:11
>
> Am I reading this correctly that the RF Return is working, the way my
cable
> box is hooked up is that:
>
> Wall -> Input A on Mitsubitshi HSU-70 SVHS VCR -> Loop-thru -> Motorola
> DCT2000 -> Input B on Mitsubitshi HSU-70 SVHS VCR -> Pioneer PDP4330HD
> Plasma TV Media Receiver?

Be careful.  It is very rare that a VCR will allow an return RF path.  I
suggest splitting the RF input and dedicate one side to the DCT input.  Use
A/V patches to loop in the VCR.

It appears form your data that the RF return is functional.  What I don't
understand is an update timestamp two days after the last request timestamp.
A typo on your part?

An RF level of 25 is very low suggesting you are connected to a low
attenuation tap with a more or less direct connection to that particular
outlet.  There seems to be little return loss to overcome.  It's possible
that 11.552mHz is a very clean spot in the sub-band, but I doubt it.
Because return noise is cumulative it is very common to see return levels at
55 dBmV or higher.  It's possible, if RF return is a new feature of your
plant, that system balancing has yet to be fully fleshed out.


> Since is basically the LAST POLL REQ when the
> headend last polled the box and LAST POLL ACK is when it last responded?

This is correct.  Did you misread the request/acknowledge dates?  They
should match, or the acknowledge will lag behind the request date.

> Also, another question is I noticed the time seems to always be a future
> time/date - is it just using the Greenwhich Mean Time (GMT) instead of
> Pacific Standard Time GMT -8?  Thanks.
>
> John

You don't say what time zone you are in, but GMT is standard operating
procedure.


weithrino