[linux-dvb] dst_test info results on twinhan card
Dominique Dumont
domi.dumont at free.fr
Sat Apr 2 17:07:37 CEST 2005
Hello Manu (and all others)
I've played some more with dts_test info and looked closely at the hex
values returned by the MCU. (You'll find at the end of the mail the raw
values returend by the CAM with various hardware setup.)
Here are some patterns found in the MCU values:
- byte [5] is always 44 for SCM CAM after reload (i.e. the only case
where I can communicate with CAM and de-scramble programs)
- byte [5] is always 41 for Aston CAM (which does not work at all: no
communication with the CAM)
- byte[5] result is 41 or 44 for hotplugged SCM CAM. (Case where CAM
communication and descrambling are broken)
- taken together (i.e nb = byte[2] << 8 | byte[3]), byte 2 and 3 have
interesting statistical properties that suggest they are the result
of a measure done by MCU. Probably related to a timing measure. (see
below for the statistical results)
- For the record, byte[4] is already known and interpreted in the
driver (used to check whether the CAM is plugged and/or ready)
- last byte is the usual checksum
So now, the question is, can we make some use of the info returned by
the MCU ?
What the deal with byte[5] ? How can we interpret 44 or 41 ? Is this
actually related with succesfull com with the CAM ??
Could the byte[2] and [3] info be used to tune the some of the msleep
that are present in the dst and dst_ca drivers ?
Cheers
Statistical result (computed by gnumeric):
Mean 5882.48
Standard Error 0
Median 5882
Mode 5892
Standard Deviation 23
Sample Variance 531
Range 162
Minimum 5804
Maximum 5966
Sum 4135380
Count 703
Raw values returned by MCU:
No CAM:
Apr 2 15:20:20 localhost kernel: 3 ef 17 4 0 44 1 ae
Apr 2 15:20:21 localhost kernel: 3 ef 17 1f 0 44 1 93
Apr 2 15:20:22 localhost kernel: 3 ef 17 22 0 44 1 90
Apr 2 15:20:23 localhost kernel: 3 ef 17 39 0 44 1 79
Apr 2 15:20:24 localhost kernel: 3 ef 17 4 0 44 1 ae
Aston CAM hot-plugged, no module reload:
Apr 2 15:23:45 localhost kernel: 3 ef 16 e6 80 41 1 50
Apr 2 15:23:48 localhost kernel: 3 ef 17 9 80 41 1 2c
Apr 2 15:23:49 localhost kernel: 3 ef 17 13 80 41 1 22
Apr 2 15:23:50 localhost kernel: 3 ef 17 4 80 41 1 31
Apr 2 15:23:51 localhost kernel: 3 ef 16 f4 80 41 1 42
Apr 2 15:23:52 localhost kernel: 3 ef 16 e7 80 41 1 4f
Apr 2 15:24:04 localhost kernel: 3 ef 17 18 80 41 1 1d
Apr 2 15:24:06 localhost kernel: 3 ef 16 f6 80 41 1 40
Aston CAM after module reload:
Apr 2 15:25:02 localhost kernel: 3 ef 16 ee 80 41 1 48
Apr 2 15:25:03 localhost kernel: 3 ef 16 e8 80 41 1 4e
Apr 2 15:25:05 localhost kernel: 3 ef 16 f9 80 41 1 3d
Apr 2 15:25:06 localhost kernel: 3 ef 17 22 80 41 1 13
Apr 2 15:25:07 localhost kernel: 3 ef 16 eb 80 41 1 4b
Apr 2 15:25:08 localhost kernel: 3 ef 17 30 80 41 1 5
Apr 2 15:25:09 localhost kernel: 3 ef 17 b 80 41 1 2a
Apr 2 15:25:10 localhost kernel: 3 ef 16 e8 80 41 1 4e
SCM CAM hot-plugged, no module reload:
Apr 2 15:26:30 localhost kernel: 3 ef 17 1c 80 41 1 19
Apr 2 15:26:31 localhost kernel: 3 ef 17 7 80 41 1 2e
Apr 2 15:26:32 localhost kernel: 3 ef 16 fd 80 44 1 36
Apr 2 15:26:33 localhost kernel: 3 ef 17 1b 80 44 1 17
Apr 2 15:26:34 localhost kernel: 3 ef 17 11 80 41 1 24
Apr 2 15:26:35 localhost kernel: 3 ef 17 f 80 44 1 23
Apr 2 15:26:36 localhost kernel: 3 ef 17 3 80 44 1 2f
Apr 2 15:26:37 localhost kernel: 3 ef 16 ed 80 44 1 46
Apr 2 15:26:38 localhost kernel: 3 ef 17 28 80 41 1 d
Here the only case where the value returned by byte[5] is shaky. At
this point, the communication with the CAM is broken.
SCM CAM plugged, after module reload:
Apr 2 15:27:49 localhost kernel: 3 ef 17 24 80 44 1 e
Apr 2 15:27:59 localhost kernel: 3 ef 16 fb 80 44 1 38
Apr 2 15:28:00 localhost kernel: 3 ef 17 33 80 44 1 ff
Apr 2 15:28:00 localhost kernel: 3 ef 17 b 80 44 1 27
Apr 2 15:28:01 localhost kernel: 3 ef 16 fc 80 44 1 37
Apr 2 15:28:02 localhost kernel: 3 ef 16 e2 80 44 1 51
Apr 2 15:28:03 localhost kernel: 3 ef 16 ef 80 44 1 44
Apr 2 15:28:04 localhost kernel: 3 ef 16 f8 80 44 1 3b
Apr 2 15:28:04 localhost kernel: 3 ef 17 c 80 44 1 26
More information about the linux-dvb
mailing list