43 replies to this topic

[Alias1]

Yuo are all wrong
http://sss-mag.com/ebn0.html

[littlesat]

I'm not wrong... If we had this BER from this document then you were right.......!!! I know everything about BERs as I created the improved BER for PLi for E1.... For E2 I was never able to make it as I did not have the right specs and even I do not know if this is possible.... The BER we get in all E2 boxes has in fact no added value!!!!!

But you did not read... If you find a good way to present it nicely... I can consider to put it back....

Edited by littlesat, 2 December 2011 - 16:35.

[Erik Slagter]

Let's start with AGC, I've seen someone mention as "useful information". Do you know what AGC means? It's Automatic Gain Control that is a circuit in the tuner that amplifies the incoming signal to a level that's optimal for demodulation. Strong signals need little amplification, weak signals need a lot. This also means that the strength of a signal is of no importance at all, is regulated by the AGC to an optimal level anyway. Also this means that for a strong signal, the AGC would be "low" and for a weak signal the AGC would be "high". Unfortunately every tuner manufacturer and every receiver manufacturer gives it's own interpretation on AGC so the data is essentially useless. The DVB-S2 tuner on my dm800 gives a max AGC (99%) on no reception, somewhat lower AGC value on a too weak signal and jumpy AGC on reception of "some" signal it can't handle. When lock has been achieved, the AGC is always on 99% so the value it really useless.

There is no information in the exact number of the BER value. The only information would be whether it's zero or not. Most of the time you will notice when BER is not zero.

So that leaves the SNR as being the only real informative data. As long as there is lock and the SNR is below 100%, the SNR value is always sufficient information for dish configuration. I've actually managed to achieve 100% SNR on a few transponders, but then the value in dB's can still rise for even better reception.

[ambrosa]

1) in a perfect world you are right. And DVB-S/S2 in E2 decoder usually is perfect: you have all infos and SNR is enough. I agree with you.
But I've opened this thread because USB DVB-T driver world is far to be "perfect".
Almost all DVB-T driver lacks some infos about signal quality and usually there is not SNR, only AGC and/or BER

I.e. Avermedia A867: since yesterday the driver output only BER value: SNR always =0 and AGC always =100
So BER was the only info that users can check to have some indirect value about signal quality.
Yesterday I've patched A867 driver (see my other post) and now A867 output also SNR (and BER, no AGC fixed to 100). Good.

But other most used drivers have not SNR (i.e. Nova-T stick) . Is common that DVB-T driver output only BER or AGC (signal strength).

For this reason I've asked to you to show SNR,AGC,BER in upper second infobar : to help DVB-T users to have a feedback about their terrestrial signal. If driver don't output SNR (common) user can check BER or AGC
I like very much Pli-HD skin and I'm happy that now is the OpenPli default skin.
But since Pli-HD is default skin, in my personal opinion it must have a more "general" behaviour, good for sat and good for terrestrial (and cable)


2) BER and AGC are available in E2 since years ago. Values can be simply fetch from FrontendInfo.py
http://openpli.git.s...07dfa1d;hb=HEAD

This is an example taken from Infinity_HD skin.xml : I see on OSD correctly SNR,AGC,BER numeric values without any problem.
I suppose it is very simple add SNR,AGC,BER numeric values into PLiHD second infobar skin.xml in upper right corner and show to user something like:

SNR: 99%
AGC: 100%
BER: 122
or
SNR: 99% AGC: 100% BER: 122 -> all in one row

	<widget source="session.FrontendStatus" render="Label" position="237, 610" size="64, 22" font="Regular;18" halign="right" backgroundColor="black" transparent="1" foregroundColor="white">
	  <convert type="FrontendInfo">SNR</convert>
	</widget>
 
	<widget source="session.FrontendStatus" render="Label" position="458, 610" size="84, 22" font="Regular;18" halign="left" backgroundColor="black" transparent="1" foregroundColor="white">
	  <convert type="FrontendInfo">AGC</convert>
	</widget>
 
	<widget source="session.FrontendStatus" render="Label" position="598, 610" size="70, 22" font="Regular;18" halign="left" backgroundColor="black" transparent="1" foregroundColor="white">
	  <convert type="FrontendInfo">BER</convert>
	</widget>

Best regards.

[Erik Slagter]

I think I have a much better solution. If the SNR value is zero (due to BUGGY driver or hardware), then, and only then, show the BER value as workaround.

[ambrosa]

Let's start with AGC, I've seen someone mention as "useful information". Do you know what AGC means? It's Automatic Gain Control that is a circuit in the tuner that amplifies the incoming signal to a level that's optimal for demodulation. Strong signals need little amplification, weak signals need a lot. This also means that the strength of a signal is of no importance at all, is regulated by the AGC to an optimal level anyway. Also this means that for a strong signal, the AGC would be "low" and for a weak signal the AGC would be "high". Unfortunately every tuner manufacturer and every receiver manufacturer gives it's own interpretation on AGC so the data is essentially useless. The DVB-S2 tuner on my dm800 gives a max AGC (99%) on no reception, somewhat lower AGC value on a too weak signal and jumpy AGC on reception of "some" signal it can't handle. When lock has been achieved, the AGC is always on 99% so the value it really useless.

There is no information in the exact number of the BER value. The only information would be whether it's zero or not. Most of the time you will notice when BER is not zero.

So that leaves the SNR as being the only real informative data. As long as there is lock and the SNR is below 100%, the SNR value is always sufficient information for dish configuration. I've actually managed to achieve 100% SNR on a few transponders, but then the value in dB's can still rise for even better reception.

I can tell you about DVB-T driver: during these weeks I'm analyzing them to solve some problems.

Usually DVB-T drive map it's internal "signal strength" value to DVB API dvb_frontend_ops.signal_strength and E2 remap this value to its internal "AGC"
Probably DVB-S/S2 driver output the "real" agc and it's not useful. I agree.

But DVB-T drivers have a different behaviour and every driver made something different. It's a nightmare, I know !
So "AGC" become a signal strength from 0 to 100 .... and it's not the real AGC as you mean.. It's a double nightmare.

I repeat: I agree with you. In satellite world SNR it's enough BER and AGC are not useful.
But the world is not perfect.

And I've not feedback about DVB-C drivers behaviour. Here in Italy there is not DVB-C provider.

BTW: in Italy DVB-T is very common. People can tune about 300-400 channels on terrestrial.
So every user that buy an STB, he also buy a DVB-T USB stick (or two stick....)
For every E2 satellite receiver there is one DVB-T stick.

[ambrosa]

I think I have a much better solution. If the SNR value is zero (due to BUGGY driver or hardware), then, and only then, show the BER value as workaround.

SNR can be 0, 100 or any other fixed value. Driver dependent. It's difficult to check it.
And If I have SNR = fixed , BER = fixed and the only correct value is AGC ( that is not the "agc" but a signal strength, see above) ?

[Erik Slagter]

The way AGC is "misused" by these drivers, they should at least have followed the semantics of AGC and reverse the value, i.e. stronger signal is lower AGC-value...

Anyway, it's always a very tough decision how to handle drivers/hardware that do not adhere to standards. As soon as you start making exceptions for one, the next comes by and you'll end up with one big pile of ugly, error-prone code. I think you should at least try to communicate to the manufacturer that their driver is buggy and request to have it fixed.

[ambrosa]

Linux DVB-T drivers usually are NOT made directly by manufacturer but often they are made by reverse-engineering efforts from open source community.
And often they are a "mix" of code taken from different driver for similar stick.
STB world is NOT PERFECT, so there is need a good level of "flexibility"

BTW: I don't understand WHY is not possibile to have infos like screenshot attached below. Many skins have them.
Is a 6 lines patch, it's simple, no performance impact .... some user can found it useful ... why not ? Because "it's not following some standard ?"

[littlesat]

See the latest commit on http://github.com/littlesat

Edited by littlesat, 2 December 2011 - 19:23.

[pieterg]

The way AGC is "misused" by these drivers, they should at least have followed the semantics of AGC and reverse the value, i.e. stronger signal is lower AGC-value...

no, it's e2 which misuses the term AGC.
Most drivers provide 'signal strength' and 'signal quality' values.
The first is what e2 displays as AGC, the latter SNR.

[Alias1]

@littlesat
You mean like this ????

Attached Files

•  screenshot.png   511.92KB   63 downloads

[Alias1]

Even better.
Do I care if you use it no if you dont like it make your own

Attached Files

•  screenshot.png   461.4KB   72 downloads
•  skin.xml   149.91KB   9 downloads

[Alias1]

Edit line 344 snr and line 351 agc to suit your location of png files

Attached Files

•  Icons.rar   2.91KB   8 downloads

[Erik Slagter]

If these reverse-engineered drivers are produced by the open source community, then it's even easier to fix them!

[ims]

I think, Littlesat's solution is enought. I dont like next bars on infobar, better is place it to 2nd infobar. Info about softcam could be moved to 2nd infobar too, imho.

[littlesat]

I leave it the way it is now.... Please not on the normal zap screen... and not as ugly as presented in these screenshot... Especially on the normal zapscreen I wanted to keep it as quit as possible... Putting SNR/AGC progress bars there makes it restless... and usually the number is enough...

Everyone is still welcome and should be feel free to create his own derived skin based on the PLi-HD skin.... and put some sources e.g. on github.com...

Edited by littlesat, 3 December 2011 - 11:58.

[ambrosa]

I've just recompiled latest Pli (I was out for week-end)
Nice !

In second infobar I've all infos I needed.

With Avermedia A867 DVBT I have
SNR OK
AGC OK: range from 50% to 99% (remember that really this is "signal strength" and not a real "agc")
BER: 0 or more

Parhaps AGC can have a bar like SNR but is not mandatory.
Sure BER doesn't need any bar.

Really, I've not used the bar also for SNR. Only 3 text values in one row. But in this way is nice.


Thanks.

BTW: probably I've discovered a bug (?) in CT9100 satellite tuner driver: AGC is always 0 (???)

Edited by ambrosa, 4 December 2011 - 18:47.

[littlesat]

BTW: probably I've discovered a bug (?) in CT9100 satellite tuner driver: AGC is always 0 (???)

This is in fact not a bug... As the ET tuners do nog give an AGC value.... this demonstrates the nonsense of having AGC there as the SNR should be enough...

I also discover that some USB-DVB-T tuners do not have a SNR, but only AGC... I'm considering in "swapping" the SNR and AGC in case the SNR is zero... -or- overrule the SNR by the AGC in case the SNR is 0%... so you'll always have an valuable indication of the signal during normal zapping...

Edited by littlesat, 4 December 2011 - 20:36.

[ambrosa]

This is in fact not a bug... As the ET tuners do nog give an AGC value.... this demonstrates the nonsense of having AGC there as the SNR should be enough...

OpenPli runs on 20 different types of STB.
Probably in other STB different than ClarkeTeck ET9x00 driver is ok and AGC/BER are OK.
Anyway with some DVB-T stick, AGC/BER are working fine.

I also discover that some USB-DVB-T tuners do not have a SNR, but only AGC...

.....or only BER.
I've said to you many times before: every DVB-T driver has its own behaviour: some return SNR others not, some return AGC others not, some return BER othres not...
And some satellite driver (like ET9x00) doesn't return AGC .... others return it !

I'm considering in "swapping" the SNR and AGC in case the SNR is zero... -or- overrule the SNR by the AGC in case the SNR is 0%... so you'll always have an valuable indication of the signal during normal zapping...

BAD idea.
People get confused. SNR display a value. Is it really SNR or is it AGC ? And if AGC is always 0 and you have only BER ?
Developer get confused for the same reason: if I need to find a driver bug, the value displayed on OSD what is ?

Leave things as is: in my opinion now it's perfect.