/Exactly/ what frequency would you expect to find a given mux on?

"Mark Carver" wrote in message
oups.com...
On Feb 22, 1:31 am, "Mallory" wrote:
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/recep..._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.

Bill

In Hannington's case they are all +167 kHz, for Oxford Ch48 0

http://www.ofcom.org.uk/static/recep..._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 ?

"Mark Carver" wrote in message
oups.com...

In Hannington's case they are all +167 kHz, for Oxford Ch48 0

http://www.ofcom.org.uk/static/recep..._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 ?

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

"Michael Rozdoba" wrote in message
...
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

( 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...Sear ch&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.

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 cent
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

Brian Gregory [UK] wrote:
"Michael Rozdoba" wrote in message
...
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
m r o z a t u k g a t e w a y d o t n e t

Bill Wright wrote:
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

Thanks for the explanation. I imagined it was something like that, but
was only guessing.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

Ron Lowe wrote:
"Michael Rozdoba" wrote in message
...
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...Sear ch&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 cent
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.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

Bill Wright wrote:

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 he
http://www.bbc.co.uk/rd/pubs/whp/whp023.shtml

--
Andy

On Wed, 21 Feb 2007 20:57:10 +0000, Dave Pickles
wrote:

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. 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/recep...index.asp.html

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

"Alan Pemberton" wrote in message
rve.co.uk.invalid...
Bill Wright 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.

Such analogue transmissions have reduced vestigial sideband (0.75MHz
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