[linux-dvb] uk-Rowridge initial frequency file that works for both Nova-T and WT-220U?

Kevin Page linux-dvb-list at krp.org.uk
Sun Sep 23 03:10:45 CEST 2007


Good evening,

My DVB-T reception is from the Rowridge transmitter in Southern England,
and I'd like to use both my (old) Hauppauge Nova-T PCI and newer Freecom
USB stick (identified as a WideView WT-220U).

The existing uk-Rowridge initial tuning file looks like this:
# Rowridge, Isle of Wight
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 489833333 8MHz 3/4 NONE QAM16 2k 1/32 NONE

This works - and has always worked - with my Nova-T and scan. However it
doesn't work with the WT-220U, which fails to tune.

After trawling the list archives, I came to the conclusion that the
WT-220U didn't like the initial frequency supplied. I also consulted the
official frequencies at:
http://www.ofcom.org.uk/static/reception_advice/digital_trans_guide/show_transmitter.asp-siteID=81.html

combined with:
http://www.digitalspy.co.uk/terrestrial/tuning/

To begin, I misread the OFCOM page (I didn't notice the offsets
footnote), so used an initial frequency 490000000 rather than the
current value of 489833333.

But a helpful mistake! This seems to work fine with the WT-220U.
BUT the Nova-T now won't tune with it. It doesn't pick up any channels.

If I create an initial scan file with all 6 mux frequencies:
- using the centre frequency - but without the 167kHz offsets from the
OFCOM page - the WT-220U finds all the channels, but the Nova-T finds
none (the WT-220U actually "finds" duplicates for 3 of the muxes).

- if all the offsets are added and subtracted, the WT-220U fails to find
any channels, while the Nova-T finds them all.

- if I create a compromise file with half the mux frequencies with
offsets added (see attached) both the WT-220U and the Nova-T find all
the channels.

While this compromise file works, it seems like a bit of a fudge? Also,
the WT-220U continues trying other channels (which don't tune) after
trying the specified frequencies - why does this happen?

I also note that the frequencies in channel.conf generated are
different: 490000000 for the WT220U, 489833330 for the Nova-T; 546000000
and 545833330; 514000000 and 513833330. These are, of course, the
frequencies for the muxes I didn't apply the offset to.

Further queries: I'm not really sure what all the fields in the initial
scan file are for, or how one should ascertain their values?

Should the frequencies include offsets or not? Is one of the two drivers
broken, or is the inconsistency considered acceptable?

(w_scan with the WT-220U reports the published frequencies without
offsets and AUTO for the 3rd field onwards, but won't report anything
with the Nova-T)

As far as I can see, all values after the frequency are dependent on
your national implementation of DVB-T, and won't vary by transmitter?

I know what Forward Error Correction is at a basic level, though I can't
see why there's a "hi" and "lo" value? In the UK, this would seem to be
tied into the modulation (16QAM and 64QAM) along with the guard
interval?

In my attached version should there be a second FEC value? (and if so,
what?)

Any insights appreciated,

Regards,

kev.
-------------- next part --------------
# Rowridge, Isle of Wight
#
# References:
# http://www.ofcom.org.uk/static/reception_advice/digital_trans_guide/show_transmitter.asp-siteID=81.html
# http://www.digitalspy.co.uk/terrestrial/tuning/
#
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
# Mux 1
T 490000000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
# Mux 2
T 530167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
# Mux A
T 546000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
# Mux B
T 562167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
# Mux C
T 514000000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
# Mux D
T 570167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE


More information about the linux-dvb mailing list