[linux-dvb] FusionHDTV DVB-T Dual Digital2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All Just a question for the readers of this list, I have just found out that Fusion/DvICO have released the FusionHDTV DVB-T Dual Digital2 tuner card which is significantly different from the version that I bought a few months back (the one where you had to plug the second tuner into a spare USB port using a fly lead). Has anyone received the new one (they have removed the need for the use of the USB cable) and does it work under Linux. I have managed to get my version 1 partially working under SuSE 10.1 open source edition, but still struggling to get it fully working. I also think there is another change but cannot be sure unless I open my pc up, but the circuit board shows a VIA chipset on there, personally I dont remember one on mine but I could be mistaken. Sorry if posted incorrectly, but I am trying to find out as much as I can before deciding what to do with my version 1 card. Regards to all Andrew McDonald (United Kingdom) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGk/r2Sf3S/79AgMRAghZAJ9Q46b53B+0TGXrOAKTYog5CtFsawCfZc4D wLBHPebpMlt7Dhfn311PT0Q= =A6Sy -END PGP SIGNATURE- ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: MSI Megasky 580 using Uli m9206 -- http://linuxtv.org/hg/~mkrufky/m920x
Hi Aapo, First some comments to your patch. On Wed, 27 Sep 2006, Aapo Tahkola wrote: > On Tue, 26 Sep 2006 14:21:08 -0400 > Couple improvements in this patch: > -hardware pid filtering no longed enabled unless in usb 1.x mode You actually don't need to do this. The dvb-usb-stuff is looking for that already and adjusts itself depending on the properties set: DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF - means, the PID filter is turned off when USB2.0 is detected, on otherwise. DVB_USB_ADAP_NEED_PID_FILTERING - means, regardless whether there is USB2.0 or not, the PID filter is used. Setting both makes no sense. Please check if this is sufficient for and adapt your patch. > It stalls with silence if I modprobe the driver and plug in the stick. > If I plug in and then modprobe, nothing happens. > Compiling linux-2.6.18 to see if that sorts it out. Doesn't seem to be > related to m920x code though... Can you load the dvb-usb.ko with debug=0x(something, see modinfo dvb-usb.ko)? Maybe it loops somewhere. Patrick. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Manu, Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Hi Marcus, The problems with 2031 were unfortunately never fixed. IIRC we were left with the following problems: 1) tuner device sometimes missing in /dev/dvb/adapterX/ on boot (app. 20% of the boots, tested on 2 different machines) 2) needed to tune twice in case of freq change; the first time would almost never give a lock (but sometimes it did strangely enough) 3) unstable signal, where signal would be lost after some time (hours); this problem I never investigated thoroughly, because of 1) and 2) which needed a solution first <> http://linuxtv.org/hg/v4l-dvb?f=4f65bdd94527;file=linux/drivers/media/dvb/bt8xx/dst.c;style=gitweb at line #1648, does adding a msleep(20) or something around that order help ? for your problem (2) mentioned for (1) try using dst_addons=0x20 as module parameter. You will need this patch as well (for fixing the dvb-attach). Apply this patch first http://article.gmane.org/gmane.linux.drivers.dvb/27792/match= Alongwith one of the previous patches, commenting out one line for DCT-CI cards Unfortunately using dst_addons=0x20 for problem (1) does not seem to help. I dug up 2 of my 2031 cards, and put them in a machine. First time after boot, both cards did show a tuner; but the second time the tuner of adapter0 failed as follows: /dev/dvb/ /dev/dvb/adapter1 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/ca0 /dev/dvb/adapter1/net0 /dev/dvb/adapter1/dvr0 /dev/dvb/adapter1/demux0 /dev/dvb/adapter0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/demux0 Here is how I loaded my modules: dvb_core dvb_shutdown_timeout=0 bttv i2c_hw=1 card=0x71 bt878 dst verbose=5 dst_addons=0x20 dst_ca dvb-bt8xx Relevant part of dmesg: Linux video capture interface: v2.00 bttv: driver version 0.9.16 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :00:09.0[A] -> GSI 17 (level, low) -> IRQ 16 bttv0: Bt878 (rev 17) at :00:09.0, irq: 16, latency: 32, mmio: 0xef00 bttv0: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 bttv0: using: Twinhan DST + clones [card=113,insmod option] bttv0: gpio: en=, out= in=00f100fd [init] bttv0: using tuner=4 bttv0: add subdevice "dvb0" bttv: Bt8xx card found (1). ACPI: PCI Interrupt :00:0a.0[A] -> GSI 18 (level, low) -> IRQ 18 bttv1: Bt878 (rev 17) at :00:0a.0, irq: 18, latency: 32, mmio: 0xee00 bttv1: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 bttv1: using: Twinhan DST + clones [card=113,autodetected] bttv1: gpio: en=, out= in=00f100fd [init] bttv1: using tuner=4 bttv1: add subdevice "dvb1" bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). ACPI: PCI Interrupt :00:09.1[A] -> GSI 17 (level, low) -> IRQ 16 bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. bt878(0): Bt878 (rev 17) at 00:09.1, irq: 16, latency: 32, memory: 0xee80 bt878: Bt878 AUDIO function found (1). ACPI: PCI Interrupt :00:0a.1[A] -> GSI 18 (level, low) -> IRQ 18 bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. bt878(1): Bt878 (rev 17) at 00:0a.1, irq: 18, latency: 32, memory: 0xed80 DVB: registering new adapter (bttv0). dst(0) rdc_8820_reset: Resetting DST dst(0) dst_gpio_outb: mask=[0004], enbb=[0004], outhigh=[] dst(0) dst_gpio_outb: mask=[0004], enbb=[0004], outhigh=[0004] dst(0) dst_comm_init: Initializing DST. dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(0) rdc_reset_state: Resetting state machine dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 06 00 00 00 00 00 fa ] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(0) read_dst: reply is 0xff dst(0) dst_wait_dst_ready: dst wait ready after 1 dst(0) read_dst: reply is 0x0 0x44 0x43 0x54 0xd 0x43 0x49 0x6c dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(0) dst_get_device_id: Checksum failure! dst(0) dst_probe: unknown device. frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem 1822/0001 DVB: registering new adapter (bttv1). dst(1) rdc_8820_reset: Resetting DST dst(1) dst_gpio_outb: mask=[0004], enbb=[0004], outhigh=[] dst(1) dst_gpio_outb: mask=[0004], enbb=[0004], outhigh=[0004] dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 06 00 00 00 00 00 fa ] dst(1) dst_gpio_outb: mask=[]
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Hi Manu, Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: <...> 2) needed to tune twice in case of freq change; the first time would almost never give a lock (but sometimes it did strangely enough) <...> msleep(20) does not seem to make any difference for problem (2). If I change frequencies, I have to select twice in order to obtain a lock ... Also msleep(100) make no change. I wonder if this problem has to do with CA initialization after tuner freq change, but unfortunately I have no FTA-channels so I cannot compare it. As mentioned, the tuning problem persists, with msleep(20) as well as msleep(100). I think that it has something to do with CA initialization. Here is a dmesg dump while trying to change freq 322,750,000 (pid=12183) to 306,750,000 (pid=12242). dst_ca_open: Device opened [dd29b3c0] dst_ca_ioctl: Getting Slot capabilities put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xb5 dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_set_freq: set Frequency 30675 dst(1) dst_set_frontend: Set Frequency=[30675] dst(1) dst_set_symbolrate: set symrate 690 dst(1) dst_set_symbolrate: DCT-CI dst(1) dst_write_tuna: type_flags 0x1219 dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 07 40 02 00 02 00 00 b5 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0xa 0x40 0x0 0x0 0x2 0x3 0x0 0x1 0x18 0x1 0x97 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ca_get_slot_caps: -->dst_put_ci SUCCESS ! ca_get_slot_caps: Slot cap = [1] === 10 64 0 0 2 3 0 1 24 1 151 dst_ca_ioctl: -->CA_GET_CAP Success ! dst_ca_ioctl: Getting Slot info put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xfb dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 05 00 00 00 00 00 fb ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 2 dst(1) read_dst: reply is 0x0 0x5 0x0 0x14 0x88 0x4b 0x0 0x14 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ca_get_slot_info: -->dst_put_ci SUCCESS ! ca_get_slot_info: Slot info = [20] === 0 5 0 20 136 75 0 20 dst_ca_ioctl: -->CA_GET_SLOT_INFO Success ! dst_ca_ioctl: Sending message ca_send_message: ca_send_message: Command=[0x9f8020] ca_send_message: Getting Cam Application information put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xb7 dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 07 40 01 00 01 00 00 b7 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0xd 0x40 0x0 0x0 0x1 0x6 0x0 0x0 0x3 0x1 0x0 0x41 0x0 0x67 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xf
[linux-dvb] Re: MSI Megasky 580 using Uli m9206 -- http://linuxtv.org/hg/~mkrufky/m920x
Hi Micheal,
Attached you'll find my suggestions to your current tree.
Patrick.
On Tue, 26 Sep 2006, Michael Krufky wrote:
> Patrick,
>
> Could you look over the changesets in this tree and let me know whether
> or not you approve of this?
>
> Aapo,
>
> After you sent your patch in to the linux-dvb mailing list, Patrick had
> some comments and requests for certain things to be cleaned up. I have
> not seen any response from you about those requests.
>
> In an effort to move things along, I have taken it upon myself to clean
> up your patch. I've updated it to comply with some of the recent
> changes in the dvb-usb structure, and to use the new dvb_attach() method.
>
> I have also separated the qt1010 tuner code into a separate header file.
> It has come to my attention, thanks to Markus Rechberger, that there
> may be more fixing to do with regards to the qt1010 stuff... but that
> can be done later, in a separate patch.
>
> I'd like it if you could test the updated tree and confirm that it works
> as expected with your device. Please clone the following tree:
>
> http://linuxtv.org/hg/~mkrufky/m920x
>
> You will notice that I have decided to rename the driver from megasky to
> m920x -- I did this for a few reasons:
>
> 1) There are probably other devices out there based on the m9205, m9206
> and m9207 chipsets ... Adding support for those devices will probably be
> a matter of updating the code in this driver, in which case, the name
> 'megasky' may be inappropriate.
>
> 2) There is another device out there, called "MSI Megasky 580", based on
> the gl861 chipset, using the same exact usb id as your device based on
> the m9206 chipset. This means that MSI released two completely
> different devices, each with the same exact name and USB ID!
>
> 3) We should name the driver based on the chipset it uses, rather than
> the Vendor's retail name of the product.
>
> Please let me know what happens.
>
> Regards,
>
> Michael Krufky
> diff -r f955dadfe5bc linux/drivers/media/dvb/dvb-usb/m920x.c
--- a/linux/drivers/media/dvb/dvb-usb/m920x.c Sat Sep 23 19:40:20 2006 -0400
+++ b/linux/drivers/media/dvb/dvb-usb/m920x.c Wed Sep 27 13:14:03 2006 +0200
@@ -9,16 +9,19 @@
* see Documentation/dvb/README.dvb-usb for more information
*/
-#include "m920x.h"
+#define DVB_USB_LOG_PREFIX "m920x"
+#include "dvb-usb.h"
#include "mt352.h"
-#include "mt352_priv.h"
+#include "mt352_priv.h" /* really?? there is priv in the name, I thought it
means private :) */
#include "qt1010.h"
/* debug */
-int dvb_usb_m920x_debug;
+static int dvb_usb_m920x_debug;
module_param_named(debug,dvb_usb_m920x_debug, int, 0644);
MODULE_PARM_DESC(debug, "set debugging level (1=rc (or-able))."
DVB_USB_DEBUG_STATUS);
+
+#define deb_rc(args...) dprintk(dvb_usb_m920x_debug,0x01,args)
static struct dvb_usb_rc_key megasky_rc_keys [] = {
{ 0x0, 0x12, KEY_POWER },
@@ -72,7 +75,7 @@ static int m9206_rc_query(struct dvb_usb
int i, ret = 0;
u8 rc_state[2];
- if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
+ if (mutex_lock_interruptible(&d->i2c_mutex) < 0) /* I'm not sure about
using the i2c_mutex here is a good idea - maybe it is better to create
m920x_state and put a device-specific mutex or use the usb_mutex from
dvb_usb_device */
return -EAGAIN;
if ((ret = m9206_read(d->udev, 0x22, 0x0, 0xff51, rc_state, 1)) != 0)
@@ -141,7 +144,7 @@ static int m9206_i2c_xfer(struct i2c_ada
goto unlock;
if (i + 1 < num && msg[i + 1].flags & I2C_M_RD) {
- if (msg[i].addr == 0x1e)
+ if (msg[i].addr == 0x1e) // This screams for a comment
or for another solution.
w_len = 0x1f;
else
w_len = 0xc5;
@@ -225,8 +228,6 @@ static int megasky_mt352_demod_init(stru
return 0;
}
-struct mt352_state;
-
static struct mt352_config megasky_mt352_config = {
.demod_address = 0x1e,
.demod_init = megasky_mt352_demod_init,
@@ -243,47 +244,7 @@ static int megasky_frontend_attach(struc
return -EIO;
}
-/* DVB USB Driver stuff */
-static struct dvb_usb_device_properties megasky_properties;
-
-static int m920x_probe(struct usb_interface *intf, const struct usb_device_id
*id)
-{
- struct dvb_usb_device *d;
- struct usb_host_interface *alt;
- int ret;
-
- if ((ret = dvb_usb_device_init(intf, &megasky_properties, THIS_MODULE,
&d)) == 0) {
- deb_rc("probed!\n");
-
- alt = usb_altnum_to_altsetting(intf, 1);
- if (alt == NULL) {
- deb_rc("not alt found!\n");
- return -ENODEV;
- }
-
- ret = usb_set_interface(d->udev, alt->desc.bInterfaceNumber,
alt->desc.bAlternateSetting);
- if (ret < 0)
- return ret;
-
- de
[linux-dvb] Re: MSI Megasky 580 using Uli m9206 -- http://linuxtv.org/hg/~mkrufky/m920x
On Wed, 27 Sep 2006 13:16:36 +0200 (CEST) Patrick Boettcher <[EMAIL PROTECTED]> wrote: > Hi Micheal, > > Attached you'll find my suggestions to your current tree. -#include "m920x.h" +#define DVB_USB_LOG_PREFIX "m920x" +#include "dvb-usb.h" -#ifndef _DVB_USB_M920X_H_ -#define _DVB_USB_M920X_H_ -#define DVB_USB_LOG_PREFIX "m920x" -#include "dvb-usb.h" - -extern int dvb_usb_m920x_debug; -#define deb_rc(args...) dprintk(dvb_usb_m920x_debug,0x01,args) - -#endif New defines in m920x.h . - if (mutex_lock_interruptible(&d->i2c_mutex) < 0) + if (mutex_lock_interruptible(&d->i2c_mutex) < 0) /* I'm not sure about using the i2c_mutex here is a good idea - maybe it is better to create m920x_state and put a device-specific mutex or use the usb_mutex from dvb_usb_device */ You can actually drop this altogether. M9206_CORE, M9206_I2C, M9206_FILTER and M9206_FW can be accessed concurrently. - if (msg[i].addr == 0x1e) + if (msg[i].addr == 0x1e) // This screams for a comment or for another solution. Given in my patch. I wouldn't try to fix it until we know whether they are different on different tuners or demods. - if (pid == 8192) + if (pid == 8192) /* handling this special PID should be in dvb-usb-dvb and should call the pid_filter_ctrl-ops */ This is now done differently because I think this might fall when both of the disabling methods are used at the same time. The way pid filters need to be set seems a bit picky also. > Patrick. > > On Tue, 26 Sep 2006, Michael Krufky wrote: > > > Patrick, > > > > Could you look over the changesets in this tree and let me know > > whether or not you approve of this? > > > > Aapo, > > > > After you sent your patch in to the linux-dvb mailing list, Patrick > > had some comments and requests for certain things to be cleaned > > up. I have not seen any response from you about those requests. > > > > In an effort to move things along, I have taken it upon myself to > > clean up your patch. I've updated it to comply with some of the > > recent changes in the dvb-usb structure, and to use the new > > dvb_attach() method. > > > > I have also separated the qt1010 tuner code into a separate header > > file. It has come to my attention, thanks to Markus Rechberger, > > that there may be more fixing to do with regards to the qt1010 > > stuff... but that can be done later, in a separate patch. > > > > I'd like it if you could test the updated tree and confirm that it > > works as expected with your device. Please clone the following > > tree: > > > > http://linuxtv.org/hg/~mkrufky/m920x > > > > You will notice that I have decided to rename the driver from > > megasky to m920x -- I did this for a few reasons: > > > > 1) There are probably other devices out there based on the m9205, > > m9206 and m9207 chipsets ... Adding support for those devices will > > probably be a matter of updating the code in this driver, in which > > case, the name 'megasky' may be inappropriate. > > > > 2) There is another device out there, called "MSI Megasky 580", > > based on the gl861 chipset, using the same exact usb id as your > > device based on the m9206 chipset. This means that MSI released > > two completely different devices, each with the same exact name and > > USB ID! > > > > 3) We should name the driver based on the chipset it uses, rather > > than the Vendor's retail name of the product. > > > > Please let me know what happens. > > > > Regards, > > > > Michael Krufky > > -- Aapo Tahkola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DViCO FusionHDTV DVB-T Dual Digital problems
Peter Fern wrote: Kielogl wrote: I also tried Chris Pascoe's tree http://linuxtv.org/hg/~pascoe/v4l-dvb-test/ and it has the same problems with USB tuner stability and with SBS on the PCI tuner. But it does not require the +17Hz offset for Nine and SBS (thanks Damien) as the current development tree does, so it looks like all of Chris's changes have not been merged as yet. I have both tuners working fine under 2.6.16.19 with the hg tree using the ZL10353 based version, with the following transports for SBS and Nine in Melbourne: Nine: 191791667 SBS: 53667 Perhaps try a stock kernel instead of the FC-rolled version? I have just tried compiling the 2.6.18 kernel and today's sources from the main hg repository. Distro is FC5 (with vanilla kernel 2.6.18), DViCO Board is revision 1.4, with the ZL10353 frontend. In just doing some quick testing, SBS in Brisbane, Australia appears to be more stable than before - with some notes: - It (and channel 9) still require the +17Hz offset. - When using tzap, the PCI tends to lock on SBS on the the 3rd line consistently, whereas all other channels lock by the 2nd line. - The USB for SBS tends to lock by the second tzap. This behavior seems to be quite repeatable. I am going to leave tzap on overnight on the USB and see If I get the "drop out" problem described before. Tzap is recoding an SNR of about D5D5 for SBS and FEFE for most other channels. Chris's test branch, which is what I have installed on my old vanilla kernel (2.6.17.8, I think), does not require the offset, but has been known to have stability problems as described in previous threads. I will probably report back with another round of testing over the next couple of days. Best regards Damien Dusha. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KWorld VStream XPert DVB-T card fails to lock kernel 2.6.18
Babstar wrote: Hello, I just upgraded to kernel 2.6.18 and my Kworld V-Stream DVB-T card now fails to lock, whereas everything was fine with 2.6.17. Here is a copy of dmesg & lsmod -- Ben # dmesg 1fff8000 (ACPI data) BIOS-e820: 1fff8000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000fb880 On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fa710 ACPI: RSDT (v001 AMIINT VIA_K7 0x0010 MSFT 0x0097) @ 0x1fff ACPI: FADT (v001 AMIINT VIA_K7 0x0011 MSFT 0x0097) @ 0x1fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x0009 MSFT 0x0097) @ 0x1fff00c0 ACPI: DSDT (v001VIA VIA_K7 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:6 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Detected 1399.849 MHz processor. Built 1 zonelists. Total pages: 131056 Kernel command line: root=/dev/hda2 ro mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 516700k/524224k available (1543k kernel code, 6972k reserved, 560k data, 152k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2801.09 BogoMIPS (lpj=1400547) Security Framework v1.0.0 initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1cbfbff CPU: After vendor identify, caps: 0383fbff c1cbfbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 0420 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. CPU: AMD Athlon(tm) XP 1600+ stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20060707 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfdb21, last bus=1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 *12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 9 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: :00:01.0 IO window: disabled. MEM window: d1e0-d3ef PREFETCH window: c1c0-d1cf PCI: Bus 2, cardbus bridge: :00:06.0 IO window: 1000-10ff IO window: 1400-14ff PREFETCH window: 3000-31ff MEM window: 3200-33ff PCI: Setting latency timer of device :00:01.0 to 64 PCI: Enabling device :00:06.0 ( -> 0003) ACPI: PCI Interrupt :00:06.0[A] -> GSI 17 (level, low) -> IRQ 169 PCI: Setting latency timer of device :00:06.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
RE: [linux-dvb] FusionHDTV DVB-T Dual Digital2
I recieved mine in the mail today, actually, and i've installed it and had very little success so far. They've definatly removed the need for the USB cable. What they've done with the card is include two usb->pci bridges on the card (VIA VT82x) and installed two USB tuners on the card. The usb devices have the USB ID 0fe9:db58. So far i've tried the dvb_usb_cxusb driver with its firmware with no success. The driver appears to not even acknowledge the card's existance. I'm still trying to figure out what exactly to do with the card. I'm certainly open to ideas. Mark > Hi All > > Just a question for the readers of this list, I have just found out > that Fusion/DvICO have released the FusionHDTV DVB-T Dual Digital2 > tuner card which is significantly different from the version that I > bought a few months back (the one where you had to plug the second > tuner into a spare USB port using a fly lead). > > Has anyone received the new one (they have removed the need for the > use of the USB cable) and does it work under Linux. I have managed to > get my version 1 partially working under SuSE 10.1 open source > edition, but still struggling to get it fully working. > > I also think there is another change but cannot be sure unless I open > my pc up, but the circuit board shows a VIA chipset on there, > personally I dont remember one on mine but I could be mistaken. > > Sorry if posted incorrectly, but I am trying to find out as much as I > can before deciding what to do with my version 1 card. > > Regards to all > Andrew McDonald (United Kingdom) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
RE: [linux-dvb] FusionHDTV DVB-T Dual Digital2
Hi, > I'm still trying to figure out what exactly to do with the card. I'm > certainly open to ideas. Give it to me? Tap into the USB bus and use it as an extra USB hub. I'm, I'm not much help now am I dad? Soyeb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KWorld VStream XPert DVB-T card fails to lock kernel 2.6.18
Sid Boyce wrote: Babstar wrote: Hello, I just upgraded to kernel 2.6.18 and my Kworld V-Stream DVB-T card now fails to lock, whereas everything was fine with 2.6.17. Here is a copy of dmesg & lsmod -- Ben I was beginning to suspect my lead to this PCC from the amplifier, the other PC is running 2.6.18-rc7-smp (Athlon 64x2) without problems and this one (XP300+ 32-bit) on 2.6.18 gives the errors. later today I shall boot the 64x2 on 2.6.18 to see if it has the same problem. kaffeine: XinePart: Using xine-config file: /home/lancelot/.kde/share/apps/kaffeine/xine-config Tuning to: ITV1 / autocount: 0 DvbCam::probe(): /dev/dvb/adapter0/ca0: : No such file or directory Using DVB device 0:0 "Zarlink MT352 DVB-T" tuning DVB-T to 658166000 Hz inv:2 bw:0 fecH:2 fecL:9 mod:3 tm:0 gi:0 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed Tuning delay: 1825 ms Tuning to: ITV3 / autocount: 0 Using DVB device 0:0 "Zarlink MT352 DVB-T" tuning DVB-T to 658166000 Hz inv:2 bw:0 fecH:2 fecL:9 mod:3 tm:0 gi:0 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed Tuning delay: 1755 ms Regards Sid. 2.6.18 on the 64x2 is running kaffeine and DVB is good, so it looks like my original analysis that it's the lead or hardware seems the likely cause. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KWorld VStream XPert DVB-T card fails to lock kernel 2.6.18
Sid Boyce wrote: > > 2.6.18 on the 64x2 is running kaffeine and DVB is good, so it looks > like my original analysis that it's the lead or hardware seems the > likely cause. > Regards > Sid. Sid, I my case it doesn't appear to be hardware related. If I boot straight back into 2.6.17 without touching the box, I can tzap any of my three adapters and gain a lock immediately, whereas in 2.6.18 I can't. -- Ben ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
R: R: [linux-dvb] Requesting help to configure remoteforSAA7134_BOARD_FLYDVB_TRIO
Hi > Peter had the card only for a very short time, but he called then for > testers with m$ using maybe regspy of DScaler to find something, IIRC. > It might be more complicated and not unlikely he went already through > pulling gpios, but can't say. I moved the card to my windows pc, I installed the windows driver and regspy. I see that as happened on linux, the only byte that change on remote key press/release is 0x0004, so this confirmed me the gpio mask, but I don't get any other gpio change related to remote. Perhaps the gpio change is used as "irq" to request driver to poll the pic. So I haad to suppose that the pic may be connected to i2c line like pinnacle or purpletv card. Eddi ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Flooding interrupts
tis 2006-09-26 klockan 09:57 +0200 skrev Jimmy Hedman: > On Mon, 2006-09-25 at 23:40 +0200, Hartmut Hackmann wrote: > > Hi, > > > > Jimmy Hedman wrote: > > > Hi, > > > I have a Compro DVB-T 300 which uses the saa7134-dvb-driver. When it's > > > tuned it is flooding my system with between 12000 and 16000 interrupts a > > > second. It works, but that amout of interrupts doesn't sound healty. Any > > > ideas what this could be? > > > > > > Many thanks in advance, > > > Jimmy Hedman > > > > > The streaming DMA causes loads of interrupts, but not that many. > > For DVB-T you should expect about 70 per sec, and for analog, its > > up to 50 per sec for 50Hz systems. > > The only other valid interrupt source are the GPIOs (Remote control). > > If there really are so many interrupts, there must be something wrong > > with the GPIO config but i don't think so. > I actually have a problem with the remote! It's giving the last pressed > key plus the current key every time which makes it impossible to use. > The first key goes through, but all the following keys gets duplicated > on the next key press. For example, if I press DOWN, DOWN, UP, LEFT, i > get DOWN, DOWN+DOWN, DOWN+UP, UP+LEFT. > Can I debug this in any way? I did some debugging with 'ir_debug=1 i2c_debug=1 irq_debug=1 gpio_tracking=1' for saa7134 and 'debug=1' on both ir_common and ir_kbd_i2c and when i do this the remote seem to be working fine. I have logfiles at http://www.linuxguru.se/temp/messages.gz and http://www.linuxguru.se/temp/syslog.gz if anyone is interrested in looking at it. // Jimmy ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Zoilo Gomez wrote: >> === >> 0 5 0 20 136 75 0 20 >> dst_ca_ioctl: -->CA_GET_SLOT_INFO Success ! >> dst_ca_ioctl: Sending message >> ca_send_message: ca_send_message: Command=[0x9f8020] >> >> ca_send_message: Getting Cam Application information >> put_checksum: Computing string checksum. >> put_checksum: -> string length : 0x07 >> put_checksum: -> checksum : 0xb7 >> dst_put_ci: Put Command >> dst(1) dst_comm_init: Initializing DST. >> dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] >> dst(1) rdc_reset_state: Resetting state machine >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] >> writing [ 07 40 01 00 01 00 00 b7 ] >> dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] >> dst(1) read_dst: reply is 0xff >> dst(1) dst_wait_dst_ready: dst wait ready after 1 >> dst(1) read_dst: reply is 0xd >> 0x40 0x0 0x0 0x1 0x6 0x0 0x0 0x3 0x1 0x0 0x41 0x0 0x67 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >> ca_get_app_info: -->dst_put_ci SUCCESS ! >> ca_get_app_info: CI Module >> Application Info == >> ca_get_app_info: Application Type=[0], Application Vendor=[769], >> Vendor Code=[65] >> ca_get_app_info: Application info=[] >> ca_get_app_info: >> == It looks like the CAM no longer responds. Which CAM are you using ? The CAM did not like some commands send to it, probably ? >> >> ca_send_message: -->CA_APP_INFO_ENQUIRY Success ! >> dst(1) dst_comm_init: Initializing DST. >> dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] >> dst(1) rdc_reset_state: Resetting state machine >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] >> dst_ca_ioctl: Getting message >> ca_get_message: Message = [9f 80 21] >> ca_get_message: Command=[0x9f8021] >> dst_ca_ioctl: -->CA_GET_MSG Success ! >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] >> writing [ 09 00 04 ae 3e 00 1a f4 40 b9 ] >> dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] >> dst(1) read_dst: reply is 0xff >> dst(1) dst_wait_dst_ready: dst wait ready after 42 >> dst(1) read_dst: reply is 0x9 >> 0x0 0x4 0xae 0x3e 0x0 0x1a 0xf4 0x40 0xb9 >> dst(1) dst_comm_init: Initializing DST. >> dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] >> dst(1) rdc_reset_state: Resetting state machine >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] >> writing [ 00 05 00 00 00 00 00 fb ] >> dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] >> dst(1) read_dst: reply is 0xff >> dst(1) dst_wait_dst_ready: dst wait ready after 1 >> dst(1) read_dst: reply is 0x0 >> 0x5 0x0 0x0 0x88 0x2 0x0 0x71 >> > > At this point things stop ... > > When I tune again to the same very channel (successfully), dmesg output > does not stop at this point, but continues as follows: > >> dst_ca_ioctl: Sending message >> ca_send_message: ca_send_message: Command=[0x9f8032] >> >> ca_send_message: Command = SEND_CA_PMT >> asn_1_decode: Length field=[21] >> asn_1_decode: Length=[21] >> >> ca_set_pmt: CA Message length=[33] >> String=[ 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 02 08 fd 00 00 04 09 >> 08 00 00 06 09 c5 00 00 06 09 05 00 00 ] >> put_checksum: Computing string checksum. >> put_checksum: -> string length : 0x28 >> put_checksum: -> checksum : 0x9b >> String=[ 28 40 03 00 03 21 00 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 >> 02 08 fd 00 00 04 09 08 00 00 06 09 c5 00 00 06 09 05 00 00 9b ] >> dst_put_ci: Put Command >> dst(1) dst_comm_init: Initializing DST. >> dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] >> dst(1) rdc_reset_state: Resetting state machine >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] >> dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] >> writing [ 28 40 03 00 03 21 00 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 >> 02 08 fd 00 00 04 09 08 00 00 06 09 c5 00 00 06 09 05 00 00 9b ] >> dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] >> dst(1) read_dst: reply is 0xff >> write_to_8820: DST-CI Command success. >> ca_send_message: -->CA_PMT Success ! >> > > So I think tha
[linux-dvb] Bad signal with Nova-T-500
Hi, I finally got the drivers installed for this card thanks to you guys. I managed to make a channels.conf file using scandvb and it found all the channels. But when I use tzap, I get results like this: using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' tuning to 71400 Hz video pid 0x006f, audio pid 0x0079 status 03 | signal 7c35 | snr | ber 001f | unc | status 1f | signal 7c38 | snr | ber | unc 08dd | FE_HAS_LOCK status 1f | signal 7c32 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7c38 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7c29 | snr | ber | unc 000e | FE_HAS_LOCK status 1f | signal 7c3d | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7c22 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7c1e | snr | ber 00c0 | unc | FE_HAS_LOCK I have used the card with Windows and had very good reception on this mux as well as other muxes with far worse signal (I have several roof antennas, and some channels/muxes are on amplified frequencies - like the one above - while others are not amplified. In Windows (dvbviewer) I can watch them all). If I run tzap for one of the "bad" channels, ber goes up but the snr is still . The output above is for adapter1, but it's exactly the same for adapter0. I also tried running dvbstream, but it just creates an empty file (this could be because of a bad installation though? - I just copied the dvbstream executable to /usr/bin). Any ideas? Regards, Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Manu Abraham wrote: Zoilo Gomez wrote: === 0 5 0 20 136 75 0 20 dst_ca_ioctl: -->CA_GET_SLOT_INFO Success ! dst_ca_ioctl: Sending message ca_send_message: ca_send_message: Command=[0x9f8020] ca_send_message: Getting Cam Application information put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xb7 dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 07 40 01 00 01 00 00 b7 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0xd 0x40 0x0 0x0 0x1 0x6 0x0 0x0 0x3 0x1 0x0 0x41 0x0 0x67 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ca_get_app_info: -->dst_put_ci SUCCESS ! ca_get_app_info: CI Module Application Info == ca_get_app_info: Application Type=[0], Application Vendor=[769], Vendor Code=[65] ca_get_app_info: Application info=[] ca_get_app_info: == It looks like the CAM no longer responds. Which CAM are you using ? The CAM did not like some commands send to it, probably ? I am using a Nagravision CAM. ca_send_message: -->CA_APP_INFO_ENQUIRY Success ! dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst_ca_ioctl: Getting message ca_get_message: Message = [9f 80 21] ca_get_message: Command=[0x9f8021] dst_ca_ioctl: -->CA_GET_MSG Success ! dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 09 00 04 ae 3e 00 1a f4 40 b9 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 42 dst(1) read_dst: reply is 0x9 0x0 0x4 0xae 0x3e 0x0 0x1a 0xf4 0x40 0xb9 dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 05 00 00 00 00 00 fb ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0x0 0x5 0x0 0x0 0x88 0x2 0x0 0x71 At this point things stop ... When I tune again to the same very channel (successfully), dmesg output does not stop at this point, but continues as follows: dst_ca_ioctl: Sending message ca_send_message: ca_send_message: Command=[0x9f8032] ca_send_message: Command = SEND_CA_PMT asn_1_decode: Length field=[21] asn_1_decode: Length=[21] ca_set_pmt: CA Message length=[33] String=[ 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 02 08 fd 00 00 04 09 08 00 00 06 09 c5 00 00 06 09 05 00 00 ] put_checksum: Computing string checksum. put_checksum: -> string length : 0x28 put_checksum: -> checksum : 0x9b String=[ 28 40 03 00 03 21 00 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 02 08 fd 00 00 04 09 08 00 00 06 09 c5 00 00 06 09 05 00 00 9b ] dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 28 40 03 00 03 21 00 03 2f 6e 01 00 07 01 09 04 18 01 e0 23 02 08 fd 00 00 04 09 08 00 00 06 09 c5 00 00 06 09 05 00 00 9b ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff write_to_8820: DST-CI Command success. ca_send_message: -->CA_PMT Success ! So I think that there is a CA problem. Any idea why the dst_ca_ioctl call does not occur? Which application are you using ? The dst_ca ioctl is called "ony for CA operations" I am using vlc. Z. _
Re: [linux-dvb] Advice: which DVB-S card to buy?
Rudy Zijlstra wrote: > Manu Abraham wrote: > >> Rudy Zijlstra wrote: >> >> >>> Dear, >>> >>> I'll be extending my setup with a new DVB-S card. As DVB-S2 is being >>> used more and more, it seems a pity not to include DVB-S2 capability. >>> >> >> The driver is still not complete yet. In pre-alpha state. >> >> > Any idea on when it would reach alpha state? The vendor itself had talked about more updates on the STB0899 specifications. It's a new delivery system and a new demodulator and a new driver. I will keep you all updated. > >> >> >> >>> Which DVB-S2 card is currently best supported, and from which tree? Can >>> anyone share experience? >>> >> >> Once done , most of the cards should be supported, (card support should >> be trivial) won't make much of a difference though. But need to fix some >> more things in there >> >> >> > Which one(s) are you using for development? Currently i am using a KNC1 DVB-S2 card, will be moving to a VP-1040 DVB-S2 soon enough. Don't let what i am working on, decide your choice at this point of stage, as i am not very sure about any positive recommendations, unless i am seeing some really good results. Most of the DVB-S2 cards are in low volume or sample level distribution, these days. it has not reached a commercial state yet. But things will change soon though. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Zoilo Gomez wrote: > Manu Abraham wrote: > >> Zoilo Gomez wrote: >> >> >> === 0 5 0 20 136 75 0 20 dst_ca_ioctl: -->CA_GET_SLOT_INFO Success ! dst_ca_ioctl: Sending message ca_send_message: ca_send_message: Command=[0x9f8020] ca_send_message: Getting Cam Application information put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xb7 dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 07 40 01 00 01 00 00 b7 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0xd 0x40 0x0 0x0 0x1 0x6 0x0 0x0 0x3 0x1 0x0 0x41 0x0 0x67 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ca_get_app_info: -->dst_put_ci SUCCESS ! ca_get_app_info: CI Module Application Info == ca_get_app_info: Application Type=[0], Application Vendor=[769], Vendor Code=[65] ca_get_app_info: Application info=[] ca_get_app_info: == >> >> >> It looks like the CAM no longer responds. Which CAM are you using ? The >> CAM did not like some commands send to it, probably ? >> >> > > I am using a Nagravision CAM. I don't see Nagravision in the list of supported modules. It does work ? Maybe the card firmware is more updated. The list what i have is a bit older. The list what i have goes like this Were you able to decrypt anything at all, with this CAM/card combination ? Crypto Works1.0 OK Cryptoworks 12011 N/A（无此CAM） Magic 1.1 OK 76.5NG Dragon I & II 2.05, 2.06 N/A（无此CAM） PentaCrypt 1.05OK Irdeto 2.09OK 110.5 OK Irdeto 1.06N/A（无此CAM） Free CAM2-018 未知 OK AstonCrypt 1.03OK Viaccess1.0 V481OK 76.5OK Viaccess1.0 V483OK 76.5OK AlphaCrypt 1.0 OK Aston I 1.05OK AstonII 未知 NG SECA I & II 1.05N/A（无此CAM） Nagravision 未知 OK Free-X-TV 2.26OK 95 OK Free-X-TV 2.0 N/A（无此CAM） Module 0.78OK Zeta Cam未知 OK 76.5/95 OK Conax 4.00e OK Conax 4.0 N/A（无此CAM） BetaCrypt 1.0 N/A（无此CAM） > ca_send_message: -->CA_APP_INFO_ENQUIRY Success ! dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst_ca_ioctl: Getting message ca_get_message: Message = [9f 80 21] ca_get_message: Command=[0x9f8021] dst_ca_ioctl: -->CA_GET_MSG Success ! dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 09 00 04 ae 3e 00 1a f4 40 b9 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 42 dst(1) read_dst: reply is 0x9 0x0 0x4 0xae 0x3e 0x0 0x1a 0xf4 0x40 0xb9 dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 05 00 00 00 00 00 fb ] dst(1) dst_gpio_outb: mask=[], enbb=[0
Re: [linux-dvb] pctv452e driver second try
Dominik Kuhlen wrote: > This stuff comes with no warranty, if you trash some or all of > your equipment its your problem ;-) Aaargh. ;-) Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad signal with Nova-T-500
Hi, SNR is zero, because there is no calculation done in the dib3000mc.c for snr. BER and UNC are 0, is something not working for you ? Do not compare the "signal strength" with other cards (demodulators) on your system. Patrick. On Wed, 27 Sep 2006, [EMAIL PROTECTED] wrote: > Hi, > > I finally got the drivers installed for this card thanks to you guys. I > managed to make a channels.conf file using scandvb and it found all the > channels. > > But when I use tzap, I get results like this: > > using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' > tuning to 71400 Hz > video pid 0x006f, audio pid 0x0079 > status 03 | signal 7c35 | snr | ber 001f | unc | > status 1f | signal 7c38 | snr | ber | unc 08dd | > FE_HAS_LOCK > status 1f | signal 7c32 | snr | ber | unc | > FE_HAS_LOCK > status 1f | signal 7c38 | snr | ber | unc | > FE_HAS_LOCK > status 1f | signal 7c29 | snr | ber | unc 000e | > FE_HAS_LOCK > status 1f | signal 7c3d | snr | ber | unc | > FE_HAS_LOCK > status 1f | signal 7c22 | snr | ber | unc | > FE_HAS_LOCK > status 1f | signal 7c1e | snr | ber 00c0 | unc | > FE_HAS_LOCK > > I have used the card with Windows and had very good reception on this mux as > well as other muxes with far worse signal (I have several roof antennas, and > some channels/muxes are on amplified frequencies - like the one above - > while others are not amplified. In Windows (dvbviewer) I can watch them all). > > If I run tzap for one of the "bad" channels, ber goes up but the snr is > still . > > The output above is for adapter1, but it's exactly the same for adapter0. I > also tried running dvbstream, but it just creates an empty file (this could > be because of a bad installation though? - I just copied the dvbstream > executable to /usr/bin). > > Any ideas? > > Regards, > Thomas > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Freecom usb dvb-t hang usb id 14aa:0221
Hi Team My Freecom usb dvb-t stick seems to hang the system after upgrade from suse 10.0 to 10.1 on my main mythtv server on insertion of the stick. It will NOT hang the system if the stick is in on boot AND the ariel lead is NOT attached. System will boot, but as soon as I try to tune it hangs. However if I dont do a scan and just tune to a channel it seems to work. But If i now reboot with the aerial attached it hangs the system on boot also. usb id is 14aa:0221 I have rebuilt from mercurial and same thing to make matters worse It does however work on my IBM thinkpad laptop also running suse 10.1also, scans, tunes, boots the lot. cant see what the difference is except perhaps the USB hardware. The stick did wotk nicely on suse 10.0 on the main mythbox. Mike C ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: %5Blinux-dvb%5D%20Twinhan%20Cab%2FCI%202031%3A%20frontend%20entry%20sometimes%20missing
Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: === 0 5 0 20 136 75 0 20 dst_ca_ioctl: -->CA_GET_SLOT_INFO Success ! dst_ca_ioctl: Sending message ca_send_message: ca_send_message: Command=[0x9f8020] ca_send_message: Getting Cam Application information put_checksum: Computing string checksum. put_checksum: -> string length : 0x07 put_checksum: -> checksum : 0xb7 dst_put_ci: Put Command dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 07 40 01 00 01 00 00 b7 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 1 dst(1) read_dst: reply is 0xd 0x40 0x0 0x0 0x1 0x6 0x0 0x0 0x3 0x1 0x0 0x41 0x0 0x67 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ca_get_app_info: -->dst_put_ci SUCCESS ! ca_get_app_info: CI Module Application Info == ca_get_app_info: Application Type=[0], Application Vendor=[769], Vendor Code=[65] ca_get_app_info: Application info=[] ca_get_app_info: == It looks like the CAM no longer responds. Which CAM are you using ? The CAM did not like some commands send to it, probably ? I am using a Nagravision CAM. I don't see Nagravision in the list of supported modules. It does work ? Maybe the card firmware is more updated. The list what i have is a bit older. The list what i have goes like this Were you able to decrypt anything at all, with this CAM/card combination ? Sure, it works great, provided that I "tune twice". For example: => vlc -v dvb: --dvb-frequency=30675 <> (nothing happens) => now hit Ctrl-C => vlc -v dvb: --dvb-frequency=30675 <> (picture!). Crypto Works1.0 OK Cryptoworks 12011 N/A（无此CAM） Magic 1.1 OK 76.5NG Dragon I & II 2.05, 2.06 N/A（无此CAM） PentaCrypt 1.05OK Irdeto 2.09OK 110.5 OK Irdeto 1.06N/A（无此CAM） Free CAM2-018 未知 OK AstonCrypt 1.03OK Viaccess1.0 V481OK 76.5OK Viaccess1.0 V483OK 76.5OK AlphaCrypt 1.0 OK Aston I 1.05OK AstonII 未知 NG SECA I & II 1.05N/A（无此CAM） Nagravision 未知 OK Here it says Nagravision in your list !? Free-X-TV 2.26OK 95 OK Free-X-TV 2.0 N/A（无此CAM） Module 0.78OK Zeta Cam未知 OK 76.5/95 OK Conax 4.00e OK Conax 4.0 N/A（无此CAM） BetaCrypt 1.0 N/A（无此CAM） ca_send_message: -->CA_APP_INFO_ENQUIRY Success ! dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst_ca_ioctl: Getting message ca_get_message: Message = [9f 80 21] ca_get_message: Command=[0x9f8021] dst_ca_ioctl: -->CA_GET_MSG Success ! dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 09 00 04 ae 3e 00 1a f4 40 b9 ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] dst(1) read_dst: reply is 0xff dst(1) dst_wait_dst_ready: dst wait ready after 42 dst(1) read_dst: reply is 0x9 0x0 0x4 0xae 0x3e 0x0 0x1a 0xf4 0x40 0xb9 dst(1) dst_comm_init: Initializing DST. dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] dst(1) rdc_reset_state: Resetting state machine dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] writing [ 00 05 00 00 00 00 00 fb ] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[000
Re: [linux-dvb] FusionHDTV DVB-T Dual Digital2
Mark McKenzie wrote: > They've definatly removed the need for the USB cable. What they've done with > the card is include two usb->pci bridges on the card (VIA VT82x) and > installed two USB tuners on the card. The usb devices have the USB ID > 0fe9:db58. Interesting... This ID is not listed in the windows inf file for the FusionHDTV driver, version 3.41 ... > So far i've tried the dvb_usb_cxusb driver with its firmware with no > success. The driver appears to not even acknowledge the card's existance. Exactly. The driver does not know about this new device, so it isn't going to try to mess with it. > I'm still trying to figure out what exactly to do with the card. I'm > certainly open to ideas. Well, you can try this: edit linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h change lines 111 and 112 from: #define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD 0xdb54 #define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM 0xdb55 to: #define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD 0xdb58 #define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM 0xdb59 ... This will tell the driver not to look for the :db54 device, and to try :db58 instead. If this screws up your older dual digital card, then instead, change lines 109 and 110 from: #define USB_PID_DVICO_BLUEBIRD_DEE1601_COLD 0xdb50 #define USB_PID_DVICO_BLUEBIRD_DEE1601_WARM 0xdb51 to: #define USB_PID_DVICO_BLUEBIRD_DEE1601_COLD 0xdb58 #define USB_PID_DVICO_BLUEBIRD_DEE1601_WARM 0xdb59 ... don't change all four lines -- that would be redundant. Basically, there were two different versions of the original dual digital card, each with the same hardware (actually, four different versions each with different pll's but lets not get into that now)... there were two different usb id's in circulation for the same device. If you change one set of ids to match the usb id's of the new, FusionHDTV DVB-T Dual Digital2, then the dvb-usb-cxusb driver will know that it must try to initialize it. I have written to my contact at DViCO with some questions about this device. While we're waiting for his response, please try the suggestion above. Please keep in mind that you will need to have the bluebird firmware present in order for this test to work. Let me know if the device works properly... If it does, then I'll add a more appropriate patch to the repository for autodetection. Good Luck! Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 310i DVB-T Linux
Hi, Mark Mark Schwarz wrote: Hartmut Hackmann schrieb: Hi, Mark Mark Schwarz wrote: Hi, i have an Pinnacle 310i but i don't want analoge TV! Is there an chance to get it runnning in DVB-T ? linuxtv.org means: only work analogue tv, not digital. :-( Please give a sign if anyone has a advice We had a preliminary patch. Unfortunately, it no longer applies. I intend to add support for this card very soon. Hartmut Is there a date when the patch release or can i try it before ? Greetings Mark Since i don't have such a card, i will need testers anyway. I will first propose a patch on the mailing list. Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB listings
Hi Guys, I am wondering if it would be possible to get my hands on the listings I am told is broadcasted in the DVB stream. MythTV offers to pick them up. I am wondering if it would be possible to replace the tv_grab_xx scripts with this service. Thanx in advance Jesper Taxbol Denmark ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
The attached patch changes the IR function in budget-ci so that it reads all IR sequences from the MSP430 chip. This allows the code to ignore invalid RC5 codes and also allows it to decide which RC5 device code was used to send the command (which would fix the problem of using multiple RC5 remotes [0]). Per default the driver still listens to commands from all devices, but using the ir_device parameter, it is possible to limit it to a single device (which is a good thing if there are other RC5 devices nearby). Compiled and tested with a programmable remote using a number of different RC5 device codes. This patch needs to be applied on top of the dynamic keymap patch posted earlier[1]. Signed-off-by: David Härdeman <[EMAIL PROTECTED]> [0] http://www.linuxtv.org/mailinglists/linux-dvb/2004/03-2004/msg00721.html [1] http://www.linuxtv.org/pipermail/linux-dvb/2006-September/013100.html -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Signal Strength for lgdt330x
Rusty Scott wrote:
> (I guess it would help if I actually attached the patch before sending...)
>
> Here it is...
>
> I have attached a patch for the LGDT330X frontend, to allow for signal
> strength
> reporting. It also reports snr in dB using the dvb_math functions. This
> change to SNR reporting still fits within the current interpretation of the
> return value, it just gives more meaning to the numbers for those of us who
> want it. The change is applied to both 3302 and 3303 frontends. I have
> passed
> it around for limited testing, and it is reported to work, so I'm posting it
> here for consideration.
>
> Thanks,
>
> Rusty
Great work, Rusty!
I have tested the patch and it seems to work as expected on cards based
on both LG DT3302 and DT3303.
Mac,
Do you have any problems with this patch being applied? Rusty has been
trying to contact you about this as well, but emails have been bouncing
back...
If I dont hear back after a few more days, I will go ahead and merge it,
although I'd be happier if Mac would add his sign-off to Rusty's patch
before I move forward.
Please review and respond.
Thanks,
Mike Krufky
>
>
> # HG changeset patch
> # User Rusty Scott <[EMAIL PROTECTED]>
> # Node ID f4de0afd4a56499607adf29bb5f7859cbeafe118
> # Parent fae890aee0c365fe8741b166690c9f0a81c495a1
> lgdt330x signal strength reporting
>
> From: Rusty Scott <[EMAIL PROTECTED]>
>
> Change read_snr to report in dB using dvb_math functions
> Add signal strength reporting as 0 to 100% of 35 dB SNR signal
>
> Signed-off-by: Rusty Scott <[EMAIL PROTECTED]>
>
> diff -r fae890aee0c3 -r f4de0afd4a56
> linux/drivers/media/dvb/frontends/lgdt330x.c
> --- a/linux/drivers/media/dvb/frontends/lgdt330x.cTue Sep 19 12:51:56
> 2006 -0300
> +++ b/linux/drivers/media/dvb/frontends/lgdt330x.cTue Sep 19 21:18:20
> 2006 -0600
> @@ -46,6 +46,7 @@
> #include
>
> #include "dvb_frontend.h"
> +#include "dvb_math.h"
> #include "lgdt330x_priv.h"
> #include "lgdt330x.h"
>
> @@ -549,130 +550,135 @@ static int lgdt3303_read_status(struct d
> return 0;
> }
>
> -static int lgdt330x_read_signal_strength(struct dvb_frontend* fe, u16*
> strength)
> -{
> - /* not directly available. */
> - *strength = 0;
> - return 0;
> -}
> -
> static int lgdt3302_read_snr(struct dvb_frontend* fe, u16* snr)
> {
> -#ifdef SNR_IN_DB
> /*
>* Spec sheet shows formula for SNR_EQ = 10 log10(25 * 24**2 / noise)
> - * and SNR_PH = 10 log10(25 * 32**2 / noise) for equalizer and phase
> tracker
> - * respectively. The following tables are built on these formulas.
> - * The usual definition is SNR = 20 log10(signal/noise)
> - * If the specification is wrong the value retuned is 1/2 the actual
> SNR in db.
> - *
> - * This table is a an ordered list of noise values computed by the
> - * formula from the spec sheet such that the index into the table
> - * starting at 43 or 45 is the SNR value in db. There are duplicate
> noise
> - * value entries at the beginning because the SNR varies more than
> - * 1 db for a change of 1 digit in noise at very small values of noise.
> - *
> - * Examples from SNR_EQ table:
> - * noise SNR
> - * 043
> - * 142
> - * 239
> - * 337
> - * 436
> - * 535
> - * 634
> - * 733
> - * 833
> - * 932
> - * 10 32
> - * 11 31
> - * 12 31
> - * 13 30
> + * and SNR_PH = 10 log10(25 * 32**2 / noise) for equalizer and phase
> + * tracker respectively.
>*/
>
> - static const u32 SNR_EQ[] =
> - { 1, 2, 2, 2, 3, 3, 4, 4, 5,
> 7,
> - 9, 11, 13, 17, 21, 26, 33,41,52,
> 65,
> - 81,102,129,162, 204,257,323, 406,
> 511, 644,
> - 810, 1020, 1284, 1616, 2035, 2561, 3224, 4059,
> 5110, 6433,
> - 8098, 10195, 12835, 16158, 20341, 25608, 32238, 40585,
> 51094, 64323,
> - 80978, 101945, 128341, 161571, 203406, 256073, 0x4
> - };
> -
> - static const u32 SNR_PH[] =
> - { 1, 2, 2, 2, 3, 3, 4, 5,
> 6, 8,
> - 10,12, 15, 19, 23, 29, 37,46,58,
> 73,
> - 91,115,144,182,229,288, 362, 456,
> 574, 722,
> - 909, 1144, 1440, 1813, 2282, 2873, 3617, 4553,
> 5732, 7216,
> - 9084, 11436, 14396, 18124, 22817, 28724, 36161, 45524,
> 57312, 72151,
> - 90833, 114351, 143960, 181235, 228161, 0x08
> - };
> -
> - static u8 buf[5];/* read data buffer */
> - static u32 noise; /* noise
Re: [linux-dvb] Hauppauge WinTV NOVA T USB2 not working any more
Hi Patrick,
this is the patch that works for me. It is against the current v4l-dvb
mercurial, but I guess you wanted to have reg52 dynamically coming
from the dibx000_agc_config.
--- linux/drivers/media/dvb/frontends/dib3000mc.c.orig 2006-09-27
23:32:40.0 +0100
+++ linux/drivers/media/dvb/frontends/dib3000mc.c 2006-09-27
22:28:51.0 +0100
@@ -152,13 +152,13 @@ static int dib3000mc_set_timing(struct d
static int dib3000mc_setup_pwm_state(struct dib3000mc_state *state)
{
- u16 reg_51, reg_52 = state->cfg->agc->setup & 0xfefb;
+ u16 reg_51, reg_52;
if (state->cfg->pwm3_inversion) {
reg_51 = (2 << 14) | (0 << 10) | (7 << 6) | (2 << 2)
| (2 << 0);
- reg_52 |= (1 << 2);
+ reg_52 = (0 << 8) | (5 << 5) | (1 << 4) | (1 << 3) |
(1 << 2) | (2 << 0);
} else {
reg_51 = (2 << 14) | (4 << 10) | (7 << 6) | (2 << 2) | (2 << 0);
- reg_52 |= (1 << 8);
+ reg_52 = (1 << 8) | (5 << 5) | (1 << 4) | (1 << 3) |
(0 << 2) | (2 << 0);
}
dib3000mc_write_word(state, 51, reg_51);
dib3000mc_write_word(state, 52, reg_52);
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
The attached patch changes the IR function in budget-ci so that it reads
all IR sequences from the MSP430 chip. This allows the code to ignore
invalid RC5 codes and also allows it to decide which RC5 device code was
used to send the command (which would fix the problem of using multiple
RC5 remotes [0]).
Per default the driver still listens to commands from all devices, but
using the ir_device parameter, it is possible to limit it to a single
device (which is a good thing if there are other RC5 devices nearby).
Compiled and tested with a programmable remote using a number of
different RC5 device codes.
This patch needs to be applied on top of the dynamic keymap patch posted
earlier[1].
Patch included this time :)
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
[0] http://www.linuxtv.org/mailinglists/linux-dvb/2004/03-2004/msg00721.html
[1] http://www.linuxtv.org/pipermail/linux-dvb/2006-September/013100.html
--
David Härdeman
diff -ur linux-old/drivers/media/dvb/ttpci/budget-ci.c
linux/drivers/media/dvb/ttpci/budget-ci.c
--- linux-old/drivers/media/dvb/ttpci/budget-ci.c 2006-09-26
17:12:41.0 +0200
+++ linux/drivers/media/dvb/ttpci/budget-ci.c 2006-09-27 23:11:25.0
+0200
@@ -65,6 +65,17 @@
#define SLOTSTATUS_READY 8
#define SLOTSTATUS_OCCUPIED
(SLOTSTATUS_PRESENT|SLOTSTATUS_RESET|SLOTSTATUS_READY)
+#define IR_RECV_NONE 0
+#define IR_RECV_DEVICE 1
+#define IR_RECV_CMD1 2
+#define IR_RECV_CMD2 4
+#define IR_RECV_ALL(IR_RECV_DEVICE|IR_RECV_CMD1|IR_RECV_CMD2)
+
+static int ir_device = -1;
+module_param(ir_device, int, 0644);
+MODULE_PARM_DESC(ir_device,
+"Listen to IR commands from given device (0 - 31, default:
all).");
+
struct budget_ci {
struct budget budget;
struct input_dev *input_dev;
@@ -150,36 +161,87 @@
{
struct budget_ci *budget_ci = (struct budget_ci *) data;
struct input_dev *dev = budget_ci->input_dev;
- unsigned int code =
+ static unsigned int code1;
+ static unsigned int code2;
+ static unsigned int device;
+ static int status = IR_RECV_NONE;
+ unsigned int command =
ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP,
DEBIADDR_IR, 2, 1, 0) >> 8;
- if (code & 0x40) {
- code &= 0x3f;
+ /*
+* Theory of operation
+* ===
+* (from http://home.tiscali.nl/m.majoor/DVBSHardware.pdf)
+*
+* The msp430 generates three different sequences, each one byte:
+* 0x00 <= data < 0x40 = device and toggle information
+* 0x40 <= data < 0x80 = command 1
+* 0x80 <= data < 0xc0 = invalid
+* 0xc0 <= data < 0xff = command 2
+*
+* The device and toggle information byte has the following bit
structure:
+* 00TD, T is the RC5 toggle bit, D are the device code bits (0 -
31)
+*
+* The command bytes have the following bit structure:
+* X1CC, X signifies command 1 or 2, C are the command code bits (0
- 63)
+*
+* The order of the sequences can vary, but a command is only
sucessfully
+* received once all three have appeared at least once, and when the
command 1
+* and command 2 commands match.
+*/
+
+ if (command < 0x40) {
+ /* Device and toggle information */
+ device = command & 0x1f;
+ status |= IR_RECV_DEVICE;
+ dprintk(2, "budget_ci: IR data (device code) - %02x\n", device);
+ } else if (command < 0x80) {
+ /* Command 1 */
+ code1 = command - 0x40;
+ dprintk(2, "budget_ci: IR data (command 1) - %02x\n", code1);
+ status |= IR_RECV_CMD1;
+ } else if (command >= 0xc0 && command <= 0xff) {
+ /* Command 2 */
+ code2 = command - 0xc0;
+ dprintk(2, "budget_ci: IR data (command 2) - %02x\n", code2);
+ status |= IR_RECV_CMD2;
+ } else {
+ /* Invalid */
+ printk("budget_ci: invalid IR data - %02x\n", command);
+ }
- if (timer_pending(&dev->timer)) {
- if (code == dev->repeat_key) {
- ++dev->rep[0];
- return;
- }
- del_timer(&dev->timer);
- input_report_key(dev, INPUT_KEYCODE(dev,
dev->repeat_key), 0);
- }
+ if (status != IR_RECV_ALL || code1 != code2)
+ return;
- if (!INPUT_KEYCODE(dev, code)) {
- printk("DVB (%s): no key for %02x!\n", __FUNCTION__,
code);
+ dprintk(2, "budget_ci: IR key - dev %02x, command %02x\n", device,
code1);
+ status = IR_RECV_NONE;
+
+ if (ir_device >= 0 && ir_device != device)
+ return;
+
+
Re: [linux-dvb] DVB listings
Hello Jesper, > I am wondering if it would be possible to get my hands on the listings I > am told is broadcasted in the DVB stream. MythTV offers to pick them up. You are talking about the EPG (electronic program guide) which is usually broadcast in a DVB stream. Visibility of this data is dependant on your application. I presume MythTV can decode them. Certainly Kaffeine can decode them. I'm not aware of a standalone decoder. > I am wondering if it would be possible to replace the tv_grab_xx scripts > with this service. I guess you could change your application to use the EPG instead of xmltv, but xmltv generally gives more information for programmes and will get more days worth of programming (two weeks compared to EPG's typical one week). In fact, the author of Kaffeine has expressed his desire to integrate xmltv into Kaffeine as a more flexible alternative. Regards, Soyeb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB listings
I'm not aware of a standalone decoder. tv_grab_dvb -- Nigel Pearson, [EMAIL PROTECTED]|"I thought I said no shivs." Telstra Net. Eng., Sydney, Australia | "This? This is just a Office: 9202 3900Fax: 9261 3912 | personal grooming appliance" Mobile: 0408 664435 Home: 9792 6998 |Riddick - Pitch Black ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
I demand that David Härdeman may or may not have written... > The attached patch changes the IR function in budget-ci so that it reads > all IR sequences from the MSP430 chip. This allows the code to ignore > invalid RC5 codes and also allows it to decide which RC5 device code was > used to send the command (which would fix the problem of using multiple RC5 > remotes [0]). [snip] Patches already exist to fix this and other IR-related problems for budget-ci. I've posted them (older versions) to this list a few times, but got little response. http://www.youmustbejoking.demon.co.uk/progs.linux.html#dvb> You might like to look at them since you evidently have functioning hardware with which you can test & debug them. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Play electronic games? You have too much time on your hands. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
RE: [linux-dvb] Freecom usb dvb-t hang usb id 14aa:0221
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Choy > Sent: 27 September 2006 22:02 > To: linux-dvb@linuxtv.org > Subject: [linux-dvb] Freecom usb dvb-t hang usb id 14aa:0221 > > Hi Team > > My Freecom usb dvb-t stick seems to hang the system after > upgrade from suse 10.0 to 10.1 on my main mythtv server on > insertion of the stick. Mike, If you scan back though the archives, you'll see that several of us have had problems recently with variations of Freecom sticks. I have recently upgraded to GCC 4.1 and taken the latest mercurial sources and that seems to have stabilised it. My OS is somewhat in pieces at the moment but I can at least tune it repeatedly and I don't get error messages like before. I wouldn't mind betting that the output of dmesg from your system show lots of 'recv bulk' errors... I have added extra debugging to dvb-usb-urb.c expand error codes, which you can try if you are getting these 'recv bulk' errors Unfortunately I haven't really isolated what affected my system but the next step is to try and run it (again) on my NSLU2. Cheers Mark smime.p7s Description: S/MIME cryptographic signature ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Advice before buying a card.
Hi. I'm running a laptop with Ubuntu, kernel 2.6.15-27. I'd like to buy a PCMCIA/PC Card with support for DVB-T (Terrestrial TV), but I don't have the time to recompile the kernel or mess with it's configuration. Is there a card which is supported by this distro and kernel "out of the box"?. Thank you very much -- Un saludo, Javier ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: MSI Megasky 580 using Uli m9206 -- http://linuxtv.org/hg/~mkrufky/m920x
Aapo Tahkola wrote: > On Wed, 27 Sep 2006 13:16:36 +0200 (CEST) > Patrick Boettcher <[EMAIL PROTECTED]> wrote: > >> Hi Micheal, >> >> Attached you'll find my suggestions to your current tree. First I applied Aapo's patch, then I incorporated suggestions from Patrick and Aapo in this email thread. http://linuxtv.org/hg/~mkrufky/m920x has been updated by the following: - m920x: misc updates and fixes - m920x: more cleanups dvb-usb/m920x.c| 346 ++--- dvb-usb/m920x.h| 30 ++ frontends/qt1010.h |7 3 files changed, 214 insertions(+), 169 deletions(-) How does this look now? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] FusionHDTV DVB-T Dual Digital2
Michael Krufky wrote:
> I have written to my contact at DViCO with some questions about this
> device. While we're waiting for his response, please try the suggestion
> above. Please keep in mind that you will need to have the bluebird
> firmware present in order for this test to work.
I've received confirmation from DViCO that the usb components on the
DViCO FusionHDTV DVB-T Dual Digital 2 are identical to the usb component
on the DViCO FusionHDTV DVB-T Dual Digital 1.
The attached patch, applied against v4l-dvb master repository, adds
support for your device. Please test this and let me know how it goes.
...or you can just clone the tree located at:
http://linuxtv.org/hg/~mkrufky/cxusb
cxusb.c | 14 ++
dvb-usb-ids.h | 10 ++
2 files changed, 16 insertions(+), 8 deletions(-)
Please confirm proper functionality ASAP. I'd like this tested soon, so
that I can add this patch to kernel 2.6.19.
# HG changeset patch
# User Michael Krufky <[EMAIL PROTECTED]>
# Node ID 99961fcb2221dcff2c7024bc5e97b42f16ff4364
# Parent 1ec2f18a9505dafb143518fe7aaf780767ef8c84
cxusb: add support for DViCO FusionHDTV DVB-T Dual Digital 2
From: Michael Krufky <[EMAIL PROTECTED]>
add support for DViCO FusionHDTV DVB-T Dual Digital 2 USB, which
is identical to the usb portion of DViCO FusionHDTV DVB-T Dual Digital 1.
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
diff -r 1ec2f18a9505 -r 99961fcb2221 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Mon Sep 25 13:14:24 2006 -0400
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Thu Sep 28 01:07:48 2006 -0400
@@ -505,14 +505,16 @@ static struct usb_device_id cxusb_table
{ USB_DEVICE(USB_VID_MEDION, USB_PID_MEDION_MD95700) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DEE1601_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DEE1601_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_WARM) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM) },
{} /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -663,6 +665,10 @@ static struct dvb_usb_device_properties
{ &cxusb_table[9], NULL },
{ &cxusb_table[10], NULL },
},
+ { "DViCO FusionHDTV DVB-T Dual Digital 2",
+ { &cxusb_table[11], NULL },
+ { &cxusb_table[12], NULL },
+ },
}
};
diff -r 1ec2f18a9505 -r 99961fcb2221 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Mon Sep 25 13:14:24 2006 -0400
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Thu Sep 28 01:07:48 2006 -0400
@@ -106,10 +106,12 @@
#define USB_PID_DVICO_BLUEBIRD_LGZ201_WARM 0xdb01
#define USB_PID_DVICO_BLUEBIRD_TH7579_COLD 0xdb10
#define USB_PID_DVICO_BLUEBIRD_TH7579_WARM 0xdb11
-#define USB_PID_DVICO_BLUEBIRD_DEE1601_COLD 0xdb50
-#define USB_PID_DVICO_BLUEBIRD_DEE1601_WARM 0xdb51
-#define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD 0xdb54
-#define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM 0xdb55
+#define USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD 0xdb50
+#define USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM 0xdb51
+#define USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD 0xdb58
+#define USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM 0xdb59
+#define USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD 0xdb54
+#define USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM 0xdb55
#define USB_PID_MEDION_MD957000x0932
#define USB_PID_KYE_DVB_T_COLD0x701e
#define USB_PID_KYE_DVB_T_WARM0x701f
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] FusionHDTV DVB-T Dual Digital2
Michael Krufky wrote:
> Michael Krufky wrote:
>> I have written to my contact at DViCO with some questions about this
>> device. While we're waiting for his response, please try the suggestion
>> above. Please keep in mind that you will need to have the bluebird
>> firmware present in order for this test to work.
>
> I've received confirmation from DViCO that the usb components on the
> DViCO FusionHDTV DVB-T Dual Digital 2 are identical to the usb component
> on the DViCO FusionHDTV DVB-T Dual Digital 1.
>
> The attached patch, applied against v4l-dvb master repository, adds
> support for your device. Please test this and let me know how it goes.
>
> ...or you can just clone the tree located at:
>
> http://linuxtv.org/hg/~mkrufky/cxusb
Oops Slight problem in that last patch... I fixed it in the tree,
and the corrected patch is attached. Let me know how it works.
cxusb.c | 16 +++-
dvb-usb-ids.h | 10 ++
2 files changed, 17 insertions(+), 9 deletions(-)
# HG changeset patch
# User Michael Krufky <[EMAIL PROTECTED]>
# Node ID 56cb67d6c6324916393f5d7e8437e7272bf1f353
# Parent 1ec2f18a9505dafb143518fe7aaf780767ef8c84
cxusb: add support for DViCO FusionHDTV DVB-T Dual Digital 2
From: Michael Krufky <[EMAIL PROTECTED]>
add support for DViCO FusionHDTV DVB-T Dual Digital 2 USB, which
is identical to the usb portion of DViCO FusionHDTV DVB-T Dual Digital 1.
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
diff -r 1ec2f18a9505 -r 56cb67d6c632 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Mon Sep 25 13:14:24 2006 -0400
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Thu Sep 28 01:16:01 2006 -0400
@@ -505,14 +505,16 @@ static struct usb_device_id cxusb_table
{ USB_DEVICE(USB_VID_MEDION, USB_PID_MEDION_MD95700) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DEE1601_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DEE1601_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_WARM) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_COLD) },
{ USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD) },
+ { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM) },
{} /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -653,7 +655,7 @@ static struct dvb_usb_device_properties
.generic_bulk_ctrl_endpoint = 0x01,
- .num_device_descs = 2,
+ .num_device_descs = 3,
.devices = {
{ "DViCO FusionHDTV DVB-T Dual USB",
{ &cxusb_table[3], NULL },
@@ -662,6 +664,10 @@ static struct dvb_usb_device_properties
{ "DigitalNow DVB-T Dual USB",
{ &cxusb_table[9], NULL },
{ &cxusb_table[10], NULL },
+ },
+ { "DViCO FusionHDTV DVB-T Dual Digital 2",
+ { &cxusb_table[11], NULL },
+ { &cxusb_table[12], NULL },
},
}
};
diff -r 1ec2f18a9505 -r 56cb67d6c632 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Mon Sep 25 13:14:24 2006 -0400
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Thu Sep 28 01:16:01 2006 -0400
@@ -106,10 +106,12 @@
#define USB_PID_DVICO_BLUEBIRD_LGZ201_WARM 0xdb01
#define USB_PID_DVICO_BLUEBIRD_TH7579_COLD 0xdb10
#define USB_PID_DVICO_BLUEBIRD_TH7579_WARM 0xdb11
-#define USB_PID_DVICO_BLUEBIRD_DEE1601_COLD 0xdb50
-#define USB_PID_DVICO_BLUEBIRD_DEE1601_WARM 0xdb51
-#define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_COLD 0xdb54
-#define USB_PID_DIGITALNOW_BLUEBIRD_DEE1601_WARM 0xdb55
+#define USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD 0xdb50
+#define USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM 0xdb51
+#define USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD 0xdb58
+#define USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM 0xdb59
+#define USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD 0xdb54
+#define USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM 0xdb55
#define USB_PID_MEDION_MD957000x0932
#define USB_PID_KYE_DVB_T_COLD0x701e
#define USB_PID_KYE_DVB_T_WARM0x701f
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad signal with Nova-T-500
On Wed, 27 Sep 2006 22:52:29 +0200 (CEST), Patrick Boettcher wrote ... > SNR is zero, because there is no calculation done in the dib3000mc.c > for snr. Well I won't worry about the numbers, then:-) > BER and UNC are 0, is something not working for you ? Yes, kind of. I thought 0 was good (I do get an occasional value for ber and unc, but they are very low and steady)? When I try to grab to a file using dvbstream I just get an empty file. I just read that I can grab to a file using tzap so I will try that tonight to test if my problem is with dvbstream. > Do not compare the "signal strength" with other cards (demodulators) > on your system. No problem yet - my HVR-1300 is lying around on the desk waiting for things to start working:-) Regards, Thomas > Patrick. > > On Wed, 27 Sep 2006, [EMAIL PROTECTED] wrote: > > Hi, > > > > I finally got the drivers installed for this card thanks to you guys. I > > managed to make a channels.conf file using scandvb and it found all the > > channels. > > > > But when I use tzap, I get results like this: > > > > using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' > > tuning to 71400 Hz > > video pid 0x006f, audio pid 0x0079 > > status 03 | signal 7c35 | snr | ber 001f | unc | > > status 1f | signal 7c38 | snr | ber | unc 08dd | > > FE_HAS_LOCK > > status 1f | signal 7c32 | snr | ber | unc | > > FE_HAS_LOCK > > status 1f | signal 7c38 | snr | ber | unc | > > FE_HAS_LOCK > > status 1f | signal 7c29 | snr | ber | unc 000e | > > FE_HAS_LOCK > > status 1f | signal 7c3d | snr | ber | unc | > > FE_HAS_LOCK > > status 1f | signal 7c22 | snr | ber | unc | > > FE_HAS_LOCK > > status 1f | signal 7c1e | snr | ber 00c0 | unc | > > FE_HAS_LOCK > > > > I have used the card with Windows and had very good reception on this mux as > > well as other muxes with far worse signal (I have several roof antennas, and > > some channels/muxes are on amplified frequencies - like the one above - > > while others are not amplified. In Windows (dvbviewer) I can watch them all). > > > > If I run tzap for one of the "bad" channels, ber goes up but the snr is > > still . > > > > The output above is for adapter1, but it's exactly the same for adapter0. I > > also tried running dvbstream, but it just creates an empty file (this could > > be because of a bad installation though? - I just copied the dvbstream > > executable to /usr/bin). > > > > Any ideas? > > > > Regards, > > Thomas > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Flooding interrupts
> tis 2006-09-26 klockan 09:57 +0200 skrev Jimmy Hedman: >> On Mon, 2006-09-25 at 23:40 +0200, Hartmut Hackmann wrote: >> > Hi, >> > >> > Jimmy Hedman wrote: >> > > Hi, >> > > I have a Compro DVB-T 300 which uses the saa7134-dvb-driver. When >> it's >> > > tuned it is flooding my system with between 12000 and 16000 >> interrupts a >> > > second. It works, but that amout of interrupts doesn't sound healty. >> Any >> > > ideas what this could be? >> > > >> > > Many thanks in advance, >> > > Jimmy Hedman >> > > >> > The streaming DMA causes loads of interrupts, but not that many. >> > For DVB-T you should expect about 70 per sec, and for analog, its >> > up to 50 per sec for 50Hz systems. >> > The only other valid interrupt source are the GPIOs (Remote control). >> > If there really are so many interrupts, there must be something wrong >> > with the GPIO config but i don't think so. >> I actually have a problem with the remote! It's giving the last pressed >> key plus the current key every time which makes it impossible to use. >> The first key goes through, but all the following keys gets duplicated >> on the next key press. For example, if I press DOWN, DOWN, UP, LEFT, i >> get DOWN, DOWN+DOWN, DOWN+UP, UP+LEFT. >> Can I debug this in any way? > I did some debugging with 'ir_debug=1 i2c_debug=1 irq_debug=1 > gpio_tracking=1' for saa7134 and 'debug=1' on both ir_common and > ir_kbd_i2c and when i do this the remote seem to be working fine. > I have logfiles at http://www.linuxguru.se/temp/messages.gz and > http://www.linuxguru.se/temp/syslog.gz if anyone is interrested in > looking at it. The flooding of interrupts continued when I added the debug-options to the modules so this is still an "issue". // Jimmy ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
