On Monday 07 Nov 2005 18:08, Georg Acher wrote: > On Mon, Nov 07, 2005 at 07:41:50PM +0200, irk wrote: > > I can add this symptom: > > > > I have two CAM's, one is called Matrix Revolutions, another is called > > X-CAM. These are CAM's which can be used with multiple encryption > > systems. I tested them with SECA Mediaguard. What happens is that X-CAM > > works perfectly but Matrix has big troubles. Lots of squares appear in > > the picture and driver complains > > about CRC errors. Both CAM's work perfectly in quite old set-top box. > > The signal integrity of some CAMs is quite bad. The have slow and and > irregular rise and fall times for the clock, with varying setup/hold times > for the data. This can lead to data corruption on the receiving side of the > CI slot. AFAIK the Matrix cam was one of the worst I've seen. I can't > imagine how one create such an "analog" clock signal from a digital > source... > > Other CAMs (eg. Dragon Twin) have a bug in the PCMCIA bus interface and > ignore the slot specific CE1 and use only OE/WE for decoding. If you have > two slots with shared OE/WE (which is quite normal, eg. the FF cards with > the CI slot extension), only one CAM works. A second CAM (no matter which > type) is not correctly detected due to bus collisions. > > In short: There is so much badly designed crap in the CAM market. It is > a wonder that at least some CAM/receiver combinations work... Hmm, that sounds quite likely then - the "budget CI" hardware simply may not be as tolerant of these weirdnesses as commerical receivers. The budget interfaces generally are wired directly to the saa7146 DEBI bus with minimal surrounding logic, whereas commercial receivers (and the TT fullfeatured cards) likely have a "proper" CI interface chip.
