Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Progress on Skystar2 rev2.6B
On Mon, Nov 03, 2003 at 10:43:41AM +0100, Niklas Peinecke wrote:
>...
>> I did some dprintk in the DMA routine: packet length is 188.
>> But: there are bit errors in the data.
>> Below is a comparison: first comes what is found in the routine,
>> the line below shows the 'real' data (taken with a non-budget card).
>>
>> Any ideas what to try next?
>>
>> kernel: 47 40 00 16 00
>> kernel: 80 b0 bd 00 87 f9 00 00 00 09 a2 00 00 18 a2 00
>> 00000000: 00 b0 bd 00 07 f9 00 00 00 0d e2 00 00 18 e2 00
>
>I'm not sure if I understood what you where trying: Are you saying that
>you get the same data rate from the skystar as from the reference
>device? I'm just wondering because I seem to get a very low data output
>
I didn't write about data rates, but about bit errors in skystar2.c:
In skystar2.c:InterruptServiceDMA1 I waited for packets with PID 0,
and wrote them out; that are the lines starting with 'kernel'. As a
comparison what the real packets look like, I added the second line.
>from the skystar, sometimes it takes several minutes to assemble 500k of
>output. Also there seem to be large gaps in the continuity counters of
>packets belonging to the same PID (>5). Is this the expected behaviour?
>
That will be because the filters fail because of the bit errors ;-(
See above (and below): the table_id is 00, but arrives as 80 in the
skystar2 driver :-(
>@Wolfgang: At a blind guess I re-enabled the flexcop_diseqc control but
>always returning -ENOTSUPP, so that the flexcop tries to tune its way
>but also the frontend does. This results in a faster lock on some
>channels, maybe it's worth a try.
>
Thanks for the tip, but I don't have locking problems here; but I
usually do some frequency corrections for my LNB anyway, because that's
the only way to get a lock on channels with low symbolrates with my BSRV
tuner in the 'fully-featured' card.
>The bit errors might be corrections made by the stv or the flexparser,
>though they seem rather frequent.
>
Perhaps FEC is somehow disabled in the current code, so that the *un-
corrected* stream is delivered?
Or is this a DMA issue?
Sorry, I don't know much about frontends :-(
Here is another example, this time Astra, ARD transponder 11837h
(the PAT fits in one TS packet):
The lines *not* starting with 'kernel' are correct: I checked the
crc.
kernel: 47 00 00 19 00
^ PUSI bit is not set: wrong
kernel: 80 b0 1d 0c cd db 00 00 00 00 e0 18 ed ca e0 64
0000000: 00 b0 5d 04 4d db 00 00 00 00 e0 10 6d ca e0 64
kernel: ed cb e0 c8 ed c8 a1 2c ed c9 a1 98 6d ca e1 fc
0000010: 6d cb e0 c8 6d cc e1 2c 6d cd e1 90 6d ce e1 f4
kernel: ed cf e2 58 ed d0 a2 bc ed d1 a3 28 ed d2 e3 8c
0000020: 6d cf e2 58 6d d0 e2 bc 6d d1 e3 20 6d d2 e3 84
kernel: ed d8 ab b8 ed d9 ac 1c ed da ac 80 ed db ec ec
0000030: 6d d8 eb b8 6d d9 ec 1c 6d da ec 80 6d db ec e4
kernel: 6d dc ed 48 ed dd ad ac ed de ae 18 ed df ee 74
0000040: 6d dc ed 48 6d dd ed ac 6d de ee 10 6d df ee 74
kernel: ed e0 ee d8 ed e1 af 3c ed e2 e7 d0 63 33 03 81
0000050: 6d e0 ee d8 6d e1 ef 3c 6d e2 e7 d0 e3 37 43 81
kernel: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kern message repeated 4 times
kernel: ff ff ff ff ff ff bf
^ definitively wrong!
Wolfgang
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index