RE: CI/CAM support for offline (from file) decoding

2012-01-26 Thread COEXSI 


> -Original Message-
> From: Kovacs Balazs [mailto:b...@bitklub.hu]
> Sent: jeudi 26 janvier 2012 14:45
> To: Sébastien RAILLARD (COEXSI)
> Cc: 'Ralph Metzler'; linux-media@vger.kernel.org
> Subject: Re: CI/CAM support for offline (from file) decoding
> 
> 
> 
> 
> >> -Original Message-
> >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> >> ow...@vger.kernel.org] On Behalf Of Ralph Metzler
> >> Sent: jeudi 26 janvier 2012 13:21
> >> To: linux-media@vger.kernel.org
> >> Subject: Re: CI/CAM support for offline (from file) decoding
> >>
> >> Kovacs Balazs writes:
> >>  > Yes,  i  thought about that, but i need the Hardware CAM + CI,
> >> because  > it's chip paired encryption. It means in my situation that
> >> the EMM and  > ECM is also encrypted so it's hard to use in a SoftCam
> >> configuration.
> >>  >
> >>  > I hope there's a solution in the DVB driver space.
> >>  >
> >>  > I receive the signal via RF or IP. If via RF i think it can be
> >> decoded  > via  the  HW,  and  the  record  it  to  disk,  but i need
> >> the full TS  > decrypted, and i think it's not possible (to decrypt
> >> all the encrypted  > ES  which  can be 20-30-40 in real time when i
> >> receive the signal). In  > IP  configuration  it's also not possible.
> >> So i have the recorded full  > TS  pieces  and somehow i have to
> >> decrypt with a
> >> CAM+Card paired to each  > other.  Of  course  i know that the
> >> decryption is only possible if the  > Smartcard  has  the
> >> authorization in those date ranges when the files  > was recorded. I
> >> have seen this kind of solution in Windows, but i need  > it on Linux
> now.
> >>
> >> Yes, you can do that, but only if the hardware supports it. Most
> >> cards with CAM/CI are hardwired in such a way that the transport
> >> stream comes from the demodulator, goes through the CAM/CI and then
> >> into the PCIe/PCI bridge. There are only a few cards where you can
> >> send a TS from memory to the CAM/CI and back.
> >>
> >> -Ralph
> >>
> >>
> 
> > The "Octopus CI" from "Digital Devices" is the only one I know where
> > you can input the TS stream directly to the CAM:
> > http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ViewObjectID=
> > 370117
> > 11
> 
> Is  this  the  only  solution?  I need s2 tuner and IP input (from the
> motherboard's  Ethernet)  and  record  them to file splices. Then (for
> request)  i  have to decrypt one or more ES from the recorded file and
> push them back. It's a DVB monitoring solution.
> 

If you need to decrypt stream using an official CAM, I don't think you'll
have too much choice.
By the way, this "Octopus CI" card has 2 connectors where you can connect
two double DVB-S2 tuners.
Tuners and CAM work independently.

If you don't need an official CAM, maybe you can look to the OSCAM
project...

> thanks
> Balazs


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

RE: CI/CAM support for offline (from file) decoding

2012-01-26 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Ralph Metzler
> Sent: jeudi 26 janvier 2012 13:21
> To: linux-media@vger.kernel.org
> Subject: Re: CI/CAM support for offline (from file) decoding
> 
> Kovacs Balazs writes:
>  > Yes,  i  thought about that, but i need the Hardware CAM + CI,
> because  > it's chip paired encryption. It means in my situation that
> the EMM and  > ECM is also encrypted so it's hard to use in a SoftCam
> configuration.
>  >
>  > I hope there's a solution in the DVB driver space.
>  >
>  > I receive the signal via RF or IP. If via RF i think it can be
> decoded  > via  the  HW,  and  the  record  it  to  disk,  but i need
> the full TS  > decrypted, and i think it's not possible (to decrypt all
> the encrypted  > ES  which  can be 20-30-40 in real time when i receive
> the signal). In  > IP  configuration  it's also not possible. So i have
> the recorded full  > TS  pieces  and somehow i have to decrypt with a
> CAM+Card paired to each  > other.  Of  course  i know that the
> decryption is only possible if the  > Smartcard  has  the  authorization
> in those date ranges when the files  > was recorded. I have seen this
> kind of solution in Windows, but i need  > it on Linux now.
> 
> Yes, you can do that, but only if the hardware supports it. Most cards
> with CAM/CI are hardwired in such a way that the transport stream comes
> from the demodulator, goes through the CAM/CI and then into the PCIe/PCI
> bridge. There are only a few cards where you can send a TS from memory
> to the CAM/CI and back.
> 
> -Ralph
> 
> 

The "Octopus CI" from "Digital Devices" is the only one I know where you can
input the TS stream directly to the CAM:
http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ViewObjectID=370117
11


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

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

RE: [DVB Digital Devices Cine CT V6] status support

2012-01-09 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Martin Herrman
> Sent: lundi 9 janvier 2012 09:06
> To: linux-media@vger.kernel.org
> Subject: Re: [DVB Digital Devices Cine CT V6] status support
> 
> 2012/1/8 Sébastien RAILLARD (COEXSI) :
> >
> >> http://shop.digital-
> >> devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/62357162/Categ
> >> ori es/HDTV_Karten_fuer_Mediacenter/Cine_PCIe_Serie/DVBC_T
> >>
> >> But.. is this card supported by the Linux kernel?
> >>
> >
> > The short answer is yes, and as far as I know, it's working fine with
> > DVB-T (I've never tested the DVB-C).
> > For support, you need to compile the drivers from Oliver Endriss as
> > they are not merged in mainstream kernel.
> >
> > Check here (kernel > 2.6.31):
> > http://linuxtv.org/hg/~endriss/media_build_experimental/
> > Or here (kernel < 2.6.36) :
> > http://linuxtv.org/hg/~endriss/ngene-octopus-test/
> 
> Hi Sébastien,
> 
> thanks for your quick and positive reply.
> 
> Anyone here that tested it with DVB-C?
> 
> Are there any plans to merge this in the mainstream kernel?
> 

I think Oliver and Ralph are the best persons for answering these questions.

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

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

RE: [DVB Digital Devices Cine CT V6] status support

2012-01-08 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Martin Herrman
> Sent: dimanche 8 janvier 2012 23:15
> To: linux-media@vger.kernel.org
> Subject: [DVB Digital Devices Cine CT V6] status support
> 
> Dear list-members,
> 
> I'm building a HTPC based on Linux and searching for an DVB-C tuner card
> that:
> - fits the mobo (only pci-e/usb available, not pci or firewire)
> - fits the case (antec fusion remote, big enough)
> - is supported by linux
> - is dual tuner
> - supports encrypted HD content
> - provides good quality
> 
> digital devices cine ct v6 seems to be a perfect solution, together with
> a softcam based on smargo cartreader.
> 
> http://shop.digital-
> devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/62357162/Categori
> es/HDTV_Karten_fuer_Mediacenter/Cine_PCIe_Serie/DVBC_T
> 
> But.. is this card supported by the Linux kernel?
> 

The short answer is yes, and as far as I know, it's working fine with DVB-T
(I've never tested the DVB-C).
For support, you need to compile the drivers from Oliver Endriss as they are
not merged in mainstream kernel.

Check here (kernel > 2.6.31):
http://linuxtv.org/hg/~endriss/media_build_experimental/
Or here (kernel < 2.6.36) :
http://linuxtv.org/hg/~endriss/ngene-octopus-test/

> In 3.2.0-rc7 kernel I have found the driver for most of the digital
> devices cards, which includes the Cine S2 v6, but not the Cine CT v6.
> (I have also found some experimental drivers for CI moduels in the
> staging drivers section).
> 
> On the other hand, this discussion seems to indicate that drivers for
> Cine CT v6 should be working at this time:
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg37183.html
> 
> Can you give me an update on the status of a possibly existing driver
> for Cine CT v6?
> 
> Much thanks in advance,
> 
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: Tr. : Irdeto Cam Problem, any help

2011-12-11 Thread COEXSI 
"en50221_stdcam_llci_poll: Error reported by stack:-7" :
This isn’t really an error, it’s a design flaw in the libdvben50221 (it’s 
receving something it isn’t waiting for), it’s more a warning.I’ve published a 
patch for correcting that  few months ago (I think the patch wasn’t noticed...)

There must be something wrong elsewhere, as I never got this error 
"EN50221ERR_BADCAMDATA".
There is only one place where the code generate this error, in 
"en50221_stdcam_llci.c", during CAM reset :

static void llci_cam_in_reset(struct en50221_stdcam_llci *llci)
{
if (dvbca_get_cam_state(llci->cafd, llci->slotnum) != 
DVBCA_CAMSTATE_READY) {
return;
}

// register the slot
if ((llci->tl_slot_id = en50221_tl_register_slot(llci->tl, llci->cafd, 
llci->slotnum,
 
LLCI_RESPONSE_TIMEOUT_MS, LLCI_POLL_DELAY_MS)) < 0) {
llci->state = EN50221_STDCAM_CAM_BAD;
return;
}

// create a new connection on the slot
if (en50221_tl_new_tc(llci->tl, llci->tl_slot_id) < 0) {
llci->state = EN50221_STDCAM_CAM_BAD;
llci->tl_slot_id = -1;
en50221_tl_destroy_slot(llci->tl, llci->tl_slot_id);
return;
}

llci->state = EN50221_STDCAM_CAM_OK;
}

As there are many possible sources for this error, it may be useful to check 
the value of the "tl->error" variable.

Sebastien.


From: dub...@crans.org [mailto:dub...@crans.org] 
Sent: mercredi 7 décembre 2011 00:05
To: sraill...@coexsi.fr
Subject: Tr. : Irdeto Cam Problem, any help

C'est pour toi ça. 

-- 
Brice

- Forwarded message -
De : "JULIAN GARDNER" 
Pour : "linux-media@vger.kernel.org" 
Objet : Irdeto Cam Problem, any help
Date : mar., déc. 6, 2011 23:50


Been trying now to get my IrdetoCam and card working, im using mumudvb for this.

Turning on debug i get the folowing in the output

nfo:  Autoconf:  Channel number :   0, name : "ERT World"  service id 0 
Info:  Autoconf:  Multicast4 ip : 227.25.0.1:1234
Deb0:  Autoconf:  pids : 5001 (PMT), 1160 (Video (MPEG4-AVC)), 1120 
(Audio (MPEG2)), 
Info:  Main:  Channel "ERT World" is
now higly scrambled (97% of scrambled packets). Card 0
en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from 
module on slot 00

en50221_stdcam_llci_poll: Error reported by stack:-7

Deb1:  CAM:  Status change from EN50221_STDCAM_CAM_INRESET to 
EN50221_STDCAM_CAM_OK.
WARN: 
CAM:  Transport Layer Error change from EN50221ERR_NONE (No Error.) to 
EN50221ERR_BADCAMDATA (CAM supplied an invalid request.)
Deb1:  CAM:  CAM Application_Info_Callback
Info:  CAM:  CAM Application type: 01
Info:  CAM:  CAM Application manufacturer: cafe
Info:  CAM:  CAM Manufacturer code: babe
Info:  CAM:  CAM Menu string: Irdeto Access

Now can anybody help with the -7 error, as i am getting no decryption.

Patches would be welcome, before i start trying to delve deeper in

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

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

[DVB] ddbridge driver oops

2011-11-07 Thread COEXSI 
Dear Ralph,

I had a crash when testing the latest ddbridge driver.
I didn't manage to get all the call trace, but I manage to get some
information where the crash is coming from.
It seems to be related with a irq processing problem or scheduling/power
management.

Using gdb and the call trace address, it shows me an origin in line 2021
from this code "tasklet_schedule(&dev->dma[0].tasklet);" :

2016if (s & 0x0004)
2017irq_handle_i2c(dev, 2);
2018if (s & 0x0008)
2019irq_handle_i2c(dev, 3);
2020
2021if (s & 0x0100)
2022tasklet_schedule(&dev->dma[0].tasklet);
2023if (s & 0x0200)
2024tasklet_schedule(&dev->dma[1].tasklet);
2025if (s & 0x0400)

Here is a part of the call trace I managed to get:

error_code
init_sched_groups_power
get_signal_to_deliver
wake_up_common
spin_lock_irqsave
wake_up
irq_handler+0x2a5/0x490 [ddbridge] => this translate to the code above

Sebastien

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

RE: [DVB] Digital Devices Cine CT V6 support

2011-10-27 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Ralph Metzler
> Sent: lundi 24 octobre 2011 20:31
> To: S é bastien RAILLARD (COEXSI)
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] Digital Devices Cine CT V6 support
> 
> Sébastien RAILLARD (COEXSI) writes:
>  > I've seen a new parameter "ts_loop", can you explain how it's
> working?
>  > Is-it for sending the stream from the demodulator directly to the CAM
> > reader?
> 
> No, it is mainly for testing. It declares one TAB as loopback, which
> means that the data output is directly connected to the input.
> 
> For redirecting a stream through a CI see the "redirect" attribute.
> I don't know if my small redirect readme was included in the package I
> sent to Oliver. So, I attached it below.
> 
> 
> -Ralph
> 
> 
> 
> Redirection of TS streams through CI modules is now supported through
> /sys/class/ddbridge/ddbridge0/redirect.
> It only works with cards based on the ddbridge PCIe bridge, not with
> nGene based cards.
> 
> It is set up in such a way that you can write "AB CD" to a "redirect"
> attribute and data from input B of card A is then piped through port D
> (meaning TAB (D+1) which uses output D and input 2*D for CI io) of card
> C and then shows up in the demux device belonging to input B (input
> (B&1) of TAB (B/2+1)) of card A.
> 
> E.g.:
> 
> echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect
> 
> will pipe input 0 of card 0 through CI at port 1 (TAB 2) of card 0.
> 

Dear Ralph,

I've made two diagrams (see below) to explain the numbering based on your
explanation and the driver code source.
I hope they are right and it can help for understanding the octopus bridge.

The good news with the new redirect function is we can emulate the
traditional CAM handling and then use the current DVB software without
modification.

Best regards,
Sebastien.


  OCTOPUS BRIDGE

++
  Tuner 0 -> Input 0 -> ||
| Port 0 - TAB 1 | -> Output 0
  Tuner 1 -> Input 1 -> ||
++
  Tuner 0 -> Input 2 -> ||
| Port 1 - TAB 2 | -> Output 1
  Tuner 1 -> Input 3 -> ||
++
  Tuner 0 -> Input 4 -> ||
| Port 2 - TAB 3 | -> Output 2
  Tuner 1 -> Input 5 -> ||
++
  Tuner 0 -> Input 6 -> ||
| Port 3 - TAB 4 | -> Output 3
  Tuner 1 -> Input 7 -> ||
++


 CineS2 v6 + 2 CAM Readers

++
  Tuner 0 -> Input 0 -> ||
| Port 0 - TAB 1 | -> Output 0
  Tuner 1 -> Input 1 -> | DVB-S2 |
++
 Input 2 -> ||
| Port 1 - TAB 2 | -> Output 1
 Input 3 -> ||
++
CAM 0 -> Input 4 -> ||
| Port 2 - TAB 3 | -> Output 2 -> CAM 0
 Input 5 -> |   CAM  |
++
CAM 1 -> Input 6 -> ||
| Port 3 - TAB 4 | -> Output 3 -> CAM 1
 Input 7 -> |   CAM  |
++

Two redirections to set : 

* "X0 X2" (input #0 to port #2)
* "X1 X3" (input #1 to port #3)

Where X is the device number.


> Redirection should only be done right after loading the driver (or
> booting if the driver is built-in) and before using the devices in any
> way.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: [DVB] Digital Devices Cine CT V6 support

2011-10-24 Thread COEXSI 


> -Original Message-
> From: Ralph Metzler [mailto:r...@metzlerbros.de]
> Sent: lundi 24 octobre 2011 20:31
> To: S é bastien RAILLARD (COEXSI)
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] Digital Devices Cine CT V6 support
> 
> Sébastien RAILLARD (COEXSI) writes:
>  > I've seen a new parameter "ts_loop", can you explain how it's
> working?
>  > Is-it for sending the stream from the demodulator directly to the CAM
> > reader?
> 
> No, it is mainly for testing. It declares one TAB as loopback, which
> means that the data output is directly connected to the input.
> 

Ok

> For redirecting a stream through a CI see the "redirect" attribute.
> I don't know if my small redirect readme was included in the package I
> sent to Oliver. So, I attached it below.
> 
> 
> -Ralph
> 
> 
> 
> Redirection of TS streams through CI modules is now supported through
> /sys/class/ddbridge/ddbridge0/redirect.
> It only works with cards based on the ddbridge PCIe bridge, not with
> nGene based cards.
> 
> It is set up in such a way that you can write "AB CD" to a "redirect"
> attribute and data from input B of card A is then piped through port D
> (meaning TAB (D+1) which uses output D and input 2*D for CI io) of card
> C and then shows up in the demux device belonging to input B (input
> (B&1) of TAB (B/2+1)) of card A.
> 

Great feature, thanks!

> E.g.:
> 
> echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect
> 
> will pipe input 0 of card 0 through CI at port 1 (TAB 2) of card 0.
> 
> Redirection should only be done right after loading the driver (or
> booting if the driver is built-in) and before using the devices in any
> way.


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

RE: [DVB] Digital Devices Cine CT V6 support

2011-10-24 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Oliver Endriss
> Sent: lundi 24 octobre 2011 09:06
> To: Sébastien RAILLARD (COEXSI)
> Cc: Linux Media Mailing List
> Subject: Re: [DVB] Digital Devices Cine CT V6 support
> 
> Hi,
> 
> > Using your latest development tree (hg clone
> > http://linuxtv.org/hg/~endriss/media_build_experimental), I have made
> > a small modification in ddbridge-core.c (see below) to make the new
> > "Cine CT V6" card detected by the ddbridge module.
> >
> > With this small patch, the card is now detected, but not the double
> > C/T tuner onboard.
> 
> This cannot work, as the cards requires different frontend drivers.
> 
> Please try a fresh check-out from
>   http://linuxtv.org/hg/~endriss/media_build_experimental
> 
> The Cine CT v6 is supported now.
> 

Thank you for the update, we'll test it soon, we're waiting for the new
double-CI reader support.

I've seen a new parameter "ts_loop", can you explain how it's working?
Is-it for sending the stream from the demodulator directly to the CAM
reader?


> > Also, I was wondering why they put a male and a female RF connectors
> > on the "Cine CT V6" (maybe a loop-through?) where there are two female
> > RF connectors on the "DuoFlex CT" card.
> 
> The second connector of the Cine CT is the loop-through output.
> 

Ok

> CU
> Oliver
> 
> --
> 
> VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
> 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
> Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder

2011-10-06 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Manu Abraham
> Sent: mercredi 21 septembre 2011 19:53
> To: Mauro Carvalho Chehab
> Cc: Lutz Sammer; linux-media@vger.kernel.org
> Subject: Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
> 
> Mauro,
> 
> On Wed, Sep 21, 2011 at 10:14 PM, Mauro Carvalho Chehab
>  wrote:
> > Em 04-05-2011 08:27, Lutz Sammer escreveu:
> >> On 05/04/11 01:16, Mauro Carvalho Chehab wrote:
> >>> Em 13-04-2011 21:05, Lutz Sammer escreveu:
> > On 05/04/11 21:07, Steffen Barszus wrote:
> >> On Tue, 05 Apr 2011 13:00:14 +0200 "Issa Gorissen"
> >>  wrote:
> >>
> >>> Hi,
> >>>
> >>> Eutelsat made a recent migration from DVB-S to DVB-S2 (since
> >>> 31/3/2011) on two transponders on HB13E
> >>>
> >>> - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500
> >>> Msymb/s 0.2 Pilot off Polar H
> >>>
> >>> - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500
> >>> Msymb/s 0.2 Pilot off Polar H
> >>>
> >>>
> >>> Before those changes, with my TT S2 3200, I was able to watch TV
> >>> on those transponders. Now, I cannot even tune on those
> >>> transponders. I have tried with scan-s2 and w_scan and the
> latest drivers from git.
> >>> They both find the transponders but cannot tune onto it.
> >>>
> >>> Something noteworthy is that my other card, a DuoFlex S2 can
> >>> tune fine on those transponders.
> >>>
> >>> My question is; can someone try this as well with a TT S2 3200
> >>> and post the results ?
> >> i read something about it lately here (german!):
> >> http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv
> >> -dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938
> >>
> >> It says in stb0899_drv.c function:
> >> static void stb0899_set_iterations(struct stb0899_state *state)
> >>
> >> This:
> >> reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER);
> >> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
> >> stb0899_write_s2reg(state, STB0899_S2DEMOD,
> >> STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg);
> >>
> >> should be replaced with this:
> >>
> >> reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER);
> >> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
> >> stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER,
> >> STB0899_OFF0_MAX_ITER, reg);
> >>
> >> Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2
> >> lines affected.
> >>
> >> Kind Regards
> >>
> >> Steffen
> > Hi Steffen,
> >
> > Unfortunately, it does not help in my case. Thx anyway.
> 
>  Try my locking fix. With above patch I can lock the channels
>  without problem.
> >>>
> >>> Can someone confirm that such patch would fix the issue? If so,
> >>> please forward it in a way that it could be applied (patch is
> >>> currently line-wrapped), and submit with some comments/description
> and your SOB.
> >>>
> >>> As the patch is currently broken, I'm just marking it as rejected at
> patchwork.
> >>>
> >>> Manu,
> >>>
> >>> Please take a look on this trouble report.
> >>>
> >>
> >> Sorry, the things are mixed here. My patch (resend and hopefully this
> >> time not broken) handles only DVB-S transponders.
> >>
> >> The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz
> >> for me.  But I have very weak receiption,
> >>

We did a lot of experiments with this card and these 2 transponders, and
here is what you need:
* The dish must be perfectly oriented
* Check carefully the X-pol (LNB rotation)
* Be careful that all the LNB are not equal: we managed to get good results
with some LNBs and never manage to have reception with other models of LNB
* It seems that the DVB-S2 demodulator (that is quite old now) in this card
is very sensitive to bad signals and maybe sensitive to cross polarization
more than other demodulators.

So make a short answer: to correct the issues with these specifics
transponders and this card, we first do a fine dish/LND orientation and then
change the LNB, usually, it's enough. Specific measurement tool is needed to
make good work.

Finally, it isn't that much a driver problem in my opinion.

> >> Johns
> >
> > Manu,
> >
> > We're still missing your review on this patch[1], or it were
> > eventually missed. Please review it.
> >
> > Thanks,
> > Mauro
> >
> > [1] http://patchwork.linuxtv.org/patch/6511/
> >
> 
> Patch is good and correct. Thanks.
> Reviewed-by: Manu Abraham 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
M

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

2011-10-06 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: mardi 4 octobre 2011 13:57
> To: o.endr...@gmx.de; s...@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


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

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

2011-10-03 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: lundi 3 octobre 2011 16:46
> To: 'Issa Gorissen'; o.endr...@gmx.de
> Cc: 'Linux Media Mailing List'
> Subject: RE: [DVB] CXD2099 - Question about the CAM clock
> 
> 
> 
> > -Original Message-
> > From: Issa Gorissen [mailto:flo...@usa.net]
> > Sent: lundi 3 octobre 2011 15:59
> > To: o.endr...@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=0x => 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 majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

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

2011-10-03 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: lundi 3 octobre 2011 15:59
> To: o.endr...@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=0x => fMCLKI= 8,99986 => Not working, a lot of TS errors

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


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

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

2011-10-03 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: lundi 3 octobre 2011 15:18
> To: o.endr...@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


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

[DVB] CXD2099 - Question about the CAM clock

2011-10-01 Thread 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.



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

[DVB] Digital Devices Cine CT V6 support

2011-09-23 Thread COEXSI 
Dear Oliver,

Using your latest development tree (hg clone
http://linuxtv.org/hg/~endriss/media_build_experimental), I have made a
small modification in ddbridge-core.c (see below) to make the new "Cine CT
V6" card detected by the ddbridge module.

With this small patch, the card is now detected, but not the double C/T
tuner onboard.
If I connect a "DuoFlex CT" on a port, the tuners of the add-in card are
detected.

Also, I was wondering why they put a male and a female RF connectors on the
"Cine CT V6" (maybe a loop-through?) where there are two female RF
connectors on the "DuoFlex CT" card.

Best regards,
Sebastien.


Before 
--

static struct ddb_info ddb_v6 = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Cine S2 V6 DVB adapter",
.port_num = 3,
};

And

DDB_ID(DDVID, 0x0003, DDVID, 0x0020, ddb_v6),

After
-

static struct ddb_info ddb_v6_s2 = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Cine S2 V6 DVB-S/S2 adapter",
.port_num = 3,
};

static struct ddb_info ddb_v6_ct = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Cine S2 V6 DVB-C/T adapter",
.port_num = 3,
};

And

DDB_ID(DDVID, 0x0003, DDVID, 0x0020, ddb_v6_s2),
DDB_ID(DDVID, 0x0003, DDVID, 0x0030, ddb_v6_ct),








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

RE: [DVB] Possible regression in stb6100 module for DVBS2 transponders

2011-07-06 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: lundi 4 juillet 2011 14:25
> To: "Sébastien RAILLARD (COEXSI)"
> Cc: Linux Media Mailing List; abraham.m...@gmail.com
> Subject: Re: [DVB] Possible regression in stb6100 module for DVBS2
> transponders
> 
> On 01/07/2011 10:44, Sébastien RAILLARD (COEXSI) wrote:
> > Dear Manu,
> >
> > I think there is a regression in your patch from December 2010
> > regarding the
> > stb6100 module.
> > With the latest version of stb6100 published in media_build git
> > branch, we can't tune the TT-S2-3200 on some DVBS2 transponders like
> > Hotbird 13E
> > 11681-H-27500 or Hotbird 13E 12692-H-27500.
> > After reverting to the previous stb6100_set_frequency function, it's
> > working fine.
> > So, there is maybe in issue in the last December code refactoring.
> >
> > Reference of the patch: "[media] stb6100: Improve tuner performance"
> > http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/dvb/fr
> > ontend s/stb6100.c;h=bc1a8af4f6e105181670ee33ebe111f98425e0ff;hb=HEAD
> >
> > See below for the code removed from the stb6100.c file (the
> > stb6100_set_frequency function) and the code added (the previous
> > stb6100_set_frequency function and the stb6100_write_regs function).
> >
> > Best regards,
> > Sebastien.
> 
> Reported back in may
> [http://www.mail-archive.com/linux-media@vger.kernel.org/msg31334.html]

I can confirm what was reported by Issa, my problem was solved after
applying these two patches:

1- https://patchwork.kernel.org/patch/244201/
Why this patch is noted as "refused"? 
It seems to solve the last issues encountered with the TT-S2-3200.

2- https://patchwork.kernel.org/patch/753392/
This patch is still in "RFC"

And removing this one that seem to introduce a regression, as noted before:
http://git.linuxtv.org/media_tree.git?a=commit;h=f14bfe94e459cb070a489e1786f
26d54e9e7b5de

Sebastien.






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

RE: [DVB] TT S-1500b tuning issue

2011-07-06 Thread COEXSI 


> -Original Message-
> From: Oliver Endriss [mailto:o.endr...@gmx.de]
> Sent: lundi 4 juillet 2011 00:43
> To: Linux Media Mailing List
> Cc: Sébastien RAILLARD (COEXSI); Malcolm Priestley
> Subject: Re: [DVB] TT S-1500b tuning issue
> 
> On Wednesday 29 June 2011 15:16:10 Sébastien RAILLARD wrote:
> > Dear all,
> >
> > We have found what seems to be a tuning issue in the driver for the
> > ALPS BSBE1-D01A used in the new TT-S-1500b card from Technotrend.
> > On some transponders, like ASTRA 19.2E 11817-V-27500, the card can
> > work very well (no lock issues) for hours.
> >
> > On some other transponders, like ASTRA 19.2E 11567-V-22000, the card
> > nearly never manage to get the lock: it's looking like the signal
> > isn't good enough.
> 
> Afaics the problem is caused by the tuning loop
> for (tm = -6; tm < 7;)
> in stv0288_set_frontend().
> 
> I doubt that this code works reliably.
> Apparently it never obtains a lock within the given delay (30us).
> 
> Could you please try the attached patch?
> It disables the loop and tries to tune to the center frequency.
> 

Ok, I've tested this patch with ASTRA 19.2 #24 transponder that wasn't
always working: it seems to work.
I think it would be great to test it for few days more to be sure.

> CU
> Oliver
> 
> --
> 
> VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
> 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
> Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
> 

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

[DVB] Possible regression in stb6100 module for DVBS2 transponders

2011-07-01 Thread COEXSI 
Dear Manu,

I think there is a regression in your patch from December 2010 regarding the
stb6100 module.
With the latest version of stb6100 published in media_build git branch, we
can't tune the TT-S2-3200 on some DVBS2 transponders like Hotbird 13E
11681-H-27500 or Hotbird 13E 12692-H-27500.
After reverting to the previous stb6100_set_frequency function, it's working
fine.
So, there is maybe in issue in the last December code refactoring.

Reference of the patch: "[media] stb6100: Improve tuner performance"
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/dvb/frontend
s/stb6100.c;h=bc1a8af4f6e105181670ee33ebe111f98425e0ff;hb=HEAD

See below for the code removed from the stb6100.c file (the
stb6100_set_frequency function) and the code added (the previous
stb6100_set_frequency function and the stb6100_write_regs function).

Best regards,
Sebastien.

- CODE ADDED -

static int stb6100_write_regs(struct stb6100_state *state, u8 regs[])
{
stb6100_normalise_regs(regs);
return stb6100_write_reg_range(state, ®s[1], 1, STB6100_NUMREGS -
1);
}

static int stb6100_set_frequency(struct dvb_frontend *fe, u32 frequency)
{
int rc;
const struct stb6100_lkup *ptr;
struct stb6100_state *state = fe->tuner_priv;
struct dvb_frontend_parameters p;

u32 srate = 0, fvco, nint, nfrac;
u8 regs[STB6100_NUMREGS];
u8 g, psd2, odiv;

if ((rc = stb6100_read_regs(state, regs)) < 0)
return rc;

if (fe->ops.get_frontend) {
dprintk(verbose, FE_DEBUG, 1, "Get frontend parameters");
fe->ops.get_frontend(fe, &p);
}
srate = p.u.qpsk.symbol_rate;

regs[STB6100_DLB] = 0xdc;
/* Disable LPEN */
regs[STB6100_LPEN] &= ~STB6100_LPEN_LPEN; /* PLL Loop disabled */

if ((rc = stb6100_write_regs(state, regs)) < 0)
return rc;

/* Baseband gain.   */
if (srate >= 1500)
g = 9;  //  +4 dB
else if (srate >= 500)
g = 11; //  +8 dB
else
g = 14; // +14 dB

regs[STB6100_G] = (regs[STB6100_G] & ~STB6100_G_G) | g;
regs[STB6100_G] &= ~STB6100_G_GCT; /* mask GCT */
regs[STB6100_G] |= (1 << 5); /* 2Vp-p Mode */

/* VCO divide ratio (LO divide ratio, VCO prescaler enable).*/
if (frequency <= 1075000)
odiv = 1;
else
odiv = 0;
regs[STB6100_VCO] = (regs[STB6100_VCO] & ~STB6100_VCO_ODIV) | (odiv
<< STB6100_VCO_ODIV_SHIFT);

if ((frequency > 1075000) && (frequency <= 1325000))
psd2 = 0;
else
psd2 = 1;
regs[STB6100_K] = (regs[STB6100_K] & ~STB6100_K_PSD2) | (psd2 <<
STB6100_K_PSD2_SHIFT);

/* OSM  */
for (ptr = lkup;
 (ptr->val_high != 0) && !CHKRANGE(frequency, ptr->val_low,
ptr->val_high);
 ptr++);
if (ptr->val_high == 0) {
printk(KERN_ERR "%s: frequency out of range: %u kHz\n",
__func__, frequency);
return -EINVAL;
}
regs[STB6100_VCO] = (regs[STB6100_VCO] & ~STB6100_VCO_OSM) |
ptr->reg;

/* F(VCO) = F(LO) * (ODIV == 0 ? 2 : 4) */
fvco = frequency << (1 + odiv);
/* N(I) = floor(f(VCO) / (f(XTAL) * (PSD2 ? 2 : 1)))*/
nint = fvco / (state->reference << psd2);
/* N(F) = round(f(VCO) / f(XTAL) * (PSD2 ? 2 : 1) - N(I)) * 2 ^ 9
*/
nfrac = DIV_ROUND_CLOSEST((fvco - (nint * state->reference << psd2))
 << (9 - psd2),
  state->reference);
dprintk(verbose, FE_DEBUG, 1,
"frequency = %u, srate = %u, g = %u, odiv = %u, psd2 = %u,
fxtal = %u, osm = %u, fvco = %u, N(I) = %u, N(F) = %u",
frequency, srate, (unsigned int)g, (unsigned int)odiv,
(unsigned int)psd2, state->reference,
ptr->reg, fvco, nint, nfrac);
regs[STB6100_NI] = nint;
regs[STB6100_NF_LSB] = nfrac;
regs[STB6100_K] = (regs[STB6100_K] & ~STB6100_K_NF_MSB) | ((nfrac >>
8) & STB6100_K_NF_MSB);
regs[STB6100_VCO] |= STB6100_VCO_OSCH;  /* VCO search
enabled */
regs[STB6100_VCO] |= STB6100_VCO_OCK;   /* VCO search clock
off */
regs[STB6100_FCCK] |= STB6100_FCCK_FCCK;/* LPF BW setting
clock enabled   */
regs[STB6100_LPEN] &= ~STB6100_LPEN_LPEN;   /* PLL loop disabled
*/
/* Power up. */
regs[STB6100_LPEN] |= STB6100_LPEN_SYNP | STB6100_LPEN_OSCP |
STB6100_LPEN_BEN;

msleep(2);
if ((rc = stb6100_write_regs(state, regs)) < 0)
return rc;

msleep(2);
regs[STB6100_LPEN] |= STB6100_LPEN_LPEN;/* PLL loop enabled
*/
if ((rc = stb6100_write_reg(state, STB6100_LPEN,
regs[STB6100_LPEN])) < 0)
r

RE: [PATCH] STV0288 Fast Channel Acquisition

2011-07-01 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Malcolm Priestley
> Sent: vendredi 1 juillet 2011 00:22
> To: Linux Media Mailing List
> Cc: Sébastien RAILLARD (COEXSI)
> Subject: [PATCH] STV0288 Fast Channel Acquisition
> 
> On Wed, 2011-06-29 at 15:16 +0200, Sébastien RAILLARD (COEXSI) wrote:
> 
> > On some other transponders, like ASTRA 19.2E 11567-V-22000, the card
> > nearly never manage to get the lock: it's looking like the signal
> > isn't good enough.
> > I turned on the debugging of the stb6000 and stv0288 modules, but I
> > can't see anything wrong.
> 
> I have had similar problems with the stv0288 on astra 19.2 and 28.2 with
> various frequencies.
> 
> I have been using this patch for some time which seems to improve
> things.
> 
> The STV0288 has a fast channel function which eliminates the need for
> software carrier search.
> 
> The patch removes the slow carrier search and replaces it with this
> faster and more reliable built-in chip function.
> 
> If carrier is lost while channel is running, fast channel attempts to
> recover it.
> 
> The patch also reguires registers 50-57 to be set correctly with
> inittab. All current combinations in the kernel media tree have been
> checked and tested.
> 

Thanks Macolm for this patch!

Regarding the TT-S-1500b, it's using a specific inittab, I hope Oliver can have 
a look and check if this patch is compatible with the ALPS BSBE1 tuner.

Sebastien

> Signed-off-by: Malcolm Priestley 
> ---
>  drivers/media/dvb/frontends/stv0288.c |   75 +-
> --
>  1 files changed, 49 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/media/dvb/frontends/stv0288.c
> b/drivers/media/dvb/frontends/stv0288.c
> index 8e0cfad..fa5cba5 100644
> --- a/drivers/media/dvb/frontends/stv0288.c
> +++ b/drivers/media/dvb/frontends/stv0288.c
> @@ -142,6 +142,12 @@ static int stv0288_set_symbolrate(struct
> dvb_frontend *fe, u32 srate)
>   stv0288_writeregI(state, 0x28, b[0]);
>   stv0288_writeregI(state, 0x29, b[1]);
>   stv0288_writeregI(state, 0x2a, b[2]);
> +
> + stv0288_writeregI(state, 0x22, 0x0);
> + stv0288_writeregI(state, 0x23, 0x0);
> + stv0288_writeregI(state, 0x2b, 0x0);
> + stv0288_writeregI(state, 0x2c, 0x0);
> +
>   dprintk("stv0288: stv0288_set_symbolrate\n");
> 
>   return 0;
> @@ -309,12 +315,13 @@ static u8 stv0288_inittab[] = {
>   0xf1, 0x0,
>   0xf2, 0xc0,
>   0x51, 0x36,
> - 0x52, 0x09,
> - 0x53, 0x94,
> - 0x54, 0x62,
> - 0x55, 0x29,
> - 0x56, 0x64,
> - 0x57, 0x2b,
> + 0x52, 0x21,
> + /* Fast Channel MIN/MAX Freqency Bounds MSB bit 7 sets stop */
> + 0x53, 0x94, /*Min MSB (0-6)*/
> + 0x54, 0x62, /*Min LSB*/
> + 0x55, 0x29, /*Max MSB (0-6)*/
> + 0x56, 0x64, /*Max LSB*/
> + 0x57, 0x2b, /* Increment (signed) */
>   0xff, 0xff,
>  };
> 
> @@ -356,6 +363,35 @@ static int stv0288_init(struct dvb_frontend *fe)
>   return 0;
>  }
> 
> +/* STV0288 Fast channel accquisition and blind search */ static int
> +stv0288_get_fast(struct dvb_frontend *fe) {
> + struct stv0288_state *state = fe->demodulator_priv;
> + int timeout = 0;
> +
> + /* Coarse Tune */
> + stv0288_writeregI(state, 0x50, 0x35);
> + /* Wait 15ms */
> + msleep(15);
> + /* Fine Tune Control & Center Carrier */
> + stv0288_writeregI(state, 0x50, 0x16);
> + /* Check for Timing lock */
> + while (!(stv0288_readreg(state, 0x1e) & 0x80)) {
> + if (timeout++ > 5)
> + return -EINVAL;
> + msleep(15);
> + }
> +
> + /* Center Carrier for further length of time */
> + stv0288_writeregI(state, 0x50, 0x14);
> + udelay(500);
> + /* Fast Search End*/
> + stv0288_writeregI(state, 0x50, 0x10);
> +
> + return 0;
> +}
> +
> +
>  static int stv0288_read_status(struct dvb_frontend *fe, fe_status_t
> *status)  {
>   struct stv0288_state *state = fe->demodulator_priv; @@ -369,6
> +405,9 @@ static int stv0288_read_status(struct dvb_frontend *fe,
> fe_status_t *status)
>   *status = 0;
>   if (sync & 0x80)
>   *status |= FE_HAS_CARRIER | FE_HAS_SIGNAL;
> + else
> + stv0288_get_fast(fe); /*try to recover*/
> +
>   if (sync & 0x10)
>   *status |= FE_HAS_VITERBI;
>   if (sync & 0x08) {
> @@ -458,9 +497,7 @@ static int stv0288_s

[DVB] TT S-1500b tuning issue

2011-06-29 Thread COEXSI 
Dear all,

We have found what seems to be a tuning issue in the driver for the ALPS
BSBE1-D01A used in the new TT-S-1500b card from Technotrend.
On some transponders, like ASTRA 19.2E 11817-V-27500, the card can work very
well (no lock issues) for hours.

On some other transponders, like ASTRA 19.2E 11567-V-22000, the card nearly
never manage to get the lock: it's looking like the signal isn't good
enough.
I turned on the debugging of the stb6000 and stv0288 modules, but I can't
see anything wrong.

Also, we have noticed that the lock maybe lost by intermittence on others
transponders where it may work fine for few hours and then stop working for
few hours.

After doing some researches about the ALPS BSBE1-D01A frontend, I've found
it's the one used in the DREAMBOX DVB-S tuner module (that is running
Linux), but I didn't manage to find the source code repository to check
their drivers, maybe someone know where is it?

Best regards,
Sebastien.




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

RE: [DVB] Octopus driver status

2011-06-24 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Oliver Endriss
> Sent: vendredi 24 juin 2011 11:52
> To: Sébastien RAILLARD (COEXSI)
> Cc: Linux Media Mailing List
> Subject: Re: [DVB] Octopus driver status
> 
> Hi,
> 
> On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote:
> > Dear all,
> >
> > I'm looking at the Octopus DVB cards system from Digital Devices for a
> > while as their system seems to be very interesting
> >
> > Here is link with their products:
> > http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/S
> > hops/6
> > 2357162/Categories
> >
> > The good points I have found:
> >
> > * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S
> > and
> > DVB-S2
> > * They are moderately priced
> > * There is a CAM support with a CI adapter for unscrambling channels
> > * They are using the now de-facto standard PCI-Express bus
> > * The new Octopus system is using a LATTICE PCI-Express bridge that
> > seems to be more future proof than the previous bridge Micronas
> > APB7202A
> > * They seem to be well engineered ("Designed and manufactured in
> > Germany" as they say!)
> >
> > And now the doubts :
> >
> > * The DVB-C/T frontend driver is specific to this system and is very
> > new, so as Devin said one week ago, it's maybe not yet production
> > ready
> > * The way the CAM is supported break all the existing userland DVB
> > applications (gnutv, mumudvb, vlc, etc.)
> > * There isn't so much information about the Digital Devices company
> > and their products roadmap (at least in English)
> >
> > So, my two very simple questions to the developers who worked on the
> > drivers (I think Oliver and Ralph did) and know the product:
> > * How you feel the future about the Octopus driver?
> 
> The drivers work fine. I am not aware of any problems.
> 
> All Digital Devices cards and tuner variants are supported by the driver
> http://linuxtv.org/hg/~endriss/media_build_experimental
> 
> ddbridge (Lattice bridge):
> - Octopus (all variants)
> - cineS2 v6
> - DuoFlex S2 (stv0900 + stv6110 + lnbp21)
> - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2)
> 
> ngene bridge:
> - cineS2 (v4,v5), Satix S2 Dual
> - PCIe bridge, mini PCIe bridge
> - DuoFlex S2 (stv0900 + stv6110 + lnbp21)
> - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2)
> 
> For a German description, see
> http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-
> s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-
> duoflex-s2-duoflex-ct-sowie-tt-s2-6400
> 
> From an operational point of view, the driver is ready for the kernel.
> Unfortunately I did not have the time yet to clean up the coding-style.
> There are thousands of coding-style issues waiting to be fixed...
> 

Ok, thank you for the update.
We will try some Octopus cards.

> > * Do you think a compatibility mode (like module parameter) can be
> > added to simulate the way the CAM is handled in the other drivers?
> 
> Yes, this could be done:
> ++ The CI could be used with any application.
> -- The CI will be attached to one tuner exclusively.
> 
> It is not very hard to implement this.
> Patches are welcome. ;-)
> 

Maybe I'll ask for advices!!!

> CU
> Oliver
> 
> --
> 
> VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
> 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
> Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

[DVB] Octopus driver status

2011-06-23 Thread COEXSI 
Dear all,

I'm looking at the Octopus DVB cards system from Digital Devices for a while
as their system seems to be very interesting 

Here is link with their products:
http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6
2357162/Categories

The good points I have found:

* They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and
DVB-S2
* They are moderately priced
* There is a CAM support with a CI adapter for unscrambling channels
* They are using the now de-facto standard PCI-Express bus
* The new Octopus system is using a LATTICE PCI-Express bridge that seems to
be more future proof than the previous bridge Micronas APB7202A
* They seem to be well engineered ("Designed and manufactured in Germany" as
they say!)

And now the doubts :

* The DVB-C/T frontend driver is specific to this system and is very new, so
as Devin said one week ago, it's maybe not yet production ready
* The way the CAM is supported break all the existing userland DVB
applications (gnutv, mumudvb, vlc, etc.)
* There isn't so much information about the Digital Devices company and
their products roadmap (at least in English)

So, my two very simple questions to the developers who worked on the drivers
(I think Oliver and Ralph did) and know the product:
* How you feel the future about the Octopus driver?
* Do you think a compatibility mode (like module parameter) can be added to
simulate the way the CAM is handled in the other drivers?

I'm ready to buy the different cards and do some testing if it can help.

Best regards,
Sebastien.


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

RE: [RFC] vtunerc - virtual DVB device driver

2011-06-20 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Devin Heitmueller
> Sent: lundi 20 juin 2011 20:25
> To: HoP
> Cc: Rémi Denis-Courmont; linux-media@vger.kernel.org
> Subject: Re: [RFC] vtunerc - virtual DVB device driver
> 
> On Mon, Jun 20, 2011 at 2:17 PM, HoP  wrote:
> > Can you tell me when such disscussion was done? I did a big attempt to
> > check if my work is not reinventing wheels, but I found only some very
> > generic frontend template by Emard .
> 
> See the "userspace tuner" thread here for the background:
> 
> http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840
> 
> >> easier for evil tuner manufacturers to leverage all the hard work
> >> done by the LinuxTV developers while providing a closed-source
> solution.
> >
> > May be I missunderstood something, but I can't see how frontend
> > virtualization/sharing can help to leverage others work.
> 
> It helps in that it allows third parties to write drivers in userspace
> that leverage the in-kernel implementation of DVB core.  It means that a
> product developer who didn't want to abide by the GPL could write a
> closed-source driver in userland which takes advantage of the thousands
> of lines of code that make up the DVB core.
> 
> >> It was an explicit goal to *not* allow third parties to reuse the
> >> Linux DVB core unless they were providing in-kernel drivers which
> >> conform to the GPL.
> >
> > I'm again not sure if you try to argument against vtunerc code or
> > nope.
> 
> I am against things like this being in the upstream kernel which make it
> easier for third parties to leverage GPL code without making their code
> available under the GPL.
> 

If I may put my two cents in this discussion regarding the closed source
code problem: maybe it could be great to have some closed source drivers
making some DVB hardware working better or even allowing more DVB hardware
working under Linux. For example, there is a good support of PCI DVB
devices, but not yet so much support for PCIe DVB devices (and even less if
you're searching for DVB-S2 tuner with CAM support at reasonable price).
Also, most the DVB drivers code released under GPL is nearly impossible to
understand as there is no documentation (because of NDA agreements with
developers - as I understood) and no inline comments. So does-it make so
much difference with closed source code? I really don't want to aggress
anybody here, but it's really a question I have.
 
> Devin
> 
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: "dvb_ca adaptor 0: PC card did not respond :(" with Technotrend S2-3200

2011-06-13 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Bart Coninckx
> Sent: lundi 13 juin 2011 19:14
> To: linux-media@vger.kernel.org
> Subject: Re: "dvb_ca adaptor 0: PC card did not respond :(" with
> Technotrend S2-3200
> 
> On 06/13/11 00:30, Bart Coninckx wrote:
> > Hi all,
> >
> >
> > hope you can help me this one, because there's not a whole of info
> > about similar problems to be found.
> >
> > I have a Technotrend S2-3200 with CI and on three different distros I
> > get this
> >
> > "dvb_ca adaptor 0: PC card did not respond :(
> >
> >
> > in /var/log/messages.
> >
> > I guess this is the reason why I cannot see encrypted channels on
> Linux.
> > Unencrypted works fine. In Windows XP the cord works fine too.
> >
> > I tried Opensuse 11.4, the latest Mythbuntu and the latest Mythdora.
> >
> > Can anyone give any hints on how to go about this?
> >

Your reporting isn't very clear:
- When you try under Linux and Windows, is-it the same PC with the same
configuration?
- Does-it work with unscrambled channels on Windows ? 
- Can you decrypt scrambled channels on Windows ?
- Does-it work with unscrambled channels on Linux ? 
- Can you decrypt scrambled channels on Linux ?

> >
> > thx!!!
> >
> > Bart
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
> 
> 
> All,
> 
> (risking to just talk to myself, but hey, that would not be the first
> time).
> 
> 
> I manually reinstalled the latest linuxtv media drivers, but this this
> does not seem to bring any relieve.
> 
> Any ideas much appreciated!
> 
> 
> B.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: [PATCH] DVB-APPS : correct some issues in libdvben50221

2011-05-24 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: jeudi 3 mars 2011 17:52
> To: Linux Media Mailing List
> Subject: [PATCH] DVB-APPS : correct some issues in libdvben50221
> 
> Dear all,
> 
> Here are two patches against the latest version of libdvben50221 in the
> hg repository.
> 
> Details of corrections:
> ---
> 
> * In "en50221_sl_handle_close_session_response", the expected data
> length wasn't good, the "close_session_response" object is 3 bytes long,
> not 4 bytes long (see the specification)
> 
> * The "LLCI_RESPONSE_TIMEOUT_MS" has been increased from 1000ms to
> 1ms in order to wait for long/complex MMI operations. The timeout
> work at TPDU 2nd level and not at LPDU 1st level of communication stack.
> 
> * In "en50221_stdcam_llci_destroy", all data from the CA device are read
> before closing the device. This prevent from keeping the last poll reply
> in the dvb_core module ringbuffer. The polling function used to keep
> contact with the CAM is first reading data then writing data, so there
> is always a reply left in the buffer.
> 
> * In "llci_lookup_callback", some tests permitting resource usage limit
> are disabled as they are not working correctly. When a new session is
> created, it is declared. But when a session is closed, this isn't
> declared so a new session can't be opened a second time.
> 
> * In "llci_session_callback", a test was removed as it was duplicated.
> 
> * In "en50221_stdcam_llci_poll" and "llci_datetime_enquiry_callback", if
> the function "en50221_stdcam_llci_dvbtime" isn't called regularly, a
> wrong date/time is send to the CAM. So, if the time wasn't supplied, we
> send the UTC time from the system. Also, the "time_offset" parameter of
> the called function "en50221_app_datetime_send" has been set to -1 as we
> don't have the "local_offset" information and as this information is
> optional (see the specification).
> 
> Best regards,
> Sebastien RAILLARD.

This is a patch re-submission with the correct format in order to get catch
in patchwork:

Signed-off-by: Sebastien RAILLARD 

diff -r 1f246cbf8104 -r abf3b2af3520 lib/libdvben50221/en50221_session.c
--- a/lib/libdvben50221/en50221_session.c   Mon Jan 31 14:47:32 2011
+0100
+++ b/lib/libdvben50221/en50221_session.c   Tue May 24 23:28:53 2011
+0200
@@ -715,13 +715,13 @@
 uint8_t connection_id)
 {
// check
-   if (data_length < 5) {
+   if (data_length < 4) {
print(LOG_LEVEL, ERROR, 1,
  "Received data with invalid length from module on slot
%02x\n",
  slot_id);
return;
}
-   if (data[0] != 4) {
+   if (data[0] != 3) {
print(LOG_LEVEL, ERROR, 1,
  "Received data with invalid length from module on slot
%02x\n",
  slot_id);
diff -r 1f246cbf8104 -r abf3b2af3520 lib/libdvben50221/en50221_stdcam_llci.c
--- a/lib/libdvben50221/en50221_stdcam_llci.c   Mon Jan 31 14:47:32 2011
+0100
+++ b/lib/libdvben50221/en50221_stdcam_llci.c   Tue May 24 23:28:53 2011
+0200
@@ -32,7 +32,7 @@
 #include "en50221_app_tags.h"
 #include "en50221_stdcam.h"

-#define LLCI_RESPONSE_TIMEOUT_MS 1000
+#define LLCI_RESPONSE_TIMEOUT_MS 10*1000
 #define LLCI_POLL_DELAY_MS 100

 /* resource IDs we support */
@@ -207,7 +207,16 @@
en50221_app_mmi_destroy(llci->stdcam.mmi_resource);

if (closefd)
+   {
+   // Read the buffer before closing the device to remove the
last polling answer
+   uint8_t r_slot_id;
+   uint8_t connection_id;
+   uint8_t data[4096];
+   dvbca_link_read(llci->cafd, &r_slot_id,
+   &connection_id,
+   data, sizeof(data));
close(llci->cafd);
+   }

free(llci);
 }
@@ -243,9 +252,14 @@
if (llci->datetime_session_number != -1) {
time_t cur_time = time(NULL);
if (llci->datetime_response_interval && (cur_time >
llci->datetime_next_send)) {
-   en50221_app_datetime_send(llci->datetime_resource,
-
llci->datetime_session_number,
-   llci->datetime_dvbtime, 0);
+   if (llci->datetime_dvbtime>0)
+
en50221_app_datetime_send(llci->datetime_resource,
+
llci->datetime_session_number,
+
llci->datetime_dv

RE: STV090x FE_READ_STATUS implementation

2011-05-24 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Guy Martin
> Sent: mardi 24 mai 2011 20:45
> To: Sébastien RAILLARD (COEXSI)
> Cc: abraham.m...@gmail.com; linux-media@vger.kernel.org
> Subject: Re: STV090x FE_READ_STATUS implementation
> 
> On Tue, 24 May 2011 19:47:17 +0200
> Sébastien RAILLARD (COEXSI)  wrote:
> 
> > > Does the STV6110 supports reporting of signal, carrier, viterbi and
> > > sync ?
> > >
> >
> > I've done some tests with the CineS2, that is using the STV6110A as
> > the tuner and the STV0903 as the demodulator.
> >
> > The values you are searching for don't come from the tuner, but the
> > demodulator.
> >
> > In my case, the STV0903 is reporting the five following states :
> > SCVYL.
> >
> 
> Indeed, after some more troubleshooting, I found out that the problem is
> not in the STV6110 but in the STV090X code. The card I'm using is a TT
> S2-1600.
> 
> The function stv090x_read_status() only reports the status when locked.
> 
> I couldn't find the datasheet either for this one. Manu is the
> maintainer as well. Maybe he has more input on this.
> 

Strange, as it must be the same demodulator and code as for the CineS2!

Not easy to get the datasheets from ST, they have never replied to my 
enquiries...

> In the meantime, I'll give a closer look at the code see if I can figure
> out a way to fix that.
> 
> 
> Thanks,
>   Guy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: STV6110 FE_READ_STATUS implementation

2011-05-24 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Guy Martin
> Sent: mardi 24 mai 2011 18:18
> To: abraham.m...@gmail.com
> Cc: linux-media@vger.kernel.org
> Subject: STV6110 FE_READ_STATUS implementation
> 
> 
> Hi Manu,
> 
> I'm currently writing an application that needs to know the detailed
> frontend status when there is no lock.
> As far as I can see from the sources, the code will only set the right
> status when there is a lock in stv6110x_get_status().
> 
> Does the STV6110 supports reporting of signal, carrier, viterbi and sync
> ?
> 

I've done some tests with the CineS2, that is using the STV6110A as the
tuner and the STV0903 as the demodulator.

The values you are searching for don't come from the tuner, but the
demodulator.

In my case, the STV0903 is reporting the five following states : SCVYL.


> I'd be happy to implement that if it does but I wasn't able to find the
> datasheet. Do you have that available ?
> 
> Regards,
>   Guy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: [DVB] In research of chip's datasheets

2011-05-20 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: vendredi 20 mai 2011 19:26
> To: "Sébastien RAILLARD (COEXSI)"
> Cc: linux-media@vger.kernel.org
> Subject: Re: [DVB] In research of chip's datasheets
> 
> On 20/05/2011 18:01, Sébastien RAILLARD (COEXSI) wrote:
> > I'm in research of datasheets of the following chips:
> > - tuner STV6110A from ST
> > - dual demodulator STV0900B from ST
> > - CI interface CXD2099AR from SONY
> 
> Hi Sebastien,
> 
> If you're targeting the ngene based cards, I think you will also need
> the spec for the ngene chip and my guess is that it has been programmed
> (not generic like the 3 other chips). So as Ralph is already in contact
> with digital devices, I wonder if you will get this information.
> 
> For the cxd2099ar, talk to sony europe CXD2099_support<>eu./sony/.com
> 

I sent them an email at the beginning of the week, I still have no answer
yet, I hope they will answer.
Did you personally manage to get access to the CXD2099 datasheet ?

> --
> Issa

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

[DVB] In research of chip's datasheets

2011-05-20 Thread COEXSI 
Dear all,

I'm in research of datasheets of the following chips:
- tuner STV6110A from ST
- dual demodulator STV0900B from ST
- CI interface CXD2099AR from SONY

The main goal is first to understand how all these parts are working and
then to provide (if possible) some improvements.

The source code associated with these drivers is released under GPL terms,
but without any comments or descriptions in the code, so it's nearly useless
for people other than the original developers to understand and contribute
(that is basically the goal of the GPL spirit).

What is our advice regarding the procedure to have access to these
documents?

Best regards,
Sebastien.

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

RE: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when "resource non-existent"

2011-05-19 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Andreas Oberritter
> Sent: jeudi 19 mai 2011 14:58
> To: Tomer Barletz
> Cc: Brice DUBOST; linux-media@vger.kernel.org
> Subject: Re: [libdvben50221] [PATCH] Assign same resource_id in
> open_session_response when "resource non-existent"
> 
> On 05/18/2011 09:16 PM, Tomer Barletz wrote:
> > On Tue, May 17, 2011 at 8:46 AM, Brice DUBOST 
> wrote:
> >> On 18/01/2011 15:42, Tomer Barletz wrote:
> >>> Attached a patch for a bug in the lookup_callback function, were in
> >>> case of a non-existent resource, the connected_resource_id is not
> >>> initialized and then used in the open_session_response call of the
> >>> session layer.
> >>>
> >>
> >> Hello
> >>
> >> Can you explain what kind of bug it fixes ?
> >>
> >> Thanks
> >>
> >
> > The standard states that in case the module can't provide the
> > requested resource , it should reply with the same resource id - this
> > is the only line that was added.
> > Also, since the caller to this function might use the variable
> > returned, this variable must be initialized.
> > The attached patch solves both bugs.
> 
> Can you please resend the patch inline with a proper signed-off-by line,
> in order to get it tracked by patchwork.kernel.org?
> 

Yes, of course, but I don't find information that can help me to provide the
correct format.
Is-there a documentation somewhere that explains how patches must be
formatted to be correctly tracked?

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

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

RE: DVB nGene CI : TS Discontinuities issues

2011-05-11 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: mercredi 11 mai 2011 15:13
> To: Ralph Metzler
> Cc: Linux Media Mailing List; S-bastien RAILLARD; Oliver Endriss
> Subject: Re: DVB nGene CI : TS Discontinuities issues
> 
> From: Ralph Metzler 
> > Issa Gorissen writes:
> >  > Could you please take a look at the cxd2099 issues ?
> >  >
> >  > I have attached a version with my changes. I have tested a lot of
> > > different settings with the help of the chip datasheet.
> >  >
> >  > Scrambled programs are not handled correctly. I don't know if it is
> > the  > TICLK/MCLKI which is too high or something, or the sync
> > detector ? Also,  > as we have to set the TOCLK to max of 72MHz, there
> > are way too much null  > packets added. Is there a way to solve this ?
> >
> > I do not have any cxd2099 issues.
> > I have a simple test program which includes a 32bit counter as payload
> > and can pump data through the CI with full speed and have no packet
> > loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> > but also had no problems with this.
> >
> > Please take care not to write data faster than it is read. Starting
> > two dds will not guarantee this. To be certain you could write a small
> > program which never writes more packets than input buffer size minus
> > the number of read packets (and minus the stuffing null packets on
> ngene).
> >
> > Before blaming packet loss on the CI data path also please make
> > certain that you have no buffer overflows in the input part of the sec
> > device.
> > In the ngene driver you can e.g. add a printk in tsin_exchange():
> >
> > if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) { ...
> > } else
> > printk ("buffer overflow \n");
> >
> >
> > Regards,
> > Ralph
> 
> 
> Ralph,
> 
> Please find my testing tool for the decryption attached. The idea is to
> write
> 5 packets and read them back from the CAM.
> 
> My input is a raw ts captured with a gnutv I modified with a demux
> filter of 0x2000. Gnutv outputs at dvr and dvbloop reads from it,
> process via sec0 and writes output to a file.
> 
> The channel I selected has been decrypted. Only problem is I have
> artifacts in the image and the sound.
> 
> Do you have any idea of what I should improve from my test tool to fix
> that issue ?
> 
> 

Good news, it seems that you managed to get it working!
You can check that your input and output TS files doesn't have issues or
discontinuities.

If you have access to a Windows running computer, you can test your TS files
with a small analyzer I wrote:
http://www.coexsi.fr/publications/mpegts-analyzer/


> Thx,
> --
> Issa


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

RE: DVB nGene CI : TS Discontinuities issues

2011-05-09 Thread COEXSI 


> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: lundi 9 mai 2011 02:42
> To: Ralph Metzler
> Cc: Linux Media Mailing List; "Sébastien RAILLARD (COEXSI)"; Oliver
> Endriss; Martin Vidovic
> Subject: Re: DVB nGene CI : TS Discontinuities issues
> 
> On 07/05/11 23:34, Ralph Metzler wrote:
> > I do not have any cxd2099 issues.
> > I have a simple test program which includes a 32bit counter as payload
> > and can pump data through the CI with full speed and have no packet
> > loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> > but also had no problems with this.
> >
> > Please take care not to write data faster than it is read. Starting
> > two dds will not guarantee this. To be certain you could write a small
> > program which never writes more packets than input buffer size minus
> > the number of read packets (and minus the stuffing null packets on
> ngene).
> >
> > Before blaming packet loss on the CI data path also please make
> > certain that you have no buffer overflows in the input part of the sec
> > device.
> > In the ngene driver you can e.g. add a printk in tsin_exchange():
> >
> > if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) { ...
> > } else
> > printk ("buffer overflow \n");
> >
> >
> > Regards,
> > Ralph
> 
> Ralph,
> 
> As mentioned earlier, the warning message in tsin_exchange() is somewhat
> useless because it is printed endlessly at module start.
> 
> However, I've written the small test (attached) and took care to not
> write more than read (not taking account of null packets).
> 
> I still cannot descrambled channels. I'm using the source from 2.6.39 rc
> 5 with the fix from Oliver
> [http://linuxtv.org/hg/~endriss/v4l-dvb/rev/3d3e6ec2d0a7].  I launched
> gnutv with output to dvr, and launched my tool to read from dvr,
> write/read from sec0, write to a file.
> 
> The end result is a file which is clean of null packets, but cannot be
> played by mplayer (no audio, or no video, or both...)
> 
> I don't know if CAT needs to be in the stream passed through sec0 as
> Sebastien mentioned, so I modified gnutv to add it to dvr.
> 

Yes, the CAT table is mandatory, it must be sent to the CAM, as well as :
* the EMM PID referenced in the CAT
* all the private descriptors (binary blobs) in the PMT and, of course
* the ECM PID referenced in the PMT

Of course, the CAM must be initialized, all the necessary CAM resources must
be initialized and a CA_PMT object must be sent through the CAM command
channel to ask for unscrambling of needed channels.

That why it's better to send directly the raw TS output of the demodulator
directly in the CAM.
And then doing the demux filtering stuff on the TS stream coming from the
CAM (once unscrambled).

> Sebastien, Martin, could you try Ralph suggestion and post results as
> well. Thx.
> 
> 
> Please also find an update of ngene-dvb.c, the sec device now handles
> blocking/non blocking access.
> 
> --
> Issa

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

DVB nGene CI : TS Discontinuities issues

2011-05-03 Thread COEXSI 
Dear all,

I'm doing some tests with the CI interface of the "Linux4Media cineS2 DVB-S2
Twin Tuner (v5)" card.
I notice some TS discontinuities during my tests.

My setup:
- Aston Viaccess Pro CAM
- Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card
- Latest git media_build source with DF_SWAP32 patch
- DVB-S source from ASTRA 19.2E / 12285.00-V-27500

Test #1: (idle)
Reading from sec0 (without CI init or sec0 input stream) using "dd" give me
a stream of NULL TS packets of roughly 62mbps or 7.8MB/s (seems normal
behavior)
Command line: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800
count=1

Test #2: (CAM removal)
After CAM initialization and some tests, if CAM is removed, the output sec0
bandwidth isn't anymore 62mbps of NULL TS packets
Same command line as Test #1 is used.
It seems that the CI is badly reacting after hot remove of CAM.
After rebooting, everything is fine again.

Test #3: (Test dvr0 stream)
- Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf
-out dvr CHAINE
- Channel configuration: CHAINE:12285:v:0:27500:170:120:17030
- Dumping the dvr0 output: dd if=/dev/dvb/adapter14/dvr0 of=/root/test.ts
bs=1880 count=1000
=> The dvr0 output bandwidth is roughly 300kB/s (normal for one filtered
channel)
=> The resulting TS file is correct (no sync missing, no continuity error)

Test #4: (Loop mode - No CAM inserted)
- Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0
of=/dev/dvb/adapter14/sec0 bs=1880
- Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf
-out dvr CHAINE
- Channel configuration: CHAINE:12285:v:0:27500:170:120:17030
- Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts
bs=18800 count=1
=> The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is
always 62mbps)
=> The resulting TS file is filled at 96% by NULL TS packets (normal,
regarding the input stream bandwidth of 300kB/S)
=> All the input PID seem to present in the output file
=> But, there are some discontinuities in the TS packets (a lot and for all
the PID)

Test #5: (Trough CAM - CAM is inserted)
- Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0
of=/dev/dvb/adapter14/sec0 bs=1880
- Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf
-out dvr CHAINE
- Channel configuration: CHAINE:12285:v:0:27500:170:120:17030
- Waiting for CAM initialization (the CAM is correctly initialized and the
PMT packet is send to the CAM)
- Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts
bs=18800 count=1
=> The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is
always 62mbps)
=> The resulting TS file is filled at 96% by NULL TS packets (normal,
regarding the input stream bandwidth of 300kB/S)
=> All the input PID seem to present in the output file
=> The stream isn't decoded (normal as the CAT table isn't outputted by
gnutv)
=> But, there are some discontinuities in the TS packets (a lot and for all
the PID)

So, in summary, I'm observing discontinues when stream is going through the
sec0 device, if CAM is present or not.
Also, the CI adapter doesn't seem to react correctly when the CAM is hot
removed.
I can provide the TS files (from dvr0, from sec0 with CAM and without CAM)
if someone is interested.

Does someone has a setup that show no discontinuities when a TS stream is
going through sec0? (with an input TS file)
I would like to test it as for me the CI interface doesn't seem to work for
the nGene cards.

Best regards,
Sebastien.







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

RE: ngene CI problems

2011-05-02 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Issa Gorissen
> Sent: samedi 23 avril 2011 12:20
> To: Ralph Metzler
> Cc: xtro...@gmail.com; linux-media@vger.kernel.org
> Subject: Re: ngene CI problems
> 
> On 23/04/11 00:16, Issa Gorissen wrote:
> >> Hi all!
> >>
> >> I'm trying to make the DVB_DEVICE_SEC approach work, however I'm
> >> experiencing certain problems with the following setup:
> >>
> >> Software:
> >> Linux 2.6.34.8 (vanilla)
> >> drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/
> >> 
> >>
> >> Hardware:
> >> Digital Devices CineS2 + CI Module
> >>
> >> Problems:
> >>
> >> - Packets get lost in SEC device:
> >>
> >> I write complete TS to SEC, but when reading from SEC there are
> >> discontinuities on the CC.
> >>
> >> - SEC device generates NULL packets (ad infinitum):
> >>
> >> When reading from SEC, NULL packets are read and interleaved with
> >> expected packets. They can be even read with dd(1) when nobody is
> >> writing to SEC and even when CAM is not ready.
> >>
> >> - SEC device blocks on CAM re-insertion:
> >>
> >> When CAM is removed from the slot and inserted again, all read()
> >> operations just hang. Rebooting resolves the problem.
> >>
> >> - SEC device does not respect O_NONBLOCK:
> >>
> >> In connection to the previous problem, SEC device blocks even if
> >> opened with O_NONBLOCK.
> >>
> >> Best regards,
> >> Martin Vidovic
> >
> > Hi,
> >
> > Running a bunch of test with gnutv and a DuoFLEX S2.
> >
> > I saw the same problem concerning the decryption with a CAM.
> >
> > I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also
> > applied the patch moving from SEC to CAIO.
> >
> > I would run gnutv  like 'gnutv -out stdout channelname >
> > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 |
> mplayer -'
> > Mplayer would complain the file is invalid. Simply running simply 'cat
> > /dev/dvb/adapter0/caio0' will show me the same data pattern over and
> over.
> >
> > Anyone using ngene based card with a CAM running successfully ?
> 
> Hi Ralph,
> 
> Could you enlighten us on the following matter please ?
> 
> I took a look inside cxd2099.c and I found that the method I suspect to
> read/write data from/to the CAM are not activated.
> 

These methods dont't seem to be needed, except by the "BUFFER_MODE" (no doc 
about what it is).

Usually, the CA device is only used to dialog with the CAM through 4 specials 
functions (x_attribute_mem  and x_cam_control)
The TS stream to be decoded and the decoded TS stream don't go through this CA 
device but through the SEC device.
The SEC device is associated to one serial TS out pin and one serial in pin of 
the Micronas nGene bridge.
The CI device seems to be hardcoded to work at 62mbps, that means you will 
always read at 62mbps from SEC and you will not be able to write at more than 
62mbps on SEC.
When there is not enough TS packets to decode, the CI device will send padding 
TS packets (the one with PID=0x1FFF and full of 0xFF data) to keep the output 
bandwidth at 62mbps.

This is my current understanding of this (un)famous CI interface, hope it may 
help.
By the way, I wasn't yet able to decode any channel with this card.

Does someone here manage to decode a channel and kind provide a setup?


> static struct dvb_ca_en50221 en_templ = {
> .read_attribute_mem  = read_attribute_mem,
> .write_attribute_mem = write_attribute_mem,
> .read_cam_control= read_cam_control,
> .write_cam_control   = write_cam_control,
> .slot_reset  = slot_reset,
> .slot_shutdown   = slot_shutdown,
> .slot_ts_enable  = slot_ts_enable,
> .poll_slot_status= poll_slot_status,
> #ifdef BUFFER_MODE
> .read_data   = read_data,
> .write_data  = write_data,
> #endif
> 
> };
> 
> Methods read_data and write_data are both enclosed inside the
> BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does
> not provide for read_data/write_data methods, right ?
> 
> If I recall right, you once told that you manage to test the CAM
> ,
> how did you do ?
> 
> Thx
> --
> Issa
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder

2011-04-05 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Issa Gorissen
> Sent: mardi 5 avril 2011 13:00
> To: linux-media@vger.kernel.org
> Subject: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
> 
> Hi,
> 
> Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011)
> on two transponders on HB13E
> 
> - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s
> 0.2 Pilot off Polar H
> 
> - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s
> 0.2 Pilot off Polar H
> 

I can confirm that we have a lot of problem with these two transponders and
the TT-S2-3200 card.

Here are some observations:

- It seems that going from DVB-S to DVB-S2 make the antenna settings very
sensitive. We have some sites where everything is working correctly and on
some other sites where we needed to redo the antenna setup, especially the
LNB tilt.

- The STB0899 driver doesn't seem to work correctly: if the reception isn't
really good, we are missing a lot of TS packets and these packets are
altered (mainly garbage). But, the BER returned from the demodulator stay at
zero! (using FE_READ_BER ioctl). By the way, the FE_READ_UNCORRECTED_BLOCKS
ioctl isn't implemented in this driver.

Does anyone can confirm these observations?


> 
> Before those changes, with my TT S2 3200, I was able to watch TV on
> those transponders. Now, I cannot even tune on those transponders. I
> have tried with
> scan-s2 and w_scan and the latest drivers from git. They both find the
> transponders but cannot tune onto it.
> 
> Something noteworthy is that my other card, a DuoFlex S2 can tune fine
> on those transponders.
> 
> My question is; can someone try this as well with a TT S2 3200 and post
> the results ?
> 
> Thank you a lot,
> --
> Issa
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

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

RE: [PATCH] DVB-APPS : correct some issues in libdvben50221

2011-04-04 Thread COEXSI 
Dear Mauro and Manu,

As maintainers of the dvb-apps tree, did you have some chance to look at the
patches I've sent to correct some issues with the libdvben50221?
I think it can help to solve some issues, especially when using the CAM menu
(MMI).
Please feel free to discuss any point that seems blocking for including this
patch!

Best regards,
Sebastien


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: jeudi 3 mars 2011 17:52
> To: Linux Media Mailing List
> Subject: [PATCH] DVB-APPS : correct some issues in libdvben50221
> 
> Dear all,
> 
> Here are two patches against the latest version of libdvben50221 in the
> hg repository.
> 
> Details of corrections:
> ---
> 
> * In "en50221_sl_handle_close_session_response", the expected data
> length wasn't good, the "close_session_response" object is 3 bytes long,
> not 4 bytes long (see the specification)
> 
> * The "LLCI_RESPONSE_TIMEOUT_MS" has been increased from 1000ms to
> 1ms in order to wait for long/complex MMI operations. The timeout
> work at TPDU 2nd level and not at LPDU 1st level of communication stack.
> 
> * In "en50221_stdcam_llci_destroy", all data from the CA device are read
> before closing the device. This prevent from keeping the last poll reply
> in the dvb_core module ringbuffer. The polling function used to keep
> contact with the CAM is first reading data then writing data, so there
> is always a reply left in the buffer.
> 
> * In "llci_lookup_callback", some tests permitting resource usage limit
> are disabled as they are not working correctly. When a new session is
> created, it is declared. But when a session is closed, this isn't
> declared so a new session can't be opened a second time.
> 
> * In "llci_session_callback", a test was removed as it was duplicated.
> 
> * In "en50221_stdcam_llci_poll" and "llci_datetime_enquiry_callback", if
> the function "en50221_stdcam_llci_dvbtime" isn't called regularly, a
> wrong date/time is send to the CAM. So, if the time wasn't supplied, we
> send the UTC time from the system. Also, the "time_offset" parameter of
> the called function "en50221_app_datetime_send" has been set to -1 as we
> don't have the "local_offset" information and as this information is
> optional (see the specification).
> 
> Best regards,
> Sebastien RAILLARD.




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

[PATCH] DVB-APPS : correct some issues in libdvben50221

2011-03-03 Thread COEXSI 
Dear all,

Here are two patches against the latest version of libdvben50221 in the hg
repository.

Details of corrections:
---

* In "en50221_sl_handle_close_session_response", the expected data length
wasn't good, the "close_session_response" object is 3 bytes long, not 4
bytes long (see the specification)

* The "LLCI_RESPONSE_TIMEOUT_MS" has been increased from 1000ms to 1ms
in order to wait for long/complex MMI operations. The timeout work at TPDU
2nd level and not at LPDU 1st level of communication stack. 

* In "en50221_stdcam_llci_destroy", all data from the CA device are read
before closing the device. This prevent from keeping the last poll reply in
the dvb_core module ringbuffer. The polling function used to keep contact
with the CAM is first reading data then writing data, so there is always a
reply left in the buffer.

* In "llci_lookup_callback", some tests permitting resource usage limit are
disabled as they are not working correctly. When a new session is created,
it is declared. But when a session is closed, this isn't declared so a new
session can't be opened a second time.

* In "llci_session_callback", a test was removed as it was duplicated.

* In "en50221_stdcam_llci_poll" and "llci_datetime_enquiry_callback", if the
function "en50221_stdcam_llci_dvbtime" isn't called regularly, a wrong
date/time is send to the CAM. So, if the time wasn't supplied, we send the
UTC time from the system. Also, the "time_offset" parameter of the called
function "en50221_app_datetime_send" has been set to -1 as we don't have the
"local_offset" information and as this information is optional (see the
specification).

Best regards,
Sebastien RAILLARD.


en50221_session.patch
Description: Binary data


en50221_stdcam_llci.patch
Description: Binary data

RE: [PATCH] DVB : add option to dump PDU exchanged with CAM in dvb_core

2011-03-03 Thread COEXSI 

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
> Sent: lundi 28 février 2011 18:53
> To: Linux Media Mailing List
> Subject: [PATCH] DVB : add option to dump PDU exchanged with CAM in
> dvb_core
> 
> Dear all,
> 
> Here is a patch for the dvb_core module, you'll find it attached to this
> message.
> 
> It's adding a new module integer parameter called "cam_dump_pdu" that
> can have the following values:
> - 0 (by default): don't dump PDU (do nothing)
> - 1: Dump all PDU written and read on device through the syscall
> functions.
> The PDU are dumped in segments of 16 bytes maximum written in
> hexadecimal.
> - 2: like value 1 but remove the commonly used PDU for polling
> (generating a lot of "noise" in the logs)
> 
> The goal of dumping PDU exchanged with CAM is to help debugging userland
> applications and libraries.

I have to add that the PDU dumped are the "TPDU" (Transport Protocol Data
Units), the 2nd level of the stack.
The first level of PDU, the "LPDU" (Link Protocol Data Unit) fragments, are
reassembled by the dvb_core module and are not exposed to the applications.

Anyone interested by this option?

> 
> This is my first patch submission, so I may have made some errors
> regarding the submission rules.
> 
> Best regards,
> Sebastien.

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

RE: Sony CXD2099AR support

2011-03-02 Thread COEXSI 


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Ralph Metzler
> Sent: mardi 1 mars 2011 14:03
> To: Issa Gorissen
> Cc: linux-media@vger.kernel.org
> Subject: Sony CXD2099AR support
> 
> Issa Gorissen writes:
>  > I have read that this CI chip driver is in staging because some
> questions on  > how to handle it are still not answered.
>  >
>  > I volunteer to handle this one. I'm a regular java developer, but I'm
> willing  > to put effort in learning linux drivers writing.
>  >
>  > So Ralph, can you give me some pointers on where the discussion
> should resume  > ?
>  >
> 
> AFAIR, the only problem was that the old "sec"-Device name was abused. I
> do not see a problem in just adding a "cam" or whatever device in dvb-
> core and use that.
> Or just rename "sec" since it is no longer used.
> 
> Regarding the interface I think it should just remain being like a pipe.
> Using the dvr and demux devices for this just adds overhead.
> 

Dear all,

I'm looking for a while the work done on the nGene driver and especially the
CI driver.
For sure, this new kind of card add a lot of flexibility as the CI is
completely independent.

I wondering if a parameter can be added to the driver in order to make the
card working like a classic one:

- Having the tuner#1 working with the CAM the classic way:

  * Keep the frontend0 device as it is for controlling the tuning parameters

  * Create the ca0 and sec0 devices attached to the CI like it is done now

  * Send the full TS stream from the demodulator unfiltered to the CI
interface (CAM usually need full TS stream for working correctly - The Multi
Transponder Decrypt advertised has a risky future with all the new
protections planed for smartcard and CAM). Is this can be done directly in
the APB7202 chip or all data has first to be retrieved by the kernel before
being send back to the CI trough sec0?

  * Create the dvr0 and demux0 devices for the sec0 output

- Having the tuner#2 working without the CAM, with its demux1, dvr1,
frontend1 devices

It may help to keep compatibility with existent DVB applications.
What do you think?

Best regards,
Sebastien.

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

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

[PATCH] DVB : add option to dump PDU exchanged with CAM in dvb_core

2011-02-28 Thread COEXSI 
Dear all,

Here is a patch for the dvb_core module, you'll find it attached to this
message.

It's adding a new module integer parameter called "cam_dump_pdu" that can
have the following values:
- 0 (by default): don't dump PDU (do nothing)
- 1: Dump all PDU written and read on device through the syscall functions.
The PDU are dumped in segments of 16 bytes maximum written in hexadecimal.
- 2: like value 1 but remove the commonly used PDU for polling (generating a
lot of "noise" in the logs)

The goal of dumping PDU exchanged with CAM is to help debugging userland
applications and libraries.

This is my first patch submission, so I may have made some errors regarding
the submission rules.

Best regards,
Sebastien.


dvb_ca_en50221.patch
Description: Binary data

[DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal

2011-02-28 Thread COEXSI 
Dear all,

Are-there some maintainers for the dvb_core module and the budget_ci module
on the linux-media mailing list?

I would like to discuss and submit some patches I have developed for these
modules:
- dvb_core: add an option for logging the PDU exchanged with the CAM for
debugging purposes
- dvb_core: clean all ring buffers associated with CAM when a device is
opened
- budget_ci: print information about CI firmware used
- budget_ci: add module option for disabling the IR receiver and the IRQ
mode

Best regards,
Sebastien.




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