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 -- 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: CI/CAM support for offline (from file) decoding
-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: [DVB Digital Devices Cine CT V6] status support
-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) s...@coexsi.fr: 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
-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
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 joo...@btinternet.com
Pour : linux-media@vger.kernel.org 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
RE: [DVB] Digital Devices Cine CT V6 support
-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 (B1) 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
-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: [DVB] Digital Devices Cine CT V6 support
-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 (B1) 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
-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 mche...@redhat.com 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 flop.m@xxx 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 m...@linuxtv.org -- 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
-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, Ive 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
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, Ive 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
-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, Ive 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
[DVB] CXD2099 - Question about the CAM clock
Dear Oliver, Ive 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
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] TT S-1500b tuning issue
-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
RE: [DVB] Possible regression in stb6100 module for DVBS2 transponders
-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: [PATCH] STV0288 Fast Channel Acquisition
-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 tvbox...@gmail.com
---
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_set_frontend(struct dvb_frontend
*fe, {
struct stv0288_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
-
- char tm;
- unsigned char tda[3];
+ int ret = 0;
dprintk(%s : FE_SET_FRONTEND\n, __func__);
@@ -487,28 +524,14 @@ static int stv0288_set_frontend(struct
dvb_frontend *fe,
stv0288_set_symbolrate(fe, c-symbol_rate);
/* Carrier lock control register */
stv0288_writeregI(state, 0x15, 0xc5);
-
- tda[0] = 0x2b; /* CFRM */
- tda[2] = 0x0; /* CFRL
[DVB] Possible regression in stb6100 module for DVBS2 transponders
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, regs[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)
return rc;
regs[STB6100_VCO] = ~STB6100_VCO_OCK;
[DVB] TT S-1500b tuning issue
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
-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
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
-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 jpetr...@gmail.com 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 em...@softhome.net. 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
-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: STV6110 FE_READ_STATUS implementation
-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: STV090x FE_READ_STATUS implementation
-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) s...@coexsi.fr 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: [PATCH] DVB-APPS : correct some issues in libdvben50221
-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 s...@coexsi.fr
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_dvbtime0)
+
en50221_app_datetime_send(llci-datetime_resource,
+
llci-datetime_session_number,
+
llci-datetime_dvbtime, -1);
+ else
+
en50221_app_datetime_send(llci-datetime_resource,
+
llci-datetime_session_number,
+ time(NULL), -1);
llci-datetime_next_send = cur_time +
llci-datetime_response_interval;
}
}
@@ -334,12 +348,14 @@
return -3;
break;
case EN50221_APP_CA_RESOURCEID
[DVB] In research of chip's datasheets
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: [DVB] In research of chip's datasheets
-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_supporteu./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
RE: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
-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 bra...@braice.net 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
-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 r...@metzlerbros.de
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
-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
RE: ngene CI problems
-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/
http://linuxtv.org/hg/%7Eendriss/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
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html,
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
DVB nGene CI : TS Discontinuities issues
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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
-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
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
RE: [PATCH] DVB : add option to dump PDU exchanged with CAM in dvb_core
-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
[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. en50221_session.patch Description: Binary data en50221_stdcam_llci.patch Description: Binary data
RE: Sony CXD2099AR support
-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
[DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal
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
[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. 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
