On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote:
Em Thu, 17 Jan 2013 11:33:46 +0200
Antti Palosaari <crope@xxxxxx> 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
There is one issue what I now still think.
dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
For me this looks like uncorrected errors are reported as a rate too (as
both error count and total count are reported to app). But that is not
suitable for reporting uncorrected blocks! It fits fine for BER, but not
UCB. If UCB counter is running that fast then picture is totally broken.
Behavior of UCB should remain quite same as it is currently, increases
slowly over the time. If you start resetting counters as for BER then
UCB is almost all the time 0. User wants to know UCB errors in frame of
days rather than minutes.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
