ABM (UK-Terrestrail ): Add HD channels/regions REVISTED Bluebell Hill

[adm]

Had a look at the section of the log file relevant to the frequency scan, and see the following apparent error messages:

<01-19-57.380>  [eDVBFrontend] FE_READ_BER failed: Operation not supported
<01-19-57.380>  [eDVBFrontend] FE_READ_SNR failed: Operation not supported
<01-19-57.381>  [eDVBFrontend] FE_READ_SIGNAL_STRENGTH failed: Operation not supported

which makes me wonder whether the signal quality values of $FFFF actually mean "quality unknown", in which case it would seem that DVB-T frequency finder is simply going to select the first "copy" of a mux it sees on ET10Ks.

EMJB

The box knows if the MUX is active or not. On non-active transmitter channels the SNR is reported as zero. Bit Error Rate is the measurement of quality and not necessarily SNR.

However, I think that you are probably correct in what is being reported is actually junk and as a result the frequency finder is possibly next to useless on a ET10K.

As an experiment I inserted another 22dB of in-line attenuation at which point the picture was at the point of break-up. The SNR bar always still reported 100% and the BER never moved from zero. The SNR figure fell from 301dB (no additional attenuation) to 190dB (22dB of additional attenuation).

Selecting the first MUX it sees with a decent SNR or signal strength is a poor way of selecting the MUXs to scan. As mentioned previously both Crystal Palace and Bluebell Hill give me a strong signal and reliable reception on many days but because the path to CP is masked by nearby tall buildings signals from this source have proved unreliable longer term. You need reliable signals for unsupervised recordings.

For info.

I inserted a 4G filter in my system (approx 4dB insertion loss)
The frequency finder now finds 11 discrete MUXs rather than the previous 12
There are still the 3 missing MUXs from Bluebell Hill and now an additional MUX from Crystal Palace.
The filter is allowing Channel 56 to be seen from Bluebell Hill.

https://www.blake-uk.com/home/534-f-type-external-masthead-lte-blocking-filter-35db-55db-upto-ch-57-proception.html

[ccs]

As I said before, the SNR is now stuck on 100%, I remember checking the april 2018 driver update to see if it was working again, because it used to show more realistic values. So it could be the last but one driver update which messed it up.

[EMJB]

Thanks for the additional information adm & ccs. I have tried a USB tuner with a Si2168 chipset rather than the Si2169-based tuners supplied with the ET10K. When this is used by DVB-T frequency finder I get slightly different error messages, but still the same $FFFF quality value.

I have also tried setting "Force legacy stats" on the tuner configuration page to "yes", in the hope that might help, but it stopped DVB-T frequency finder from finding any muxes.

Incidentally, it has just occurred to me that the quality-generating code has probably been written in C, and $FFFF as a 16-bit word equals -1, which is what one might expect when no quality information is available.


EMJB

[EMJB]

The issues identified in this thread would have a major impact on my proposed tuning guide if not fixed, so in the absence of response from elsewhere I have been investigating the code and identified what I think is the major issue and suggested fixes in the attached file.

Not all tuners give a useful response to the "self.frontend.readFrontendData(iFrontendInformati on.signalQuality)" call, at least one (Si2168) returning 0 and another (Si2169) 0xFFFF to indicate no data available. As the quality is only interrogated after a lock is found, the actual SNR must be greater than ~20 dB when this call is made, so a received value of 0 must always indicate invalid information rather than just a very poor signal. Assuming the tuner does not change and does not provide valid data, the same value will be returned for each mux found. With the present logic a return value of zero will lead to wasted time searching all channels and finding no muxes, and a return value of 0xFFFF is treated as a large SNR and the first mux of each type found will be used, whether or not it is best. To be pedantic, the problem lies in the drivers for the various tuners and/or frontend.cpp, but it seems unlikely that these will be corrected in the short term, or that problems will not be found with any new tuners. To mitigate these issues I have made the following changes:

(a) When 0 or 0xFFFF is returned I have amended the logic to try 3 other measures of signal quality.

(b) If no valid measure of signal quality is found the user is given the choice of continuing (using the first version of each mux found), or abandoning the search with the following message:
Tuner Msg.jpg

N.B. Ignore the actual tuner type in this message - the screenshot was generated by inhibiting the use of alternative measures.

The tuner selection is currently redone for each frequency, which raises (the rather remote) possibility of a major problem if it results in a different tuner models being selected, as the quality levels reported are not consistent between tuner models. There is a lesser problem if poor cabling or uneven distribution amps lead to different signal levels to otherwise identical tuners. I have therefore changed this to run just once at the beginning. The preference for the last tuner is perhaps non-ideal, as this will favour USB tuners which are arguably less likely to be properly supported than the normal ones, but I have not changed this.

If anyone would like to try it, as a minimum they need to copy the attached file to "/usr/lib/enigma2/python/plugins/SystemPlugins/AutoBouquetsMaker/scanner/", and reboot the GUI, but if they think they may need to revert to the old version they should rename the "frequencyfinder.pyo" file in that dierectory to something like "frequencyfinder.pyo.orig" before rebooting. The reboot will create a new "frequencyfinder.pyo" file. I would welcome reports of which tuners work and which do not.

frequencyfinder.py

[Huevos]

The tuner selection is currently redone for each frequency, which raises (the rather remote) possibility of a major problem if it results in a different tuner models being selected

This assumption is false. On subsequent runs the same tuner is always selected.

First iteration here: https://github.com/oe-alliance/AutoB...finder.py#L230
Subsequent iterations here: https://github.com/oe-alliance/AutoB...r.py#L244-L245

[EMJB]

This assumption is false. On subsequent runs the same tuner is always selected.

Apologies for that misunderstanding of the code. Do you want to take on board the other changes, and if so do you want me to produce a version without the additional logging and explanations of my changes?


EMJB

[Huevos]

As I said before, the SNR is now stuck on 100%, I remember checking the april 2018 driver update to see if it was working again, because it used to show more realistic values. So it could be the last but one driver update which messed it up.

Can you post screengrabs of SignalFinder of an identical pair of transponders.

[ccs]

This could be significant.

CH22 bbc sd mux is showing values, but CH28 bbc hd mux shows no signal.

[birdman]

Can you post screengrabs of SignalFinder of an identical pair of transponders.

I thought that the idea was that different chipsets produce different results (but could easily be wrong).
I have a box with 4-different DVB-T2 tuners in....

[EMJB]

One of the problems I hit when investigating different tuners was that the different display features appear to use different data, and/or display the available data incorrectly. Using the logic I proposed for DVB-T frequency finder both Si2168 & Si2169 provide sensibly varying values. The Si2169 responds sensibly to the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.snrValue)", but the Si2168 does not and so the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.signalQualitydB) is invoked and gives values that appear to be in milliBels - i.e. 30 dB is reported as 3000.


The following SNRdB results from the webif "web/signal?AGC=" command may be of interest (the main figures are averages across 20 samples, and those in brackets are the lowest figures in those samples) :

   	      	               <----------------- Signal SNR -----------------> 
	Name	Status	Tuner A	        Tuner B	     Tuner C	     Tuner D
	    	       Si2169 	  Si2169 	 Si2169 	      Si2168 

1	PSB1	In Use	340 (334)	301 (301)	340 (340)	31 (31)	

2	PSB2	In Use	348 (347)	341 (340)	340 (334)	32 (31)	

3	PSB3	In Use	354 (353)	348 (347)	347 (308)	31 (31)	

4	COM4	In Use	360 (353)	358 (353)	360 (360)	33 (32)	

5	COM5	In Use	360 (360)	343 (340)	341 (340)	33 (33)	

6	COM6	In Use	355 (353)	284 (275)	301 (301)	28 (27)

Note that the "HD" mux is being shown apparently correctly, unlike Signal finder where I have seen the same problem as reported by ccs.

It would also appear that the Si2169 reports are in centiBels, as they seem to be a factor of 10 larger than for the Si2168. However as DVB-T frequency finder is only interested in relative levels, that would not affect the results.


EMJB

[EMJB]

I thought that the idea was that different chipsets produce different results (but could easily be wrong).
I have a box with 4-different DVB-T2 tuners in....

I would certainly be interested in what happens if you run my version for each tuner, and the log file would be even better as it would indicate which data item is being used for each chipset.


EMJB

[ccs]

@EMJB How do you run "webif "web/signal?AGC=" command"

[EMJB]

@EMJB How do you run "webif "web/signal?AGC=" command"

"http://et10000/web/signal?AGC=" on your browser, changing the address as necessary of course.


EMJB

[Huevos]

This could be significant.

CH22 bbc sd mux is showing values, but CH28 bbc hd mux shows no signal.

Something is seriously wrong with the arithmetic for that tuner. Someone needs to look at that.

CH 58 is not showing signal because the selected region does not correspond to your mast. If you switch into user defined mode you should be able to tune that mux.

[Huevos]

do you want me to produce a version without the additional logging and explanations of my changes?

I don't want to accept fixes for broken drivers. But I do appreciate your contribution.