On Monday 07 Nov 2005 20:44, irk wrote: > From: "Andrew de Quincey" <adq_dvb@xxxxxxxxxxxxx> > > >> I wonder if it would be possible to simple have some form of > >> retransmission > >> at the application level... I'll have a look at en50221. > > > > Hmm, I've had a look. Unfortunately, even though the CAM control protocol > > is > > massively overdesigned for what is needed, it doesn't seem to provide any > > support for error detection or retransmission of corrupt messages!! :( > > So again the question posed before: How the set-top folks do this that > there are no > visible problems? I suspect they use dedicated CI interface chips - for example the Atmel T90-FJR. Since they're dedicated, they can have workarounds to "fix" common CAM specific-problems. Or else they develop their own interface using custom logic (e.g. an ASIC or CPLD); either way they will have far more flexibility than the design currently used on the budget cards (see below). The budget cards are really _budget_. The ones I have dealt with both use the DEBI bus of the SAA7146 chip. This is a 16 bit general purpose digital expansion bus. The timing requirements of DEBI don't precisely match that required by EN50221 style CI interfaces.. although for many CAMs they are fine. It is likely not very tolerant of larger problems with the signals though, and as Georg reported, the matrix cards are pretty bad. Assuming it is a hardware problem (and it looks that way since other CAMs work flawlessly), there's not really much more I can do - beyond getting the basic data transfer routines up and running, there is virtually no configuration possible... Robert Schlabbach and I tried many times to get one of these non-functional cards working with no success. Even TT could not as I remember :( One thing you could try is to install the Hauppauge/TT/whatever windows software and see if the CAM is reliable in that. If so, then a workaround must be feasible, whether at a driver or application level.
