Em Thu, 17 Jan 2013 11:33:46 +0200
Antti Palosaari <[email protected]> escreveu:
> What goes to these units in general, dB conversion is done by the driver
> about always. It is quite hard or even impossible to find out that
> formula unless you has adjustable test signal generator.
>
> Also we could not offer always dBm as signal strength. This comes to
> fact that only recent silicon RF-tuners are able to provide RF strength.
> More traditionally that estimation is done by demod from IF/RF AGC,
> which leads very, very, rough estimation.
>
> So at least for the signal strength it is impossible to require dBm. dB
> for SNR is possible, but it is very hard due to lack of developers
> knowledge and test equipment. SNR could be still forced to look like it
> is in given dB scale. I think it is not big loss even though SNR values
> reported are a little bit wrong.
>
>
> About half year ago I looked how SNR was measured every demod we has:
>
> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
>
> as we can see there is currently only two style used:
> 1) 0.1 dB (very common in new drivers)
> 2) unknown (== mostly just raw register values)
It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
they can't converted into any of the supported scales.
Btw, as agreed, on v11:
- dB scale changed to 0.001 dB (not sure if this will bring much
gain, as I doubt that demods have that much precision);
- removed QoS nomenclature (I hope I didn't forget it left on
some patch);
- removed DTV_QOS_ENUM;
- counters reset logic is now driver-specific (currently, resetting
it at set_frontend callback on mb8620s);
I'll be posting the patches after finishing the tests.
What's left (probably we need more discussions):
a) a flag to indicate a counter reset (my suggestion).
Does it make sense? If so, where should it be? At fe_status_t?
b) per-stats/per-dvb-property error indicator (Devin's suggestion).
I don't think it is needed for statistics. Yet, it may be interesting for
the other dvb properties.
So, IMHO, I would do add it like:
struct dtv_property {
__u32 cmd;
__s32 error; /* Linux error code when set/get this specific
property */
__u32 reserved[2];
union {
__u32 data;
struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));
A patch adding this for statistics should be easy, as there's just one
driver currently implementing it. Making the core and drivers handle
per-property errors can be trickier and will require more work.
But I'm still in doubt if it does make sense for stats.
Devin?
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
