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: [EMAIL PROTECTED] > D-84568 Pleiskirchen, Germany URL: www.cadsoft.de > _______________________________________________________________ > > > -- > Info: > To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as >subject. > -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
