Hi, Wolfgang Wegner wrote: > Hi, > > how should this discussion take place? > Your valuable comments, whatever it is in a positive way can lead to a good discussion. :) Please don't remove the CC's. The CC'd people generally don't bother about mails from the ML, probably. > Up to now, my personal experience showed only some drawbacks in the > frontend API, and reading the current proposal v4_0.3 I have some > comments/questions concerning this part: > > - dvb_fe_type: DVB-S2 is missing and I personally would also like > to see ASI here... the multiproto update can handle S2, DSS, DVB-H possibly looking at DMB-T/H as well a while later. We can pull in ARIB from V4. We won't use V4 straight away as it is, it needs an overhaul as well. 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. > - 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 > > For signal strength and snr, I already wrote about a possible partly > solution: provide a means to query the frontend for corresponding min > and max values (in dvb_frontend_info?). Some of the aspects that my hands were itching to fix was statistics. Currently in all the API's we have, with regards to BER, we have an issue. BER is in fact averaged by the demod over a short period of time, with some amount of hardware specific computations. This needs some time and is not available off hand. BER: V3 forces the user application to ignore the first few values of BER and do averaging. This a crude and a rough way of doing it. In fact since there is some amount of HW dependency for the same, the computation should be done by the demod only and not by the user application. The driver needs to make the computation in a short span. 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. 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. 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. The general user will naturally prefer a relative scale (something like say 0 - 100 ie percentage to make life simple) since he doesn't have to know anything. In some cases people would like to get the absolute value for some instrumentation reasons. > > I know signal strength is very unreliable for most frontends (are silicon > frontends really better, as claimed from time to time?), but at least > the snr can be calculated very good for most demodulators. Would it be > possible to do this calculation somewhere "near the driver" to provide > a uniform value to the caller regardless of the frontend actually used? > One advantage about Silicon tuners is that the vendor can provide information on what it's characteristics would be: thus it is well defined. In the case of a PLL with discrete components: difficult as there are RF stages involved in the picture. In the case of a discrete tuner, each vendor can make their specific changes which will make changes to the Input gain Noise floor etc, and hence might not be very accurate unless you get specific information from the "metal can" vendor. In many cases even from the metal can vendor this information is missing. The disadvantages of Silicon tuners is that generally they get heated up fast, once heated up this results in thermal instability and or additional noise reducing SNR a bit at least. For the first generation Silicon tuners this has been a curse for which there exists no solution. Some people provide solutions for this by reducing the gain for the silicon tuner when unnecessary, since with a reduced gain, the tuner has a lesser dissipation, but this is not a very effective method as it brings in only a very small change. Nothing large that we can consider. In reality it is a hard choice, some vendors still provide a metal can tuner and advertise as a premium product because of the disadvantages with the silicon tuners. That said silicon tuners are improving from generation to generation. The third generation devices have almost little dissipation, the third generation devices being used in portable devices and hence dissipation has to be kept low for all reasons such as power consumption, stability and reliability. I wrote that on another mail some time back. Checking.. Here it is: Also, it might be interesting to have a comparison between the dissipation on the various devices that we have support now (though not driver related), as dissipation is the culprit for thermal noise, and thermal instabilities on silicon tuners. XC3028: 300mA @5v = 1.5W MT2060: 370mA @3.3v = 1.221W QT1010: 300mA @3.6v = 1.08W MC44S802(3): 210mA @1.8v = 0.378W MXL5003(5): 165mA @1.9v = 0.3135W TDA18291: 54mA @2.8v = 0.1521W > 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. Thanks, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
