On Mon, Sep 17, 2007 at 06:02:50PM +0200, Johannes Stezenbach wrote: > On Sat, Sep 15, 2007, Wolfgang Wegner wrote: > > > > - dvb_fe_type: DVB-S2 is missing and I personally would also like > > to see ASI here... > > See my other mail, IMHO we should add the ASI defines at > the same time we merge a driver which uses it. Well, on the other hand this can prevent from others (hardware vendors?) to have a deeper look into the linux-dvb api because it does not even care about ASI. Again, I think the "dummy" frontend approach from Manu could be a viable solution, but you should have the possibility to add a basic frontend with minimal status information (lock/no lock) without much headache. > > - frontend status: > > - BER is lacking a proper definition (to which base is it calculated?) > > - signal strength: same problem, what are the ranges? > > - snr: again, no base and ranges given > > The original Nokia DVB API spec had proper definitions, but > Holger Waechtler and me decided to drop them in favour of > "read hw register and scale to range 0..0xffff". The reasons > for this were: > - for some hw we didn't have info to implement it properly > - for those hw where we had info we saw it wasn't worth the > effort -- I believe the implementation in the demod firmware > is just such a coarse approximation that it doesn't > even make a difference if you take the logarithm or not > (provided you scale back into the 16bit range) > (of course you get different numbers, but none of them > maps any better to what you'd expect) [...] I do not have info about much hardware, all I can say is that BER and SNR work quite good with STV0299, STV0288, TDA10046 and TDA1002x. This is reason enough for me to raise the hand for voting for an interface that at least gives the possibility to implement this in the demod driver. (I have to admit that you have to use some basic averaging, but if this could be handled in some kind of frontend thread, I see no problem. I will see how this can be implemented without floating point calculation, because up to now this was done on another platform where floating point was not an issue.) The main reason to do this is because this is the only place where it _can_ be done! The application accesses the demod through the API and does not know anything about its registers or anything, neither should it. BTW, the "scale to range 0..0xffff" does not seem to be true for all demods (at least this is what I remember), and at the very least, this scale and direction (0 = best or worst?) should be clearly stated in the API! >From my point of view and taking into account your arguments, the main problem is: how could one implement such an interface in a backward-compatible manner and such that an application can see if the demod it currently uses does return precise values (that can be displayed as dB or something like that) or not, because there may be demods where we really can not provide proper values or that simply nobody had the time to look at yet. Best regards, Wolfgang _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
