Message ID | 790b5e1664c84e806a13143eff1c79b95fb4bf63.1467240152.git.mchehab@s-opensource.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
> add a new ops that will allow tuners to better report the > dB level of its AGC logic to the demod drivers. As the maximum > gain may vary from tuner to tuner, we'll be reversing the > logic here: instead of reporting the gain, let's report the > attenuation. This way, converting from it to the legacy DVBv3 > way is trivial. It is also easy to adjust the level of > the received signal to dBm, as it is just a matter of adding > an offset at the demod and/or at the bridge driver. Mauro, Have you verified this work with a detailed spectrum analysis study? If so then please share. For example, by measuring the I/F out of various tuners in a mix of use cases, with and without the AGC being driven by any downstream demodulator? Also, taking into consideration any external LNA variance. I'm concerned that a tuner AGC Gain is a meaningless measurement and in practice demodulators don't actually care, and tuners don't implement their gain reporting capabilities correctly at all. This feels like a solution to a problem that doesn't exist.
Hi Steven, Em Thu, 30 Jun 2016 09:48:30 -0400 Steven Toth <stoth@kernellabs.com> escreveu: > > add a new ops that will allow tuners to better report the > > dB level of its AGC logic to the demod drivers. As the maximum > > gain may vary from tuner to tuner, we'll be reversing the > > logic here: instead of reporting the gain, let's report the > > attenuation. This way, converting from it to the legacy DVBv3 > > way is trivial. It is also easy to adjust the level of > > the received signal to dBm, as it is just a matter of adding > > an offset at the demod and/or at the bridge driver. > > Mauro, > > Have you verified this work with a detailed spectrum analysis study? > If so then please share. For example, by measuring the I/F out of > various tuners in a mix of use cases, with and without the AGC being > driven by any downstream demodulator? Also, taking into consideration > any external LNA variance. > > I'm concerned that a tuner AGC Gain is a meaningless measurement and > in practice demodulators don't actually care, and tuners don't > implement their gain reporting capabilities correctly at all. > > This feels like a solution to a problem that doesn't exist. The role idea here is to provide a rough estimation about the signal strength, and not to enter into the measurement instrument business. I know that the actual tuner AGC gain is not precise[1]: - it may vary with the frequency; - it may vary with the component variance; - it may vary with modulation parameters; - it may vary with the temperature. Yet, the signal strength is used on some software to detect "weak" signals and skip such transponders. There is such code, for example in Kaffeine since 2009: commit 73a5aae68ab46d761267043c9774289833b79dbc Author: Christoph Pfister <christophpfister@gmail.com> Date: Sat Apr 25 13:41:28 2009 +0000 add autoscan support + if ((signal != 0) && (signal < 0x2000)) { + // signal too weak + carry = false; + } The color on Kaffeine's gauge gradient bar also tries to express if the signal level is OK or not, showing only red for weak signals, and becoming green as the signal increases up to a certain level. The strength is also one parameters to estimate the signal quality. The libdvbv5 considers it, when reporting DTV_QUALITY parameter. So, the hole idea here is *not* to provide a precise measure, but to try to use about the same scale on the drivers, whenever possible. Regards, Mauro [1] I would give a 5-stars here for Siano: on the tests I did, the signal strength reported by the siano devices is very precise. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/dvb-core/dvb_frontend.h b/drivers/media/dvb-core/dvb_frontend.h index 9592573a0b41..e8a4d341f420 100644 --- a/drivers/media/dvb-core/dvb_frontend.h +++ b/drivers/media/dvb-core/dvb_frontend.h @@ -227,8 +227,17 @@ enum dvbfe_search { * should return 0. * @get_status: returns the frontend lock status * @get_rf_strength: returns the RF signal strengh. Used mostly to support - * analog TV and radio. Digital TV should report, instead, - * via DVBv5 API (@dvb_frontend.dtv_property_cache;). + * analog TV and radio. This is deprecated, in favor of + * @get_rf_attenuation. + * @get_rf_attenuation: returns the RF signal attenuation, relative to the + * maximum supported gain, in 1/1000 dB steps. Please + * notice that 0 means that the tuner is using its maximum + * gain. So, a value of 10000, for example, means a 10dB + * attenuation. This is ops is meant to be used by + * demodulator drivers to estimate the maximum signal + * strength. For that, it will add an offset, in order to + * expose the signal strength to userspace via dvbv5 + * stats, in dBm. * @get_afc: Used only by analog TV core. Reports the frequency * drift due to AFC. * @calc_regs: callback function used to pass register data settings @@ -264,6 +273,7 @@ struct dvb_tuner_ops { #define TUNER_STATUS_STEREO 2 int (*get_status)(struct dvb_frontend *fe, u32 *status); int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength); + s32 (*get_rf_attenuation)(struct dvb_frontend *fe); int (*get_afc)(struct dvb_frontend *fe, s32 *afc); /*
add a new ops that will allow tuners to better report the dB level of its AGC logic to the demod drivers. As the maximum gain may vary from tuner to tuner, we'll be reversing the logic here: instead of reporting the gain, let's report the attenuation. This way, converting from it to the legacy DVBv3 way is trivial. It is also easy to adjust the level of the received signal to dBm, as it is just a matter of adding an offset at the demod and/or at the bridge driver. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> --- drivers/media/dvb-core/dvb_frontend.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)