Quoting Holger Waechtler <holger@xxxxxxx>:
> Johannes Stezenbach wrote:
>
> >>unsigned int i20Log10(unsigned short val)
> >>{
> >> unsigned int rntval = 100;
> >> unsigned int tmp = val;
> >> unsigned int exp = 1;
> >>
> >> while(tmp > 100) {tmp /= 100; exp++;}
> >>
> >> val = (2 * val)/denom[exp];
> >> if(exp > 1) rntval = 2000*exp;
> >>
> >> rntval += i100x20log10[val];
> >> return rntval;
> >>}
> >>
> >>
> >...
> >
> >
> >> /* The value reported back from the frontend will be FFFF=100% 0000=0% */
> >> *strength = (((5334 - i20Log10(snr_equ))/3+5)*65535)/1000;
> >>
> >>
> >
> >This is kind of neat, but since none of the other frontends does it
> >I ask myself if we should either drop it, or factor it out into
> >dvb_frontend.c so the other frontends could use it, too.
> >
> >
>
> Since most demod specs don't provide the infos for a correct mapping for
> this conversion we changed the API from absolut values (v1 and v2) to
> relative values between 0x0000 and 0xffff (API versions v3 and later).
> You can simply pass these values the user space and remove the
> conversion code... most user space applications will map these values to
> a progress-bar-style widget anyways.
>
Isn't that essentially what this code is doing? (providing relative values
between 0x0000 and 0xFFFF) The log calculation provides relative values for
those that don't care and a % of a 30dB signal for those that do care. I don't
think we should remove value from those cards that can provide information
simply because "most cards" can't or don't.
I'm not sold on factoring it out to dvb-frontend unless there is another card
that wants it outside of the HD2000 and HD3000. These cards are from the same
manufacturer and use similar demodulation chips, so naturally they would use
the same functions. My personal preference is to factor the code at the third
duplication.
I will provide a "clean-up" patch with the rest of Johannes' suggestions but for
now will leave the strength code where it is.
Rusty
