[linux-dvb] Some thoughts and questions
Hi all,
After quite a lot of eyeballing in dvb_frontend.c, Some thoughts and questions
that i came
up with having no answers.
They are such:
1) LNB drift:
http://linuxtv.org/hg/v4l-dvb/file/4e590391b11f/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
279 /* calculate the lnb_drift */
280 fepriv-lnb_drift = fepriv-auto_step *
fepriv-step_size;
281
282 /* wrap the auto_step if we've exceeded the maximum
drift */
283 if (fepriv-lnb_drift fepriv-max_drift) {
284 fepriv-auto_step = 0;
285 fepriv-auto_sub_step = 0;
286 fepriv-lnb_drift = 0;
287 }
The point here is that the frontend (demodulator + tuner) doesn't know about
the LNB drift.
Also the most important point to be noted is that LNB drift cannot be
calculated, but is measured on test criteria.
The reason being LNB drift being attributed to the Noise Temperature and is LNB
specific
You can't calculate it in anyway.
Currently, only userspace can know about this and this is LNB model specific !
Also there is no way how one can tell the frontend driver about it.
My guess is that the person who added this changed confused with PLL step's and
the channel spacing, natural frequency of the system and hence. Can someone who
has a more better insight clarify ?
Also interesting is this line
306 fepriv-lnb_drift = -fepriv-lnb_drift;
LNB drift going up and down ? Sounds like bad understanding. Thermal runaway on
LNB's happen in one direction.
ie, they are not Bidirectional.
As far as i can say, this one line #306, is playing with the derotator on the
STV0299. The derotator is present on some of the demodulator's from STM. The
derotator is used for Carrier recovery, as far as i can understand. Also most
of the datasheets do specify that way.
This is demodulator specific code. I don't understand why such demodulator
specific code is part of the core where other devices can't even use it.
2) Inversion AUTO
273 /* are we using autoinversion? */
274 autoinversion = ((!(fe-ops.info.caps FE_CAN_INVERSION_AUTO))
275(fepriv-parameters.inversion ==
INVERSION_AUTO));
What does Inversion AUTO mean ? As far as i understand Inversion means the I/Q
inputs swapped. It is either not swapped or not.
What does Auto mean, again ? The driver author doesn't know whether I/Q inputs
are swapped on the hardware ?
At some point of time, i believed as well the fact that I/Q swap at the
modulator (transmitter/satellite side) can cause an Inversion change.
Looking at scan.c, i see the same misunderstanding there as well.
But as i stand enlightened, i don't think this is right. I just happened to
correct someone who asked me the same question, which was a major problem as to
get proper tuning time on the STB0899 based cards. The lack of not using these
two, the STB0899 tunes and LOCK's quite fast.
Can someone clarify these two ?
Thanks,
Manu
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Hi, On Sat, Sep 29, 2007 at 04:29:16AM +0400, Manu Abraham wrote: Hi folks, I have pushed out a tree containing support for the mentioned hardware. Please note, support is still incomplete. Still much more to happen. Thanks for the new tree. I have just downloaded and compiled it. Please collect all your issues, will go through one by one. I can go through the issues one by one only, so please bear with me. The hacked szap is here http://abraham.manu.googlepages.com/szap.c Do you have also the other files of szap? I can't compile your szap.c with the current dvb-apps. Here is the compile error that I get: [EMAIL PROTECTED] ~/source/szap $ gcc -Wall -I/home/artem/source/multiproto/linux/include/ -O2 szap.c -o szap /tmp/ccNjXaIj.o: In function `bad_usage': szap.c:(.text+0x48): undefined reference to `lnb_enum' /tmp/ccNjXaIj.o: In function `main': szap.c:(.text+0x1c40): undefined reference to `lnb_enum' szap.c:(.text+0x1d3e): undefined reference to `lnb_decode' collect2: ld gab 1 als Ende-Status zurück I would like to know the issues you face. Some people have said that the STB0899 tunes and LOCK's incredibly faster than any of the demodulator drivers we have. Would like to verify this as well. I am wondering whether this is too good to believe. Please give it a go. Testers, please give results with the stb0899 module with verbose=5 module parameter by the way i forgot to mention the tree. http://jusst.de/hg/multiproto Please change the subject to reflect the hardware you have, for getting back results. It seems that this driver does not recognise my Skystar HD: (modprobe stb0899 verbose=5 + modprobe budget_ci only logs this to my dmesg: saa7146: register extension 'budget_ci dvb'.) Here the lspci -vn of my card: 00:0a.0 0480: 1131:7146 (rev 81) Subsystem: 13c2:1019 Flags: bus master, stepping, medium devsel, latency 32, IRQ 11 Memory at fe7ff800 (32-bit, non-prefetchable) [size=512] Memory at ignored (32-bit, non-prefetchable) Memory at ignored (32-bit, non-prefetchable) Memory at ignored (32-bit, non-prefetchable) Memory at ignored (32-bit, non-prefetchable) Memory at ignored (32-bit, non-prefetchable) Expansion ROM at ignored Thanks, Artem -- Artem Makhutov | Fon: +49 6196 5929595 | [EMAIL PROTECTED] Unterort Str. 36 | Mobile: +49 179 9104618 | www.makhutov.org D-65760 Eschborn | Fax: +49 371 45009987 | VoIP: +49 371 3179041 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Artem Makhutov wrote: Hi, On Sat, Sep 29, 2007 at 04:29:16AM +0400, Manu Abraham wrote: Hi folks, I have pushed out a tree containing support for the mentioned hardware. Please note, support is still incomplete. Still much more to happen. Thanks for the new tree. I have just downloaded and compiled it. Please collect all your issues, will go through one by one. I can go through the issues one by one only, so please bear with me. The hacked szap is here http://abraham.manu.googlepages.com/szap.c Do you have also the other files of szap? I can't compile your szap.c with the current dvb-apps. Here is the compile error that I get: [EMAIL PROTECTED] ~/source/szap $ gcc -Wall -I/home/artem/source/multiproto/linux/include/ -O2 szap.c -o szap /tmp/ccNjXaIj.o: In function `bad_usage': szap.c:(.text+0x48): undefined reference to `lnb_enum' /tmp/ccNjXaIj.o: In function `main': szap.c:(.text+0x1c40): undefined reference to `lnb_enum' szap.c:(.text+0x1d3e): undefined reference to `lnb_decode' collect2: ld gab 1 als Ende-Status zurück You need to use lnb.o from util/szap. It is missing that. I would like to know the issues you face. Some people have said that the STB0899 tunes and LOCK's incredibly faster than any of the demodulator drivers we have. Would like to verify this as well. I am wondering whether this is too good to believe. Please give it a go. Testers, please give results with the stb0899 module with verbose=5 module parameter by the way i forgot to mention the tree. http://jusst.de/hg/multiproto Please change the subject to reflect the hardware you have, for getting back results. It seems that this driver does not recognise my Skystar HD: Can you add in the PCI ID's into budget_ci.c. Only PCIID's and adding the SKYSTAR_HD into the case alongwith the TTS2 3200 would be sufficient to get you moving. Please do send in a patch as well for the same. 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
Hi Manu, The point here is that the frontend (demodulator + tuner) doesn't know about the LNB drift. Also the most important point to be noted is that LNB drift cannot be calculated, but is measured on test criteria. I think the misunderstanding is that lnb_drift doesn't correlate to any physical property (like the difference of the LNB local oscillator to its nominal value), but in fact is the offset between the userspace set frequency and the real, tuned frequency (after zig-zack scanning). When locking is finally archived (and only then), lnb_drift will hold the real LNB drift (+Satellite drift +setting file derivation). Also interesting is this line 306 fepriv-lnb_drift = -fepriv-lnb_drift; This is part of the zig-zack scan, which, as the name implies, scans up, then jumps down ... As far as i can say, this one line #306, is playing with the derotator on the STV0299. The derotator is present on some of the demodulator's from STM. The derotator is used for Carrier recovery, as far as i can understand. Also most of the datasheets do specify that way. The derotator on the STV0299 does the final frequency fine-tune. In a locked state (and possibly before already), it contains the offset between the PLL frequency and the center carrier frequency. The derotator shifts the zero-IF signal to really zero (which isn't possible with the PLL alone, given the relatively huge step size). However, when the derotator value becomes bigger than the step size, the offset should feedback into the PLL, because the bandwidth of the AD conversion is limited. Everything which falls out of the AD bandwidth (or better, its input filter) is lost, and cannot be recovered by derotation. This is demodulator specific code. I don't understand why such demodulator specific code is part of the core where other devices can't even use it. My understanding is that the basical concept is the same on every frontend. Your input PLL (tuner) is usually not exact enough to not require a derotator in the demod. I'm not saying that zig-zack scanning is a good thing, nor saying that it's a bad thing. It doesn't perform well in all cases, that's true. But please be very sure to understand the whole problem before trying to attempt to remove things. I'm not a frontend guy, so please wait for them to evaluate this topic and possible improvements. What does Inversion AUTO mean ? As far as i understand Inversion means the I/Q inputs swapped. It is either not swapped or not. Again, your misunderstanding is the part of the picture we are looking at. Inversion=AUTO just means that it's unknown, and the frontend should autodetect it. For several reasons, inversion autodetect is/was important. In a perfect world, we would always know, but: - Inversion might happen on up- and downconversion, depending on what frequency situation you have. - The SatelliteDeliverySystemDescriptor does not specify Inversion. - Inversion can be caused by tuner-specific wiring (some STV0299-based frontends have swapped I/Q inputs) So you see, sometimes there is no way to know the Inversion setting. Most, even older, demods support automatic inversion detection. I think the STV0299 is an exception here. Thus the driver tries best to hide this fact. At some point of time, i believed as well the fact that I/Q swap at the modulator (transmitter/satellite side) can cause an Inversion change. Not only that, it will also be swapped by a frequency inversion, which happens for example on a C-Band LNB (where the channel frequency is lower than the local oscillator). But as i stand enlightened, i don't think this is right. I just happened to correct someone who asked me the same question, which was a major problem as to get proper tuning time on the STB0899 based cards. The lack of not using these two, the STB0899 tunes and LOCK's quite fast. Yes, zig-zack needs some improvements. But we definitely need zigzack. And auto-inversion as well. You cannot do those things in userspace, because you don't know enough of the frontend. Felix ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Dear Manu, В Сбт, 29/09/2007 в 04:29 +0400, Manu Abraham пишет: Hi folks, I have pushed out a tree containing support for the mentioned hardware. Please note, support is still incomplete. Still much more to happen. NOTE: Still in BETA stage. Please collect all your issues, will go through one by one. I can go through the issues one by one only, so please bear with me. The hacked szap is here http://abraham.manu.googlepages.com/szap.c I have downloaded latest hg clone http://linuxtv.org/hg/dvb-apps and replacing szap.c. szap compiled successfully. Also I have installed http://jusst.de/hg/multiproto tree (dvb-core.ko and another modules). My card (KNC TV STAR DVB-S) detected successfully: saa7146: found saa7146 @ mem f89a4000 (revision 1, irq 17) (0x1894,0x0016). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (KNC TV STAR DVB-S) adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-1: MAC addr = 00:09:d6:65:9c:67 DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. budget-av: cam inserted B but hacked szap won't work: szap # ./szap -a 1 MTV Russia reading channels from file '/root/.szap/channels.conf' zapping to 2 'MTV Russia': sat 0, frequency = 12245 MHz V, symbolrate 2750, vpid = 0x0142, apid = 0x0194 sid = 0x283f Querying info .. Delivery system=DVB-S using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' ioctl DVBFE_GET_INFO failed: Operation not supported As I see DVBFE_GET_INFO is not implemented for stv0299. I have commented this call in szap (because obtained fe_info is not used inside szap - seems like a stub call). szap stil not work: szap # ./szap -a 1 MTV Russia reading channels from file '/root/.szap/channels.conf' zapping to 2 'MTV Russia': sat 0, frequency = 12245 MHz V, symbolrate 2750, vpid = 0x0142, apid = 0x0194 sid = 0x283f Querying info .. Delivery system=DVB-S using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' do_tune: API version=3, delivery system = 0 do_tune: Frequency = 1645000, Srate = 2750 do_tune: Frequency = 1645000, Srate = 2750 status 03 | signal 6429 | snr 7053 | ber ff00 | unc | status 03 | signal 651d | snr 7086 | ber ff08 | unc | status 03 | signal 63f9 | snr 7080 | ber ff08 | unc | not hacked szap lock's successfully: #szap -a 1 MTV Russia reading channels from file '/root/.szap/channels.conf' zapping to 2 'MTV Russia': sat 0, frequency = 12245 MHz V, symbolrate 2750, vpid = 0x0142, apid = 0x0194 sid = 0x283f using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 05 | signal cae2 | snr 7c83 | ber ff00 | unc | status 1f | signal cf7e | snr c8b2 | ber 5400 | unc | FE_HAS_LOCK status 1f | signal cf78 | snr c82b | ber | unc | FE_HAS_LOCK Please, explain how to solve this problem ? Thanks ! I would like to know the issues you face. Some people have said that the STB0899 tunes and LOCK's incredibly faster than any of the demodulator drivers we have. Would like to verify this as well. I am wondering whether this is too good to believe. Please give it a go. Testers, please give results with the stb0899 module with verbose=5 module parameter by the way i forgot to mention the tree. http://jusst.de/hg/multiproto Please change the subject to reflect the hardware you have, for getting back results. Will get some sleep now. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Abylai Ospan [EMAIL PROTECTED] NetUP Inc. 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
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Hello, Manu thanks for your efforts. Is there the diseqc protocol's support in your driver. I mean the 1, 1.1, 1.2 version. Igor ___ 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
Felix Hi, Felix Domke wrote: Hi Manu, The point here is that the frontend (demodulator + tuner) doesn't know about the LNB drift. Also the most important point to be noted is that LNB drift cannot be calculated, but is measured on test criteria. I think the misunderstanding is that lnb_drift doesn't correlate to any physical property (like the difference of the LNB local oscillator to its nominal value), but in fact is the offset between the userspace set frequency and the real, tuned frequency (after zig-zack scanning). Ideally when zigzag is employed, in the end result the offset should be zero or neglible. In the case of the STB0899, IIRC it is rounded off. So in most cases, you don't have an offset. When locking is finally archived (and only then), lnb_drift will hold the real LNB drift (+Satellite drift +setting file derivation). Also interesting is this line 306fepriv-lnb_drift = -fepriv-lnb_drift; This is part of the zig-zack scan, which, as the name implies, scans up, then jumps down ... As far as i can say, this one line #306, is playing with the derotator on the STV0299. The derotator is present on some of the demodulator's from STM. The derotator is used for Carrier recovery, as far as i can understand. Also most of the datasheets do specify that way. The derotator on the STV0299 does the final frequency fine-tune. In a locked state (and possibly before already), it contains the offset between the PLL frequency and the center carrier frequency. The derotator shifts the zero-IF signal to really zero (which isn't possible with the PLL alone, given the relatively huge step size). Yeah agreed, you are right. But even then you shouldn't be tuning to the entire bandwidth. But i guess then you are using the drift to do that calculation in dvb_frontend.c, which is something very much STV0299 specific. You will be trying to tune to the entire bandwidth in such a case, which would be a bit dependant on the PLL, afaict. this wouldn't be a problem on ZIF devices, but on simple PLL's this brings in an additional penality. The penality is imposed on the demodulator and not on the tuner, in such a case. the result is that improper tuning results, failing to LOCK to vcertain transponders etc. The point to be noted is that other demodulators using the same parameters is forced to behave in a STV0299 specific way, which is obviously wrong, as well. If you look at the STB0899, the DVB-S mode what i use, does the STV0299 compatible way of zig-zag. However, when the derotator value becomes bigger than the step size, the offset should feedback into the PLL, because the bandwidth of the AD conversion is limited. Everything which falls out of the AD bandwidth (or better, its input filter) is lost, and cannot be recovered by derotation. The STB0899 does exactly the same, but it doesn't need zigzag as defined in dvb_frontend.c This is demodulator specific code. I don't understand why such demodulator specific code is part of the core where other devices can't even use it. My understanding is that the basical concept is the same on every frontend. Your input PLL (tuner) is usually not exact enough to not require a derotator in the demod. I'm not saying that zig-zack scanning is a good thing, nor saying that it's a bad thing. It doesn't perform well in all cases, that's true. But please be very sure to understand the whole problem before trying to attempt to remove things. I'm not a frontend guy, so please wait for them to evaluate this topic and possible improvements. I just asked the question, since it affects other devices in an inverse way. But this we cannot exactly say each device how it would respond to the same. Some devices behave very bad. For a long time i tried disabling the swzigzag for the dst, but then i had to come up with various hacks to get it going. Also this is specific to DVB-S alone. Rather than saying that, it is much demod specific i would say, since one of the devices that i have it has a microcontroller/CPU on it to do the specific zigzag tuning, in a well device optimized way (the demod is still STV0299). In such a case, i have to just resort to workarounds. What does Inversion AUTO mean ? As far as i understand Inversion means the I/Q inputs swapped. It is either not swapped or not. Again, your misunderstanding is the part of the picture we are looking at. Inversion=AUTO just means that it's unknown, and the frontend should autodetect it. For several reasons, inversion autodetect is/was important. In a perfect world, we would always know, but: - 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. - Inversion can be caused by tuner-specific wiring (some STV0299-based frontends have swapped I/Q inputs)
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Hi ,
Abylai Ospan wrote:
Dear Manu,
В Сбт, 29/09/2007 в 04:29 +0400, Manu Abraham пишет:
Hi folks,
I have pushed out a tree containing support for the mentioned hardware.
Please note, support is still incomplete. Still much more to happen.
NOTE: Still in BETA stage.
Please collect all your issues, will go through one by one. I can go through
the issues one
by one only, so please bear with me.
The hacked szap is here http://abraham.manu.googlepages.com/szap.c
I have downloaded latest hg clone http://linuxtv.org/hg/dvb-apps and
replacing szap.c.
szap compiled successfully.
Also I have installed http://jusst.de/hg/multiproto tree (dvb-core.ko
and another modules). My card (KNC TV STAR DVB-S) detected successfully:
saa7146: found saa7146 @ mem f89a4000 (revision 1, irq 17) (0x1894,0x0016).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (KNC TV STAR DVB-S)
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-1: MAC addr = 00:09:d6:65:9c:67
DVB: registering frontend 1 (ST STV0299 DVB-S)...
budget-av: ci interface initialised.
budget-av: cam inserted B
but hacked szap won't work:
Ahh ..
The szap modification was older than a previous API update.
Just change the following line in szap.c
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 1)){
to
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 2)){
Please try whether it fixes.
Thanks,
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
Hi, Ideally when zigzag is employed, in the end result the offset should be zero or neglible. In the case of the STB0899, IIRC it is rounded off. So in most cases, you don't have an offset. Satellite transponders also tend to drift. Good operators will measure the exact drift and fix their NIT, but this isn't always done. Yes, ideally it would be zero, but in real world, it isn't. Userspace can read back the frequency, adjust their tables, but even that isn't perfect (if the LOF drifts with temperature, for example, the original center frequency might be closer to the current real frequency than the last compensated frequency). In really worse cases, you could drift into the next transponder. So I'd say that reading back the real frequency and using it for tuning should be avoided. Instead, the drift should be evaluated every time. Usually the drift can be fully compensated by the derotator, and in that case, it doesn't slow down tuning. Of course if you have a really big drift, something is wrong. But even then you shouldn't be tuning to the entire bandwidth. But i guess then you are using Why not? We do our best to archive lock. The border line to avoid false positives (i.e. locking to neighbor channels) it the entire bandwidth. (or did I misunderstand you here?) I just asked the question, since it affects other devices in an inverse way. But this we cannot exactly say each device how it would respond to the same. Some devices behave very bad. For a long time i tried disabling the swzigzag for the dst, but then i had to come up with various hacks to get it going. Yes. We need a better control over the zigzack-process, and the possibility to disable it (and possibly handle it inside the demod driver). - 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? So you see, sometimes there is no way to know the Inversion setting. When it is just a matter of wiring on the hardware/card, why not do it according to the hardware rather than trying to do autodetection, by taking up more time ? The point being, it is just a matter of detecting it one time, whether the specific hardware has I/Q input swapped or not. I agree, the HW wiring should not be autodetected. But given the fact that its not possible to know whether the original, non-downconverted signal (as broadcasted by the satellite) has Inversion on or off (as it isn't specified in the NIT, for example), we don't know the end result. Just because some hardware is capable of detecting the inversion, does it mean that we need to emulate that same mode by doing it in software thereby making tuning slow on the devices, that cannot do the AUTO mode ? Usually not, you are right (for example we don't try to autodetect symbolrate when the hardware is not capable of). But as said above, Inversion is a special case, because you don't know it. At some point of time, i believed as well the fact that I/Q swap at the modulator (transmitter/satellite side) can cause an Inversion change. Not only that, it will also be swapped by a frequency inversion, which happens for example on a C-Band LNB (where the channel frequency is lower than the local oscillator). Didn't think of that case. But in that case it would be a matter of the userspace telling the driver whether it is negative or positive, ie INVERSION ON or OFF Yes, that's right. Felix ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Igor Nikanov wrote: Hello, Manu thanks for your efforts. Is there the diseqc protocol's support in your driver. I mean the 1, 1.1, 1.2 version. Yep. Additionally if that matters, Diseqc 2.0 receiver support code is temporarily commented out. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
В Сбт, 29/09/2007 в 13:44 +0400, Manu Abraham пишет:
but hacked szap won't work:
Ahh ..
The szap modification was older than a previous API update.
Just change the following line in szap.c
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 1)){
to
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 2)){
this helps because I have DVB_API_VERSION_MINOR equal 3:
251c251
if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 1)) {
---
if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR == 3)) {
287c287
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR ==
3)){
---
} else if ((DVB_API_VERSION == 3) (DVB_API_VERSION_MINOR ==
1)){
after this change szap locked successfully:
szap # ./szap -a 1 MTV Russia
reading channels from file '/root/.szap/channels.conf'
zapping to 2 'MTV Russia':
sat 0, frequency = 12245 MHz V, symbolrate 2750, vpid = 0x0142, apid
= 0x0194 sid = 0x283f
Querying info .. Delivery system=DVB-S
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
status 01 | signal cd06 | snr b56e | ber ff00 | unc |
status 1f | signal cf74 | snr c7b9 | ber 0800 | unc |
FE_HAS_LOCK
status 1f | signal d0b9 | snr c819 | ber 0100 | unc |
FE_HAS_LOCK
but szap lost lock if I'm trying to touch CI+CAM with following command:
libdvb-0.5.5.1-sat # ./cam_set -a 1
Found 1CAM(s)
CAMInit: CI link layer level interface type
Using /dev/dvb/adapter1/ca0
Found 0 slots. caps.slot_num:1
CAM: Viaccess, 01, 0500, 0500
szap show:
status 1f | signal d0bc | snr c753 | ber 0100 | unc |
FE_HAS_LOCK
status 1f | signal cf85 | snr c7f5 | ber | unc |
FE_HAS_LOCK
status 1f | signal d0bd | snr c828 | ber 0100 | unc |
FE_HAS_LOCK
status 01 | signal 95fe | snr 7ff5 | ber 334e | unc |
status 01 | signal 951a | snr 7f56 | ber 34f8 | unc |
status 01 | signal 95e4 | snr 7fe3 | ber 33e7 | unc |
anu ideas ?
Thanks !
--
Abylai Ospan [EMAIL PROTECTED]
NetUP Inc.
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
Re: [linux-dvb] Some thoughts and questions
Felix Domke wrote:
Hi,
Ideally when zigzag is employed, in the end result the offset should be zero
or neglible.
In the case of the STB0899, IIRC it is rounded off. So in most cases, you
don't have an
offset.
Satellite transponders also tend to drift. Good operators will measure
the exact drift and fix their NIT, but this isn't always done.
Yes, ideally it would be zero, but in real world, it isn't. Userspace
can read back the frequency, adjust their tables, but even that isn't
perfect (if the LOF drifts with temperature, for example, the original
center frequency might be closer to the current real frequency than the
last compensated frequency). In really worse cases, you could drift into
the next transponder.
True
So I'd say that reading back the real frequency and using it for tuning
should be avoided. Instead, the drift should be evaluated every time.
Usually the drift can be fully compensated by the derotator, and in that
case, it doesn't slow down tuning.
I am not stating that zigzag is evil, but making a STV0299 specific zigzag for
other
devices is evil, since it can never be made generic for a wide range of
hardware,
While all the demodulators work perfectly fine.
Of course if you have a really big drift, something is wrong.
True
But even then you shouldn't be tuning to the entire bandwidth. But i guess
then you are using
Why not? We do our best to archive lock. The border line to avoid false
positives (i.e. locking to neighbor channels) it the entire bandwidth.
(or did I misunderstand you here?)
If we try to tune to the entire bandwidth in one shot, the centering wouldn't
be correct.
I just happen to do it in 3Mhz steps. A deviation from a 10 MHz step to a 3Mhz
yielded in
sufficiently large positive results. Regarding the time taken to tune.
I just asked the question, since it affects other devices in an inverse way.
But this we cannot exactly say each device how it would respond to the same.
Some devices behave very bad. For a long time i tried disabling the swzigzag
for the dst, but then i had to come up with various hacks to get it going.
Yes. We need a better control over the zigzack-process, and the
possibility to disable it (and possibly handle it inside the demod driver).
Exactly. That is exactly what i do. I don't allow the zig-zag in
dvb_frontend.c, but
use the zigzag for the driver specific way, eventhough the zig-zag, what i do
is in a
STV0299 compatible method, There IS something wrong in the zig-zag in
dvb_frontend.c as it resulted in bad tuning for me, when i initially took a go
at the STB0899
http://jusst.de/hg/multiproto/file/557067efd932/linux/drivers/media/dvb/frontends/stb0899_algo.c
What i do for the STB0899 is that in the frontend thread, i use a new callback
called search rather than
using set_frontend to define the zigzag in a more accurate way inside the
STB0899 driver rather than using
the one from dvb_frontend.c
This is what i do in there.
295/*
296 * stb0899_search_carrier
297 * Search for a QPSK carrier with the derotator
298 */
299static enum stb0899_status stb0899_search_carrier(struct stb0899_state
*state)
300{
301 struct stb0899_internal *internal = state-internal;
302
303 short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop = 3;
304 int index = 0;
305 u8 cfr[2];
306 u8 reg;
307
308 internal-status = NOCARRIER;
309 derot_limit = (internal-sub_range / 2L) / internal-mclk;
310 derot_freq = internal-derot_freq;
311
312 reg = stb0899_read_reg(state, STB0899_CFD);
313 STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
314 stb0899_write_reg(state, STB0899_CFD, reg);
315
316 do {
317 dprintk(state-verbose, FE_DEBUG, 1, Derot Freq=%d, mclk=%d, derot_freq,
internal-mclk);
318 if (stb0899_check_carrier(state) == NOCARRIER) {
319 index++;
320 last_derot_freq = derot_freq;
321 derot_freq += index * internal-direction * internal-derot_step; /* next
zig zag derotator position */
322
323 if(ABS(derot_freq) derot_limit)
324 next_loop--;
325
326 if (next_loop) {
327 reg = stb0899_read_reg(state, STB0899_CFD);
328 STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
329 stb0899_write_reg(state, STB0899_CFD, reg);
330
331 STB0899_SETFIELD_VAL(CFRM, cfr[0], MSB(state-config-inversion *
derot_freq));
332 STB0899_SETFIELD_VAL(CFRL, cfr[1], LSB(state-config-inversion *
derot_freq));
333 stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /* derotator frequency */
334 }
335 }
336
337 internal-direction = -internal-direction; /* Change zigzag direction */
338 } while ((internal-status != CARRIEROK) next_loop);
- 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.
So you
Re: [linux-dvb] Some thoughts and questions
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. (I might be terribly wrong, but that's how I remember it.) Felix ___ 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
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 ___ 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 Sat, Sep 29, 2007, Manu Abraham wrote: ... Instead of losing myself in the details of your questions, some background info: 1) LNB drift - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) - the demod can only compensate for a limited frequency offset (e.g. both stv0299 and stb0899 QPSK are specced to +/-5% fM_CLK for Carrier loop capture range, where fM_CLK is typically 88MHz for stv0299 and 108MHz for stb0899, thus 4.4 MHz vs. 5.4 MHz. But note that this are best case figures which only hold with good CNR.) - if the LNB error + drift is higer than what the demod can capture, then tuning fails - _only when initial tuning fails_ does the sw zig-zag kick in, and it attempts to tune in increasing steps around the nominal frequency until the demod either locks on the signal, or the scanned frequency range covers the complete channel bandwidth (we want to avoid locking on the neighbour channel; note that adjacent channels on satellite use different polarization so we can't lock there unless we really stepped way too far) - the parameters for sw zig-zag are provided by the demod driver in struct dvb_frontend_tune_settings int min_delay_ms; // when to assume tuning failed - do next step int step_size;// size of zig-zag step int max_drift;// when to stop zig-zagging a demod driver can disable sw zig-zag by setting step_size and max_drift to zero (which is what DVB-T and DVB-C drivers do) - sw zig-zag is by no means stv0299 specific and is used by (almost?) all DVB-S demod drivers The bottom line is that: 1. zig-zag doesn't slow down tuning, because it only ever kicks in when the initial tuning attempt failed (however, it is possible that a driver sets min_delay_ms too small, then zig-zag kicks in too soon and ruins your day) 2. zig-zag tries harder to tune, and makes users happy, even if tuning might take some time; without zig-zag, all you can do is tell your user sorry, no signal found 3. once zig-zag succeeded, the offset (drift compensation) is stored and reused at the next channel switch -- thus not every tuning is slowed down even if there is a large offset 4. zig-zag could also be implemented in user space, but IMHO it's better the way it is now -- since some hw doesn't heed sw zig-zag, and the ones that need it need different parameters IIRC Andrew de Quincey spent significant time optimizing the zig-zag code and the parameters for various frontends. 2) Inversion AUTO In the old days there were literally two wires with the I and Q signals running from the baseband processor to the QPSK modulator. It probably was a common mistake that someone messed up the wiring at the broadcaster. Nowadays the equipment is integrated and the inversion setting is just a check box in the control software. Still broadcasters seem to set it at random. Like Felix explained, at the receiver side you don't know if the spectrum is inverted. If the demod firmware doesn't handle it, you have to try both inversion settings in sw. And like with zig-zag, you could do it in userspace but IMHO it's better to let the core handle it. Apps which want to optimize tuning performance could use FE_GET_FRONTEND after successful tuning to get the real inversion setting, and use that instead of AUTO. The reason why scan/szap don't do this is that a) not all drivers get it right, and b) for DVB-C and DVB-S inversion settings can be regionally different -- we don't want channel lists which only work with some cards in some regions. HTH, Johannes ___ 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 Sat, Sep 29, 2007, Manu Abraham wrote: ... Instead of losing myself in the details of your questions, some background info: 1) LNB drift - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift - the demod can only compensate for a limited frequency offset (e.g. both stv0299 and stb0899 QPSK are specced to +/-5% fM_CLK for Carrier loop capture range, where fM_CLK is typically 88MHz for stv0299 and 108MHz for stb0899, thus 4.4 MHz vs. 5.4 MHz. But note that this are best case figures which only hold with good CNR.) - if the LNB error + drift is higer than what the demod can capture, then tuning fails even a max of 20k is so small within the actual bandwidth window, for a demod not to lock A demod has a bandwidth of normally 5 - 10 MHz, depending on the device. - _only when initial tuning fails_ does the sw zig-zag kick in, and it attempts to tune in increasing steps around the nominal frequency until the demod either locks on the signal, or the scanned frequency range covers the complete channel bandwidth (we want to avoid locking on the neighbour channel; note that adjacent channels on satellite use different polarization so we can't lock there unless we really stepped way too far) - the parameters for sw zig-zag are provided by the demod driver in struct dvb_frontend_tune_settings int min_delay_ms; // when to assume tuning failed - do next step int step_size;// size of zig-zag step int max_drift;// when to stop zig-zagging a demod driver can disable sw zig-zag by setting step_size and max_drift to zero (which is what DVB-T and DVB-C drivers do) - sw zig-zag is by no means stv0299 specific and is used by (almost?) all DVB-S demod drivers hmm, i didn't mean swzigzag, but as you see from that discussion, it was the drift that i am looking at The bottom line is that: 1. zig-zag doesn't slow down tuning, because it only ever kicks in when the initial tuning attempt failed (however, it is possible that a driver sets min_delay_ms too small, then zig-zag kicks in too soon and ruins your day) 2. zig-zag tries harder to tune, and makes users happy, even if tuning might take some time; without zig-zag, all you can do is tell your user sorry, no signal found My point being to have zigzag specific to the demod, since each device of the devices which implements zigzag does it in a different way. The computation being different 3. once zig-zag succeeded, the offset (drift compensation) is stored and reused at the next channel switch -- thus not every tuning is slowed down even if there is a large offset 4. zig-zag could also be implemented in user space, but IMHO it's better the way it is now -- since some hw doesn't heed sw zig-zag, and the ones that need it need different parameters I wasn't meaning to implement it in userspace, it easier as it is within a driver, but as you see different devices does it in different way altogether. What i was suggesting was to move it into the drivers, where it would make life a bit more easier, rather than one device implement a search callback and another implement a set_params. This leads to confusion for a person writing a driver. With regards to the STB0899, it doesn't use the set_frontend call to avoid such a nasty circumstance. A new callback such as search is implemented. IIRC Andrew de Quincey spent significant time optimizing the zig-zag code and the parameters for various frontends. I do remember the time where he spent so much time optimizing the swzigzag for the STV0299. 2) Inversion AUTO In the old days there were literally two wires with the I and Q signals running from the baseband processor to the QPSK modulator. It probably was a common mistake that someone messed up the wiring at the broadcaster. Nowadays the equipment is integrated and the inversion setting is just a check box in the control software. Still broadcasters seem to set it at random. You have any cases of broadcasters doing it in a non-standard way ? ie inverted transmission ? Like Felix explained, at the receiver side you don't know if the spectrum is inverted. If the demod firmware doesn't handle it, you have to try both inversion settings in sw. And like with zig-zag, you could do it in userspace but IMHO it's better to let the core handle it. At the receiver side it is quite fine, we know that we can handle it when the downconversion phase is negative or when the I/Q inputs are connected in an inverted way The only question, being the broadcaster side. Manu ___ linux-dvb mailing list
Re: [linux-dvb] Some thoughts and questions
Hi, On Sat, Sep 29, 2007 at 04:18:31PM +0400, Manu Abraham wrote: Johannes Stezenbach wrote: 1) LNB drift - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift hmm I am not sure how old our LNBs (at work) are, but there and with my LNBs at home (around 2 years old) I have measured offsets of around 1-2 MHz. - sw zig-zag is by no means stv0299 specific and is used by (almost?) all DVB-S demod drivers hmm, i didn't mean swzigzag, but as you see from that discussion, it was the drift that i am looking at Is it really a difference? I am not sure if I understand it correctly, but IMHO this is or could be handled as the same issue. For low symbol rates, the problem is that you can not get the frontend locked to the transponder if the offset (probably being caused by drift or simply constant frequency offset because of the cheap crystal in frontend PLL and/or LNB) is too high. You can only overcome this by zig-zag-scan. My point being to have zigzag specific to the demod, since each device of the devices which implements zigzag does it in a different way. The computation being different Why is the computation different? I did not look into it yet, but at the moment I can only see stepsize and transponder bandwidth (symbol rate in case of DVB-S) as the parameters the algorithm depends on. [...] IIRC Andrew de Quincey spent significant time optimizing the zig-zag code and the parameters for various frontends. I do remember the time where he spent so much time optimizing the swzigzag for the STV0299. It seems my thinking is too easy above, I will have to look into the code to get enlightenment, I hope. :-) You have any cases of broadcasters doing it in a non-standard way ? ie inverted transmission ? I do not remember the transponders, but there are some - not on Astra/Hotbird, though. Maybe I can give an example on monday. Regards, Wolfgang ___ 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 Sat, Sep 29, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift If you make that 20kHz per °K then it's about the usual range for Ku Band, maybe slightly better than average. (An LNB with +/-20KHz drift over the full temperature range would be ridiculously expensive.) Don't forget that your tuner also has maybe +/-50ppm tolerance. The errors can add up. Johannes ___ 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 Sat, Sep 29, 2007 at 04:18:31PM +0400, Manu Abraham wrote: - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift old LNBs? That's the majority in the consumer market. In fact I haven't seen a PLL stabilized LNB until now in that area. Even the high quality consumer stuff made by Invacom have no PLL and just a simple DRO pill for the LO. even a max of 20k is so small within the actual bandwidth window, for a demod not to lock A demod has a bandwidth of normally 5 - 10 MHz, depending on the device. This is only true if you have high symbolrates. On the STV0299, a 3MS/s transponder tolerates just about 500-800kHz drift. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ 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 Sat, Sep 29, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift If you make that 20kHz per °K then it's about the usual range for Ku Band, maybe slightly better than average. (An LNB with +/-20KHz drift over the full temperature range would be ridiculously expensive.) ACK didn't account for the / K. But still for a LNB with 27 K, It amounts to around +/- 0.5MHz Which is still quite small for a 5 - 10 MHz window. As you said, maybe there are really bad ones with +/-1MHz drift, but i think +/-3MHz is a bit too exaggerated figure Don't forget that your tuner also has maybe +/-50ppm tolerance. The errors can add up. Let's assume with a step size of 1MHz at the most max. 50ppm (error even when summed) is too small even for the largest 1MHz step, comparing to +/- 0.5Mhz drift. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] nova-t 500
1) system (uname -a) Linux media 2.6.22.1 #1 SMP Mon Jul 16 19:58:53 CEST 2007 x86_64 GNU/Linux 2) lspci-output [EMAIL PROTECTED]:~# lspci 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a2) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a2) 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a1) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 04:08.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1Controller (rev 61) 04:08.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1Controller (rev 61) 04:08.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 04:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 3) DiB0700 device name (USB Stick, Nova-T 500) Nova-T 500 4) Application using the device (MythTV, VDR etc) MythTV 5) Symptoms (unusable, disconnect after x days, no problem) Disconnects, usualy when recording ocn both tuners. Semi random. Currenly once a week, was once a month for a while. /Henrik ___ 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
Hi, Wolfgang Wegner wrote: Hi, On Sat, Sep 29, 2007 at 04:18:31PM +0400, Manu Abraham wrote: Johannes Stezenbach wrote: 1) LNB drift - LNBs have a constant error plus a temperature drift (e.g. +/-1MHz error, +/-3Mhz drift for a temperature range of -40 ... +60 °C -- cheap no name equipment usually worse) This is the old LNB, the one's we use are generally based on PLL's have some 15 - 20k drift hmm I am not sure how old our LNBs (at work) are, but there and with my LNBs at home (around 2 years old) I have measured offsets of around 1-2 MHz. - sw zig-zag is by no means stv0299 specific and is used by (almost?) all DVB-S demod drivers hmm, i didn't mean swzigzag, but as you see from that discussion, it was the drift that i am looking at Is it really a difference? I am not sure if I understand it correctly, but IMHO this is or could be handled as the same issue. For low symbol rates, the problem is that you can not get the frontend locked to the transponder if the offset (probably being caused by drift or simply constant frequency offset because of the cheap crystal in frontend PLL and/or LNB) is too high. You can only overcome this by zig-zag-scan. My point being to have zigzag specific to the demod, since each device of the devices which implements zigzag does it in a different way. The computation being different Why is the computation different? I did not look into it yet, but at the moment I can only see stepsize and transponder bandwidth (symbol rate in case of DVB-S) as the parameters the algorithm depends on. A quick generalized comparison. (looked at 2 devices from 2 vendors) devices from STM does Fs / 2 zigzag, where Fs is variable. Intel uses Foff = (err1 * mclk / 65536 + err2 * srate / 262144) Although point to be noted is that dvb_frontend is not doing Fs/2 zigzag either. It does some zigzag. [...] IIRC Andrew de Quincey spent significant time optimizing the zig-zag code and the parameters for various frontends. I do remember the time where he spent so much time optimizing the swzigzag for the STV0299. It seems my thinking is too easy above, I will have to look into the code to get enlightenment, I hope. :-) You have any cases of broadcasters doing it in a non-standard way ? ie inverted transmission ? I do not remember the transponders, but there are some - not on Astra/Hotbird, though. Maybe I can give an example on monday. Thanks, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
In 1998 the Technotrend GmbH develops the still very popular PC DVB card with a full- featured STB processor on it. In 1999 Siemens produces a card based on the Technotrend design However, Manu recounts, and other things that I have seen written collaborate with his recollection, that it was Siemens who were the original FF card designer. Apparently, although it was the TechnoTrend produced model that stepped into the spotlight (read: became very popular), the TT card itself was based upon the Siemens design, and, hence, it was the Siemens that truly was the mother of all FF cards. If I'm not mistaken SNI (Siemens Nixdorf Informationssysteme AG; the actual Siemens division responsible for the card) continued to produce their own model through 1999, until at which time SNI was split from its parent company and parts of which (SNI) were used to form the Fujitsui-Siemens joint venture. AFAIR, this is correct. I also remember that the firmware was first done by Siemens. Technotrend added their own stuff but e.g. did not give back the DiSEqC code to Siemens. So, the code we got from Siemens did not include this and we had to add our own code for this. I also have a couple of questions related to the continuing part of the same above statement: In 1999 Siemens produces a card and supports the development of the ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Stupid problem !
Hi everybody. I'm having a very stupid, and boring, problem as I am trying to install drivers for a 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... Can someone please help me? Thanks ! Regards, François. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technisat DVB-S2 Skystar HD
Artem Makhutov wrote:
Hi,
with Manu's new drivers I run into this problem with my Technisat
Skystar HD: frontend_init: No LNBP21 found!
Has someone the same problem? Is the driver working for you?
What about the TT3200? Is the driver working?
Sep 29 13:40:22 gandalf [ 472.064609] frontend_init: No LNBP21 found!
Sep 29 13:40:22 gandalf [ 472.064613] stb0899_release: Release Frontend
Sep 29 13:40:22 gandalf [ 472.064616] budget-ci: A frontend driver was not
found for device 1131/7146 subsystem 13c2/1019
In
http://jusst.de/hg/multiproto/file/557067efd932/linux/drivers/media/dvb/ttpci/budget-ci.c
1758 if (lnbp21_attach(budget_ci-budget.dvb_frontend,
budget_ci-budget.i2c_adap, 0, 0)) {
change it to
1758 if (!lnbp21_attach(budget_ci-budget.dvb_frontend,
budget_ci-budget.i2c_adap, 0, 0)) {
Manu
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Trouble with Pinnacle 310i DVB
Hi, I have trouble getting my Pinnacle 310i to work. Analog tuning is ok, but DVB never worked. I think I have tried everything I could find at the net about this card, so therefore I try this list. I'm using the modules from the 2.6.22 kernel on a Gentoo system. saa7134 loads automatically at boot giving the following in the log: Sep 29 19:21:13 ampere Linux video capture interface: v2.00 Sep 29 19:21:13 ampere saa7130/34: v4l2 driver version 0.2.14 loaded Sep 29 19:21:13 ampere ACPI: PCI Interrupt :05:04.0[A] - Link [LNKA] - GSI 5 (level, low) - IRQ 5 Sep 29 19:21:13 ampere saa7133[0]: found at :05:04.0, rev: 209, irq: 5, latency: 32, mmio: 0xd0201000 Sep 29 19:21:13 ampere saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] Sep 29 19:21:13 ampere saa7133[0]: board init: gpio is 600e000 Sep 29 19:21:13 ampere input: Pinnacle PCTV as /class/input/input4 Sep 29 19:21:13 ampere ir-kbd-i2c: Pinnacle PCTV detected at i2c-0/0-0047/ir0 [saa7133[0]] Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2e 08 1b ff ff Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 03 c4 79 54 Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Sep 29 19:21:13 ampere saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Sep 29 19:21:13 ampere saa7133[0]: registered device video0 [v4l2] Sep 29 19:21:13 ampere saa7133[0]: registered device vbi0 Sep 29 19:21:13 ampere saa7133[0]: registered device radio0 Looks to me like the card is found correctly and analog works so I gues this is true Then I modprobe saa7134_dvb and get the following in the log: Sep 29 19:23:11 ampere DVB: Unable to find symbol tda827x_attach() Sep 29 19:23:11 ampere saa7133[0]/dvb: no tda827x tuner found at addr: 61 Sep 29 19:23:11 ampere DVB: registering new adapter (saa7133[0]). Sep 29 19:23:11 ampere DVB: registering frontend 0 (Philips TDA10046H DVB-T)... Sep 29 19:23:11 ampere tda1004x: setting up plls for 48MHz sampling clock Sep 29 19:23:13 ampere tda1004x: timeout waiting for DSP ready Sep 29 19:23:13 ampere tda1004x: found firmware revision 0 -- invalid Sep 29 19:23:13 ampere tda1004x: trying to boot from eeprom Sep 29 19:23:15 ampere tda1004x: timeout waiting for DSP ready Sep 29 19:23:15 ampere tda1004x: found firmware revision 0 -- invalid Sep 29 19:23:15 ampere tda1004x: waiting for firmware upload... Sep 29 19:23:29 ampere tda1004x: found firmware revision 29 -- ok Sep 29 19:24:35 ampere tda1004x: setting up plls for 48MHz sampling clock Sep 29 19:24:35 ampere tda1004x: found firmware revision 29 -- ok First and second line looks wrong to me, but I'm not sure. Then, with w_scan I am sometimes able to find a signal. Funny thing is, that it it only works the first time after a reboot. If I run w_scan several times, it only finds a signal the first time. dvbscan sometimes works, and gives me a channels.conf, that looks correctly. But I never got any picture with xine or mplayer. xine: input_dvb: continuing in get_instance mplayer: dvb_tune Freq: 63400 Not able to lock to the signal on the given frequency, timeout: 30 dvb_tune, TUNING FAILED ERROR, COULDN'T SET CHANNEL 0: Failed to open dvb://DR1 At first I though I had a bad signal (because of w_scan and dvbscan failing), but the DVB tuner works fine using Windows XP. Hope someone on the list is able to help me getting this card to work. Please let me know if you need more information. Best Regards, Bo ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Stupid problem !
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] DiB0700 device report
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.1 Controller (rev 61) 01:01.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (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
Re: [linux-dvb] Stupid problem !
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 bMaxPacketSize0 64 idVendor 0x2040 Hauppauge idProduct 0x9950 bcdDevice 1.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
Re: [linux-dvb] Some thoughts and questions
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, 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. (This is supposing on the basis that we are not fiddling around with the STV0299) 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 ? Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
