[vdr] Re: Finding channels

[Steve Brown <steve@deltabbs.org>]

Gavin Hamill wrote:
> Yes I know that one... timeout on PAT .. then timeout on SDP .. yeh...

Ah yes, that'd be the errors I was trying to remember, ta. Dvbtune was 
what I was using to scan blocks of frequencies with my DVB-C card. I 
found maybe 5 likely frequencies that the frontend locked onto, but all 
produced the timeouts.

I've no idea what a PAT or SDP is though?

> From my own experiences, the QAM and CR settings don't matter for simply 
> getting a lock onto a frequency...

Aha, right. So does the fact the frontend and a few other bits and 
pieces lock, imply that it is tuned to a digital channel and that it's 
the QAM setting or Symbol Rate that's wrong?

> In a cable system, I would expect QAM128 or even QAM256 to be in use, since 
> the signal strength is almost guaranteed to be perfect...

Heh, not judging by the state of the analogue service ;-) What would be 
real handy would be for an NTL engineer to pop up about now and say 'we 
use x y and z'.... <pause>.... bugger.

> The Beeb dropped from QAM64 to QAM16 which dramatically reduces the number of 

That's my other project :-)

I'm on the fringe of both the Hannington (Basingstoke) and Crystal 
Palace (London) terrestrial transmitters. Strangely, the DTV postcode 
checker says that CP is the one for me, despite the fact the entire area 
prefers Hannington for analogue service. According to a technical report 
I came across, it's due to radiation pattern making the analogue signals 
too large compared with the digital ones - presumably the AGC int he 
receiver drops the digital signal to the nosie floor.

-S



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.