[DVB] CXD2099 - Question about the CAM clock

[DVB] CXD2099 - Question about the CAM clock

[Sébastien RAILLARD (COEXSI)]

Dear Oliver,

I’ve done some tests with the CAM reader from Digital Devices based on Sony
CXD2099 chip and I noticed some issues with some CAM:
* SMIT CAM    : working fine
* ASTON CAM   : working fine, except that it's crashing quite regularly
* NEOTION CAM : no stream going out but access to the CAM menu is ok

When looking at the CXD2099 driver code, I noticed the CAM clock (fMCLKI) is
fixed at 9MHz using the 27MHz onboard oscillator and using the integer
divider set to 3 (as MCLKI_FREQ=2).

I was wondering if some CAM were not able to work correctly at such high
clock frequency.

So, I've tried to enable the NCO (numeric controlled oscillator) in order to
setup a lower frequency for the CAM clock, but I wasn't successful, it's
looking like the frequency must be around the 9MHz or I can't get any
stream.

Do you know a way to decrease this CAM clock frequency to do some testing?

Best regards,
Sebastien.

Re: [DVB] CXD2099 - Question about the CAM clock

[Issa Gorissen]

> Dear Oliver,
> 
> I’ve done some tests with the CAM reader from Digital Devices based on
Sony
> CXD2099 chip and I noticed some issues with some CAM:
> * SMIT CAM    : working fine
> * ASTON CAM   : working fine, except that it's crashing quite regularly
> * NEOTION CAM : no stream going out but access to the CAM menu is ok
> 
> When looking at the CXD2099 driver code, I noticed the CAM clock (fMCLKI)
is
> fixed at 9MHz using the 27MHz onboard oscillator and using the integer
> divider set to 3 (as MCLKI_FREQ=2).
> 
> I was wondering if some CAM were not able to work correctly at such high
> clock frequency.
> 
> So, I've tried to enable the NCO (numeric controlled oscillator) in order
to
> setup a lower frequency for the CAM clock, but I wasn't successful, it's
> looking like the frequency must be around the 9MHz or I can't get any
> stream.
> 
> Do you know a way to decrease this CAM clock frequency to do some testing?
> 
> Best regards,
> Sebastien.

Weird that the frequency would pose a problem for those CAMs. The CI spec [1]
explains that the minimum byte transfer clock period must be 111ns. This gives
us a frequency of ~9MHz.

Anyway, wouldn't it be wiser to base MCLKI on TICLK ?

--
Issa

[1] http://www.dvb.org/technology/standards/En50221.V1.pdf

RE: [DVB] CXD2099 - Question about the CAM clock

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: Issa Gorissen [mailto:flop.m@usa.net]
> Sent: lundi 3 octobre 2011 15:18
> To: o.endriss@gmx.de; Sébastien RAILLARD
> Cc: Linux Media Mailing List
> Subject: Re: [DVB] CXD2099 - Question about the CAM clock
> 
> > Dear Oliver,
> >
> > I’ve done some tests with the CAM reader from Digital Devices based on
> Sony
> > CXD2099 chip and I noticed some issues with some CAM:
> > * SMIT CAM    : working fine
> > * ASTON CAM   : working fine, except that it's crashing quite
> regularly
> > * NEOTION CAM : no stream going out but access to the CAM menu is ok
> >
> > When looking at the CXD2099 driver code, I noticed the CAM clock
> > (fMCLKI)
> is
> > fixed at 9MHz using the 27MHz onboard oscillator and using the integer
> > divider set to 3 (as MCLKI_FREQ=2).
> >
> > I was wondering if some CAM were not able to work correctly at such
> > high clock frequency.
> >
> > So, I've tried to enable the NCO (numeric controlled oscillator) in
> > order
> to
> > setup a lower frequency for the CAM clock, but I wasn't successful,
> > it's looking like the frequency must be around the 9MHz or I can't get
> > any stream.
> >
> > Do you know a way to decrease this CAM clock frequency to do some
> testing?
> >
> > Best regards,
> > Sebastien.
> 
> Weird that the frequency would pose a problem for those CAMs. The CI
> spec [1] explains that the minimum byte transfer clock period must be
> 111ns. This gives us a frequency of ~9MHz.
> 

You're totally right about the maximum clock frequency specified in the
norm, but I had confirmation from CAM manufacturers that their CAM may not
work correctly up to this maximum frequency.

Usually, the CAM clock is coming from the input TS stream and I don't think
there is for now a DVB-S2 transponder having a 72mbps bitrate (so a 9MHz for
parallel CAM clocking).

> Anyway, wouldn't it be wiser to base MCLKI on TICLK ?
> 

I've tried to use mode C instead of mode D, and I have the same problem, so
I guess TICLK is around 72MHz.

It could be a good idea to use TICLK, but I don't know the value and if the
clock is constant or only active during data transmission.


Did you manage to enable and use the NCO of the CXD2099 (instead of the
integer divider) ?

> --
> Issa
> 
> [1] http://www.dvb.org/technology/standards/En50221.V1.pdf

RE: [DVB] CXD2099 - Question about the CAM clock

[Issa Gorissen]

> > 
> > > Dear Oliver,
> > >
> > > I’ve done some tests with the CAM reader from Digital Devices based on
> > Sony
> > > CXD2099 chip and I noticed some issues with some CAM:
> > > * SMIT CAM    : working fine
> > > * ASTON CAM   : working fine, except that it's crashing quite
> > regularly
> > > * NEOTION CAM : no stream going out but access to the CAM menu is ok
> > >
> > > When looking at the CXD2099 driver code, I noticed the CAM clock
> > > (fMCLKI)
> > is
> > > fixed at 9MHz using the 27MHz onboard oscillator and using the integer
> > > divider set to 3 (as MCLKI_FREQ=2).
> > >
> > > I was wondering if some CAM were not able to work correctly at such
> > > high clock frequency.
> > >
> > > So, I've tried to enable the NCO (numeric controlled oscillator) in
> > > order
> > to
> > > setup a lower frequency for the CAM clock, but I wasn't successful,
> > > it's looking like the frequency must be around the 9MHz or I can't get
> > > any stream.
> > >
> > > Do you know a way to decrease this CAM clock frequency to do some
> > testing?
> > >
> > > Best regards,
> > > Sebastien.
> > 
> > Weird that the frequency would pose a problem for those CAMs. The CI
> > spec [1] explains that the minimum byte transfer clock period must be
> > 111ns. This gives us a frequency of ~9MHz.
> > 
> 
> You're totally right about the maximum clock frequency specified in the
> norm, but I had confirmation from CAM manufacturers that their CAM may not
> work correctly up to this maximum frequency.
> 
> Usually, the CAM clock is coming from the input TS stream and I don't think
> there is for now a DVB-S2 transponder having a 72mbps bitrate (so a 9MHz
for
> parallel CAM clocking).
> 
> > Anyway, wouldn't it be wiser to base MCLKI on TICLK ?
> > 
> 
> I've tried to use mode C instead of mode D, and I have the same problem, so
> I guess TICLK is around 72MHz.
> 
> It could be a good idea to use TICLK, but I don't know the value and if the
> clock is constant or only active during data transmission.
> 
> 
> Did you manage to enable and use the NCO of the CXD2099 (instead of the
> integer divider) ?

No, but if your output to the CAM is slower than what comes from the ngene
chip, you will lose bytes, no ?

RE: [DVB] CXD2099 - Question about the CAM clock

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: Issa Gorissen [mailto:flop.m@usa.net]
> Sent: lundi 3 octobre 2011 15:59
> To: o.endriss@gmx.de; Sébastien RAILLARD
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> 
> > >
> > > > Dear Oliver,
> > > >
> > > > I’ve done some tests with the CAM reader from Digital Devices
> > > > based on
> > > Sony
> > > > CXD2099 chip and I noticed some issues with some CAM:
> > > > * SMIT CAM    : working fine
> > > > * ASTON CAM   : working fine, except that it's crashing quite
> > > regularly
> > > > * NEOTION CAM : no stream going out but access to the CAM menu is
> > > > ok
> > > >
> > > > When looking at the CXD2099 driver code, I noticed the CAM clock
> > > > (fMCLKI)
> > > is
> > > > fixed at 9MHz using the 27MHz onboard oscillator and using the
> > > > integer divider set to 3 (as MCLKI_FREQ=2).
> > > >
> > > > I was wondering if some CAM were not able to work correctly at
> > > > such high clock frequency.
> > > >
> > > > So, I've tried to enable the NCO (numeric controlled oscillator)
> > > > in order
> > > to
> > > > setup a lower frequency for the CAM clock, but I wasn't
> > > > successful, it's looking like the frequency must be around the
> > > > 9MHz or I can't get any stream.
> > > >
> > > > Do you know a way to decrease this CAM clock frequency to do some
> > > testing?
> > > >
> > > > Best regards,
> > > > Sebastien.
> > >
> > > Weird that the frequency would pose a problem for those CAMs. The CI
> > > spec [1] explains that the minimum byte transfer clock period must
> > > be 111ns. This gives us a frequency of ~9MHz.
> > >
> >
> > You're totally right about the maximum clock frequency specified in
> > the norm, but I had confirmation from CAM manufacturers that their CAM
> > may not work correctly up to this maximum frequency.
> >
> > Usually, the CAM clock is coming from the input TS stream and I don't
> > think there is for now a DVB-S2 transponder having a 72mbps bitrate
> > (so a 9MHz
> for
> > parallel CAM clocking).
> >
> > > Anyway, wouldn't it be wiser to base MCLKI on TICLK ?
> > >
> >
> > I've tried to use mode C instead of mode D, and I have the same
> > problem, so I guess TICLK is around 72MHz.
> >
> > It could be a good idea to use TICLK, but I don't know the value and
> > if the clock is constant or only active during data transmission.
> >
> >
> > Did you manage to enable and use the NCO of the CXD2099 (instead of
> > the integer divider) ?
> 
> No, but if your output to the CAM is slower than what comes from the
> ngene chip, you will lose bytes, no ?

The real bandwidth of my transponder is 62mbps, so I've room to decrease the
CAM clock.

I did more tests with the NCO, and I've strange results:
* Using MCLKI=0x5553 => fMCLKI= 8,99903 => Not working, a lot of TS errors
* Using MCLKI=0x5554 => fMCLKI= 8,99945 => Working fine
* Using MCLKI=0x5555 => fMCLKI= 8,99986 => Not working, a lot of TS errors

It's strange that changing very slightly the clock make so much errors!

RE: [DVB] CXD2099 - Question about the CAM clock

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: lundi 3 octobre 2011 16:46
> To: 'Issa Gorissen'; o.endriss@gmx.de
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> 
> 
> 
> > -----Original Message-----
> > From: Issa Gorissen [mailto:flop.m@usa.net]
> > Sent: lundi 3 octobre 2011 15:59
> > To: o.endriss@gmx.de; Sébastien RAILLARD
> > Cc: 'Linux Media Mailing List'
> > Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> >
> > > >
> > > > > Dear Oliver,
> > > > >
> > > > > I’ve done some tests with the CAM reader from Digital Devices
> > > > > based on
> > > > Sony
> > > > > CXD2099 chip and I noticed some issues with some CAM:
> > > > > * SMIT CAM    : working fine
> > > > > * ASTON CAM   : working fine, except that it's crashing quite
> > > > regularly
> > > > > * NEOTION CAM : no stream going out but access to the CAM menu
> > > > > is ok
> > > > >
> > > > > When looking at the CXD2099 driver code, I noticed the CAM clock
> > > > > (fMCLKI)
> > > > is
> > > > > fixed at 9MHz using the 27MHz onboard oscillator and using the
> > > > > integer divider set to 3 (as MCLKI_FREQ=2).
> > > > >
> > > > > I was wondering if some CAM were not able to work correctly at
> > > > > such high clock frequency.
> > > > >
> > > > > So, I've tried to enable the NCO (numeric controlled oscillator)
> > > > > in order
> > > > to
> > > > > setup a lower frequency for the CAM clock, but I wasn't
> > > > > successful, it's looking like the frequency must be around the
> > > > > 9MHz or I can't get any stream.
> > > > >
> > > > > Do you know a way to decrease this CAM clock frequency to do
> > > > > some
> > > > testing?
> > > > >
> > > > > Best regards,
> > > > > Sebastien.
> > > >
> > > > Weird that the frequency would pose a problem for those CAMs. The
> > > > CI spec [1] explains that the minimum byte transfer clock period
> > > > must be 111ns. This gives us a frequency of ~9MHz.
> > > >
> > >
> > > You're totally right about the maximum clock frequency specified in
> > > the norm, but I had confirmation from CAM manufacturers that their
> > > CAM may not work correctly up to this maximum frequency.
> > >
> > > Usually, the CAM clock is coming from the input TS stream and I
> > > don't think there is for now a DVB-S2 transponder having a 72mbps
> > > bitrate (so a 9MHz
> > for
> > > parallel CAM clocking).
> > >
> > > > Anyway, wouldn't it be wiser to base MCLKI on TICLK ?
> > > >
> > >
> > > I've tried to use mode C instead of mode D, and I have the same
> > > problem, so I guess TICLK is around 72MHz.
> > >
> > > It could be a good idea to use TICLK, but I don't know the value and
> > > if the clock is constant or only active during data transmission.
> > >
> > >
> > > Did you manage to enable and use the NCO of the CXD2099 (instead of
> > > the integer divider) ?
> >
> > No, but if your output to the CAM is slower than what comes from the
> > ngene chip, you will lose bytes, no ?
> 
> The real bandwidth of my transponder is 62mbps, so I've room to decrease
> the CAM clock.
> 
> I did more tests with the NCO, and I've strange results:
> * Using MCLKI=0x5553 => fMCLKI= 8,99903 => Not working, a lot of TS
> errors
> * Using MCLKI=0x5554 => fMCLKI= 8,99945 => Working fine
> * Using MCLKI=0x5555 => fMCLKI= 8,99986 => Not working, a lot of TS
> errors
> 
> It's strange that changing very slightly the clock make so much errors!
> 

I managed to find a series of values that are working correctly for MCLKI:

MCLKI = 0x5554 - i * 0x0c

In my case I can go down to 0x5338 before having TS errors.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

RE: [DVB] CXD2099 - Question about the CAM clock

[Issa Gorissen]

> 
> I managed to find a series of values that are working correctly for MCLKI:
> 
> MCLKI = 0x5554 - i * 0x0c
> 
> In my case I can go down to 0x5338 before having TS errors.
> 

>From CXD2099 specs
--
It is a requirement for the frequency of MCLKI to be set higher than the input
data rate. ie 8
times TICLK. If this condition is not met then the internal buffer will
overflow and the register
TSIN_FIFO_OVFL is set to 1. This register should be read at regular intervals
to ensure reliable
operation.
--

Watch out that you're not slowly overflowing the internal buffer if MCLKI is
not fast enough...

Are you working with the ddbridge ?

--
Issa

RE: [DVB] CXD2099 - Question about the CAM clock

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: Issa Gorissen [mailto:flop.m@usa.net]
> Sent: mardi 4 octobre 2011 13:57
> To: o.endriss@gmx.de; sr@coexsi.fr
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> 
> >
> > I managed to find a series of values that are working correctly for
> MCLKI:
> >
> > MCLKI = 0x5554 - i * 0x0c
> >
> > In my case I can go down to 0x5338 before having TS errors.
> >
> 
> From CXD2099 specs
> --
> It is a requirement for the frequency of MCLKI to be set higher than the
> input data rate. ie 8 times TICLK. If this condition is not met then the
> internal buffer will overflow and the register TSIN_FIFO_OVFL is set to
> 1. This register should be read at regular intervals to ensure reliable
> operation.
> --
> 
> Watch out that you're not slowly overflowing the internal buffer if
> MCLKI is not fast enough...

That's the problem, if the input clock can't be slowed down...
I didn't find any parameters that allows for decreasing the clock.

> 
> Are you working with the ddbridge ?

Yes, I'm working with the ddbridge (lattice)

> 
> --
> Issa