Re: [linux-dvb] asus p7131 vs ZDF?
On Sat, 2007-09-15 at 23:55 +0200, hermann pitton wrote: > Hi Soeren, Hi Hermann, [zdf not available on p7131] > > > > ZDF:57000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:545:546:514 [...] > closest to you is this one with 8MHz bandwidth on the older one I have > without LNA. You might try with AUTO for all, except bandwidth. > > T 57800 8MHz 2/3 NONEQAM16 8k1/4 NONE so I used ZDF2:57800:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:545:546:514 but still no channel lock... > Haven't find anything special for this one so far on the tda8275a with > tda10046a. > > An FMD1216ME with tda10046a, not much tested yet, more likely has some > flaw around there on slightly weaker signal. The other budget card says has snr f5f5 - fefe (signal cdcd) for ZDF and gets BER in the twenties. While the situation is better for ARD (signal d2d2, snr fefe, ber between 0-4 for the budget card and signal a3a3 for the p7131, snr fefe, ber 0-4) I think reception is still strong enough for ZDF... Strange that I have seen the exact same problem for the dibcom dongles... Hmmhhh... Soeren ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
CityK wrote: > Its described in: > > "/EN 50083-9:2002 : //Cable networks for television signals, sound > signals and interactive services. Part 9: Interfaces for CATV/SMATV > head-ends and similar professional equipment for DVB/MPEG2 transport > streams. " > / > > //which is available (if you're registered) from: > http://www.cenelec.org/Cenelec/Code/Frameset.aspx > // > > /// > / > > / > / > > / > / Apparently Thunderbird didn't like that copy & paste of the title: EN 50083-9:2002 : Cable networks for television signals, sound signals and interactive services. Part 9: Interfaces for CATV/SMATV head-ends and similar professional equipment for DVB/MPEG2 transport streams ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Wolfgang Wegner wrote: > - dvb_fe_type: DVB-S2 is missing and I personally would also like > to see ASI here... > Manu Abraham wrote: > Can you please point me to some ASI specs if you don't mind ? I was > once supposed to work on such a device, but then that company itself got > scrapped, hence never had to figure out on ASI. Wolfgang Wegner wrote: > Well, AFAIK the ASI specification is not open, so I unfortunately I > can not point to it. > To be honest, the only thing about ASI comes from a fronted we use at > the company in professional equipment, so I am not sure if the things > I can tell from there are really valid for all ASI equipment. However, > as from time to time questions come up concerning DekTec and other boards, > at least some basic support for ASI seems to be desirable. > > So, coming to the facts, our ASI frontend gives these as "statistics": > - BER > - sync status > - 204 or 188 byte/packet mode > Its described in: "/EN 50083-9:2002 : //Cable networks for television signals, sound signals and interactive services. Part 9: Interfaces for CATV/SMATV head-ends and similar professional equipment for DVB/MPEG2 transport streams. " / //which is available (if you're registered) from: http://www.cenelec.org/Cenelec/Code/Frameset.aspx // /// / / / / / ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Q: How to test if EIT is being broadcasted correctly
Hi all, I use a STB to watch Sat TV (canalsat caraibes in the franch West Indies). It displays now/next infos during viewing so I guess that it means EIT is present on the feed. Moreover there is a special channel which is named "Guide des Programmes" (program guide in French). Using MythTV everything works but the EPG. So my question is: how can I be sure of what is really broadcasted in terms of EIT. I tried tst_sections in dvb_apps using the PID from channels.conf (I used the first number after the symbol rate) and also with 0x12 but it always emits this: test_sections: using '/dev/dvb/adapter0/demux0' PID 0x0012 Filter 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Mask 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 and stops. So I guess somethings isnot working. Any idea? TIA 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] DVB API update
Hi Wolfgang, Wolfgang Wegner wrote: > Hi Manu, > > On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote: >> Please don't remove the CC's. The CC'd people generally don't bother >> about mails from the ML, probably. > > sorry, it was definitely not my intention and I hope to include > all previous CC here. > np. :) > [have to read about the multiproto changes myself...] You can find the last update over here: http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2 It is in fact a complete tree which is encapsulated in a tarball, just because i had been in the other OS, at that point of time. >> Can you please point me to some ASI specs if you don't mind ? I was >> once supposed to work on such a device, but then that company itself got >> scrapped, hence never had to figure out on ASI. > > Well, AFAIK the ASI specification is not open, so I unfortunately I > can not point to it. > To be honest, the only thing about ASI comes from a fronted we use at > the company in professional equipment, so I am not sure if the things > I can tell from there are really valid for all ASI equipment. However, > as from time to time questions come up concerning DekTec and other boards, > at least some basic support for ASI seems to be desirable. > > So, coming to the facts, our ASI frontend gives these as "statistics": > - BER > - sync status > - 204 or 188 byte/packet mode I will try to collect whatever info i can, as well before we jump into a wrong conclusion. The more info we have, the better it is. It would be incorrect to add in to an API based much on guess work, unless we have real scenarios, once into an API it is there forever, so we have to be much cautious about it. If it is wrong, the only other option later, even if you have real information would be workarounds. > > [...] >> Since it is an IOCTL call straight away within the V3 API, i would like >> to push this into the frontend thread where it is submitted as a job >> kind of thing, where the userapplication can be notified in what >> timeframe, or via GET_EVENTS, final details can be left out for the last >> stage. > > This sounds very reasonable for me. I have no idea yet how this frontend > thread is handled now, but after all all necessary information should be > present there (e.g. lock state, to do a proper reset of averaging etc.). Currently it is used only for tuning , ie frontend setup. In the case of the dvb-s2 (stb0899) driver, i have implemented the search algorithm from the frontend thread, instead of a blind setting up of parameters >> Scale for BER is one thing that is still open ended, which i am off >> hook. I need to still check on this, but if you have some ideas would be >> nice. > > Hmm... I am not sure what is needed by others, so my voice should not > be given too much weight here. We always use 10^-8 as the base, but for > some equipment this might already be too rough. On the other hand, IIRC > some demodulators do not return more accurate values anyways. > >> Signal Strength & SNR: >> >> In reality we can provide 2 ways for the same, >> 1) Relative scale >> 2) a scale in a decibels >> >> Even with Reverse Engineered drivers we can do 1) but for 2) we might >> need more info. The user could probably select what he needs using an >> IOCTL, relative or an absolute scale. For the relative one we can just >> define a floor and ceiling and a relative value is extracted out. > > That is what I was thinking of, for most applications this would be > sufficient. I do not know what is the better solution here. Following > your proposal of two different styles of return values makes life easier > for the application (which could request the "scale" type and just take > this value). Even knowing the exact decibel value would make it necessary > to interpret it differently for different transmission schemes, i.e. 8 dB > SNR in DVB-S is no problem while there would be no reception in DVB-C... > On the other hand it might be confusing to get different values for the > same thing, which I treat as an argument for my proposal of always (if > possible) returning the dB value and giving the application (and user) > the demod min and max values for drawing a nice percentage scale. > > For a few demods I could provide the dB calculation (namely STV0299, > STV0288, TDA10046, TDA1002x), but probably these are those with > fewest problems anyways. > For others (e.g. STV0297) there seems to be no calculation possible, > I know of other implementations using a look-up-table. If needed, I > could do some measurements and see if we manage to get good results > with a look-up-table, too. That would be great, Did a quick check on some of them: All STM (299, 288, 899, 900) does 10^7 exception STV0297 Philips (10021, 23) does 10^5 Conexant varies from chip to chip CX22702 says 127 bits max CX24116 does a table lookup in the driver Samsung S5H1409 does 10^4 On the STV0297 you need to calculate from BERT_0 and BERT_1 (0xe4 and 0xe5) Though it
Re: [linux-dvb] HELP: card identification
Am Sonntag, den 16.09.2007, 22:51 +0200 schrieb Peter Missel: > Hi all! > > > then I expect that the Typhoon/Anubis/Lifeview cardbus 50500 just works > > with the current v4l-dvb mercurial master repository at linuxtv.org. > > The Typhoon 50500 is a LifeView Cardbus Duo (502TA), while the 50503 is a Duo > w/ remote feature (LR502TAR). > > The lesser "Hybrid" models have a separate radio antenna jack, and a radio > antenna included - the Duo cards have twin TV antenna jacks and no radio > function at all. > > Sources for Germany? www.schwarz.de have a selection of LifeView branded > cards > in their DVB-T section, that's where my own 502TAR came from - simply because > nobody else apparently carries the full version w/ remote control. > www.pearl.de currently have the remote-less Typhoon version for a very good > price (39.90 euros as of right now). > > The thing to look out for is the card revision - at least since last year, > these cards do not have a cooling fan inside anymore. The older revisions > with their tiny noisy fan are unbearable on a quiet notebook. > > Hope that helps. > > good night. > Peter Hi Peter, thanks! This makes it clear with the radio and also the fan issue is good to know about. We are looking for a shop in Frankfurt am Main, preferably just on the main shopping mall ZEIL and say starting from subway station Konstablerwache, which has the recent Typhoon OEM in stock or the Kworld NB-TV 220, which might be the sam then. Also no radio as far I have seen. Conrad Electronics exactly there has it not. Else we must go to such outlet centers in the peripherie along the highways, we just want to buy it, waiting for delivery takes too long. Sunday is not good to check it out ... Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HELP: card identification
Hi, Am Sonntag, den 16.09.2007, 13:22 +0200 schrieb misha: > > says either analog TV or DVB-T, but the "datasheet" there says both at > > once. If it is hybrid with only one tuner at 0x61 and none at 0x60 you > > should see errors in dmesg. Check if firmware upload is OK. > > no errors in dmesg > > > > > Better try with mercurial, there you also can set debug=1 for > > saa7134-dvb and the new tda827x frontend module. > > this went a bit over my head. i googled for mercurial, looked at my > modules, and modinfo but i dont see useful references to this. can you > explain further what modules i should be loading and with what options? > > > > > >From the eeprom it should have two tuners too. > > yes, this is verified by the manual i got. then I expect that the Typhoon/Anubis/Lifeview cardbus 50500 just works with the current v4l-dvb mercurial master repository at linuxtv.org. http://linuxtv.org/hg/v4l-dvb Click on top on bz2, unpack, cd v4l-dvb, make, make rmmod, make install. "modprobe tda827x debug=1" "modprobe saa7134-dvb debug=1" You need kernel devel environement installed, on Ubunto should be kernel headers, for others kernel-devel rpm. Where you got it? Looks like every ProMarkt, Karstadt, Conrad etcetera has it. http://www.typhoon.deProdukte, the cardbus on top, then link "Produkt kaufen" http://www.heise.de/preisvergleich/a124746.html But when I let check the Conrad in Frankfurt directly from the central, it is not in stock there. Someone saw the new Duo Kworld NB-TV 220 cardbus already in a regular shop in Germany? http://www.heise.de/preisvergleich/a209327.html Or even the LifeView TRIO cardbus in a regular shop for a regular prize? http://www.dbcomputer.de/shop/NEU/TV-DVB-T/LifeView-FlyDVB-Trio-Cardbus-Adapter::2560.html?referer=froogle&language=de Does someone have the Avermedia cardbus E502 and does it have a tda8275a tuner? Should know it ... http://www.heise.de/preisvergleich/a122614.html Any known issues with the MSI A/D cardbus like with this Vivanco 21056/LR306 clone of the PCI card and analog TV? Just remember Werner Braun also didn't get DVB-T ZDF in Berlin with it, like Soeren reported yesterday for the Asus P7131 Hybrid LNA there. http://www.quelle.de/is-bin/INTERSHOP.enfinity/WFS/Quelle-quelle_de-Site/de_DE/-/EUR/Q_DisplayProductInformation-Start;sid=YdX9l0Oy-_L9lwVfRmLMwVce5YLhu3h227iWYD28?CategoryName=264990&AAID=21483042&PersShop=&tr_from=pue&productIndex=&urlparams= Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Rainer.scherg wrote:
> Manu Abraham schrieb:
>
>>> - a "user structure" for hardware specific data (e.g. retrieve
>>> special data from a special frontend chip would be nice.
>>> this should be optional (*NULL = not used or not implemented).
>>> otherwise something like:
>>>struct { char[xx] hw_info;
>>> specific data...
>>> } *;
>>>
>> Sounds good. In a tangent thought, in many cases when a special chip is
>> used sometimes there is an overall change in the hardware design.
>>
>> In such a case, do you think, that if we abstract such an info, out as a
>> part of as a new object such as an adapter object, (such that more
>> information can be passed out clearly) would be a better approach,
>> rather than shoving everything we have into the frontend object ? (where
>> the adapter object becomes the parent object for all others)
>>
>> Though i must say, that the frontend specific should be in the frontend,
>> but the adapter object could get the frontend specific information as a
>> part of it's own and present to the application. Though, you will be
>> able to query the frontend related information alone also, for carrying
>> around shorter chunks of data if the user wants to have only a small
>> subset of the information.
>
> I did not made any deeper thoughts on how this could be implemented
> best. What was the reason of this idea:
>A university asked me some times ago, to enhance dvbsnoop to output
>more detailled error reporting data than SIG, SNR, BER, UBLCK for
>a specific frontend (DIBCOM3000).
>
> In this case it was related to the frontend. As you stated, a special
> object might be more useful and more flexible.
What i was thinking was the adapter as a parent retrieving information
from all the child objects.
The parent as a whole representing the adapter having very little info
about itself, the rest being composed out of various entities which are
being assembled together to form a one single chunk of data.
This also fills in the gap when different vendors are used (in most
cases) to comprise a global entity such as a card alone. You can think
of the current card config struct as a starting point, but just that it
is made a bit more effective when components from different vendors are
pulled in together to make a device, which brings in additional
constraints, which is not explicitly expressed by any of the vendors.
For a reference device this criteria does not apply, as all the
components are specified and in most cases tested and benchmarked on
Lab equipment.
The card manufacturer being clueless on that aspect. (What they do: take
a reference device, just like how people cut and paste code, cut and
paste happens in the schematic editor, which is the entry point for a
deviation from the Reference designs. Of course some designs which are
derivatives of the reference design are better than the reference design
themselves)
For example we have limits for each device (component would be right
term), but with each possible configuration, the actual limits posed are
different, which require the information from all the components put
together (eg: demod + tuner limits are hard to express unless it is
represented by a configuration, which handles the same. Also, i think it
might better to be represented as a global representation of the adapter
rather than a frontend.)
ie. IOW, the adapter is a representation of the final component
assembly, to put things very short.
As an example, on some of the cards that i do have, i have a discrete
GaAsFET stage in front of the frontend, which does shape and provide
some amount of gain to the frontend. This is an alteration to the actual
specifications of the devices that we look at in our drivers, which also
needs to be accounted, if we are looking at more precise information.
>>
>>> - API 3 is missing a a function for retrieving current frontend
>>> settings (e.g. on SAT LNB settings). It would be sufficient, when
>>> simply the last parameters set are returned.
>>> Currently on API3 a "second dvb application" can change the frontend,
>>> whithout any chance for the "main dvb application" to detect this
>>> easily.
>> the dvb-core saving away the last successful LOCK state, will this help
>> ? But in any case, the second application if it successfully lock's,
>> then this would change logically, since this becomes the
>> previous-previous successful locked state.
>>
>> Is that what you meant, guess i didn't follow you correctly.
>
> Following scenario (SAT):
>Application 1 tunes device 2:
> to freq 1234.567 MHz, V, HiBand, SAT "2", etc..
>Application 2 tunes device 2:
> to freq 1000.123 MHz, H, LoBand, SAT "1", etc..
>
> Currently application 1 has no chance to query the current
> frontend settings.
>
> In a first step, a simple "query current frontend
> settings" (last set data) for a device would be sufficient.
> In a s
Re: [linux-dvb] DVB API update
Marcel Siegert schrieb: >>> Is that what you meant, guess i didn't follow you correctly. >> Following scenario (SAT): >>Application 1 tunes device 2: >> to freq 1234.567 MHz, V, HiBand, SAT "2", etc.. >>Application 2 tunes device 2: >> to freq 1000.123 MHz, H, LoBand, SAT "1", etc.. >> >> Currently application 1 has no chance to query the current >> frontend settings. > > from my pov it would not be allowed to have application 2 tune to a different > transponder if application 1 still uses it. > > and, where is the deep sense in this situation? > app 1 tunes to 1234 > > app 2 tunes to 1000... and therefore destroys app 1`s data > > app 1 checks periodically (via get current tuning param), > if everything still is fine, > the result is this case is no, so app 1 would maybe > try to retune to 1234-- and app2 would check and try to retune to 100 > > i cant see sense in your example at all. > > where i can see the sense is, to query a frontend to get back the actual > frontend settings, > but your example has a totally different problem. > > >> In a first step, a simple "query current frontend >> settings" (last set data) for a device would be sufficient. >> In a second step (future APIs), one could think about notification >> by event handlers. > > which notification? a userspace application should free a frontends usage, if > is no longer > using it. am i wrong? > >> I also would ignore the LOCK state and always save/return the last >> set parameters. > what do you mean with ignoring a LOCK state? also return frontend settings, > if no LOCK > has been done on those? if that is your point, i am ok for that. > > > regards > marcel > > maybe the example was unlucky, but it should show the current problem. It's just about querying some simple data. There is no discussion about any application or its behavior. So let's simplify the example: take a shell/perl script with 2 forked, async. processes: process 1 is just tuning (a) satellite(s) in steps (dvbtune). process 2 is frequently querying the tuned data and e.g. plots a diagram. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Manu Abraham schrieb:
>
>> - a "user structure" for hardware specific data (e.g. retrieve
>> special data from a special frontend chip would be nice.
>> this should be optional (*NULL = not used or not implemented).
>> otherwise something like:
>>struct { char[xx] hw_info;
>> specific data...
>> } *;
>>
>
> Sounds good. In a tangent thought, in many cases when a special chip is
> used sometimes there is an overall change in the hardware design.
>
> In such a case, do you think, that if we abstract such an info, out as a
> part of as a new object such as an adapter object, (such that more
> information can be passed out clearly) would be a better approach,
> rather than shoving everything we have into the frontend object ? (where
> the adapter object becomes the parent object for all others)
>
> Though i must say, that the frontend specific should be in the frontend,
> but the adapter object could get the frontend specific information as a
> part of it's own and present to the application. Though, you will be
> able to query the frontend related information alone also, for carrying
> around shorter chunks of data if the user wants to have only a small
> subset of the information.
I did not made any deeper thoughts on how this could be implemented
best. What was the reason of this idea:
A university asked me some times ago, to enhance dvbsnoop to output
more detailled error reporting data than SIG, SNR, BER, UBLCK for
a specific frontend (DIBCOM3000).
In this case it was related to the frontend. As you stated, a special
object might be more useful and more flexible.
>
>
>> - API 3 is missing a a function for retrieving current frontend
>> settings (e.g. on SAT LNB settings). It would be sufficient, when
>> simply the last parameters set are returned.
>> Currently on API3 a "second dvb application" can change the frontend,
>> whithout any chance for the "main dvb application" to detect this
>> easily.
>
> the dvb-core saving away the last successful LOCK state, will this help
> ? But in any case, the second application if it successfully lock's,
> then this would change logically, since this becomes the
> previous-previous successful locked state.
>
> Is that what you meant, guess i didn't follow you correctly.
Following scenario (SAT):
Application 1 tunes device 2:
to freq 1234.567 MHz, V, HiBand, SAT "2", etc..
Application 2 tunes device 2:
to freq 1000.123 MHz, H, LoBand, SAT "1", etc..
Currently application 1 has no chance to query the current
frontend settings.
In a first step, a simple "query current frontend
settings" (last set data) for a device would be sufficient.
In a second step (future APIs), one could think about notification
by event handlers.
I also would ignore the LOCK state and always save/return the last
set parameters.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Hi Manu, On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote: > Please don't remove the CC's. The CC'd people generally don't bother > about mails from the ML, probably. sorry, it was definitely not my intention and I hope to include all previous CC here. [have to read about the multiproto changes myself...] > Can you please point me to some ASI specs if you don't mind ? I was > once supposed to work on such a device, but then that company itself got > scrapped, hence never had to figure out on ASI. Well, AFAIK the ASI specification is not open, so I unfortunately I can not point to it. To be honest, the only thing about ASI comes from a fronted we use at the company in professional equipment, so I am not sure if the things I can tell from there are really valid for all ASI equipment. However, as from time to time questions come up concerning DekTec and other boards, at least some basic support for ASI seems to be desirable. So, coming to the facts, our ASI frontend gives these as "statistics": - BER - sync status - 204 or 188 byte/packet mode [...] > Since it is an IOCTL call straight away within the V3 API, i would like > to push this into the frontend thread where it is submitted as a job > kind of thing, where the userapplication can be notified in what > timeframe, or via GET_EVENTS, final details can be left out for the last > stage. This sounds very reasonable for me. I have no idea yet how this frontend thread is handled now, but after all all necessary information should be present there (e.g. lock state, to do a proper reset of averaging etc.). > Scale for BER is one thing that is still open ended, which i am off > hook. I need to still check on this, but if you have some ideas would be > nice. Hmm... I am not sure what is needed by others, so my voice should not be given too much weight here. We always use 10^-8 as the base, but for some equipment this might already be too rough. On the other hand, IIRC some demodulators do not return more accurate values anyways. > Signal Strength & SNR: > > In reality we can provide 2 ways for the same, > 1) Relative scale > 2) a scale in a decibels > > Even with Reverse Engineered drivers we can do 1) but for 2) we might > need more info. The user could probably select what he needs using an > IOCTL, relative or an absolute scale. For the relative one we can just > define a floor and ceiling and a relative value is extracted out. That is what I was thinking of, for most applications this would be sufficient. I do not know what is the better solution here. Following your proposal of two different styles of return values makes life easier for the application (which could request the "scale" type and just take this value). Even knowing the exact decibel value would make it necessary to interpret it differently for different transmission schemes, i.e. 8 dB SNR in DVB-S is no problem while there would be no reception in DVB-C... On the other hand it might be confusing to get different values for the same thing, which I treat as an argument for my proposal of always (if possible) returning the dB value and giving the application (and user) the demod min and max values for drawing a nice percentage scale. For a few demods I could provide the dB calculation (namely STV0299, STV0288, TDA10046, TDA1002x), but probably these are those with fewest problems anyways. For others (e.g. STV0297) there seems to be no calculation possible, I know of other implementations using a look-up-table. If needed, I could do some measurements and see if we manage to get good results with a look-up-table, too. > know anything. In some cases people would like to get the absolute value > for some instrumentation reasons. It makes comparison of different frontends/setups easier, too. At least in some forums people try to compare their dish and stuff with this, so not only addicts like us might want to see these values. ;-) [Sorry for deleting your most interesting part about silicon tuners - I have not had my hands on one yet, so cannot comment] > > I understand floating-point is not possible in the kernel, but what > > other possibilities are there to get rid of the device-dependent snr > > calculation in the application? Please, no debate about complete user-space > > driver here! I really hope there are other solutions, but I have no idea > > what is possible. > > > Currently we have a log10 implementation in dvb-core in dvb-math.c We > can use this for the same, but we will still need some careful hand > crafted integer calculations, complexity depending upon the hardware > itself, since it is vendor specific. This also requires that one must > have proper specifications for the devices for this to be done. This is good news! I will have a look at current implementation and see if I can play with it a bit (to test how my above mentioned calculations fit here). There will definitely be some re-work be necessary, because up to now I used float calculations w
Re: [linux-dvb] DVB API update
On Sunday 16 September 2007, Rainer.scherg wrote:
hi rainer,
> Manu Abraham schrieb:
>
> >
> >> - a "user structure" for hardware specific data (e.g. retrieve
> >> special data from a special frontend chip would be nice.
> >> this should be optional (*NULL = not used or not implemented).
> >> otherwise something like:
> >>struct { char[xx] hw_info;
> >> specific data...
> >> } *;
> >>
> >
> > Sounds good. In a tangent thought, in many cases when a special chip is
> > used sometimes there is an overall change in the hardware design.
> >
> > In such a case, do you think, that if we abstract such an info, out as a
> > part of as a new object such as an adapter object, (such that more
> > information can be passed out clearly) would be a better approach,
> > rather than shoving everything we have into the frontend object ? (where
> > the adapter object becomes the parent object for all others)
> >
> > Though i must say, that the frontend specific should be in the frontend,
> > but the adapter object could get the frontend specific information as a
> > part of it's own and present to the application. Though, you will be
> > able to query the frontend related information alone also, for carrying
> > around shorter chunks of data if the user wants to have only a small
> > subset of the information.
>
> I did not made any deeper thoughts on how this could be implemented
> best. What was the reason of this idea:
>A university asked me some times ago, to enhance dvbsnoop to output
>more detailled error reporting data than SIG, SNR, BER, UBLCK for
>a specific frontend (DIBCOM3000).
>
> In this case it was related to the frontend. As you stated, a special
> object might be more useful and more flexible.
>
>
> >
> >
> >> - API 3 is missing a a function for retrieving current frontend
> >> settings (e.g. on SAT LNB settings). It would be sufficient, when
> >> simply the last parameters set are returned.
> >> Currently on API3 a "second dvb application" can change the frontend,
> >> whithout any chance for the "main dvb application" to detect this
> >> easily.
> >
> > the dvb-core saving away the last successful LOCK state, will this help
> > ? But in any case, the second application if it successfully lock's,
> > then this would change logically, since this becomes the
> > previous-previous successful locked state.
> >
> > Is that what you meant, guess i didn't follow you correctly.
>
> Following scenario (SAT):
>Application 1 tunes device 2:
> to freq 1234.567 MHz, V, HiBand, SAT "2", etc..
>Application 2 tunes device 2:
> to freq 1000.123 MHz, H, LoBand, SAT "1", etc..
>
> Currently application 1 has no chance to query the current
> frontend settings.
from my pov it would not be allowed to have application 2 tune to a different
transponder if application 1 still uses it.
and, where is the deep sense in this situation?
app 1 tunes to 1234
app 2 tunes to 1000... and therefore destroys app 1`s data
app 1 checks periodically (via get current tuning param),
if everything still is fine,
the result is this case is no, so app 1 would maybe
try to retune to 1234-- and app2 would check and try to retune to 100
i cant see sense in your example at all.
where i can see the sense is, to query a frontend to get back the actual
frontend settings,
but your example has a totally different problem.
>
> In a first step, a simple "query current frontend
> settings" (last set data) for a device would be sufficient.
> In a second step (future APIs), one could think about notification
> by event handlers.
which notification? a userspace application should free a frontends usage, if
is no longer
using it. am i wrong?
> I also would ignore the LOCK state and always save/return the last
> set parameters.
what do you mean with ignoring a LOCK state? also return frontend settings, if
no LOCK
has been done on those? if that is your point, i am ok for that.
regards
marcel
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AF9005 remote control
El Sun, 16 Sep 2007 15:37:33 +0200 "Moisés Pérez" <[EMAIL PROTECTED]> escribió: [please keep this on the list] > 2007/9/15, Luca Olivetti <[EMAIL PROTECTED]>: > > > > En/na Moisés Pérez ha escrit: > > > > >> Searching on luca's web, I found a new Readme.lirc and a > > >> af9005-lirc.c. I tried build it as readme says and I got lots of > > >> make errors: > > >> > > > >I've modified the Makefile in correct folder and added the flag > > > >"-I/usr/src/lirc-0.8.1/", just where I've decompressed the lirc > > sources. > > > > >At the time I tried it with lirc 0.8.1 and lirc-0.6.6, so it > > >should work > > > I could compile it!! The Include was -I/usr/src/lirc- 0.8.2/, not > -0.8.1 I erased the original module af9005-remote and put the new > lines in Makefile.The compilation was succesfully. > > >> > > >> I have any questions: > > >> 1 - the dvb-usb-af9005-lirc module (if i can compile it) will be > > >> as a module of lirc defaults?? how is it used?? > > > > >the module replaces the standard one (so make sure the standard one > > >isn't found/loaded). The "standard" modules supplied with the > > >driver decodes the ir code of a couple of remotes: the one I got > > >with my card and one of another user. The "standard" modules > > >emulates an input device (like all other remotes in linux-dvb do, > > >since most devices don't give you the complete ir stream but > > >decode it themselves in firmware): if it works you should try to > > >press e.g. "1" and you should see a "1" on the console like you > > >typed it on the keyboard. OTOH the lirc module doesn't try to > > >decode the ir, but just massages it in a format that lirc > > >understands, so you can use it like a lirc homebrew receiver. > > > Now I can understand it. If I use the provided remote module, It > would have to work writing in console as a input device (I have > another remote recognized as HID usb that works so) yes > But after compiling, dmesg insert the correct modules: > $dmesg: > [ 6912.376000] DVB: registering new adapter (Afatech DVB-T USB1.1 > stick) [ 6912.384000] DVB: registering frontend 0 (AF9005 USB > DVB-T)... [ 6912.384000] input: IR-receiver inside an USB DVB > receiver as /class/input/input10 IIRC this message comes from the dvb-usb infrastructure when using the standard module, not the lirc one (but I may be wrong, it's been a while since I did this) > [ 6912.384000] dvb-usb: schedule remote query interval to 200 msecs. > [ 6912.384000] dvb-usb: Afatech DVB-T USB1.1 stick successfully > initialized and connected. > > $ modprobe -l | grep af9005 > /lib/modules/2.6.20-16-generic/kernel/drivers/media/dvb/dvb-usb/dvb- > usb-af9005.ko > /lib/modules/2.6.20-16-generic/kernel/drivers/media/dvb/dvb-usb/dvb- > usb-af9005-lirc.ko > > the module is charged!! > > >> > > > >2 - the remote module charged with v4l-dvb standards modules > > > >doesn't work?? Can't be used with lirc or another way?? > > > > >It can be used with lirc but I lost the link where it explains how > > >to convert the input device to a lirc device. Note that with the > > >"standard" method it only recognizes the supplied remote anyway, > > >so it's of limited use, while my alternative lirc module should > > >work with any remote (once you configured it with irrecord). > > > Now, with the af9005-lirc module charged, is it recognised as > /dev/input/event10, but it doesn't be: no, with the lirc module you should configuire it with irrecord and use it with lircd, see the lirc documentation > > b$ ls /dev/input/e* > /dev/input/event0 /dev/input/event3 /dev/input/event6 /dev/input/event9 > /dev/input/event1 /dev/input/event4 /dev/input/event7 > /dev/input/event2 /dev/input/event5 /dev/input/event8 > >I've read about "inputlirc" for configure lirc with the inputs > from a device recognized as a device input (when it's a IR one). > Either I can't make it work > >¿How have to be used the af9005-irc module?? > > >> > > >> 3 - dmesg seems to recognize the IR-receiver inside of USB DVB > > receiver > > >> as /class/input/input11, can be lirc configured to use it?? On > > >> README.lirc he said he have a serial IR receiver, but can we use > > >> lirc with the IR-receiver inside of dongle?? > > > > >if you want to use it with any remote, make sure the standard > > >module isn't loaded and load the lirc one. Then look at lirc > > >documentation on how to use it. > > >OTOH if the standard remote is enough for you, try to see if the > > >standard module works. If it does, you just have to configure your > > >software to use the input device, if it doesn't probably your > > >remote is different and we can try to discover its codes to put in > > >the driver > > table. > > > As I could understand, the standard module, if working, I could type > in console directly with it. Using the new if9005-lirc module, I > could use any remote with the receptor inside the dongle. Now only > I have available the receptor's remote control, then, I
[linux-dvb] DVB-C developers interested in receiving an USB adapter for hacking?
Hi, I've access to one unused Anysee E30 Plus DVB-C USB adapter, which is useless to me without Linux support. Is there anyone eg. in Europe who'd be willing to receive the adapter by mail and thinks he/she could possibly put together a support (eventually)? The card info page is at http://linuxtv.org/wiki/index.php/Anysee_E30C_Plus , guesses that it'd similar in hardware to what cxusb supports are by mkrufky. I've put (already a few months ago) USB snoop data and other stuff at http://iki.fi/tjyrinki/anysee_dvb-c for anyone to view. I'm asking since I doubt I still have time to try/learn enough myself, and would be happy to aid anyone interested in hacking. It's apparently quite popular model, the availability of DVB-C USB adapters being very limited (I don't know other available choices besides Technotrend C-1100/C-1200 USB and Anysee's). -Timo ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Genius TVGo DVB-T02Q
Hello, I'm investigating status of this DVB-T tuner support. I've found some discussions about it in the archive, namely these two threads http://www.mail-archive.com/linux-dvb@linuxtv.org/msg20295.html http://www.mail-archive.com/linux-dvb@linuxtv.org/msg24248.html but I still can't get it to work as the repository http://linuxtv.org/hg/~mkrufky/megasky is not available anymore - I'm using 2.6.22 kernel and the experimental patch does not fit. The device I've received might be a little bit different, as the idProduct is 0x7040 and not 0x702b as in the patch. What is the current status of this patch? thanks Tomas lsusb -v output - Bus 001 Device 002: ID 0458:7040 KYE Systems Corp. (Mouse Systems) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0458 KYE Systems Corp. (Mouse Systems) idProduct 0x7040 bcdDevice0.01 iManufacturer 1 Genius iProduct2 DVB-T02Q MCE iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 50 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 63 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] MSI TVanywhere A/D is still not auto detected in 2.6.22.5
Hi, The MSI TV (at) nywhere A/D [4e42:3306] is still not auto detected in 2.6.22 series kernels. It works with the option "card=94". (It is a clone of the LifeView FlyDVB-T Hybrid Card [5168:3306,5168:3502].) It is different from; the TVanywhere Plus, the TVanywhere Duo (a LifeView FlyDVB-T Duo clone), the TVanywhere Master and the TVanywhere. Possibly off topic... Could the file linux/Documentation/video4linux/CARDLIST.* have clone names on a different line such as, 94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502] MSI [EMAIL PROTECTED] A/D [4e42:3306] Even further off topic... Parameters can no longer be passed to modules in /etc/modprobe.preload. Mine had "saa7134 card=94" in it. That does not work anymore with recent kernels. It is necessary to put "options saa7134 card=94" in /etc/modprobe.conf, or maybe in one of the modprobe* directories. TIA -- sig goes here... Peter D. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Hi,
Rainer.scherg wrote:
> Some quick thoughts:
>
> - the new API should support the DVB API v3.x as an "API layer".
> Otherwise it will take a long time, to get most dvb applications
> running on the new API, which would make it hard to replace the
> current API.
>
We can have compatibility with the V3 API, that's what you meant ? I
guess so.
> - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when
> distributing binaries (one of the bad things on linux are
> incompatible API changes over time).
> A simple major.minor version number check will IMO do.
Right.
>
> - a "user structure" for hardware specific data (e.g. retrieve
> special data from a special frontend chip would be nice.
> this should be optional (*NULL = not used or not implemented).
> otherwise something like:
>struct { char[xx] hw_info;
> specific data...
> } *;
>
Sounds good. In a tangent thought, in many cases when a special chip is
used sometimes there is an overall change in the hardware design.
In such a case, do you think, that if we abstract such an info, out as a
part of as a new object such as an adapter object, (such that more
information can be passed out clearly) would be a better approach,
rather than shoving everything we have into the frontend object ? (where
the adapter object becomes the parent object for all others)
Though i must say, that the frontend specific should be in the frontend,
but the adapter object could get the frontend specific information as a
part of it's own and present to the application. Though, you will be
able to query the frontend related information alone also, for carrying
around shorter chunks of data if the user wants to have only a small
subset of the information.
What do you think ?
> - enum dvb_fe_modulation {
> DVB_FE_QPSK = (1 << 0),
> [...]
> DVB_FE_QAM_256 = (1 << 5),
> DVB_FE_QAM_AUTO = (1 << 6)
> };
>
> better would be something like this:
> DVB_FE_QAM_AUTO = (1 << 15)
> so, we have some space for future extensions...
True, this can avoid a dummy parameter, since we would like reserve this
space.
> - API 3 is missing a a function for retrieving current frontend
> settings (e.g. on SAT LNB settings). It would be sufficient, when
> simply the last parameters set are returned.
> Currently on API3 a "second dvb application" can change the frontend,
> whithout any chance for the "main dvb application" to detect this
> easily.
the dvb-core saving away the last successful LOCK state, will this help
? But in any case, the second application if it successfully lock's,
then this would change logically, since this becomes the
previous-previous successful locked state.
Is that what you meant, guess i didn't follow you correctly.
Thanks,
Manu
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Userspace tuner
On Saturday 15 September 2007 18:58:34 Bernard Jungen wrote: > On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote: > > With respect to your kernel-userspace API for xc3028, you made > > something that seemed to be a dream: there's a consensus: not a > > single developer believed that this is the better way; nobody seems > > that this is the better approach. > > > > So, or you are the only media developer with good sense in the face > > of the Earth, or you're incapable of understand the obvious: you're > > wrong with this approach. IMO, the answer is quite obvious. > > Yes, as a newbie observer on the v4l list, the answer is obvious to > me, at last, and the reason is not entirely technical. I can't read > so many bogus arguments on so few lines without reacting. > > Rephrasing Mauro: > > "Not a single developer out of a few SEEMS to believe that it is the > BETTER approach, so since the FEW represent ALL media developers in > the world, and since there is only ONE RIGHT way to do things, and > since the GROUP is always RIGHT and always knows better than the > individual, then YOU're WRONG and I'm right. Conform to the group and > do as the group says, whatever the consequences!" > > Geeks are decidedly as prone as others to blindly accept travelling > on the slippery road of herd mentality and "obvious" conclusions > based on appearances. Is this OPEN source development or a > dictatorship or what? It's called peer-review. It's why the linux kernel is as good as it is today. Yes, the tuner belongs in kernel-space. I'll use the user-space version from Markus in my ivtv driver as long as there is no alternative, but as soon as the same tuner is merged in the kernel I'll switch to that one. Why? Because the end-user shouldn't have to install a userspace daemon just to support a stupid little tuner. I've said this before, and I'll say it again: the sole reason for this mess is personality clashes. Technically it should have gone in two years ago. I worked two years on getting the ivtv driver (and supporting i2c drivers) merged into the kernel, in the process of which many V4L2 (and a few DVB) API additions and refinements were made, all by working with the core developers. The end result was much better than if I would have done it all by myself. It can be a difficult process (it's always hard to accept that the other person is right), and sometimes it means you have to sleep on it for a few nights before you realize that you are wrong and the other person is right. It can also go the other way, but even then it helps you because it forces you to express the technical reasons why you are right. And that gives you a better understanding of the issues at stake. > So in the end Mauro will be right. And Markus will continue to > develop and defend his stuff as HE sees fit. He knows his own work > better than anyone else. It will be HIS way or nothing with his own > stuff, it's his inalienable right. You're never alone. You work within the kernel framework and within the v4l-dvb framework. You want to get something done, then you'll have to work together. The linux project is no different there then working for a company. And no, Mauro isn't always right. But just saying 'I'm right, you're wrong' never helps. Never, ever. Arguing your case based on technical arguments is the best way to go. Always remain respectful with whomever you're arguing, always remain polite. The time for rational arguments in this situation has long since passed, unfortunately. > And don't be naive, if there's no solution more viable than Markus' > one, then the latter will eventually be widely adopted somehow, > sometime, whatever the amount of grumbling from the establishment. No > dictatorship/forced consensus can decide future's direction, nor > improve its already low own viability. Sigh. Hans ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DViCO Fusion DVB-T Dual Express
Hi DVB List, This is another one of those "will this card work" emails.. Im asking because the wiki has no info on it (other than it exists). The wiki also states that "Currently, only the Conexant CX23885 IC family has published drivers from LinuxTV" which according to DViCOs site the Dual Express has.. I'm not so sure about the tuner as its only listed as an "Xceive" but I have seen at least one of these in the tuner list.. I just wanted to know if this has any chance of working before I go out and get one (Ive run out of PCI slots). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] WinTV-HVR-1600MCE
Greetings, I am new to linux and have a WinTV-HVR-1600MCE card. I understand this is not currently supported. I checked the list archives but did not see anything about this card. I was wondering if I could do anything to help get this card supported. I do not have any experience writing drivers but i can get any information from my system that anyone might need to make this work. Tom F. Rochester, NY ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
