Re: [linux-dvb] Hauppauge WINTV Nova-T 500 PCI
On Wed, 2007-08-29 at 07:44 +0200, Maillist wrote: The firmware I am using is dvb-usb-dib0700-03-pre1.fw and yesterday I tried to downgrade to dvb-usb-dib0700-01.fw but I was not able to load that, always tried to load the previous one (which I deleted to avoid conflicts). The current code absolutely needs the new firmware. You cannot use the previous firmware with this code. In order to downgrade, you would need an old revision of the code, which I guess is a possible thing to get, but you would bump into a lot of problems it had, like remotes not being available, more tuning problems, etc... We all hope that Patrick will have had good discussions with his colleagues/friends, and will come up with new stuff to sort out the last few things that are annoying with this device right now. Nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
On Tue, 28 Aug 2007, Manu Abraham wrote:
Trent Piepho wrote:
That's really inefficient. You've got about 250k of table there. I don't
think a 250k+ module is going to be very popular.
I do agree that's not the most effecient way. But given the short time
span and lack of FP operations, the quick way that came to my mind was
precomputed values.
That said, the popularity of a module is not defined by it's size. as an
eg: the nVidia module is over 1 Meg. Considering the quality/performance
of the tuners in the tree we have, i don't think there would even be a
popularity contest, coming anywhere near.
But nobody likes how huge the nvidia module is.
That said, if it can be optimized, there is no reason why it shouldn't
be done.
I had a comment from Andrew Morton as well on it: It's large, but heck,
it's not a lot of memory. The nvidia driver is a meg or something.
Huge tables like that can be a problem just for the code itself. Huge
patches, show checkouts and diffs, slow compiles, etc.
There are also problems with maintaining such code. Say you need to tweak
the tuning algorithm? Instead of just changing one constant or making an
expression round up instead of down, you have to create a whole new table.
And what if there is a new device revision, which is slightly different?
You have to have another huge table, when you could probably support both
with just a small addition to the code. Or say someone has a fake Russian
copy, that uses a 26 Mhz crystal instead of 27 MHz? Much harder to support
if you look at the driver and just see some huge table with no idea what
made it, instead of one simple constant to change.
For instance, when radio support for my tuner didn't work, I was able to
figure out from the tuner-simple code that it was using the wrong 1st IF
offset for the tda9887 radio demodulator and 2nd IF output. If there was
just some huge table of random settings, it would have been much harder to
fix.
If anyone's interested, the original version with FP is here:
http://paste.debian.net/35554
It 's a userspace application with which i did some crude tests.
The tables are here
http://jusst.de/manu/1086M_36.125M.c
http://jusst.de/manu/1086M_36.166M.c
I looked at this code, but there is code there that isn't used, so I'm not
sure exactly what it's supposed to.
There is a 'optimal_settings_index' parameter to mc44s80x_set_1st_lo(), but
it's never used.
There is still a huge table, 'tuner_step', where did that come from? The
whole table isn't used, only index 1. And lo2_divider isn't used either.
Is there some kind of formula that can calculate this table?
The 'lo1_adjustment' code is very odd. Are you sure it's really doing what
it's supposed to do?
The actual code in mc44s80x_set_1st_lo() is just a round-about way of doing
a rather simple bit of math.
So, here is a integer version of your floating point code. It's actually
_more_ accurate than the FP version. For your sample (22650 Hz,
lo1_divider 13, lo1_adjustment 0), my code finds the same divider as yours,
630. But the 'first_lo' value I find is 1,312,615,385 Hz, while your FP
code returns 1,312,615,336 Hz. Mine is within 1 Hz of the true value of
1312615384.615384.
#ifdef __KERNEL__
#include asm/div64.h
#else
#define do_div(n, base) ({ unsigned long __rem = (n)%(base); (n)/=(base);
__rem; })
typedef unsigned long long u64;
#endif
/* freq = input frequency in Hz
refdiv1 = first reference frequency divisor (10 to 15, or 26)
adj1 = mystery adjustment (signed number!) */
/* To turn the lo1_adjustment value into adj1, do this:
adj1 = (lo1_adjustment+1) / ((lo1_adjustment1)?-2:2); */
#define REF_FREQ2700 /* 27 MHz reference */
#define IF1 108600
void mc44s80x_set_1st_lo(unsigned int freq, unsigned int refdiv1, int adj1)
{
u64 div1;
unsigned int remainder, freq1, if1, lo1ref;
signed int if1_offset;
div1 = ((u64)freq + IF1) * refdiv1 + REF_FREQ/2; /* Subtract 1 to
round XXX.5 down instead of up */
printf(freq+IF * refdiv1 = %llu\n, div1);
remainder = do_div(div1, REF_FREQ);
/* adjustment sign is flipped if we didn't round div1 down.
Very stange, I don't understand what this is for. */
if (remainder = REF_FREQ/2)
adj1 *= -1;
div1 += adj1;
/* Actual frequency PLL tuned, taking into account step size, the IF
* offset, and the mystery adjustment. */
freq1 = (div1 * REF_FREQ + refdiv1/2) / refdiv1;
/* Actual IF used, taking into acount everything freq1 does */
if1 = freq1 - freq;
/* Offset of actual IF from nominal IF */
if1_offset = if1 - IF1;
/* LO1REF, whatever that is */
/* BTW, do you really want to round down, not to the nearest? */
lo1ref = 15 * (8/2) * div1 / refdiv1;
/* The n+2 divider */
div1 = (div12) ? 0 : div1-2;
Re: [linux-dvb] Hauppauge WINTV Nova-T 500 PCI
On Wed, 2007-08-29 at 07:44 +0200, Maillist wrote: The firmware I am using is dvb-usb-dib0700-03-pre1.fw and yesterday I tried to downgrade to dvb-usb-dib0700-01.fw but I was not able to load that, always tried to load the previous one (which I deleted to avoid conflicts). The current code absolutely needs the new firmware. You cannot use the previous firmware with this code. In order to downgrade, you would need an old revision of the code, which I guess is a possible thing to get, but you would bump into a lot of problems it had, like remotes not being available, more tuning problems, etc... We all hope that Patrick will have had good discussions with his colleagues/friends, and will come up with new stuff to sort out the last few things that are annoying with this device right now. Nico OK. Thanks for the explaination. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hauppauge WINTV Nova-T 500 PCI
On Wed, 2007-08-29 at 07:44 +0200, Maillist wrote: - What should I investigate to get this working? What is the permission on your firmware file? -- Torgeir Veimo [EMAIL PROTECTED] [EMAIL PROTECTED]:/home/joacim# ls -al /lib/firmware/dvb* -rw-r--r-- 1 root root 33277 2007-08-17 00:08 /lib/firmware/dvb-usb-dib0700-03-pre1.fw Regards Joacim ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] New DiB0700-firmware
El Lunes, 30 de Julio de 2007, Patrick Boettcher escribió: Dear all, Can all of you using a dib0700-based-design with problem please try the following firmware http://www.wi-bw.tfh-wildau.de/~pboettch/home/linux-dvb-firmware/dvb-usb-di b0700-03-pre1.fw and the latest drivers from http://linuxtv.org/hg/~pb/v4l-dvb/ to see whether you have still problems. From what I can see, the problems with the DiB7700P and MT2060 are gone (Hauppauge DVB-T Stick). I cannot test the Nova-T 500... unfortunately. Please don't apply any patches from other peoples, when you try this one - as they might hide the problems. best regards Patrick. I think that the streamon problem is not completely fixed. I have a lot of continuity errors with the last driver and the last firmware: In about 15 minutes: Aug 29 13:11:19 jar vdr: [3031] cTS2PES got 3 TS errors, 17 TS continuity errors The continuity errors are produced by streamon, because if I use my previous patch to avoiding streamon, there are not thes continuity errors. Thanks. Jose Alberto ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
Trent Piepho wrote: On Tue, 28 Aug 2007, Manu Abraham wrote: Trent Piepho wrote: That's really inefficient. You've got about 250k of table there. I don't think a 250k+ module is going to be very popular. I do agree that's not the most effecient way. But given the short time span and lack of FP operations, the quick way that came to my mind was precomputed values. That said, the popularity of a module is not defined by it's size. as an eg: the nVidia module is over 1 Meg. Considering the quality/performance of the tuners in the tree we have, i don't think there would even be a popularity contest, coming anywhere near. But nobody likes how huge the nvidia module is. Well, does anyone care about the size of that module in comparison to the features that which provides ? I for one, don't mind that size for the features it provides. When you don't have other alternatives, does it really matter ? That said, the module size is not that big. in fact it is smaller compared to the others in the same league: 16 -rw-r--r-- 1 root root 13756 2007-08-29 14:43 bcm3510.ko 100 -rw-r--r-- 1 root root 95704 2007-08-29 14:43 dvb-core.ko 20 -rw-r--r-- 1 root root 17472 2007-08-29 14:43 dvb-pll.ko 56 -rw-r--r-- 1 root root 50144 2007-08-29 14:43 dvb-usb-af9015.ko 32 -rw-r--r-- 1 root root 31040 2007-08-29 14:43 dvb-usb.ko 8 -rw-r--r-- 1 root root 6420 2007-08-29 14:43 mc44s80x.ko 12 -rw-r--r-- 1 root root 8392 2007-08-29 14:43 mt2060.ko 16 -rw-r--r-- 1 root root 15940 2007-08-29 14:43 mxl500x.ko 16 -rw-r--r-- 1 root root 12364 2007-08-29 14:43 or51132.ko 16 -rw-r--r-- 1 root root 12600 2007-08-29 14:43 or51211.ko 12 -rw-r--r-- 1 root root 9380 2007-08-29 14:43 qt1010.ko Also, it might be interesting to have a comparison between the dissipation on the various devices that we have support now (though not driver related), as dissipation is the culprit for thermal noise, and thermal instabilities on silicon tuners. XC3028: 300mA @5v = 1.5W MT2060: 370mA @3.3v = 1.221W QT1010: 300mA @3.6v = 1.08W MC44S802(3):210mA @1.8v = 0.378W MXL5003(5): 165mA @1.9v = 0.3135W TDA18291: 54mA @2.8v = 0.1521W Also of all the devices the Freescale tuner has the largest package and a thermal spreader, thermal runaway should be the minimal of these devices. That said, if it can be optimized, there is no reason why it shouldn't be done. I had a comment from Andrew Morton as well on it: It's large, but heck, it's not a lot of memory. The nvidia driver is a meg or something. Huge tables like that can be a problem just for the code itself. Huge patches, show checkouts and diffs, slow compiles, etc. Compilation time 0.6 s and 0.7 s, I don't think anyone would care for that difference. The table would change for the Nominal frequency and the BPF setting, so shouldn't matter much since the table won't change unless the hardware changes. When the hardware changes (this is not a firmware based device) well, anyway we need a new driver, for the new chip. There are also problems with maintaining such code. Say you need to tweak the tuning algorithm? Instead of just changing one constant or making an expression round up instead of down, you have to create a whole new table. No need to tweak the algorithm, it is fairly fixed for the hardware and RF settings. Yeah true though you have recreate the table. And what if there is a new device revision, which is slightly different? You have to have another huge table, when you could probably support both with just a small addition to the code. Or say someone has a fake Russian copy, that uses a 26 Mhz crystal instead of 27 MHz? Much harder to support if you look at the driver and just see some huge table with no idea what made it, instead of one simple constant to change. Fake Russian copy. ;-) For instance, when radio support for my tuner didn't work, I was able to figure out from the tuner-simple code that it was using the wrong 1st IF offset for the tda9887 radio demodulator and 2nd IF output. If there was just some huge table of random settings, it would have been much harder to fix. If anyone's interested, the original version with FP is here: http://paste.debian.net/35554 It 's a userspace application with which i did some crude tests. The tables are here http://jusst.de/manu/1086M_36.125M.c http://jusst.de/manu/1086M_36.166M.c I looked at this code, but there is code there that isn't used, so I'm not sure exactly what it's supposed to. There is a 'optimal_settings_index' parameter to mc44s80x_set_1st_lo(), but it's never used. There is still a huge table, 'tuner_step', where did that come from? The tuner_step is derived from the the 2 tables that i have put up above and the user application. The whole table isn't used, only index 1. And lo2_divider isn't used either. Is there some kind of formula that can calculate this table? Based on the frequency, LO2 is
Re: [linux-dvb] free channels not working on mux with crypted channels
On 08/29/2007 02:20 PM, Petri Jarvisalo wrote: Ok, this far i know. 1: I asked on #kaffeine, when ever the problem is software based. - Wasn't. 2: I also had a chat on #linuxtv: - not problem with bad signal or cabling I also compiled latest v4l from snapshot. final statment: mailing list time. Card is Hauppauge DVB-C ver 2.1 (wintv?) with saa7146_vv (latest snapshot) So problem is what topic says, everything else works like a dream. not working (free) channel: [EMAIL PROTECTED]:~$ czap -c channels.conf MTV3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' 10 MTV3:41800:INVERSION_AUTO:690:FEC_NONE:QAM_128:305:561:49 10 MTV3: f 41800, s 690, i 2, fec 0, qam 4, v 0x131, a 0x231 status 00 | signal 7f7f | snr | ber 001517c4 | unc 0038 | status 1f | signal f0f0 | snr ebeb | ber 001517c4 | unc | FE_HAS_LOCK status 1f | signal | snr eaea | ber 001517c4 | unc | FE_HAS_LOCK status 1f | signal | snr eaea | ber 000d7b72 | unc | FE_HAS_LOCK encrypted channel (from same mux): [EMAIL PROTECTED]:~$ czap -c channels.conf Subtv Juniori using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' 18 Subtv Juniori:41800:INVERSION_AUTO:690:FEC_NONE:QAM_128:517:610:257 18 Subtv Juniori: f 41800, s 690, i 2, fec 0, qam 4, v 0x205, a 0x262 status 00 | signal 3e3e | snr | ber 037a | unc | status 1f | signal f7f7 | snr e3e3 | ber 037a | unc | FE_HAS_LOCK status 1f | signal | snr eaea | ber 037a | unc | FE_HAS_LOCK status 1f | signal | snr eaea | ber 000c0cce | unc | FE_HAS_LOCK working channel: [EMAIL PROTECTED]:~$ czap -c channels.conf YLE TV1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' 21 YLE TV1:16200:INVERSION_AUTO:690:FEC_NONE:QAM_128:512:650:17 21 YLE TV1: f 16200, s 690, i 2, fec 0, qam 4, v 0x200, a 0x28a status 00 | signal 7878 | snr | ber 00054dbc | unc 007c | status 1f | signal f3f3 | snr ebeb | ber 00054dbc | unc | FE_HAS_LOCK status 1f | signal | snr ecec | ber 00054dbc | unc | FE_HAS_LOCK status 1f | signal | snr ecec | ber 0006c49e | unc | FE_HAS_LOCK status 1f | signal | snr ecec | ber 0006c49e | unc | FE_HAS_LOCK stream example on problematic channel, recorded from kaffeine: http://purkki.zapto.org/temp/%20Uutiset.m2t (patience it's only 512 adsl) Those problematic channels works fine on hardware digibox on same appartment. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb I notice the working channel is in the VHF range and the non-working in the UHF-range. Did you try another PCI slot? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] add read_signal_strength function to dvb_tuner_ops
struct dvb_frontend_ops contains a function pointer for reading signal strength from the demodulator, however, it would also be useful to be able to read the signal strength from the tuner, itself. As of now, in dvb_tuner_ops, we only have the following function for status: int (*get_status)(struct dvb_frontend *fe, u32 *status); The usability of this function is rather limited, and currently only provides a mechanism for reading a limited amount of bits. The current status bits are as follows: #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 ...this doesn't really lend itself for a useful signal strength reading. I can cite two examples of how this would be useful in the current codebase: 1) Some demodulators do not directly provide signal strength readings. For example, lgdt330x. In order to provide some sort of measurement, other values are used to arrive at an estimated reading. If we had a read_signal_strength function available from the tuner driver, such demodulator drivers that are otherwise unable to provide this functionality directly would be able to read the signal strength from the tuner driver, and either pass on that value, or use it in its calculation of status readings. 2) The analog tuner system accesses the tuner modules directly, and would benefit greatly from having such functionality available to be able to read signal strength from the tuner. I propose the following addition to the internal API. Please respond with an ack, and / or any comments that you may have: [PATCH] add read_signal_strength function to dvb_tuner_ops Signed-off-by: Michael Krufky [EMAIL PROTECTED] --- linux/drivers/media/dvb/dvb-core/dvb_frontend.h |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.h +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h @@ -92,6 +92,7 @@ #define TUNER_STATUS_LOCKED 1 #define TUNER_STATUS_STEREO 2 int (*get_status)(struct dvb_frontend *fe, u32 *status); + int (*read_signal_strength)(struct dvb_frontend* fe, u16* strength); /** These are provided seperately from set_params in order to facilitate silicon * tuners which require sophisticated tuning loops, controlling each parameter seperately. */ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
