Brute-force Feeds search

Ideas for the future versions
Post Reply
gattino
Posts: 8
Joined: Tue Jan 07, 2020 10:38 pm

Brute-force Feeds search

Post by gattino »

Referring to this table, containing the frequencies of the Feeds and the symbol rates,
of Eutelsat at 7 ° east, I have created a specific sat.ini with which to scan these frequencies.
In the video you can see the result of my test.

Image

As you can see from the test, some results are obtained, even if some nearby
frequencies are tuned several times.

The question for @Altxro is as follows:
will it be possible to implement in the future a blindserch mode that works on specific frequency/polarity values,
to be specified in a feed.ini file, and to let the remaining values (SR-System-Modulation) be found by the tuner?

This would be an innovative function, which all feedhunters think I would appreciate,
because it would allow you to scan only the frequencies of the feeds that are now listed and in the public domain.

Thanks if you want to answer me

User avatar
Mr. Orbita
Posts: 45
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: Brute-force Feeds search

Post by Mr. Orbita »

If hardware support blindscan, this can be done, but if it is so - also frequencies can be found automatically and no need to define them manually, especially because every transponder can be splitted into any parts and feed can be in fact every other MHz. Defining eg 11089V and then 11094V would result in missing eg 11091V if low SR would be used for the first time, and this was not reported earlier by anybody (an example, didn't check the list - just to point the issue here). And that can be done.

In fact to have high accuracy with manual frequencies definition, it would need to have:
- 10700
- 10701
- 10702
- 10703
...
- 12749
- 12750

In both polarities. And even if so - app would still miss signals which occupying less than 1 MHz and in other hand it would found some frequencies with high SR many times, making a lot of doubles on the final list. So as you can see - not a very optimized approach.

TT S2-1600 PCI can do much better, because it is capable of doing hardware blindscan and there are already tools for this device, to run blindscan and find real active frequencies, without attempts to lock something that is not working at the moment. That's far better than trying to defining frequencies manually for every satellite position, which may change and might result with many unnecessary failed lock, which additionally are waisting scan time. To get the best results is to define few frequency ranges, like it is done in eg EBS Pro, which helps to cut out ranges used only for MCPC transmissions.

For 7°E in EBS Pro (or BLScan command line tool) ranges for feeds on 7°E are:
- 10950-11200 V
- 10950-11200 H
- 11490-11535 V
- 11575-11700 V
- 12500-12750 H
- 12500-12750 V

Just 6 definitions and all band range currently used for feeds is covered, even on frequencies that were not yet used and would be not on any list :)

Hardware blindscan is not supported in AltDVB at this moment, also would be very happy to see such feature :)

As a workaround for now it is possible to use BLScan tool to save .ini file and then import ready file with all feeds detected at the scan time straight to AltDVB. INI probably can be saved also by EBS Pro. Both tools should work with yours TT S2-1600.

For devices that are not supporting HW blindscan - some brute-force mode would maybe have some sense, but when device is not capable of doing HW blindscan, it cannot find SR automatically. So in fact every possible combination would have to be checked, which can take... days to complete. This mode is implemented in TransEdit tool, but to scan whole band with step 2 MHz and only 3 possible SR values it need to do 6156 locks attempts. This is not suitable for short-time lived feeds, only for possible high SR MCPC detection.

gattino
Posts: 8
Joined: Tue Jan 07, 2020 10:38 pm

Re: Brute-force Feeds search

Post by gattino »

Just with EBS-pro you mentioned, I use a kind of hybrid blindscan managed through the frequencies inserted in the profiles.

I am aware that if a new frequency were activated it would not be found, but I assure you that in recent years there have been no major changes and just keep everything updated to find all the feeds in no time.

I attach the file of my profiles to try with EBS-pro
to realize what I say.

Hybrid_blindscan.files.for_Ebspro_update_311219

As you can find, thanks to the hardware blindscan, no duplicate frequencies are found and frequencies are blocked even at a distance of 5 Mhz in +/- compared to the frequency entered manually.

Watch the video, what you see is what I would like to be implemented in Altdvb, but it is only my wish.

https://jmp.sh/gOCj9XX

Thanks for your attention

User avatar
Mr. Orbita
Posts: 45
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: Brute-force Feeds search

Post by Mr. Orbita »

Hmmm...

It might be hard to explain, but basically I feel that you are using EBSPro incorrectly (meaning not optimal).

The goal of hardware blindscan is not to define ranges with range width of 1 MHz (PS: not mix steps with range - step is a jump inside range, range is a bandwidth), so card has to relock and restart blindscan process for hundreds of times. You had to put totally nearly 200 ranges, when the same (or better) result should be achieved only by giving 6 ranges and capture whole band parts at once. Such configuration needs constant updates (lately on 7°E new range for feeds was activated, closely to 11,5 GHz pol. V, which is missing in your config). Updating this would be for me a road through hell...
From HW point of view card for ~200 times starts and stops classic HW blindscan in 1 MHz ranges with 1 MHz steps, additionally it has to check same frequencies multiple times, because as you see - it finds +/- 5 MHz, so by scanning side by side 11001 and 11004 card reviews part of spectrum for two times.

IMHO that's a misconfiguration in EBSPro, I feel that correct way is (for EBSPro 17, min and max SR to be changed if needed):

Code: Select all

[Scan0]
Pol=Vertical
Start=10950
Stop=11200
MinSR=100
MaxSR=70000
Method=1 MHz
Info
[Scan1]
Pol=Horizontal
Start=10950
Stop=11200
MinSR=100
MaxSR=70000
Method=1 MHz
Info
[Scan2]
Pol=Vertical
Start=11490
Stop=11535
MinSR=100
MaxSR=70000
Method=1 MHz
Info
[Scan3]
Pol=Vertical
Start=11575
Stop=11700
MinSR=100
MaxSR=70000
Method=1 MHz
Info
[Scan4]
Pol=Horizontal
Start=12500
Stop=12750
MinSR=100
MaxSR=70000
Method=1 MHz
Info
[Scan5]
Pol=Vertical
Start=12500
Stop=12750
MinSR=100
MaxSR=70000
Method=1 MHz
Info
The only case where I see any advantage is when blindscan HW support is very slow for some reason, because in other way my definition from above should be both faster, more accurate (without missing anything new) and easier to maintain/update. HW blinscan is getting frequencies automatically, without needing to put them manually. Making it manual is spoiling the whole point of blindscanning treated as a way to discover new feeds and broadcasts, never reported before, without need of constant check for updates/new frequencies online and put them manually.

Anyway probably eventual implementation would still give a possibility to use it as you are doing it now, because basically you are not putting exact frequency, but telling EBS Pro to scan frequency range (eg between 11009 and 11009, but still defining start and end, even if they're the same) with bandwidth of 1 MHz (and 1 MHz step, but it's not the same as range bandwidth). I don't have TT S2-1600, if it works better for you in that way - I believe that this definition could be used as well.

For that we will have to wait and hope that @altxro will introduce HW blindscan feature at some point in future ;)

Post Reply