/Exactly/ what frequency would you expect to find a given mux on?
Michael Rozdoba
transmitter claims to be broadcasting on...
FWIW, I receive from Pontop Pike, so expected:
1 on C48 (690MHz)
2 on C55 (746MHz)
A on C59 (778MHz)
B on C62 (802MHz)
C on C65 (826MHz)
D on C53 (730MHz)
As listed at http://www.ukfree.tv/txdetail.php?a=NZ148526 & many other
sites.
To cut a long boring story slightly shorter, I've just bought a DVB-T
card for my PC &, disliking the Pinnacle software, have been trying to
set it up with the recommended DVBViewer software - as mentioned in this
group several times.
After some teething problems DVBViewer recognised the hardware & found
muxes 1 & D, but steadfastly refused to find 2, A, B or C. I figured it
wasn't the aerial as that also feeds two stbs with no problems. It
couldn't be down to the Pinnacle PCTV DVB-T PCI (250i) hardware, as the
Pinnacle software managed to find all muxes.
My best guess was some driver oddity which the native software works
around or fits in with (probably as both will make the same broken
assumptions), however I found a post on the DVBViewer forums
(http://www.dvbviewer.info/forum/index.php?showtopic=13945) which
described missing muxes when using a Technisat Airstar Telestick T1. The
OP found a solution. They noticed some of their other DVB-T hardware
reported muxes at the expected frequency plus a small offset of 166KHz.
Applying that knowledge, DVBViewer managed to locate the signals for the OP.
This seems to be at the root of my Pinnacle/DVBViewer problem too.
After a couple of hours trying out many possible frequency values around
the expected quoted broadcast frequencies, I find there's a range of
values near each target frequency for which I can get a signal. Outside
the range, which in 4 out of 6 cases excludes the target itself, neither
Transedit nor DVBViewer can find a signal.
Here are the detailed results:
Mux Broadcast Actual range over which a signal
freq can be found (all Freq in KHz)
1 690000 689851 - 690150
2 746000 746051 - 746300
A 778000 778051 - 778300
B 802000 802051 - 802300
C 826000 826051 - 826300
D 730000 729701 - 730000
Here's the .ini I ended up using to find all the muxes:
[SATTYPE]
1=5000
2=UK-PontopPike
[DVB]
0=6
1=690000,8
2=746176,8
3=778176,8
4=802176,8
5=826176,8
6=729850,8
Obviously this is only of use with PontopPike, but the range of values
over which a signal is found & their distance from the quoted broadcast
frequencies might help others solve this same problem for themselves.
Anyway, it'd be good to know what the heck's going on here. Anyone got a
clue?
Are the actual broadcast frequencies off slightly or is it more a matter
that some of the hardware is at fault, or maybe the drivers or some
weird combo?
Any insight would be much appreciated.
--
Michael
m r o z a t u k g a t e w a y d o t n e t
Dave Pickles
{snip}
> Are the actual broadcast frequencies off slightly or is it more a matter
> that some of the hardware is at fault, or maybe the drivers or some
> weird combo?
>
> Any insight would be much appreciated.
The transmitters do indeed broadcast at the nominal centre frequency of
the channel but with an offset of 0 or +/- 166 KHz. Normally I suspect
this would be within the AFC range of the receiver.
A full set of 'real' frequencies are available from
http://www.ofcom.org.uk/static/reception_advice/index.asp.html
--
Dave
Ron Lowe
"Michael Rozdoba" <mr...@nowhere.invalid> wrote in message
news:45dca3eb$0$2443$db0f...@news.zen.co.uk...
Are you aware of frequency offsets?
MS has broken this with it's driver spec.
Read this:
http://dayc.vispa.com/reviews/msbda.htm
( it's 404ing at the moment, the home page is still live, try later. It
explains the problem.)
--
Ron
Michael Rozdoba
> Michael Rozdoba wrote:
>
> {snip}
>> Are the actual broadcast frequencies off slightly or is it more a
>> matter that some of the hardware is at fault, or maybe the drivers
>> or some weird combo?
>>
>> Any insight would be much appreciated.
>
> The transmitters do indeed broadcast at the nominal centre frequency
> of the channel but with an offset of 0 or +/- 166 KHz.
Ok, thanks.
> Normally I suspect this would be within the AFC range of the
> receiver.
AFC? Ah: http://hem.passagen.se/communication/afc.html
That makes sense.
> A full set of 'real' frequencies are available from
> http://www.ofcom.org.uk/static/reception_advice/index.asp.html
Cheers.
In this case, does it seem likely the problem is a slightly narrower AFC
range than most DVB-T receivers, or that the driver/clients ought to be
taking into account these possible offsets? I wonder how I'd find out.
Brian Gregory [UK]
> In this case, does it seem likely the problem is a slightly narrower AFC
> range than most DVB-T receivers, or that the driver/clients ought to be
> taking into account these possible offsets? I wonder how I'd find out.
DVB-T tuners would probably need to try each of the three frequencies and
see which one is being used.
--
Brian Gregory. (In the UK)
n...@bgdsv.co.uk
To email me remove the letter vee.
Michael Rozdoba
> Are you aware of frequency offsets?
I wasn't.
> MS has broken this with it's driver spec.
Interesting.
> Read this:
> http://dayc.vispa.com/reviews/msbda.htm
>
> ( it's 404ing at the moment, the home page is still live, try later.
I'll try again later, though even Google doesn't have it cached:
http://www.google.co.uk/search?hl=en&q=site%3Adayc.vispa.com+bda&btnG=Search&meta=
> It explains the problem.)
Don't suppose you have another source?
Thanks for the info.
Bill Wright
You can tell what offset it will be as follows.
If the mux is adjacent to a higher analogue channel or adjacent to a higher
mux that's adjacent to a higher analogue channel the offset will be minus.
If the mux is adjacent to a lower analogue channel or adjacent to a lower
mux that's adjacent to a lower analogue channel the offset will be plus.
You just set the offset to move away from the analogue channel.
It's always 166kHz, either + or -.
Bill
Mallory
analogue channels?
for example:
Oxford Tx
Oxford Channel 6 Ch 47
Mux C Ch 48
Channel 5 Ch 49
or for Hannington which has two muxes sandwiched between two analogue
channels, this happens twice incidentally
Ch 39 BBC1
Ch 40 Mux A
Ch41 Mux D
Ch 42 ITV
Ch 43 Mux 2
Ch 44 Mux C
Ch45 BBC2
Stephen.
"Bill Wright" <insertmybu...@f2s.com> wrote in message
news:erioh1$u92$1...@news.freedom2surf.net...
Bill Wright
"Mallory" <i.wan...@send.me.spam.com> wrote in message
news:45dcf28f$0$8713$ed26...@ptn-nntp-reader02.plus.net...
> what about the case where a Mux or two is literally sandwiched between two
> analogue channels?
>
> for example:
>
> Oxford Tx
>
> Oxford Channel 6 Ch 47
> Mux C Ch 48
> Channel 5 Ch 49
>
> or for Hannington which has two muxes sandwiched between two analogue
> channels, this happens twice incidentally
>
> Ch 39 BBC1
> Ch 40 Mux A
> Ch41 Mux D
> Ch 42 ITV
> Ch 43 Mux 2
> Ch 44 Mux C
> Ch45 BBC2
>
> Stephen.
Dunno.
Bill
Mark Carver
> what about the case where a Mux or two is literally sandwiched between two
> analogue channels?
>
> for example:
>
> Oxford Tx
>
> Oxford Channel 6 Ch 47
> Mux C Ch 48
> Channel 5 Ch 49
>
> or for Hannington which has two muxes sandwiched between two analogue
> channels, this happens twice incidentally
>
> Ch 39 BBC1
> Ch 40 Mux A
> Ch41 Mux D
> Ch 42 ITV
> Ch 43 Mux 2
> Ch 44 Mux C
> Ch45 BBC2
>
In Hannington's case they are all +167 kHz, for Oxford Ch48 0
http://www.ofcom.org.uk/static/reception_advice/dtt_pocket_guide_2-8.pdf
Bill Wright
"Mark Carver" <markc...@onetel.com> wrote in message
news:1172131073.5...@m58g2000cwm.googlegroups.com...
apply positive offset because of the analogue channel's nicam carrier. But I
dimly remember a BBC paper that described modifications to a standard
analogue channel so that a mux could be tucked in close on the next channel
down. Nevertheless I'm surprised to hear that they actually have positive
offset on such muxes, but you live and learn.
Bill
Mark Carver
> > In Hannington's case they are all +167 kHz, for Oxford Ch48 0
>
> >http://www.ofcom.org.uk/static/reception_advice/dtt_pocket_guide_2-8.pdf
>
> I think they have no option if the mux is on the adjacent higher channel to
> apply positive offset because of the analogue channel's nicam carrier. But I
> dimly remember a BBC paper that described modifications to a standard
> analogue channel so that a mux could be tucked in close on the next channel
> down. Nevertheless I'm surprised to hear that they actually have positive
> offset on such muxes, but you live and learn.
I must say, I have experienced difficulties with Hannington on some
receivers trying to tune in Mux C (UHF Ch 44). Perhaps having it
crunching up against BBC 2 (Ch 45) because of a +ve offset isn't
helping ?
Bill Wright
I'm really quite surprised that the arrangement is used. I'd like to see it
on an analyser. Anyone do a screenshot down there in Hanningtonland? I bet
you can't get a cigarette paper in the gap.
Bill
Ron Lowe
Yes, that's a shame. It was a detailled technical article.
I didn't keep a copy.
The gist of it was:
Sensible software scans by asking the card to check the main channel number
only.
It's left up to the drivers / card to check the offset frequencies if the
main channel comes up empty.
The offsets are handled silently by the card and drivers, the application
software does not need to be aware of offsets.
This way, the software 'just works', and the muxes are tuned in even if they
are on offsets.
Then MS made changes to media centre:
It scanned not just the main channels, but the offsets too.
The logic *should* have been scan main channel first, then try offsets ONLY
if it came up blank. But the broken logic used was: scan -ve offset, scan
main channel, scan + offset .
This resulted in channel duplication: it would find the mux on the offset,
and again on the main channel because the card auto-found the offset too.
This caused slow scanning and duplicate channels.
Basically, to work around this duplicate channel problem, the drivers and
cards have to disable hardware offset auto-lock, and allow media centre to
do all the work ( slowly ).
Then, with Vista, they changed it again.
Even if we cripple the hardware offset discovery and allow media centre to
make it's broken-logic scan, we run into a new problem. Media Centre now
uses frequency information encapsulated in the transmission, not the
scan-discovered frequencies. And this is often wrong, particularly from
repeater transmiters, where the embedded frequency info often relates to the
main transmitter, not the relay. So Media Center ( brokenly ) initially
finds the muxes on the scan, but then fails to tune them in because it's
over-riding the scan-discovered frequency data with the possibly incorrect
frequency data broadcast in the mux.
Or something like that.
--
Ron
Michael Rozdoba
> "Michael Rozdoba" <mr...@nowhere.invalid> wrote in message
> news:45dcd064$0$2462$db0f...@news.zen.co.uk...
>> In this case, does it seem likely the problem is a slightly narrower AFC
>> range than most DVB-T receivers, or that the driver/clients ought to be
>> taking into account these possible offsets? I wonder how I'd find out.
>
> DVB-T tuners would probably need to try each of the three frequencies and
> see which one is being used.
That would make it a function of the client software then, rather than
the drivers. So in this case perhaps DVBViewer is lacking.
Anyone know if DVB-T in Europe commonly uses such frequency offsets or
if it's specific to the UK?
Most DVBViewer users seem to receive via satellite; of the DVB-T users I
imagine most are in/around Germany as that seems to be the primary
language on the forums.
Michael Rozdoba
Thanks for the explanation. I imagined it was something like that, but
was only guessing.
Michael Rozdoba
> "Michael Rozdoba" <mr...@nowhere.invalid> wrote in message
> news:45dcd210$0$2453$db0f...@news.zen.co.uk...
>> Ron Lowe wrote:
>>
>>> Are you aware of frequency offsets?
>>
>> I wasn't.
>>
>>> MS has broken this with it's driver spec.
>>
>> Interesting.
>>
>>> Read this:
>>> http://dayc.vispa.com/reviews/msbda.htm
Still 404.
>>> ( it's 404ing at the moment, the home page is still live, try later.
>>
>> I'll try again later, though even Google doesn't have it cached:
>> http://www.google.co.uk/search?hl=en&q=site%3Adayc.vispa.com+bda&btnG=Search&meta=
>>
>>
>>> It explains the problem.)
>>
>> Don't suppose you have another source?
>>
>> Thanks for the info.
>
> Yes, that's a shame. It was a detailled technical article.
> I didn't keep a copy.
Shame indeed.
Don't suppose you can recall any key phrases word for word which might
help identify it? Google might be able to locate mirrors.
> The gist of it was:
>
> Sensible software scans by asking the card to check the main channel
> number only.
> It's left up to the drivers / card to check the offset frequencies if
> the main channel comes up empty.
> The offsets are handled silently by the card and drivers, the
> application software does not need to be aware of offsets.
> This way, the software 'just works', and the muxes are tuned in even if
> they are on offsets.
Aha, that's what I've been trying to find out. Cheers :)
> Then MS made changes to media centre:
> It scanned not just the main channels, but the offsets too.
Sounds right for m$ - don't trust anyone else to do their job; make
things worse by trying to work around possible third party failures & in
so doing, badly of course, worsen the situation.
> The logic *should* have been scan main channel first, then try offsets
> ONLY if it came up blank. But the broken logic used was: scan -ve
> offset, scan main channel, scan + offset .
Ouch.
I wonder who does their systems analysis. Maybe a manager, since they
seem to be clueless. No one in their right mind would take an approach
other than the one you describe as the logical choice. It's not exactly
rocket science :/
> This resulted in channel duplication: it would find the mux on the
> offset, and again on the main channel because the card auto-found the
> offset too. This caused slow scanning and duplicate channels.
Indeed.
> Basically, to work around this duplicate channel problem, the drivers
> and cards have to disable hardware offset auto-lock, and allow media
> centre to do all the work ( slowly ).
How annoying. A waste of resources all round & far from ideal results
despite the extra work.
> Then, with Vista, they changed it again.
> Even if we cripple the hardware offset discovery and allow media centre
> to make it's broken-logic scan, we run into a new problem. Media
> Centre now uses frequency information encapsulated in the transmission,
> not the scan-discovered frequencies. And this is often wrong,
> particularly from repeater transmiters, where the embedded frequency
> info often relates to the main transmitter, not the relay. So Media
> Center ( brokenly ) initially finds the muxes on the scan, but then
> fails to tune them in because it's over-riding the scan-discovered
> frequency data with the possibly incorrect frequency data broadcast in
> the mux.
Ye gods. A typical m$ mess. Thanks for the explanation.
> Or something like that.
So in this case the drivers have probably been hacked about to work
around m$'s mess. Still, shouldn't this only affect Media Centre &
Vista? Surely drivers ought to be doing the sensible thing under XP? In
which case this suggests a Pinnacle drivers issue, in applying the hack
to their drivers on XP.
Andy Wade
> But I dimly remember a BBC paper that described modifications to a
> standard analogue channel so that a mux could be tucked in close on
> the next channel down.
Reduction of the width of the lower (vestigial) sideband from 1.25 MHz
to 0.75 MHz (system I1) is considered here:
http://www.bbc.co.uk/rd/pubs/whp/whp023.shtml
--
Andy
Bryce Whiteford
Not that it matters in the real world, but to answer the OP question
about the "exact" frequency, the offsets are + or - 166666 Hz,
usually rounded in documentation to + or - 166 kHz or 167 kHz.
--
Bryce Whiteford
polepo...@despammed.com
Bill Wright
"Alan Pemberton" <Spa...@pembers.freeserve.co.uk.invalid> wrote in message
news:1hty8lo.vq4lka1pvvruoN%Spa...@pembers.freeserve.co.uk.invalid...
> Bill Wright <insertmybu...@f2s.com> wrote:
>
>> I think they have no option if the mux is on the adjacent higher channel
>> to
>> apply positive offset because of the analogue channel's nicam carrier.
>> But I
>> dimly remember a BBC paper that described modifications to a standard
>> analogue channel so that a mux could be tucked in close on the next
>> channel
>> down. Nevertheless I'm surprised to hear that they actually have positive
>> offset on such muxes, but you live and learn.
>
> instead of 1.5MHz). They are called System I1 (pron 'eye-eye!'?). Sorry
> about that. Five adjacent puctuations marks that do not a smiley make.
I have a problem to solve in the near future. Because of the number of
channels (services) on this particular system, it looks as if I am going to
have to insert some VSB generated channels on channels adjacent and above
certain muxes. The muxes have positive offset. I think I will need to offset
the VSB channels. Hmm . . .
Bill
Brian Gregory [UK]
news:45dcf28f$0$8713$ed26...@ptn-nntp-reader02.plus.net...
Channel 6 ??
Mallory
power and is RSL (restricted service Licence) meant for reception in oxford
only, but I can pick it up in Northampton here with a fair amount of snow.
There is also a Bicester channel on UHF 66 I think that serves Bicester and
presumably is directional,, I cannot get it here in Northampton. This one is
even weaker than Oxford's Channel 6.
"Brian Gregory [UK]" <n...@bgdsv.co.uk> wrote in message
news:uL6dnX5h_5A...@pipex.net...
Brian Gregory [UK]
analogue channel will suffer much less interference than if it was a full
power one.