I have a very interesting problem which has taken me a while to track down. I run build 7100 (RC) of win7 on my Dell XPS 420 with 2x ATI DCTs and everything is working great, except every now and then when I change the channel on the TV, it somehow kills my cable modem (and takes down my internet connection). I use Comcast Cable in the SF Bay Area, and have a Motorola cable modem which is upstream from my 2 cablecard tuners. When the problem occurs the cable modem loses its connection (of the 4 green lights, only the power light stays on, the others have trouble connecting), and the only way to fix this immediately is to unplug the power from both my DCTs (takes about 10 seconds for internet to be restored).

I'm guessing the cablecard tuners are causing some kind of interference on the cable line, which is throwing the cable modem off. This seems extremely odd since I cant think of any reason why the cablecard tuners should be sending information back up the cable at all.

Of note is that this problem only happens in Win7 RC, and if I boot into Vista I do not have this problem at all. So clearly it must be something the Win7 DCT drivers are doing.

The problem also seems to correct itself given enough time (a couple of hours), and it doesnt happen every day (every 2nd day or so). The trigger does appear to be changing the channel on one of the tuners.

Anyone else experience anything like this? I havent tried any of the other RC builds, I'll probably wait for the RTM before upgrading.

Dieter

This is really odd. What version of the firmware are your DCTs running?

That is really odd.  How do you have everything split/ran coax wise?

Strange in deed. But your DCT are connected back to the headend with OOB a little cablemodem in the tuner and maybe there is a problem between that frequency and what comcast is using for your node for the internet service.

I would suspect that maybe there is something in the Win7 code that is waiting for the SDV which might be trying to send a request to the headend. But this should only happen with a SDV channel so it's unlikely.

It's more likely that there is a problem in the rf coax layout that has gotten just a little low in signal level somewhere. TW told me that you shouldn't amplify either VOIP or Data so if you have phone service as well these should be ahead of any amp from the drop.

I would have comcast check signal level over the entire spectrum. We used to have serious problems with amplifier tilt when it started getting hot here and they used to have to adjust all the pole amps--I think they've solved that problem but it does't mean there might not be a bad pole amp somewhere on the way to you which could have a serious impact on signal level at one end of the spectrum such that the modem is losing it's carrier.

Sounds like an RF problem.

John

There currently is no Reverse Data Channel (RDC) available in the ATI DCT platform, so I highly doubt it is related to upstream data being sent back. You should be able to ascertain the Forward Data Channel (FDC) frequencies being used by the DCTs using the standard Man-Machine Interface (MMI) web pages. The FDC/OOB frequencies are listed on the Tuner tab. The IGD may list the frequency it is using via its advanced parameters web-based management pages. If not, Comcast should know what it is. This would help to understand that variable as part of the troubleshooting process.

I find it interesting that it only appears to be doing it on channel changes. I believe the channel change commands are using UPnP-based commands from within Windows Media Center, so maybe there is a rare correlation between those commands and something on the specific IGD (although they theoretically are on two completely different subnets and Microsoft’s UPnP implementation has a TTL of 1). I wonder what happens if the UPnP features of the IGD are disabled temporarily as part of eliminating another variable….

If you are a member of the Media Center Integrator Alliance (MCIA), you could download the Digital Cable Tuner Diagnostic Tool. This allows you to manually change the channels by issuing an update to each channel’s data. The actual channel change process used by this tool differs slightly from how Windows Media Center sends out the channel change commands (at least it did prior to Windows 7 RC). That may be another way to help isolate the cause of the interaction. At least it would provide a more granular way of communicating with the DCTs as part of the problem isolation process.


Regards,

=D-

Derek R. Flickinger
Interactive Homes, Inc.