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 doesn't specify what base it is anywhere. I will verify this. I think we can convert all to one format, where the lower resolution ones are upscaled or vice versa. > >> 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 without much thinking... > FPU usage in kernel is devastating. A while back while i was working on double precision calculation is kernel, i happened to ask Akpm for a suggestion, what he thought on the same. This was what he said on FPU usage: "Nothing clever, really. Float in-kernel doesn't work. It may _seem_ to work, but then you find that the kernel corrupts userspace fp state under mysterious circumstances. Surely 64-bit integers have sufficient precision. It'd be a matter orf managing the binary point, normalising when needed.." Regards, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
