View Full Version : [ViX_Misc] Signal Quality Values
It will probably not be obvious to most people that as of OpenVix 5.2.22, the problem of 100% signal quality reports present on most if not all tuner types should have been fixed. In particular using Signal Finder on the "Tuner config" menu page, and NOT forcing legacy stats on the "Tuner setup" pages :
* The dB figure should not be much below ~20 dB when lock is achieved, nor much above ~50 dB (precise figures will depend on whether satellite, cable, or terrestrial).
*The % figure should only be 100% for dB figures >= 42/62/50 dB for satellite/cable/terrestrial i.e. close to a main transmitter in the case of terrestrial.
* Results from different tuner models should agree within a few dB.
If these criteria are not met there would appear to be a remaining problem, probably specific to that tuner type. I am aware of a problem with one SundTek model, but are there others?
Please note that the ABM DVB-T Frequency Finder and the Terrestrial Scan plug-in use the % figure to identify the best signal when receiving from more than one transmitter - if this is always the same value then the first found rather than necessarily the best will be chosen.
This is what I see with a Sundtek MediaTV Digital Home USB Tuner Cable / Terrestrial HD (DVB-C/T/T2)
The only value which changes is BER
<?xml version="1.0" encoding="UTF-8" ?>
- <e2frontendstatus>
<e2snrdb>100 dB</e2snrdb>
<e2snr>100 %</e2snr>
<e2ber>0</e2ber>
<e2acg>100 %</e2acg>
</e2frontendstatus>
abu baniaz
03-02-19, 02:33
I am not getting the constant 100%. Am I doing something differently to what I should be?
* Results from different tuner models should agree within a few dB.
Your right in theory they should, but in practice they don't. I seen variances of up to 30-40% signal from boxes connected to same dish or terrestrial feeds.
My bet is if you test the same boxes on other 3rd party images you'll get the same results, therefore you are welcome to ask the manufacturers to fix their drivers for whatever box you have.
I am not getting the constant 100%. Am I doing something differently to what I should be?
For me, Com6, C60- (785.8MHz) drops to zero signal quality when it rains, I'll check the sundtek tuner again when the signal starts to deteriorate.
No other mux's are ever affected.
Maybe I should have said in my previous post that there are no dB levels, just %'s, which is odd.
Your right in theory they should, but in practice they don't. I seen variances of up to 30-40% signal from boxes connected to same dish or terrestrial feeds.
My bet is if you test the same boxes on other 3rd party images you'll get the same results, therefore you are welcome to ask the manufacturers to fix their drivers for whatever box you have.
With the old API the term point at which SNR was measured was ill defined leading to discrepancies in what was being measured, but with the new API the definition looks fairly watertight. Another complication is that the frontend.c code for the old API has lots of correction factors for some tuners, and none for others which may reflect the fact that no-one has bothered to make the corrections rather than them not being needed. Were your 30-40% variations seen with tuners using the latest API?
Incidentally, I assume your percentages apply to the dB values i.e. around 10-15 dB - a 40% variation in (linear) power is less than 2dB.
EMJB
I am not getting the constant 100%. Am I doing something differently to what I should be?
Something looks very strange with the screenshots you have posted - the AGC and SNR % figures are always identical - it looks as if the wrong data is being displayed for one or other or both. The skin you are using does not display the SNR in dB terms, which is unfortunate as the percentage is derived from the dB figure by applying an estimated upper limit so the dB figure gives more information than the % figure. I find using the WebIf "/web/signal?AGC=" command on your browser to be accurate and reliable, though tuner selection is less convenient.
Incidentally the reported type for your tuner is slightly different from that of ccs, which I believe is "Sundtek DVB-C (III) (1/0) (USB) (DVB-T2)", which might explain the differences in behaviour.
EMJB
Maybe I should have said in my previous post that there are no dB levels, just %'s, which is odd. It is the skin you are using - compare the screenshots I sent you recently with Abu's above.
It is the skin you are using - compare the screenshots I sent you recently with Abu's above.
Could the lack of a db reading be.......
Menu -> Setup ;> User Interface -> Swap SNR in % with SNR in dB = yes/no
Could the lack of a db reading be.......
Menu -> Setup ;> User Interface -> Swap SNR in % with SNR in dB = yes/no
I've got it set to no.
On my Si2169 tuners I see %'s on the top line, and dB below left, setting to yes swaps these round, but the Sundtek remains unchanged.
I think it depends on skin & whether your tuner is in lib/dvb/frontend.cpp and conversion factors are in place.
Well it started to rain much sooner than expected, and I'm seeing reduced snr levels, as I'd expect (well, hoped that it would match the signal level indicator on the tv as soon as it dropped ever so slightly).
No dB levels, I guess this is a SundTek issue - I can't see how a skin will help, I've tried Vix-night-hd and Simple_1080 - any others??
Any ideas why just one mux would be so sensitive to local rain - new aerial, new cabling, new variable gain signal booster/splitter, tree branches reduced significantly.
Any ideas why just one mux would be so sensitive to local rain - new aerial, new cabling, new variable gain signal booster/splitter, tree branches reduced significantly.
Roof or loft mounted aerial?
Roof or loft mounted aerial?
Roof - the rain only lasted for an hour, and soon after Com6, C60- (785.8MHz) was back to normal.
Depending on location to whatever transmitter signal is received from maybe not all channels are on a very high level and very high downpour can lower line of sight and effect viewing i have found.
Signal levels and quality are 100% on everything I've got (tv's, et10k,toppy), but even light rain affects just one mux.
I can tell if it's raining at night without opening the curtains, just need to tune in to ch60.:confused:
Any ideas why just one mux would be so sensitive to local rain - new aerial, new cabling, new variable gain signal booster/splitter, tree branches reduced significantly.I'm guessing multiple factors like that specific transmitter power and maybe fact that frequency is on high end so distance reach with higher frequencies get less and less as frequency is higher.
Check out DigitalUK (http://www.digitaluk.co.uk/channels/channel_listings)'s website. On right, enter postcode/house number and click detail info.
@abu baniaz:
Have you resolved the problem of identical SNR% and AGC values? If not can you please tell me which skin you are using (and where to find it if not in the standard build) so I can check it isn't a skin problem?
EMJB
My bet is if you test the same boxes on other 3rd party images you'll get the same results, therefore you are welcome to ask the manufacturers to fix their drivers for whatever box you have.The drivers for several tuners are part of the standard Linux kernel rather then being anything to do with specific manufacturers.
So on my Xtrend et8000 the Si2169 and TDA18273 drivers are from Xtrend, but the Si2168 and mn88473 (USB tuners) are part of the Linux kernel.
abu baniaz
05-02-19, 13:45
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
06-02-19, 03:34
TTL310 on Vu Solo 4k does not have identical values. The swap db/% does not have an effect.
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
06-02-19, 13:23
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.
@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.
58322
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
06-02-19, 15:15
What is your definition of "OpenViX default" with regards to skin?
Apologies- I had forgotten I changed it many moons ago - I am using ViX-Night_HD
EMJB
I am easily confused:confused:, am I right in saying that ViX-Night_HD is the OpenViX default skin?
I am easily confused: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
06-02-19, 18:06
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
07-02-19, 03:56
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.
@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
07-02-19, 14:19
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.
@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
07-02-19, 15:55
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.
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.
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
07-02-19, 19:06
If it works, just submit a pull request.
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
@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
abu baniaz
13-02-19, 14:26
Logs attached. I went into signal finder and went between the frequencies.
…. and in the case of the new API is a number of dBs which is normally negative, not a percentage.
Now not sure that this part is correct - in spite of the name give by frontend.cpp I think the signal strength may be a percentage of a maximum, which would explain its similarity to the snr% figure. I need to trace all the signals through from API to users to follow the changing names to be sure of what is going on.
EMJB
Logs attached. I went into signal finder and went between the frequencies.
Thanks - will try to look at them tomorrow.
EMJB
I've had a look at the logs. The major issue seems to be the following sequence:
FrontendStatus.py line 25 equates the "AGC"% value to "tuner_signal_power"
python_helpers.cpp equates this to eDVBFrontendStatus::getSignalPower()
frontendparms.cpp line 84 equates this to frontend.cpp's "iFrontendInformation_ENUMS::signalPower",
frontend.cpp equates this to the new API relative signal strength, not the absolute signal strength in dBm (see https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/dvb/frontend-stat-properties.html#dtv-stat-signal-strength)
as indicated in my penultimate post.
Unfortunately the new API is rather vague about how the relative signal strength is to be calculated, and I would not be surprised if drivers just equate this to the relative SNR.
In terms of specific issues arising rom the Sundtek log, I noticed that while the new API returned a value for relative (i.e. %) SNR it did not do so for the absolute (dB) value. While frontend.cpp calculates a missing relative value from the absolute value, the reverse is not true, forcing the use of the legacy API. In the absence of tuner-specific code this can produce silly answers.
The PNP log shows that frontend.cpp thinks that this tuner supports the new API, but never gets any data from it, and so always reverts to the legacy API. Aagin, in the absence of tuner-specific code this can produce silly answers.
EMJB
On my Unicable LNB, AGC is 80% on every channel I've tried, and SNR 69% to 80% depending on channel (not tried them all, but every one I've tried AGC is 80)
On my other normal LNB motorised dish, AGC varies from 72 to 82% depending on the channel
5853358534
This is on my Gigablue UHD UE 4K
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.