[linux-dvb] Re: Progress on Skystar2 rev2.6B

[Wolfgang Thiel <w-thiel@gmx.net>]

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.