[ViX_Misc] Signal Quality Values

[abu baniaz]

I tried simple ten eighty as well as ViX night hd.

Edit:
One is the standard skin for Vix, other is pre-installed on ViX

 

[abu baniaz]

TTL310 on Vu Solo 4k does not have identical values. The swap db/% does not have an effect.

 

[EMJB]

TTL310 on Vu Solo 4k does not have identical values. The swap db/% does not have an effect.

That seems to exonerate the skin, but leaves 2 questions:

(1)What is the swap db/% supposed to do?


(2) What is your SundTek tuner providing as both SNR% and AGC? In the absence of interference I would expect both to behave in a generally similar way to changing signal levels, but I find it inconceivable that they should always be equal to within 1%. Add some in-band interference and I would expect the AGC to go up and the SNR to go down, so the difference is important. I think one of your screenshots showed a common value of 25%, which would equate to an SNR dB figure in the low teens, which is too low to achieve lock. Hence it would seem likely that it is the AGC value that is being reported, but the only way to get a clearer idea would be to use the OpenWibIf AGC command to get the SNR dB figure as well for your strongest and weakest muxes.


EMJB

 

[abu baniaz]

I am not going to use openwebif to obtain any details. The values are in Enigma2, buried somewhere. If we need to adapt signalfinder to show the details, then that is what we will have to do.

 

[EMJB]

@abu baniaz:

I think you have misunderstood my suggestion.

Firstly, there is no need to modify Satfinder/Signal Finder to display the SNR as dB - it is a just a case of using the right skin content - e.g. as in the OpenVix default as shown in the attached screenshot.



Secondly I was only suggesting the use of OpenWebIf (which is merely a convenient way of extracting the information available, as you say, from Enigma) to collect near-simultaneous SNR dB, SNR %, and AGC data as a one-off exercise to try to:

(a) Help pinpoint the source of the problem, and someone to fix it. In particular I would like to rule out with 100% confidence that it is in no way connected to the changes I made to frontend.c

(b) Establish whether the use of your tuner type is likely to cause problems with TerrestrialScan and ABM frequency finder when multiple muxes are detectable.

Use of Signal finder with a skin that displays the dB value would be equally valid way of collecting the information, which might be more convenient.


EMJB

 

[abu baniaz]

What is your definition of "OpenViX default" with regards to skin?

 

[EMJB]

Apologies- I had forgotten I changed it many moons ago - I am using ViX-Night_HD


EMJB

 

[ccs]

I am easily confused, am I right in saying that ViX-Night_HD is the OpenViX default skin?

 

[birdman]

I am easily confused, am I right in saying that ViX-Night_HD is the OpenViX default skin?

IIRC, there is a default skin, and there is a skin which is set by default. These are not the same thing.
The former is really a set of fallback definitions.
The latter is set by "DEFAULT_SKIN = "ViX-Night-HD/skin.xml".

 

[abu baniaz]

My definition of Default_Skin is the one that is used when you have no skins. To avoid confusion, I call it "Emergency skin".

The "out of the box" skin is ViX Night HD.

Anyway, ViX Night HD was the same in my tests. I'll try the emergency skin later.

 

[abu baniaz]

Using a Sundtek, these were the details on 482 MHz. It was mainly on 100 but had the odd fluctuation that I seem to have caught

<e2frontendstatus>
<e2snrdb>96 dB</e2snrdb>
<e2snr>96 %</e2snr>
<e2ber>0</e2ber>
<e2acg>96 %</e2acg>
</e2frontendstatus>

With the PNP tuner these were the details on the same frequency

<e2frontendstatus>
<e2snrdb>100 dB</e2snrdb>
<e2snr>100 %</e2snr>
<e2ber>0</e2ber>
<e2acg>95 %</e2acg>
</e2frontendstatus>


Other various screenshots with names to explain what they are.

 

[EMJB]

@au baniaz:

The Sundtek figures show the same sort of problems as seen by ccs - most obviously the 96 dB SNR is too large to be plausible, and the associated % figure should be 100% if that were correct.

Perhaps of greater concern to me is that the PNP tuner looks as if it has similar problems, which might indicate that part of the problem lies in OpenVix rather than the drivers. Alternatively perhaps the two devices use the same chipsets and similar drivers.

EMJB

 

[abu baniaz]

which might indicate that part of the problem lies in OpenVix rather than the drivers.

I have tried OpenPLI and Pure E2. They are the same. Which image does not have this issue/problem? Please suggest it.

 

[EMJB]

@abu baniaz:

Again you are reading something into my words that I did not intend. When I said that part of the problem might be in OpenVix rather than the drivers, I meant just that, not that it didn't exist in other images.

A possible source of any problems that might exist in OpenVix is frontend.cpp. Please excuse my ignorance of the details of the relationships between images, but I understand that until fairly recently a common version of this file was used across several (or all) images, so it would not be surprising if similar problems exist in many images' versions of frontend.cpp (if they exist at all).

The ideal way forward would seem to me to be to generate a new version of the enigma file with additional logging in frontend.cpp. However the versions birdman helped me create were ~26 MByte, making it difficult to ask ccs to test these for us as email is the only way I have of sending him such files.

The only other experiment I can think of would be for you to try selecting the legacy stats for the affected tuners - if the results are the same it might be the result of lack of driver support for the new DVB API, requiring special fudge factors in frontend.cpp as is already provided for the "Sundtek DVB-T (III)" tuner.

EMJB

 

[abu baniaz]

You can upload a modified cpp file. I'll ask Huevos to build with it if he has time as I usually run images from his fork as my build machine is snookered at the moment.

 

[birdman]

The ideal way forward would seem to me to be to generate a new version of the enigma file with additional logging in frontend.cpp. However the versions birdman helped me create were ~26 MByte, making it difficult to ask ccs to test these for us as email is the only way I have of sending him such files.

They become much smaller if you strip them.
Doesn't seem to be packaged for Vix, but there must be one around somewhere (I suspect the one from a Debian mips system would work...)

EDIT (fyi):
It turns out that a strip is built that runs on the native architecture of the build, but works on binaries of the architecture of the box build-for.

So, for my et8000 I get this Intel-x64 binary:

oe-alliance/builds/openvix/developer/et8000/tmp/work/et8000-oe-linux/linux-etxx00/linux-etxx00-4.10.6-.4/recipe-sysroot-native/usr/bin/mipsel-oe-linux/mipsel-oe-linux-strip


which strips mips binaries when run on Ubuntu.

 

[EMJB]

You can upload a modified cpp file. I'll ask Huevos to build with it if he has time as I usually run images from his fork as my build machine is snookered at the moment.

Thanks - will do a build for my machine with the new file and check the logging before I upload it, so it will probably be 2-3 days, perhaps more.

EMJB

 

[abu baniaz]

If it works, just submit a pull request.

 

[EMJB]

If it works, just submit a pull request.

What I will propose will almost certainly produce too much log information to be permanently incorporated. I am expecting to log 5 or 6 items per call for either the dB or the % figure, but each occur several times a second while running Signal Finder so one could easily end up with 1000s of lines in the log.

EMJB

 

[EMJB]

@abu baniaz:

Version of frontend.cpp with the additional logging attached with a ".txt" suffix to allow me to upload it - as I said in my previous post this will generate large amounts of log data so I would recommend that you do not use it for any other investigations etc. If you could collect a log including each of your DVB-T tuners on just one typical frequency that should help. Note that one second on each tuner will collect more than enough information.

In producing this, it has come to my attention that what Frequency Finder & OpenWebIf call "AGC" is called "Signal strength" or similar in the API, and in the case of the new API is a number of dBs which is normally negative, not a percentage.

EMJB