[linux-dvb] Re: Twinhan CI experimental support
domi.dumont at free.fr
Mon Apr 4 11:35:53 CEST 2005
Frederic CAND <frederic.cand at anevia.com> writes:
> I just suppose all the cams will work if one works but it's when
> supposing you only have one CAM and couldn't test with others .
Aston has lended me a CAM which does not work with Twinhan: The CAM is
detected, but the communication is broken (I don't know why).
And SCM CAM works... for a while. I still have not found why
de-scrambling fails. (See the various rants I posted last week)
>.. the idea is to know there are things to do to make different CAMS
After loading the modules, try a 'dst_test app_info' , check the
/var/log/messages to see MCU reply. I get either:
Apr 2 22:45:23 localhost kernel: ca_get_app_info: Application Type=, Application Vendor=, Vendor Code=
Apr 2 22:45:23 localhost kernel: ca_get_app_info: Application info=[Viaccess]
Or some garbage:
Apr 3 19:05:33 localhost kernel: ca_get_app_info: Application Type=, Application Vendor=, Vendor Code=
(Aplication Info string shows a lot of garbage corresponding to 0xff)
App_info tests basic communication with the CAM. If you can try that
with a lot of diferent CAMs, it might (emphasis on might) give a clue.
When the CAM communication is broken, the only way to fix it is to
reload dvb-bt8xx module.
>>>... I also noticed the dvb-bt8xx module init takes some time (3 or 4
>>>seconds), so maybe there's something to do with it...
There's a 4s second wait. Without it the communication with CAM does
not work. (at least with my CAM and my card ...)
> I'm not sure I'll be of a great help since I'm not an expert but a
> beginner ... but I have to make this twinhan card work so I'll do my
> best to help ... keeping in mind that for me, the priority is to see
> the card working, not earning 3 seconds at startup (even if it has to
> change, though)
I've managed to make it work, but it's not reliable.
More information about the linux-dvb