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