[RFC] STB0899 signal strength (pctv452e, others too?)

Message ID 20120519203207.GA48169@triton8.kn-bremen.de
State New
Headers

Commit Message

Juergen Lock May 19, 2012, 8:32 p.m. UTC
  Hi!

(I guess the forums are not the best place to post this, hence
reposted here...)

 By accident I stumbled across the special case for TT-budget S2-3200
(DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
the pctv452e driver have the same issue (which are STB0899 too,
issue is the red/yellow/green bars in femon/osd didn't appear)
I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
make config menu) to enable the patch below.  Optional since I don't
know if there are STB0899-based tuners that don't have the problem,
does anyone here know?  (see log, if vdr logs like

	vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard")

and the bars appear without the patch please let us know, noting
pci ids for the cards especially if different from 0x13c2:0x1019
or if it's usb, thanx!)

 Cheers,
	Juergen

And here comes the patch, also at:

	http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
  

Comments

Klaus Schmidinger May 19, 2012, 9:57 p.m. UTC | #1
On 19.05.2012 22:32, Juergen Lock wrote:
> Hi!
>
> (I guess the forums are not the best place to post this, hence
> reposted here...)
>
>   By accident I stumbled across the special case for TT-budget S2-3200
> (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
> the pctv452e driver have the same issue (which are STB0899 too,
> issue is the red/yellow/green bars in femon/osd didn't appear)
> I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
> make config menu) to enable the patch below.  Optional since I don't
> know if there are STB0899-based tuners that don't have the problem,
> does anyone here know?  (see log, if vdr logs like
>
> 	vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard")
>
> and the bars appear without the patch please let us know, noting
> pci ids for the cards especially if different from 0x13c2:0x1019
> or if it's usb, thanx!)
>
>   Cheers,
> 	Juergen
>
> And here comes the patch, also at:
>
> 	http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
>
> --- dvbdevice.c.orig
> +++ dvbdevice.c
> @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c
>     switch (subsystemId) {
>       case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
>       }
> +#if 1
> +  // XXX This is likely not correct for all cards using stb0899
> +  // but pctv452e usb ones seem to be affected too...
> +  if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> +    MaxSignal = 670;
> +#endif
>     int s = int(Signal) * 100 / MaxSignal;
>     if (s>  100)
>        s = 100;
> @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co
>        switch (subsystemId) {
>          case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
>          }
> +#if 1
> +     // XXX This is likely not correct for all cards using stb0899
> +     // but pctv452e usb ones seem to be affected too...
> +     if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> +       MaxSnr = 200;
> +#endif
>        int a = int(Snr) * 100 / MaxSnr;
>        int b = 100 - (Unc * 10 + (Ber / 256) * 5);
>        if (b<  0)

Maybe I'm missing something here, but why don't you just add the subsystem id of your card
to the switch statements?

Klaus
  
Juergen Lock May 20, 2012, 8:55 a.m. UTC | #2
On Sat, May 19, 2012 at 11:57:35PM +0200, Klaus Schmidinger wrote:
> On 19.05.2012 22:32, Juergen Lock wrote:
> > Hi!
> >
> > (I guess the forums are not the best place to post this, hence
> > reposted here...)
> >
> >   By accident I stumbled across the special case for TT-budget S2-3200
> > (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
> > the pctv452e driver have the same issue (which are STB0899 too,
> > issue is the red/yellow/green bars in femon/osd didn't appear)
> > I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
> > make config menu) to enable the patch below.  Optional since I don't
> > know if there are STB0899-based tuners that don't have the problem,
> > does anyone here know?  (see log, if vdr logs like
> >
> > 	vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard")
> >
> > and the bars appear without the patch please let us know, noting
> > pci ids for the cards especially if different from 0x13c2:0x1019
> > or if it's usb, thanx!)
> >
> >   Cheers,
> > 	Juergen
> >
> > And here comes the patch, also at:
> >
> > 	http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
> >
> > --- dvbdevice.c.orig
> > +++ dvbdevice.c
> > @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c
> >     switch (subsystemId) {
> >       case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
> >       }
> > +#if 1
> > +  // XXX This is likely not correct for all cards using stb0899
> > +  // but pctv452e usb ones seem to be affected too...
> > +  if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> > +    MaxSignal = 670;
> > +#endif
> >     int s = int(Signal) * 100 / MaxSignal;
> >     if (s>  100)
> >        s = 100;
> > @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co
> >        switch (subsystemId) {
> >          case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
> >          }
> > +#if 1
> > +     // XXX This is likely not correct for all cards using stb0899
> > +     // but pctv452e usb ones seem to be affected too...
> > +     if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> > +       MaxSnr = 200;
> > +#endif
> >        int a = int(Snr) * 100 / MaxSnr;
> >        int b = 100 - (Unc * 10 + (Ber / 256) * 5);
> >        if (b<  0)
> 
> Maybe I'm missing something here, but why don't you just add the subsystem id of your card
> to the switch statements?

Heh.

 Because a) it's usb, b) I'm on FreeBSD which doesn't emulate Linux'
/sys/class/dvb nodes and finding out which /dev/dvb node belongs
to which usbid isn't as straightforward there, and c) I was wondering
if the bug maybe affects all STB0899 frontends not just some.

 Cheers,
	Juergen
  
Klaus Schmidinger May 20, 2012, 9:20 a.m. UTC | #3
On 20.05.2012 10:55, Juergen Lock wrote:
> On Sat, May 19, 2012 at 11:57:35PM +0200, Klaus Schmidinger wrote:
>> On 19.05.2012 22:32, Juergen Lock wrote:
>>> Hi!
>>>
>>> (I guess the forums are not the best place to post this, hence
>>> reposted here...)
>>>
>>>    By accident I stumbled across the special case for TT-budget S2-3200
>>> (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
>>> the pctv452e driver have the same issue (which are STB0899 too,
>>> issue is the red/yellow/green bars in femon/osd didn't appear)
>>> I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
>>> make config menu) to enable the patch below.  Optional since I don't
>>> know if there are STB0899-based tuners that don't have the problem,
>>> does anyone here know?  (see log, if vdr logs like
>>>
>>> 	vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard")
>>>
>>> and the bars appear without the patch please let us know, noting
>>> pci ids for the cards especially if different from 0x13c2:0x1019
>>> or if it's usb, thanx!)
>>>
>>>    Cheers,
>>> 	Juergen
>>>
>>> And here comes the patch, also at:
>>>
>>> 	http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
>>>
>>> --- dvbdevice.c.orig
>>> +++ dvbdevice.c
>>> @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c
>>>      switch (subsystemId) {
>>>        case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
>>>        }
>>> +#if 1
>>> +  // XXX This is likely not correct for all cards using stb0899
>>> +  // but pctv452e usb ones seem to be affected too...
>>> +  if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
>>> +    MaxSignal = 670;
>>> +#endif
>>>      int s = int(Signal) * 100 / MaxSignal;
>>>      if (s>   100)
>>>         s = 100;
>>> @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co
>>>         switch (subsystemId) {
>>>           case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
>>>           }
>>> +#if 1
>>> +     // XXX This is likely not correct for all cards using stb0899
>>> +     // but pctv452e usb ones seem to be affected too...
>>> +     if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
>>> +       MaxSnr = 200;
>>> +#endif
>>>         int a = int(Snr) * 100 / MaxSnr;
>>>         int b = 100 - (Unc * 10 + (Ber / 256) * 5);
>>>         if (b<   0)
>>
>> Maybe I'm missing something here, but why don't you just add the subsystem id of your card
>> to the switch statements?
>
> Heh.
>
>   Because a) it's usb, b) I'm on FreeBSD which doesn't emulate Linux'
> /sys/class/dvb nodes and finding out which /dev/dvb node belongs
> to which usbid isn't as straightforward there, and c) I was wondering
> if the bug maybe affects all STB0899 frontends not just some.

Ah, I see.

Well, maybe if this is common to all STB0899 frontends it could even be
fixed in the driver itself ;-)
I always thought that the *driver* should provide a normalized interface
for getting signal strength and snr. It can't be reasonable that every
application has to figure these out by itself.

Klaus
  
VDRU VDRU May 20, 2012, 3:51 p.m. UTC | #4
On Sun, May 20, 2012 at 2:20 AM, Klaus Schmidinger
<Klaus.Schmidinger@tvdr.de> wrote:
> Well, maybe if this is common to all STB0899 frontends it could even be
> fixed in the driver itself ;-)
> I always thought that the *driver* should provide a normalized interface
> for getting signal strength and snr. It can't be reasonable that every
> application has to figure these out by itself.

This subject has come up at least a few times, one of which was in the
"The right way to interpret the content of SNR, signal strength and
BER from HVR 4000 Lite" thread. For some reason the
conversation/interest/whatever dies down, even with a lot of talk
about it. It would be great if it ever got resolved but if it hasn't
happened by now, with all the attention it has already received, I
don't see Linux ever getting a usable standardized scale/method. Of
course that means you also won't get one of the most basic & useful
tools, a reliable signal meter.
  
Thomas Sailer May 20, 2012, 5:24 p.m. UTC | #5
On 05/20/2012 05:51 PM, VDR User wrote:

> This subject has come up at least a few times, one of which was in the
> "The right way to interpret the content of SNR, signal strength and
> BER from HVR 4000 Lite" thread. For some reason the

Apart from the SNR/Signal Strength issue, does the card work for you? I 
just threw it out again and replaced it with a venerable stv0299 card, 
because it never reliably locked (it locked maybe every fourth time). 
This is with good signals, neither the stv0299 nor the stv090x cards 
have any problems with the signal. My stb0899 card is a technisat 
skystar hd2.

Tom
  
Papernik May 20, 2012, 5:48 p.m. UTC | #6
My card is old mystique model satix dvb-s2 ( KNC1 DVB-S2 Plus , Satelco
Easywatch DVB-S2 , TT S2 3200, Technisat DVB-S2 all i think has same
problem ).
Card is working fine, but i cannot see signal level on femon, and can not
use any channel scan program like wirbelsacn ( no signal il locked ).
I hoped the problem would be resolved in the latest kernel drivers, but not, at
least in yaVDR64 0.4.0 (based on Ubuntu 11.04 Natty Narwhal), with
linux-media-dkms.



2012/5/20 Thomas Sailer <sailer@sailer.dynip.lugs.ch>

> On 05/20/2012 05:51 PM, VDR User wrote:
>
>  This subject has come up at least a few times, one of which was in the
>> "The right way to interpret the content of SNR, signal strength and
>> BER from HVR 4000 Lite" thread. For some reason the
>>
>
> Apart from the SNR/Signal Strength issue, does the card work for you? I
> just threw it out again and replaced it with a venerable stv0299 card,
> because it never reliably locked (it locked maybe every fourth time). This
> is with good signals, neither the stv0299 nor the stv090x cards have any
> problems with the signal. My stb0899 card is a technisat skystar hd2.
>
> Tom
>
>
> ______________________________**_________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr<http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>
>
  
Joerg Riechardt May 20, 2012, 6:09 p.m. UTC | #7
Am 20.05.2012 19:24, schrieb Thomas Sailer:
> On 05/20/2012 05:51 PM, VDR User wrote:
>
>> This subject has come up at least a few times, one of which was in the
>> "The right way to interpret the content of SNR, signal strength and
>> BER from HVR 4000 Lite" thread. For some reason the
>
> Apart from the SNR/Signal Strength issue, does the card work for you? 
> I just threw it out again and replaced it with a venerable stv0299 
> card, because it never reliably locked (it locked maybe every fourth 
> time). This is with good signals,

Hi, there is a patch for this problem, which made it into the kernel 
october 2011
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=history;f=drivers/media/dvb/frontends/stb0899_algo.c;h=117a56926dcad041316a53f4ea47ed3c7263505f;hb=b8ed9e5b8c34dc9fb1882669e45b21e3d0194881
Joerg

> neither the stv0299 nor the stv090x cards have any problems with the 
> signal. My stb0899 card is a technisat skystar hd2.
>
> Tom
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  
VDRU VDRU May 20, 2012, 6:12 p.m. UTC | #8
On Sun, May 20, 2012 at 10:24 AM, Thomas Sailer
<sailer@sailer.dynip.lugs.ch> wrote:
>> This subject has come up at least a few times, one of which was in the
>> "The right way to interpret the content of SNR, signal strength and
>> BER from HVR 4000 Lite" thread. For some reason the
>
> Apart from the SNR/Signal Strength issue, does the card work for you? I just
> threw it out again and replaced it with a venerable stv0299 card, because it
> never reliably locked (it locked maybe every fourth time). This is with good
> signals, neither the stv0299 nor the stv090x cards have any problems with
> the signal. My stb0899 card is a technisat skystar hd2.

I have several cards but not that particular one. I was talking about
the subject in general. It really only makes sense that there's a
standardized way for all devices to present the info to the
user/applications.
  
Marx May 20, 2012, 9:21 p.m. UTC | #9
I have such a card, Pinnacle PCTV SAT HDTV 452E PRO USB.
I'm trying to use it but no luck.
I've tried (I use Debian):
- linux 3.2 kernel
After reboot many errors:
May 20 10:08:47 wuwek kernel: [   63.984760] pctv452e: 
pctv452e_power_ctrl: 1
May 20 10:08:47 wuwek kernel: [   63.984763]
May 20 10:09:45 wuwek kernel: [  122.072827] pctv452e: I2C error -121; 
AA 51  CC 00 01 -> 55 51  CC 00 00.
May 20 10:09:46 wuwek kernel: [  123.332819] pctv452e: I2C error -121; 
AA 36  CC 00 01 -> 55 36  CC 00 00.

after connect/disconnect and try to change channel in VDR:
May 20 13:26:43 wuwek kernel: [ 1801.872219] INFO: task khubd:96 blocked 
for more than 120 seconds.
May 20 13:26:43 wuwek kernel: [ 1801.872232] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 20 13:26:43 wuwek kernel: [ 1801.872242] khubd           D f79ea9c0 
     0    96      2 0x00000000
May 20 13:26:43 wuwek kernel: [ 1801.872259]  f71e62c0 00000046 0000d234 
f79ea9c0 00000000 00000000 c12cb2e4 c14839c0
May 20 13:26:43 wuwek kernel: [ 1801.872283]  f71e646c c14839c0 f79ea9c0 
f3ef7fcc c12c0e25 f3ef7fd0 c12bff7b f3ef7fd0
May 20 13:26:43 wuwek kernel: [ 1801.872303]  00000001 f71e62c0 c103233e 
00100100 00200200 f400d200 f3ef7fcc c105d51d
May 20 13:26:43 wuwek kernel: [ 1801.872325] Call Trace:
May 20 13:26:43 wuwek kernel: [ 1801.872347]  [<c12c0e25>] ? 
_raw_spin_lock_irq+0x9/0x12
May 20 13:26:43 wuwek kernel: [ 1801.872360]  [<c12bff7b>] ? 
wait_for_common+0xc7/0xd1
May 20 13:26:43 wuwek kernel: [ 1801.872375]  [<c103233e>] ? 
try_to_wake_up+0x155/0x155
May 20 13:26:43 wuwek kernel: [ 1801.872390]  [<c105d51d>] ? 
arch_local_irq_save+0xf/0x14
May 20 13:26:43 wuwek kernel: [ 1801.872403]  [<c12c0e03>] ? 
_raw_spin_lock_irqsave+0x8/0x21
May 20 13:26:43 wuwek kernel: [ 1801.872484]  [<f83d0c2a>] ? 
dvb_unregister_frontend+0x95/0xcb [dvb_core]
May 20 13:26:43 wuwek kernel: [ 1801.872498]  [<c104d5d0>] ? 
add_wait_queue+0x30/0x30
May 20 13:26:43 wuwek kernel: [ 1801.872530]  [<f835e0a9>] ? 
dvb_usb_adapter_frontend_exit+0x2b/0x56 [dvb_usb]
May 20 13:26:43 wuwek kernel: [ 1801.872560]  [<f835d276>] ? 
dvb_usb_exit+0x26/0x88 [dvb_usb]
May 20 13:26:43 wuwek kernel: [ 1801.872597]  [<f835d30b>] ? 
dvb_usb_device_exit+0x33/0x43 [dvb_usb]
May 20 13:26:43 wuwek kernel: [ 1801.872663]  [<f82518d3>] ? 
usb_unbind_interface+0x3a/0xe9 [usbcore]
May 20 13:26:43 wuwek kernel: [ 1801.872687]  [<c11f316a>] ? 
__device_release_driver+0x5e/0x95
May 20 13:26:43 wuwek kernel: [ 1801.872699]  [<c11f31b6>] ? 
device_release_driver+0x15/0x1e
May 20 13:26:43 wuwek kernel: [ 1801.872711]  [<c11f2e76>] ? 
bus_remove_device+0x5f/0x6a
May 20 13:26:43 wuwek kernel: [ 1801.872722]  [<c11f146d>] ? 
device_del+0xed/0x130
May 20 13:26:43 wuwek kernel: [ 1801.872768]  [<f8250268>] ? 
usb_disable_device+0x56/0x13c [usbcore]
May 20 13:26:43 wuwek kernel: [ 1801.872811]  [<f824b1c5>] ? 
usb_disconnect+0x5f/0xb0 [usbcore]
May 20 13:26:43 wuwek kernel: [ 1801.872855]  [<f824c463>] ? 
hub_thread+0x420/0xbd4 [usbcore]
May 20 13:26:43 wuwek kernel: [ 1801.872870]  [<c102a053>] ? 
__wake_up_common+0x33/0x5a
May 20 13:26:43 wuwek kernel: [ 1801.872881]  [<c104d5d0>] ? 
add_wait_queue+0x30/0x30
May 20 13:26:43 wuwek kernel: [ 1801.872925]  [<f824c043>] ? 
usb_remote_wakeup+0x23/0x23 [usbcore]
May 20 13:26:43 wuwek kernel: [ 1801.872936]  [<c104d12f>] ? 
kthread+0x63/0x68
May 20 13:26:43 wuwek kernel: [ 1801.872948]  [<c104d0cc>] ? 
kthread_worker_fn+0x101/0x101
May 20 13:26:43 wuwek kernel: [ 1801.872961]  [<c12c5bfe>] ? 
kernel_thread_helper+0x6/0x10
May 20 13:28:43 wuwek kernel: [ 1921.872145] INFO: task khubd:96 blocked 
for more than 120 seconds.
May 20 13:28:43 wuwek kernel: [ 1921.872159] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 20 13:28:43 wuwek kernel: [ 1921.872169] khubd           D f79ea9c0 
     0    96      2 0x00000000
May 20 13:28:43 wuwek kernel: [ 1921.872185]  f71e62c0 00000046 0000d234 
f79ea9c0 00000000 00000000 c12cb2e4 c14839c0
May 20 13:28:43 wuwek kernel: [ 1921.872208]  f71e646c c14839c0 f79ea9c0 
f3ef7fcc c12c0e25 f3ef7fd0 c12bff7b f3ef7fd0
May 20 13:28:43 wuwek kernel: [ 1921.872228]  00000001 f71e62c0 c103233e 
00100100 00200200 f400d200 f3ef7fcc c105d51d
(...)
dvb-usb: could not submit URB no. 0 - get them all back

- linux 3.2 kernel with linux-media-dkms from yavdr (while it compile 
without errors, it doesn't work - seems like modules doesn't fit kernel.)

Can you tell mi exactly with what kernel and driver this card work?
Marx
  

Patch

--- dvbdevice.c.orig
+++ dvbdevice.c
@@ -560,6 +560,12 @@  int cDvbTuner::GetSignalStrength(void) c
   switch (subsystemId) {
     case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
     }
+#if 1
+  // XXX This is likely not correct for all cards using stb0899
+  // but pctv452e usb ones seem to be affected too...
+  if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
+    MaxSignal = 670;
+#endif
   int s = int(Signal) * 100 / MaxSignal;
   if (s > 100)
      s = 100;
@@ -632,6 +638,12 @@  int cDvbTuner::GetSignalQuality(void) co
      switch (subsystemId) {
        case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2)
        }
+#if 1
+     // XXX This is likely not correct for all cards using stb0899
+     // but pctv452e usb ones seem to be affected too...
+     if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
+       MaxSnr = 200;
+#endif
      int a = int(Snr) * 100 / MaxSnr;
      int b = 100 - (Unc * 10 + (Ber / 256) * 5);
      if (b < 0)