<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Roger James wrote:
<blockquote cite="mid:48B69A3E.4020808@beardandsandals.co.uk"
type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Roger James wrote:
<blockquote cite="mid:48B5E1C6.9040908@beardandsandals.co.uk"
type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Werner Hauger wrote:
<blockquote
cite="mid:6f94e1a00808271238q1d42e219t9d2b6c493d056b0c@mail.gmail.com"
type="cite">
<pre wrap="">So what revision of the CI board do you have ?
</pre>
<pre wrap="">I'm glad you got it working. I wonder if that means there we indeed
have different CI firmware on new CI boards that need to be catered
for in the driver.
</pre>
<blockquote type="cite">
<pre wrap="">budget_ci: Slot status d587c000 set to NONE 3 ci_version a0
</pre>
</blockquote>
</blockquote>
Werner,<br>
<br>
The version number printed on the CI board is 1.0A. The firmware
version reported by the board is 0xa0 (it is at the end of the above
diagnostic.<br>
<br>
I think it might be an idea to patch the driver to log the version by
default so we can build a picture of which firmware/board/CAM
combinations generate interrupts. I am bit suspicious of the fact that
my 1.0 rev of the CI board is not generating interrupts in this case,
whereas you said in an earlier posting that you had a 1.0 rev of the
board that was generating interrupts with a Nova S card (were you using
a TT CI board with a Hauppauge card, I am little confused). I should be
getting an AstonCrypt CAM in the next few days. I want to test that and
see if that does generate interrupts with my 1.0A CI board before I
would suggest adding firmware version 0xa0 to the list of the ones that
do not generate interrupts.<br>
<br>
Roger<br>
</blockquote>
Werner,<br>
<br>
I spoke slightly too soon. I tested using gnutv -cammenu and got a
"CAWrite failed" message. I managed to fix this by increasing the
timeout in dvb_ca_en50221_io_write to 10 seconds ( from 0.5 seconds). I
am not too hopeful of success when I try some real decrypting, but that
will have to wait for a while.<br>
<br>
Roger<br>
</blockquote>
I have now got hold of an AstonCrypt 1.05 CAM and done a quick test
against it. Once again the CI board required polling to initialise
properly, so it looks like this is related to the firmware version and
not specific to a particular CAM. However I am still not entirely
convinced. This is because of two factors; firstly CAM insertion and
removal interrupts are generated, and secondly I still have not managed
to get sensible data out of the card when the CAM and a smartcard is
inserted, even on unencrypted channels. But this may be finger trouble
and lack of understanding of the dvb-apps utils.<br>
<br>
On the second factor. I have been testing using gnutv and szap. One
thing I notice is that I can get a FE lock reported using szap, I
cannot get one using gnutv. Any ideas anyone?<br>
<br>
Roger<br>
</body>
</html>