267 replies to this topic

[littlesat]

To widen the gate is just a ui thing? Note I hate blindscan because it is so blind... I suggest <1000 will take long scan times... I still convinced we need a spectrum analyzer thing as with this the user simply choose a peak...

[littlesat]

To widen the gate is just a ui thing? Note I hate blindscan because it is so blind... I suggest <1000 will take long scan times... I still convinced we need a spectrum analyzer thing as with this the user simply choose a peak...for real feedhunters this is a must I suppose... and for transponders that are already in satellite.xml you do not need blindscan...

Edited by littlesat, 9 March 2019 - 08:24.

[athoik]

I did change limits, don't remember changing defaults.

self.blindscan_start_symbol = ConfigInteger(default = 2, limits = (0, 59))
self.blindscan_stop_symbol = ConfigInteger(default = 45, limits = (1, 60))

[littlesat]

I would say change it...

[Huevos]

I did change limits, don't remember changing defaults.

self.blindscan_start_symbol = ConfigInteger(default = 2, limits = (0, 59))
self.blindscan_stop_symbol = ConfigInteger(default = 45, limits = (1, 60))

Not that simple. There are filters in the python code to catch junk output from the closed source binary executables. And also it will probably cause lock-ups on some of those closed source binary executables.

 

At the very least you would have to change this...

lower_symbol = (config.blindscan.start_symbol.value * 1000000) - 200000

To this...

lower_symbol = max((config.blindscan.start_symbol.value * 1000000) - 200000), 100000)

If not you could end up with junk negative values fed to enigma.

Edited by Huevos, 9 March 2019 - 10:19.

[Huevos]

BTW, the upper limit was changed from 45 to 60. Now there are people asking for 80. Surely this is just marketing.

 

The defaults were always 2-45 as values outside this range are already known to cause some closed source executables to lock-up. The OE-A version saves the config so no need to reset it every time like the PLi version.

 

Also channels with symbol rates below 1000 are going to only be audio, or if they are video they will be extremely poor quality. And also channels with symbol rates below 1000 are well out of the bandpass filtering scope of the tuner on any DTH STB.

 

Is this numbers game just measurebating?

Edited by Huevos, 9 March 2019 - 10:35.

[Huevos]

To widen the gate is just a ui thing? [...] I suggest <1000 will take long scan times...

Not much you can do about that. It is closed source code so it is up to the manufacturer how long it takes or how thorough it is.

 

Currently, using the latest drivers on Octagon sf8008 (manual scan, not blind scan) it is possible to receive 23.0E 12647 V 285 7/8 QPSK.

[MCelliotG]

Wouldn't it be useful if somehow the blindscan plug-in code read the frontent capabilities and auto configure the range values from that?
Granted SRs below 1000 are not plenty but in the other hand newer tuners can handle these quite easily if their driver and firmware support them, so why wouldn't blindscan reflect these capabilities too? For instance Availink reports a minimum SR of 0 (although it seems there's a firmware restriction that cuts all SRs below 1000) and now a new test driver for Silabs extends the range to 80000.
And besides blindscan is supposed to find everything, so why argue if that has to be audio and video? In that logic it shouldn't find data transponders either!


Στάλθηκε από το Redmi Note 5 Pro μου χρησιμοποιώντας Tapatalk

[littlesat]

It would be helpfull here when the drivers reported the min/max via e.g. procs...-or- that somehow that crasy binary can give these values back to the UI.

Edited by littlesat, 10 March 2019 - 06:36.

[Huevos]

It would be helpfull here when the drivers reported the min/max via e.g. procs...-or- that somehow that crasy binary can give these values back to the UI.

They are available (via delsys). Just press the info button when you are in NimSelection screen  to view them.

 

 tuner-info.jpg   64.5KB   4 downloads

Edited by Huevos, 10 March 2019 - 10:45.

[Huevos]

Wouldn't it be useful if somehow the blindscan plug-in code read the frontent capabilities and auto configure the range values from that?
Granted SRs below 1000 are not plenty but in the other hand newer tuners can handle these quite easily if their driver and firmware support them, so why wouldn't blindscan reflect these capabilities too? For instance Availink reports a minimum SR of 0 (although it seems there's a firmware restriction that cuts all SRs below 1000) and now a new test driver for Silabs extends the range to 80000.
And besides blindscan is supposed to find everything, so why argue if that has to be audio and video? In that logic it shouldn't find data transponders either!


Στάλθηκε από το Redmi Note 5 Pro μου χρησιμοποιώντας Tapatalk

Sounds like a good idea, but in practice it is not. For example the sf8008 reports the tuner as 800-46000, but it was the supplier of this STB that requested the blindscan plugin range be extended to 60000.

And now we know that STB will receive as low as 285 (well below its 800 bottom limit). The tuner range is what is considered reliable operation, not what the DX guys can squeeze out of it on some transponders if they are lucky.

 

Also some receivers output SRs outside the range of the blindscan search parameters. Attached image is with the search set to 1 (1000) but it has reached below that to 874. This is what we have to contend with because the executable is closed source, and one of the reasons the Python filters are present. Others don't respect the SR limits at all so 100% rely on the Python filters.

Attached Files

•  SR.jpg   248.01KB   4 downloads

Edited by Huevos, 10 March 2019 - 11:05.

[littlesat]

I suggest we should take min/max from the frontend info.... but when the min is zero limit it to eg 100....

[Huevos]

I suggest we should take min/max from the frontend info.... but when the min is zero limit it to eg 100....

That is not going to please the DX guys. They want to receive from outside those limits. That is what this request is about. Right now the plugin works fine. Also the configs are not per tuner so it would need a major recode so that when the receiver has multiple tuner types the tuner being used would provide the limits.

 

Given that the PLi version of the plugin is so far behind the OE-A master version there is much more important catching up to do such as inverted LNBs than implementing features such as this.

[Robinson]

Perhaps 0-80000 but if the value is out of the frontend theoretical limits, a warning could pop up or something like that?

[Huevos]

 

Perhaps 0-80000 but if the value is out of the frontend theoretical limits, a warning could pop up or something like that?

The what I just said was a major recode would be necessary to make the parameters correspond to the individual tuners. It is just not worth the effort. And putting any effort into this when the current PLi version is so far behind doesn't make any sense (to me at least). This is time that could be spent more productively in other areas of the image that affect the majority of users, not a couple of DX guys that just want to boast about what transponders they scanned once, but don't actually want to receive.

Edited by Huevos, 10 March 2019 - 14:11.

[Huevos]

Perhaps 0-80000 but if the value is out of the frontend theoretical limits, a warning could pop up or something like that?

BTW, whoever heard of a feed with a symbol rate in this range? So what is the point?

Edited by Huevos, 10 March 2019 - 14:19.

[MCelliotG]

Perhaps 0-80000 but if the value is out of the frontend theoretical limits, a warning could pop up or something like that?

BTW, whoever heard of a feed with a symbol rate in this range? So what is the point?

Currently only NS3 systems require such high SRs but in theory DVBS2X could support up to 70000 if I'm correct. I also think there's a 60000 SR T2mi package on C band.

Στάλθηκε από το Redmi Note 5 Pro μου χρησιμοποιώντας Tapatalk

[Huevos]

Whatever the theory the values from delsys say 46000, not 70000. But that is the upper limit, not lower limit. And also,  only a handful of tuners are S2X capable, and how many of these are blindscan capable.

 

Cutting off at the values reported by delsys would mean less transponders are found, not more.

[littlesat]

I think blindskin is not helpfull for real dx-er... real feedhunters prefer spectrumanalyzer... as blindscan is ‘blind’...why should de delsys limits not work as these should be the limits of a specific tuner...? Then the info is simply not good (and therefore useless)

Edited by littlesat, 10 March 2019 - 17:17.

[Huevos]

I think blindskin is not helpfull for real dx-er... real feedhunters prefer spectrumanalyzer... as blindscan is ‘blind’...why should de delsys limits not work as these should be the limits of a specific tuner...? Then the info is simply not good (and therefore useless)

Spectrum analyzer does not return transponders. It draws a graph. You still need a tuner that is capable of syncing with the various transport streams and blindly opening them. Also blindscan will find transport streams that don't even show on a spectrum graph.

 

Delsys returns the RELIABLE limits of a tuner. It doesn't return the practical limits. Most tuners can operate outside the range listed by delsys. Why should we impose delsys as an artificial cut-off point when we know the tuner can operate outside this range? Also there is probably no proper standard for measuring delsys limits, so maybe for one manufacturer they are -3dB and for another they are -6dB, etc.

Edited by Huevos, 10 March 2019 - 18:34.