[linux-dvb] [Fwd: RE: Some thoughts and questions]
Felix Hi, Fwd'd mail inlined. Reply from one of the major broadcasters over here in the persian Gulf region. http://www.adduniverse.com So as the reply states, i was right additionally, alongwith Felix conclusion of the C band inversion. In reality, we therefore have inversion due to * I/Q wiring * Flo Frf Does anybody have any different thoughts ? Regards, Manu Original Message Subject: RE: [linux-dvb] Some thoughts and questions Date: Sun, 30 Sep 2007 09:56:53 +0400 From: Shaji Joseph [EMAIL PROTECTED] To: Manu Abraham [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In my understanding, Spectral inversion was done only on C band analogue transmissions. And receivers used to have an option to select inversion ON or OFF. Regards Shaji Joseph -Original Message- From: Manu Abraham [mailto:[EMAIL PROTECTED] Sent: 29 September 2007 15:33 To: Shaji Joseph Cc: Felix Domke Subject: Re: [linux-dvb] Some thoughts and questions Dear Shaji, Can you please enlighten us whether broadcasters are required to send non-inverted signals as described in the rest of the mail, in case you have any idea on the same. (We are talking about QPSK modulation/demodulation, according to college books, as implemented by a broadcaster) Regards, Manu Felix Domke wrote: Hi, - Inversion might happen on up- and downconversion, depending on what frequency situation you have. - The SatelliteDeliverySystemDescriptor does not specify Inversion. AFAICS, Inversion isn't a part of the transport. Why not? It's part of it like the frequency, isn't it? What i meant is that it does not depend on the transport, but the hardware. LNB + tuner - demod wiring Whereas frequency is not. Some transponders have an inversed frequency spectrum already when broadcasted (before downconversion). There is no way for the broadcaster to specify this. What do you mean by a inverted spectrum when broadcast ? AFAICS, Inversion happens after there is a Phase shift to extract the I and Q signals Swapping I/Q is *one* way to create spectral inversion. Just inverting the spectrum is (obviosly) another one, and can happen on the (non-complex) modulated signal as well. Just mix it with another frequency and take the lower sideband. It's the same thing which happens in a C-Band downconversion - it can also happen in the upconversion. I don't know if broadcasters are required to send non-inverted signals. I just know (read: remember) that some do. I might be wrong, so second opinions are welcome. Again, I'm not a frontend guy. Maybe somebody with broadcasting experiences can tell us more here. Felix __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ Arab Digital Distribution DISCLAIMER: This Email and its attachments may contain information that is confidential and may be subject to legal privilege and copyright. If you are not the intended recipient you may not peruse, use, disclose, distribute, copy or retain this message. For more information about us visit www.art-tv.net or www.pehlatv.net or www.firstnettv.net This email has been scanned by the MessageLabs Email Security System ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 firmware problems
Hmm, It seems like it only happens while recording on both tuners. I´ll dig some more and see if there is any pattern with MUXes or other. /Henrik On 9/26/07, Patrick Boettcher [EMAIL PROTECTED] wrote: Hi all, it seems that there still problems related to USB with the latest firmware. In order to figure out what is the problem I would like to gather some information about the affected systems: Can everyone (people who still have the disconnects and the ones who don't) please reply directly to this email giving the following information: 1) system (uname -a) 2) lspci-output 3) DiB0700 device name (USB Stick, Nova-T 500) 4) Application using the device (MythTV, VDR etc) 5) Symptoms (unusable, disconnect after x days, no problem) Please make sure that you are using the latest firmware (version 1.10) . thanks and regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ 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] DiB0700 device report
Hi, Can I ask you a few questions about the TD stick, 1. How is reception compared to the nova-t 500 2. What firmware do you use for it I bought and returned a TD yesterday, it didn´t find a single channel, tried both in windows and in linux, kaffein detected all channels but none worked, w_scan didn´t find a single channel. I have 60% signal strenght on my t-500 but I suspect that somnething else was wrong. /Henrik On 9/29/07, Jonas Anden [EMAIL PROTECTED] wrote: 1) system (uname -a) Linux ragnyr.garth.anden.nu 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:47:21 EDT 2007 i686 i686 i386 GNU/Linux 2) lspci-output 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 04) 01:01.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1Controller (rev 61) 01:01.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1Controller (rev 61) 01:01.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 03:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) 2.5) lsusb | grep Hauppauge output Bus 008 Device 002: ID 2040:9950 Hauppauge Bus 007 Device 006: ID 2040:7050 Hauppauge Bus 007 Device 005: ID 2040:9580 Hauppauge 3) DiB0700 device name (USB Stick, Nova-T 500) Nova-T 500 (PCI) Nova-T Stick (USB) Nova-T Diversity Stick (USB) 4) Application using the device (MythTV, VDR etc) MythTV 5) Symptoms (unusable, disconnect after x days, no problem) I have only had the Nova-T Stick connected to the box for the past month and that has been stable. Using multiple tuners have caused problems (MPEG decoding failures, channel lock failures, USB disconnects) in the past. I just put the Nova-T 500 card back in the box today and upgraded the firmware + drivers. For the past month, I have only had the Nova-T Stick connected and have had no problems (this device has always been the most stable). This machine is on 24/7,and MythTV has EIT scanning enabled (so there's a whole lot of channel switching going on). With the latest drivers and firmware (downloaded and compiled today), all adapters appear to be working. The Nova-TD Stick failed to tune with the previous firmware (03-pre1), but now it appears to work. MythTV has (so far) only been configured for one adapter. I'm going to configure all tuners in MythTV and see what happens. Stand by for more updates. // J ___ 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] is TT-3600/3200 supprted (even dvb-s only) ?
hello i am interested in buying another dvb-s(2) card for my myth-box i currently only need dvb-s, but i preffer to buy a dvb-s2 card, and currently use it as dvb-s (until dvb-s2 will be supported too) the reseller near me, has tt-3200 and tt-3600 only. i preffer the tt-3600 (usb) as i can also use it on my laptop (and maybe on my nslu2 as well ;-) and to my question: is the tt-3600 and/or tt-3200 supported under linux ? it would be good enough for me if i can use it only in dvb-s mode. ( and i am not afraid of compiling a kernel ;-) manu ? anyone ? thanks, erez. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sun, Sep 30, 2007 at 03:11:39AM +0400, Manu Abraham wrote: Johannes Stezenbach wrote: On Sat, Sep 29, 2007, Manu Abraham wrote: ... Instead of losing myself in the details of your questions, some background info: 1) LNB drift That said, since we have different LNB LO drifts and the frontend driver doesn't know what the actual drift the LO is having, but that only a standard (vague ?) definition of the drift, The actual drift is totally irrelevant for the zig-zag scan. Zig-zag is a trial-and-error approach, and only needs to know - the step size (derived from the demod's carrier capture range) - max. the number of steps (derived from channel bandwidth) - the time to wait between steps (derived from the demod's worst case time to lock on a signal) Got it _now_? i would like to experiment a bit with the stb0899 with regards on the same. Since the STB0899 doesn't use the swzigzag from dvb_frontend.c, it is much easier to do it in the stb0899 driver. dvb_frontend lacks a hook which would allow one to implement auto-offset correction for the TU1216 DVB-T demod (I mean the +/- n * 125kHz or +/- n * 166kHz offset from the frequency given in the NIT used by some transmitters to reduce interference with adjacent channels.) If what you add for stb0899 would be usable for tu1216 etc. it would be useful. You must not break the exisiting sw zig-zag though. (This is supposing on the basis that we are not fiddling around with the STV0299) Why do you still try to single out stv0299 when I told you that almost all existing DVB-S frontends use it? (cx24116 being the one exception, as Georg Acher informed me.) Ok, now that i explained the test scenario, how would you prefer LNB drift be provided to the frontend ? The criteria would be thus, that the user be able to specify the drift for his LNB, since people have small LO drift values to large LO drift values. ie it is not fixed as it is originally thought to be. Do you think it would be the best if the user specifies the drift ? Or maybe in a user specific library, for example the lnb.c that one could be extended further. What's your opinion ? Most people have no idea what drift their LNB has, nor should they ever have to care about it. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 device report
Can I ask you a few questions about the TD stick, 1. How is reception compared to the nova-t 500 I think it is pretty similar, though I don't have any exact numbers to give you at this time. I'm going to do an overhaul of my cabling (with a better quality amplifier and splitter); I've got a small aerial antenna which is partially blocked by trees that feeds my four inputs and the current splitters and amplifier are pretty tacky, so any differences in reception is likely to be more dependent on the cabling than the tuners. I'll try to get back with better numbers when I have better surrounding equipment. That being said, depending on which multiplex I tune to I have very varying reception on the Nova-T 500. My reception on mux 1 (with SVT channels) is usually between 70-80% according to MythTV (with the internal LNA enabled), while mux 5 (with the local channels) is varying from 40 to 60%. 2. What firmware do you use for it I now use the 1.10 firmware. Using the 03-pre1 firmware I had similar problems to yours; dvbscan found plenty of channels but MythTV failed to get a lock. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
Johannes Stezenbach wrote: On Sun, Sep 30, 2007 at 03:11:39AM +0400, Manu Abraham wrote: Johannes Stezenbach wrote: On Sat, Sep 29, 2007, Manu Abraham wrote: ... Instead of losing myself in the details of your questions, some background info: 1) LNB drift That said, since we have different LNB LO drifts and the frontend driver doesn't know what the actual drift the LO is having, but that only a standard (vague ?) definition of the drift, The actual drift is totally irrelevant for the zig-zag scan. Zig-zag is a trial-and-error approach, and only needs to know - the step size (derived from the demod's carrier capture range) - max. the number of steps (derived from channel bandwidth) - the time to wait between steps (derived from the demod's worst case time to lock on a signal) Got it _now_? Johannes, This is what i am doing in the STB0899 driver. You are preaching to the choir. But what you said initially is different from what you are saying now. This zigzag method what STM generally use is called Fs/2 zigzag. ie the zigzag is based on the sampling frequency, ie optimized for the sampling at the nyquist rate, since the most important part in a demodulator is the ADC clock, to put it short. i would like to experiment a bit with the stb0899 with regards on the same. Since the STB0899 doesn't use the swzigzag from dvb_frontend.c, it is much easier to do it in the stb0899 driver. dvb_frontend lacks a hook which would allow one to implement auto-offset correction for the TU1216 DVB-T demod (I mean the +/- n * 125kHz or +/- n * 166kHz offset from the frequency given in the NIT used by some transmitters to reduce interference with adjacent channels.) If what you add for stb0899 would be usable for tu1216 etc. it would be useful. You must not break the exisiting sw zig-zag though. ACK. This would work (search) Will be going this way for some other devices. (This is supposing on the basis that we are not fiddling around with the STV0299) Why do you still try to single out stv0299 when I told you that almost all existing DVB-S frontends use it? (cx24116 being the one exception, as Georg Acher informed me.) Intel CE6313 is different, Fujitsu MB86A15/16 is different, CX24123 is different, and many others The dst based one's are different. The CX24116 has it's roots from the CX24123 demod, just like how the STB0899 has some roots in the STV0299. The reason is that they do not simply zigzag. The MB86A15/6 from Fujitsu for example sweeps the spectrum, not zigzag's. Different methods, that's all I am not just stating something stupid, but referring quite a lot of demodulator specifications. Not just one STV0299 or CX24116 For a person writing a driver for the first time, that device always different. Look at XC3028 as an example So the only common one's are the one's from STM. I am not trying to single out the STV0299, but i was looking at why there is a drastic difference in LOCK/tune times with the STB0899 and the STV0299, while the STB0899 what i am using is in STV0299 tuning algorithm compatible way. I hope i am not loosing you, in what i am trying to say. What i am stating is that, there is a derivative of a Fs/2 zigzag in dvb_frontend, which is not a Fs/2 zigzag even, such that it can be adapted for others. Ok, now that i explained the test scenario, how would you prefer LNB drift be provided to the frontend ? The criteria would be thus, that the user be able to specify the drift for his LNB, since people have small LO drift values to large LO drift values. ie it is not fixed as it is originally thought to be. Do you think it would be the best if the user specifies the drift ? Or maybe in a user specific library, for example the lnb.c that one could be extended further. What's your opinion ? Most people have no idea what drift their LNB has, nor should they ever have to care about it. Hmm .. Then i guess the swzigzag for the STV0299 in dvb_frontend is a bit bogus thing, which has been forced for other devices where it is not even applicable. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
On Sun, Sep 30, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: The actual drift is totally irrelevant for the zig-zag scan. Zig-zag is a trial-and-error approach, and only needs to know - the step size (derived from the demod's carrier capture range) - max. the number of steps (derived from channel bandwidth) - the time to wait between steps (derived from the demod's worst case time to lock on a signal) This is what i am doing in the STB0899 driver. You are preaching to the choir. Then why don't you use the dvb-core implementation instead of reimplementing it in the STB0899 driver? But what you said initially is different from what you are saying now. How so? I just added more detail for clarification, it doesn't contradict what I said earlier. This zigzag method what STM generally use is called Fs/2 zigzag. ie the zigzag is based on the sampling frequency, ie optimized for the sampling at the nyquist rate, since the most important part in a demodulator is the ADC clock, to put it short. Which is just a more complicated wy of saying derived from the demod's carrier capture range, right? Why do you still try to single out stv0299 when I told you that almost all existing DVB-S frontends use it? (cx24116 being the one exception, as Georg Acher informed me.) Intel CE6313 is different, Fujitsu MB86A15/16 is different, CX24123 is different, and many others The dst based one's are different. You can probably find more examples if you try hard enough, but just grep the code for get_tune_settings to see the current state of affairs (note that dvb_frontend.c enables zig-zag using default values for frontends which don't implement get_tune_settings). The CX24116 has it's roots from the CX24123 demod, just like how the STB0899 has some roots in the STV0299. The reason is that they do not simply zigzag. The MB86A15/6 from Fujitsu for example sweeps the spectrum, not zigzag's. Different methods, that's all I am not just stating something stupid, but referring quite a lot of demodulator specifications. Not just one STV0299 or CX24116 For a person writing a driver for the first time, that device always different. Look at XC3028 as an example So the only common one's are the one's from STM. I am not trying to single out the STV0299, but i was looking at why there is a drastic difference in LOCK/tune times with the STB0899 and the STV0299, while the STB0899 what i am using is in STV0299 tuning algorithm compatible way. Well, there are serveral years of development between stv0299 and stb0899, one would hope they used the time to improve their algorithms. And the stb0899 runs at higher clock rates and has more processing power. And the tuner and the whole electrical design of the card matters, etc. pp. I haven't used SAT equipment for serveral years now, I don't remember the stv0299 based FF cards we had at convergence as being slow. What card do you use for comparison? Did you do timing measurements? I hope i am not loosing you, in what i am trying to say. What i am stating is that, there is a derivative of a Fs/2 zigzag in dvb_frontend, which is not a Fs/2 zigzag even, such that it can be adapted for others. Ok, now that i explained the test scenario, how would you prefer LNB drift be provided to the frontend ? The criteria would be thus, that the user be able to specify the drift for his LNB, since people have small LO drift values to large LO drift values. ie it is not fixed as it is originally thought to be. Do you think it would be the best if the user specifies the drift ? Or maybe in a user specific library, for example the lnb.c that one could be extended further. What's your opinion ? Most people have no idea what drift their LNB has, nor should they ever have to care about it. Hmm .. Then i guess the swzigzag for the STV0299 in dvb_frontend is a bit bogus thing, which has been forced for other devices where it is not even applicable. Sorry, I can't follow that conclusion. The guys who implemented dvb_frontend noticed that all the vendor's tuning algorithm flow charts looked similar, and factored out common code into dvb-core to simplify the individual demod drivers. There's certainly room to improve and extend dvb_frontend, but why are you opposed to keep common code which _works_ for a variety of frontends? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Stupid problem !
Hello. Thank you for your quick response. Everything works perfectly now. That's a fact : it should be documented :) See ya. François. You need to enable I2C either as modules or as compiled in. The fuckhats at lunix-dvb never even list a number of requisites for the drivers... Once I2C is in, you will see more choices in DVB stuff. -tc On 9/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Thank you for your response.These are the only modules which I can compile : # modprobe -l | grep dvb /lib/modules/2.6.22-gentoo-r5/kernel/drivers/media/dvb/dvb-core/dvb-core.ko /lib/modules/2.6.22-gentoo-r5/kernel/drivers/media/dvb/ttusb-dec/ttusb_dec.ko /lib/modules/2.6.22-gentoo-r5/kernel/drivers/media/dvb/ttusb-dec/ttusbdecfe.ko I've loaded these modules and nothing happend... I see no reference to my card neither in /var/log/message nor in dmesg. Also I have no /dev/dvb directory... For info : # lsusb -v [...] Bus 002 Device 002: ID 2040:9950 Hauppauge Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2040 Hauppauge idProduct 0x9950 bcdDevice1.00 iManufacturer 1 Hauppauge iProduct 2 WinTV Nova-DT iSerial 3 4028942220 bNumConfigurations 1 [...] See ya. On Sat, 2007-09-29 at 19:06 +0200, [EMAIL PROTECTED] wrote: I'm having a very stupid, and boring, problem as I am trying to install drivers for a Hauppauge WinTV-NOVA-T-500. Let me suggest to have that read first: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500 I'm saying that this si a stupid problem bcause I just can't find the driver neither in my kernel menuconfig (2.6.22-gentoo-r5) nor in the v4l-dvb (fetched today) menuconfig . I have Technotrend/Hauppauge USB DEC devices selected to compile as a module but I cant choose any DBV frontend, the list is empty ! So I can't find a way to build the dib0700 kernel module... I guess I have done something I my kernel config that prevents it to be shown but I can't guess what... You do not compile a specific module from the v4l-dvb tree, you just compile the whole tree against your kernel headers. At least this is how I am doing it successfully. More instructions here: http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers Nico ___ 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 mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
Johannes Stezenbach wrote: On Sun, Sep 30, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: The actual drift is totally irrelevant for the zig-zag scan. Zig-zag is a trial-and-error approach, and only needs to know - the step size (derived from the demod's carrier capture range) - max. the number of steps (derived from channel bandwidth) - the time to wait between steps (derived from the demod's worst case time to lock on a signal) This is what i am doing in the STB0899 driver. You are preaching to the choir. Then why don't you use the dvb-core implementation instead of reimplementing it in the STB0899 driver? From what i understood, it didn't resemble Fs/2 zigzag as i explained and hence found it not usable. But it does resemble some aspects, but not all. But what you said initially is different from what you are saying now. How so? I just added more detail for clarification, it doesn't contradict what I said earlier. This zigzag method what STM generally use is called Fs/2 zigzag. ie the zigzag is based on the sampling frequency, ie optimized for the sampling at the nyquist rate, since the most important part in a demodulator is the ADC clock, to put it short. Which is just a more complicated wy of saying derived from the demod's carrier capture range, right? All methods are based on the capture range directly. But doesn't mean that they are the same. a = f(b) doesn't mean that a = b Why do you still try to single out stv0299 when I told you that almost all existing DVB-S frontends use it? (cx24116 being the one exception, as Georg Acher informed me.) Intel CE6313 is different, Fujitsu MB86A15/16 is different, CX24123 is different, and many others The dst based one's are different. You can probably find more examples if you try hard enough, but just grep the code for get_tune_settings to see the current state of affairs (note that dvb_frontend.c enables zig-zag using default values for frontends which don't implement get_tune_settings). Will take a look at that approach. The CX24116 has it's roots from the CX24123 demod, just like how the STB0899 has some roots in the STV0299. The reason is that they do not simply zigzag. The MB86A15/6 from Fujitsu for example sweeps the spectrum, not zigzag's. Different methods, that's all I am not just stating something stupid, but referring quite a lot of demodulator specifications. Not just one STV0299 or CX24116 For a person writing a driver for the first time, that device always different. Look at XC3028 as an example So the only common one's are the one's from STM. I am not trying to single out the STV0299, but i was looking at why there is a drastic difference in LOCK/tune times with the STB0899 and the STV0299, while the STB0899 what i am using is in STV0299 tuning algorithm compatible way. Well, there are serveral years of development between stv0299 and stb0899, one would hope they used the time to improve their algorithms. And the stb0899 runs at higher clock rates and has The STB0899 runs at 90MHz in DVB-S mode, not much different. The DVB-S tuning algorithm is mostly the same, but there is an additional mode where you can use a STB0899 specific mode of tuning as well. I am using the STV0299 compat mode of operation. The other one is a bit more faster though, but initially for me to get it going was more important than speed, but i found that even in the compatibility mode it worked damn fast. more processing power. And the tuner and the whole electrical design of the card matters, etc. pp. I haven't used SAT equipment for serveral years now, I don't remember the stv0299 based FF cards we had at convergence as being slow. What card do you use for comparison? I used a B2C2 skystar. (that was the only one where i had a normal STV0299 based on it.) The only other one i had was a Galaxis FF card, but the ghost went out of it. The VP-1030A (dst) uses the Fs/2 zigzag for the STV0299 on board which is implemented in firmware, rather than in the driver. Did you do timing measurements? The same implementation i haven't tried on the STV0299 driver. But based on the driver in the x86 class CPU on the dst it looked like it was tuning faster. I will try to do it a while later and get in some benchmarks. I hope i am not loosing you, in what i am trying to say. What i am stating is that, there is a derivative of a Fs/2 zigzag in dvb_frontend, which is not a Fs/2 zigzag even, such that it can be adapted for others. Ok, now that i explained the test scenario, how would you prefer LNB drift be provided to the frontend ? The criteria would be thus, that the user be able to specify the drift for his LNB, since people have small LO drift values to large LO drift values. ie it is not fixed as it is originally thought to be. Do you think it would be the best if the user specifies the drift ? Or maybe in a user specific library, for
[linux-dvb] DVB-s Device Suggestions?
Hi! I would like to by a dvb-s usb device. Are there any especially well supported ones for linux (more as listed in the wiki, which are just 2, where one is actually not working). I would really like to have one for my laptop. Besides Firewire or ExpressCard suggestions are also welcomed, but it needs to be dvb-s. I would be very thankful for any suggestions. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Video and audio pid problems with dvb- t channels in Norway
Il Sunday 30 September 2007 21:16:42 Per Thomas Jahr ha scritto: On Sat, 2007-09-29 at 20:55 +0200, Per Thomas Jahr wrote: ... but the video and audio pid for me is always 0 after a scan. ... (see http://heim.ifi.uio.no/~perja/channels.conf) Hmm, in channels.conf there is a service named Bootload. Could that have anything to do with me getting no video and audio pid? From googling a bit, it seems that this service is a way to initialize and upgrade the setup boxes. But how can I use it from linux-dvb? Anyone knows? yes, those 0-pids may indicate a generic data service, including firmware updates. Of all those channels only National Geographic seem to be playable (as audio only), that is very suspicious. If you compile dvbstream from cvs (dvbtools.sf.net) and run ./dvbstream -f FREQUENCY -bw 8 -c 0 -n 10 -prog -o:/dev/null 1 wil give you a list of the available programs, then run ./dvbstream -f FREQUENCY -bw 8 -n 30 -c 0 -prog -o:dump.ts 'PROGRAM NAME' wil dump 30 seconds of program to dump.ts, that players such as mplayer, vlc, xine and kaffeine could be able to play. If you want to analyze the TS you can use dvbsnoop or decode_pat and decode_pmt available in libdvbpsi ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re : DVB-s Device Suggestions?
On 09/30/2007 10:58:26 AM, Heinz Wiesinger wrote: Hi! I would like to by a dvb-s usb device. Are there any especially well supported ones for linux (more as listed in the wiki, which are just 2, where one is actually not working). I would really like to have one for my laptop. Besides Firewire or ExpressCard suggestions are also welcomed, but it needs to be dvb-s. I would be very thankful for any suggestions. Do you plan on using a cam card for pay tv? If yes I guess there is even less option with USB. For PCI: TT S-1500 (technotrend) is well supported, though I got some trouble with the board itself, could be a bad board though. People here could comment on its fiability perhaps. HTH Bye Manu ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re : DVB-s Device Suggestions?
Am Montag, 1. Oktober 2007 00:15:16 schrieb manu: On 09/30/2007 10:58:26 AM, Heinz Wiesinger wrote: Hi! I would like to by a dvb-s usb device. Are there any especially well supported ones for linux (more as listed in the wiki, which are just 2, where one is actually not working). I would really like to have one for my laptop. Besides Firewire or ExpressCard suggestions are also welcomed, but it needs to be dvb-s. I would be very thankful for any suggestions. Do you plan on using a cam card for pay tv? If yes I guess there is even less option with USB. For PCI: TT S-1500 (technotrend) is well supported, though I got some trouble with the board itself, could be a bad board though. People here could comment on its fiability perhaps. HTH Bye Manu No. CAM would be fine, but is definitely not needed. I know there are some well-supported PCI-devices out there, but I can't use them with my laptop. So I need something more 'external'. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
