Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Hi Oliver, I'm not sure if you missed my last statement, that the patch works now fine in my environment. But I use the changed value not only for QAM256 but for every Modulationrate. In that case I can get rid of the unofficial frequencyshifting in av7110.c, where I had to tune down every frequency by -25. @Hartmut: Can you explain the connection with the frequency shift? Maybe those people that didn't need the shifting had merely a better signal, but vdr-portal tells of quite some that need the shifting. Maybe the value can be parametrized with module_param to make everybody happy. Johann Oliver Endriss schrieb: > [EMAIL PROTECTED] wrote: >> 2007/10/28, e9hack <[EMAIL PROTECTED]>: >>> I've seen two different values for the carrier offset on Windows XP for a >>> TT-C2300. Registers 20/21h >>> are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value >>> depends on the driver >>> revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may >>> be possible, that the >>> value is calculated from some other values. I know, that the patch has no >>> effect for some testers. >>> This is the first report with a failure. So it isn't possible to add the >>> patch. >>> >>> In my case, I've some channels in the UHF range with a poor signal >>> strength. Without the patch, I >>> got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0. >> Sorry, 'carrier offset' should be 'initial demodulation frequency'. > > What shall we do with this patch? > I think we cannot apply it right now. > > @e9hack: > Could it be that the windows driver tries different settings, > and uses the one with the lowest BER? > (Some kind of zig-zag scan for this parameter.) > > CU > Oliver > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Oliver Endriss wrote: > [EMAIL PROTECTED] wrote: >> 2007/10/28, e9hack <[EMAIL PROTECTED]>: >>> I've seen two different values for the carrier offset on Windows XP for a >>> TT-C2300. Registers 20/21h >>> are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value >>> depends on the driver >>> revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may >>> be possible, that the >>> value is calculated from some other values. I know, that the patch has no >>> effect for some testers. >>> This is the first report with a failure. So it isn't possible to add the >>> patch. >>> >>> In my case, I've some channels in the UHF range with a poor signal >>> strength. Without the patch, I >>> got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0. >> Sorry, 'carrier offset' should be 'initial demodulation frequency'. > > What shall we do with this patch? > I think we cannot apply it right now. Carrier offset as by STM what i understand is like this: the free running demodulator can detect how far it is away from the center freq. "fc". usually the the tuner has a b/w and the number of steps can be calculated, eventually the demod is stepped through, but not set_frontend as a whole, but certain stages in the demod The problem what i understand is that the windows driver uses the tuning algorithm as specified by STM, where as it is absent in our drivers. I did find this as the case for the STV0299 a while back. Some people said they had problems to tune to certain frequencies, ie it will just lock to adjacent slots. But to fix the same in the current stv0297 driver implies that a large chunk would need to be reworked, afaics. I don't know whether it is worth that effort. I had done this for the STB0899 since i felt the same very early itself. @Oliver, You can look at the algorithm defined (Master state machine diagram) for the STV0297, it will give you a better idea on it. ie the Carrier offset is detected in the Acquisition phase, the offset is applied to the digital oscillator and mixer of the initial demodulator. That said, tuning algorithms are far advanced than a simple zig-zag that we do in dvb_frontend. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
[EMAIL PROTECTED] wrote: > 2007/10/28, e9hack <[EMAIL PROTECTED]>: > > > > I've seen two different values for the carrier offset on Windows XP for a > > TT-C2300. Registers 20/21h > > are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value > > depends on the driver > > revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may > > be possible, that the > > value is calculated from some other values. I know, that the patch has no > > effect for some testers. > > This is the first report with a failure. So it isn't possible to add the > > patch. > > > > In my case, I've some channels in the UHF range with a poor signal > > strength. Without the patch, I > > got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0. > > Sorry, 'carrier offset' should be 'initial demodulation frequency'. What shall we do with this patch? I think we cannot apply it right now. @e9hack: Could it be that the windows driver tries different settings, and uses the one with the lowest BER? (Some kind of zig-zag scan for this parameter.) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Hi Oliver, Hartmut I have to modify my last statement concerning this patch. I forgot that I had to use a frequency shift in av7110.c to achieve a good reception. If I set this shift to 0 and use the new value of initial_demod_freq I get a lock again on QAM256-channels with reception as good as before. As this freq shift also improved reception on QAM64-channels I'm at the moment using 6718 for QAM256 and QAM64 with resulting BERs in the same range as with unpatched stv0297.ko and a frequency shift of -25. Maybe this also sheds some light on the discussion about shifting frequencies on vdr-portal.de Oliver Endriss schrieb: > Hi, > >> Oliver Endriss <[EMAIL PROTECTED]> wrote: >>> e9hack wrote: I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization of the stv0297 is a little bit different. If I change the value for the initial demodulation frequency, the ber value is reduced to a fourths. >>> @all: >>> please test with QAM256 channels and report any problems. >>> >>> If nobody objects I'll commit this patch. > > Apparently we cannot use 6718 for all cards. > So the patch must be modified... > > @TT/Hauppauge DVB-C 2300 users: > Are there any problems with this patch? > > CU > Oliver > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
2007/10/28, e9hack <[EMAIL PROTECTED]>: > > I've seen two different values for the carrier offset on Windows XP for a > TT-C2300. Registers 20/21h > are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value > depends on the driver > revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may > be possible, that the > value is calculated from some other values. I know, that the patch has no > effect for some testers. > This is the first report with a failure. So it isn't possible to add the > patch. > > In my case, I've some channels in the UHF range with a poor signal > strength. Without the patch, I > got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0. Sorry, 'carrier offset' should be 'initial demodulation frequency'. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Johann Friedrichs schrieb: > I get no lock on any QAM-256 channel with my C-2300 after applying that > patch. I've seen two different values for the carrier offset on Windows XP for a TT-C2300. Registers 20/21h are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value depends on the driver revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may be possible, that the value is calculated from some other values. I know, that the patch has no effect for some testers. This is the first report with a failure. So it isn't possible to add the patch. In my case, I've some channels in the UHF range with a poor signal strength. Without the patch, I got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Hi, Guy Martin wrote: > On Sat, 27 Oct 2007 08:17:14 +0200 > Oliver Endriss <[EMAIL PROTECTED]> wrote: > > e9hack wrote: > > > I did eavesdrop the i2c-bus on the TT-C2300 on windows. The > > > initialization of the stv0297 is a little bit different. If I > > > change the value for the initial demodulation frequency, the ber > > > value is reduced to a fourths. > > > > @all: > > please test with QAM256 channels and report any problems. > > > > If nobody objects I'll commit this patch. > > This breaks my cablestar. After applying the patch, I cannot lock any > QAM256 channel. Thanks for reporting! Apparently we cannot use 6718 for all cards. So the patch must be modified... @TT/Hauppauge DVB-C 2300 users: Are there any problems with this patch? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Hi Oliver, I get no lock on any QAM-256 channel with my C-2300 after applying that patch. Johann Oliver Endriss schrieb: > e9hack wrote: >> Hi, >> >> I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization >> of the stv0297 is a >> little bit different. If I change the value for the initial demodulation >> frequency, the ber value is >> reduced to a fourths. > > @all: > please test with QAM256 channels and report any problems. > > If nobody objects I'll commit this patch. > > CU > Oliver > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
Hi Oliver, This breaks my cablestar. After applying the patch, I cannot lock any QAM256 channel. Guy On Sat, 27 Oct 2007 08:17:14 +0200 Oliver Endriss <[EMAIL PROTECTED]> wrote: > e9hack wrote: > > Hi, > > > > I did eavesdrop the i2c-bus on the TT-C2300 on windows. The > > initialization of the stv0297 is a little bit different. If I > > change the value for the initial demodulation frequency, the ber > > value is reduced to a fourths. > > @all: > please test with QAM256 channels and report any problems. > > If nobody objects I'll commit this patch. > > CU > Oliver > -- Guy Martin Gentoo Linux - HPPA port lead ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] stv0297: improvement for qam256 modulated channels
e9hack wrote: > Hi, > > I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization of > the stv0297 is a > little bit different. If I change the value for the initial demodulation > frequency, the ber value is > reduced to a fourths. @all: please test with QAM256 channels and report any problems. If nobody objects I'll commit this patch. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb