Frederic CAND <frederic.cand@xxxxxxxxxx> 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 >work . 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=[1], Application Vendor=[1280], Vendor Code=[1280] 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=[185], Application Vendor=[65535], Vendor Code=[65535] (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. HTH
