From: thomas schorpp <thomas.schorpp@googlemail.com>
To: hermann pitton <hermann-pitton@arcor.de>
Cc: linux-media@vger.kernel.org
Subject: Re: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Date: Sat, 27 Feb 2010 01:31:41 +0100 [thread overview]
Message-ID: <4B8867ED.2030906@gmail.com> (raw)
In-Reply-To: <1267228898.3239.2.camel@pc07.localdom.local>
Hello, Hermann,
hermann pitton wrote:
> Hi Thomas,
>
> Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp:
>> Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-)
>>
>> Even at higher BER:
>>
>> Current parameters:
>> Frequency: 1945.320 MHz
>> Inversion: OFF
>> Symbol rate: 22.000154 MSym/s
>> FEC: FEC 5/6
>>
>> cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>> cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
>>
>> I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then.
>>
>> y
>> tom
>
> I just started to try to look it up, but don't have ground yet.
Look for tda10086 changesets in the stable branch git repository at kernel.org 2.6.32.7...33
and linux-media repository ?
If there's no applicable change then I've misinterpreted the fix for the clear sky tonight :D
but I'm pretty sure the issue occured at any weather with hours of clear sky periods last week,
there's not been a minute without TS errors in VDR as long as the card has been in use.
>
> I reported unexpected bad performance under GNU/Linux for that card
> previously.
On this list? Give weblink pls.
>
> Can you point me to the fix?
>
> Cheers,
> Hermann
y
tom
>
>> thomas schorpp wrote:
>>> Hi,
>>> Issue is already confirmed here:
>>> http://www.vdr-portal.de/board/thread.php?threadid=93268
>>>
>>> Linux 2.6.32.8, 80cm dish.
>>>
>>> Do we have any Tuner/Decoder optimization points in the FE code?
>>>
>>> This is not OK:
>>>
>>> lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips
>>> Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01)
>>> Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium
>>> devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable)
>>> [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in
>>> use: saa7134
>>>
>>> grep cTS2PES /var/log/syslog
>>> Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS
>>> continuity errors
>>> Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS
>>> continuity errors
>>> Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS
>>> continuity errors
>>> Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS
>>> continuity errors
>>> Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS
>>> continuity errors
>>> Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS
>>> continuity errors
>>> Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS
>>> continuity errors
>>> Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS
>>> continuity errors
>>> Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS
>>> continuity errors
>>> Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS
>>> continuity errors
>>> Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS
>>> continuity errors
>>> Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS
>>> continuity errors
>>> Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS
>>> continuity errors
>>> Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS
>>> continuity errors
>>> Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS
>>> continuity errors
>>>
>>> dvbsnoop -s feinfo -adapter 2
>>> Current parameters:
>>> Frequency: 1236.253 MHz
>>> Inversion: OFF
>>> Symbol rate: 31.794142 MSym/s
>>> FEC: FEC 3/4
>>>
>>> dvbsnoop -s signal -adapter 2
>>> cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>> cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f
>>> [SIG CARR VIT SYNC LOCK ]
>>>
>>> Low signal strength values are AGC-loop misinterpretation as usual?
>>>
>>> y
>>> tom
>>>
>>>
>
>
>
next prev parent reply other threads:[~2010-02-27 0:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 14:39 [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input thomas schorpp
2010-02-26 23:34 ` thomas schorpp
2010-02-27 0:01 ` hermann pitton
2010-02-27 0:31 ` thomas schorpp [this message]
2010-02-27 2:39 ` hermann pitton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8867ED.2030906@gmail.com \
--to=thomas.schorpp@googlemail.com \
--cc=hermann-pitton@arcor.de \
--cc=linux-media@vger.kernel.org \
--cc=thomas.schorpp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.