[linux-dvb] Re: New UK DVB-T channels testing

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

On Wed, 2002-10-09 at 20:36, Klaus Schmidinger wrote:
> Lauri Pesonen wrote:
> > 
> > On Wed, Oct 09, 2002 at 11:51:18AM +0200, Holger Waechtler wrote:
> > > Klaus Schmidinger wrote:
> > >
> > > >  The NIT reports frequencies like 283000000Hz when I'm using 282750000Hz
> > > >  with VDR. So The NIT reports the 'official' freqs without the offset.
> > > >  Offsets are -250kHz for QAM_128 freqs and -125kHz for QAM_64 freqs.
> > > >
> > > >Therefore it should be sufficient to store the "center frequency" and
> > > >allow for
> > > >an offset handling, which in case of DVB-T could be done by an 'O'
> > > >parameter
> > > >(note that it's the character between 'N' and 'P', not the number 'zero'),
> > > >and in case of DVB-C a table of offsets for the various QAM modes should
> > > >do the trick.
> > >
> > > Are you sure that these offsets are related to the used modulation? What
> > > makes you sure of that?
> > >
> > > Holger
> > 
> > I emailed about theo ffset in DVB-C in Finland (the text segment Klaus
> > quoted above).
> > 
> > Some guy in Finland (sorry, I can't remember your name) came up with the
> > offsets after trial and error. There is no guarantee that they are correct
> > or that the offset is related to the modulation. Actually the only QAM_64
> > bouquet in my providers network is on 162MHz and all QAM_128 bouquets
> > (that I'm whatching) are above that, e.g. in the range of 283MHz. So the
> > offset might also be related to the freq rather than the modulation (which
> > would make more sense to me).
> > 
> > All I can say for sure is that I have offset the QAM_64 bouquet by -125kHz
> > and all the QAM_128 bouquets by -250kHz and all channels work perfectly.
> > Before I applied the offset 80% of my channels switches across bouquets
> > failed.
> 
> Well, after all these postings I guess the bottom line is that it will be best
> to store both DVB-T _and_ DVB-C frequencies generally in kHz (I believe
> going all the way down to Hz would be really unnecessary, because the user would
> then have to enter a NINE digit number when defining a channel in VDR's OSD - pretty
> sure six of which would be zeroes).

I don't want to interfere here as I probably don't understand the
problem but:

Why not STORE the values as Hz, but allow input via OSD to be in
whatever is most sensible?

Also - why not let user suffix their values with Mhz, Khz, Ghz or hz? 
On the OSD you could use up/down to select the units (but default to the
most likely units for the source type).  This would seem (to me) to be
the most flexible.

> VDR would then in no way bother with any offsets, these would have to be added to
> the frequency in whatever way the person or program that generates the data sees fit.
> The only question left is whether the data broadcast in the data stream really defines
> the frequency *precisely*.
> 
> Klaus
> -- 
> _______________________________________________________________
> 
> Klaus Schmidinger                       Phone: +49-8635-6989-10
> CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
> Hofmark 2                               Email:   kls@cadsoft.de
> D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
> _______________________________________________________________
> 
> 
> -- 
> Info:
> To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.
> 



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