SNR in dB

[BeMax]

Hello

Is it possible to get the SNR value in dB instead of "%" ? Tested

options tbsfe esno=1 into file
/etc/modprobe.d/tbsfe.conf

But still no SNR in dB when running szap...(after reboot)

[crazycat]

for this card used open-source stv090x demod drivers and this option not useful

[BeMax]

Ok, so the open source driver don't support SNR in dB ? Does it exist any conversion table between reported SNR value to SNR value in dB ?

[LubosD]

The TBS driver seems to be supplying made up SNR values. When I cover half of the LNB with my hand, the SNR values remain unchanged.

With different DVB-S cards, the values drop immediately.

[updatelee]

I've switched the stv090x driver to dB but it'll only work with my software. If you want to change it it's easy enough

UDL

[LubosD]

I've switched the stv090x driver to dB but it'll only work with my software. If you want to change it it's easy enough

UDL

Well, when I was using a cx23885-based card, it was sufficient to write a very simple wrapper around femon to convert data from the driver to decibels. Is it possible to accomplish something like that with your code?

It also seems that BER reporting in stv090x is broken. The numbers in the BER column belong to the UNC column.

[updatelee]

personally I think the whole % thing is one of the stupidest things Ive ever seen in the v4l tree. Such a royally asinine thing I cant fathom why they took an industry standard and destroyed it to the point its completely useless now. I intend to bring it up with the v4l mailing list just havent had time.

V4L way is take the current_db / (max_db - min_db) = register, register / 65535 = %, any relevent info is now lost, and a completely useless value is returned.

To keep the number semi relevent between old code and mine I chose

current_db * 10 * 256 = register,
register / 10 / 256 = db
register / 65535 = %

10.2db * 10 * 256 = 26112
26112 / 10 / 256 = 10.2db
26112 / 65535 = 40%

The other thing Ive considered doing is

65535 * (10.2db / 100) = 6684
6684 / 65535 * 100 = 10.2db
6684 / 65535 = 10.2%

So the userland apps not changed would at first glance apear to have terrible signal quality but would actually be displaying db.

The big problem is linus has stated very clearly that kernel changes can NOT break userland applications, even if the original decision to use % was stupid, he thinks we should be stuck with it till an API change happens, dvb APIv6 maybe? who knows.

UDL