Blindscan on linux with tbs cards

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
This solved diseqc issues for my Si2183 based cards:

Code:
static int si2183_diseqc_send_msg(struct dvb_frontend *fe,
                                                                    struct dvb_diseqc_master_cmd *d)
{
    struct i2c_client *client = fe->demodulator_priv;

    int ret;
    u8 remaining = d->msg_len;
    u8 *p = d->msg;
    u8 len = 0;
    char msg[256];
    char*ps = &msg[0];
    int i;
    ps += sprintf(ps,  "Diseqc message[%d]: ", d->msg_len);
    for(i=0; i< d->msg_len; ++i)
        ps += sprintf(ps, "0x%x ", d->msg[i]);
    vprintk("%s", msg);

    while (remaining > 0) {
        p += len;
        len = (remaining > 6) ? 6 : remaining;
        remaining -= len;
        if(remaining!=0)
            dprintk("REMAIN= %d/%d", remaining, d->msg_len);
        msleep(100);  //## added 24 September 2023 ##

        ret = send_diseqc_cmd(fe, 0, 0, 0,
                                                    (remaining == 0) ? 1 : 0, len, p);
        if (ret)
            goto err;
        msleep(10);
    }

    return 0;
 err:
    dev_err(&client->dev, "set_tone failed=%d", ret);
    return ret;
}
 

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
Your messages point out what the problem is: some kind of timing issue.

Are you running the drivers in a virtual machine?


However, the solution is not a good one:
the original code waits 10ms in case of a temporary error and tries that 10 times. That does not
work for you. Your fix risks waiting 10x 100ms =1 second in the worst case. Note that this is
1 second per transmitted byte. That could make the driver "soft lock" for several seconds.

Also I suspect that the problems may be related to powering up the lnbd and swicth (see below).
Then the amount to wait depends on what happened before sending the diseqc command.

In any case, waiting should not be done in this low level driver
code but at a higher level (either in dvb_frontend.c) or in user space.

This is because in general the needed amount to wait depends not on a specific call
(in this case diseqc sending) but also on what happened before (e.g., was the voltage switched
from 0 to 18V or was it already 18V for a long time) So only higher level code can estimate the optimal
value because it involves multiple system calls.

So a solution in the driver (like your fix) needs to always make the worst case estimate (e.g., always
wait 100 ms because the LNB may have been only just powered up, even if this delay is not always needed).
As a result all these delays will pile up, resulting in slower channel change.

Another issue is that all drivers need to behave in the same way (either all of them sleep for safety,
or none should do that; most other drivers don't seem to wait either).

So I would not recommend this fix.

Here is some more info on things I have noticed myself (and which may be different from your problem):
I have noticed in reality is all kinds of weird behaviour with switches and motors during power up.
The main thing is that after powering up from 0 voltage you need to wait longer than the specs state.
Also, when powering a rotor behind a switch the motor can go into "overload" if you power up from 0 to 18 Volt.
So neumodvb first switches to 12 Volt and a moment later to 18 volt.

None of this should actually be needed according to the specifications, but this is is based on experiments, including an oscilloscope and even measuring currents. Most programs introduce some delays, but the values are based on
the specs and do not take into account weird behaviour.

I have also noticed that some tbs usb devices are more sensitive in this respect, probably because they
create more complex startup behaviour due to usb current limitations. And of cours, the longer the cables, or the
poorer the connectors, the more risk of problems.

It is quite possible that such problems are only seen with the blindscan drivers, for the following reason:
many of the (not modified by me) tbs drivers rarely power down the lnbs. I do not think this is a good idea,
and it may be the reason why have seen many of my lnbs fail after a few years of usage by tvheadend:
I have noticed that switches and the selected lnbs stay powered on (even in power save mode), which needlessly consumes energy and which could (just a theory of mine) reduce lifetime.

Instead my blindscan drivers power down lnbs whenever the driver knows they are not being used. That
of course means powering up at each "device open", and if some devices react poorly to power up problems, it also means more problems. With the regular drivers, you will see these problems only once per boot (the first time
you use the device) because the 2nd, 3rd... time the switch is already powered up.

I am not sure what is the proper fix in your case. Obviously, you do not want to modify all user programs.
One work around may be the "repeat diseqc" option that many user space apps offer. This works because
programs wait before repeating, and by that time power up has happened.

In any case, this could be something to experiment with, just to see if the problem is related to powering up.
You could also insert a 100 or 200ms delay in the tsduck code before sending diseqc. This will shed some
light on the nature of the problem.
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I added a delay after lnb powerup in tsduck now. That works well. It also works well adding repeat of the diseqc command.
Also tested my Moteck SG-2100A diseqc rotor does move now if I add 700ms delay after LNB power on, plus one diseqc repeat after 15ms. I assume it is normal that a rotor needs more time to power up.
 
Last edited:

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
I added a delay after lnb powerup in tsduck now. That works well. It also works well adding repeat of the diseqc command.
Also tested my Moteck SG-2100A diseqc rotor does move now if I add 700ms delay after LNB power on, plus one diseqc repeat after 15ms. I assume it is normal that a rotor needs more time to power up.
700ms is a long time. I think the problem is usually that several things power up at the same time. You could try reducing the times
to 100 or 200ms.
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I have not tested the Moteck SG-2100A diseqc rotor with antenna or LNB connected. It is placed on my desk while testing. I will retry with a LNB connected as well to get 75ohm termination as that may make a difference .
 

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
The LNB will certainly make a difference. A diseqc switch will make even more difference as all of these things consume
power. Good connectors are essential.

Although not the best solution, I have a motor connected behind a diseqc switch. All that motor power then needs
to go through the switch. It still works and for me (and it is just within current limits) it was the easiest regarding cabling (diseqc switch
is located near a wavefrontier dish.

Note that how much current the rotor consumes also depends on load. So attaching a dish will make a different.
Even "slack adjustment" on the rotor makes a difference. My rotor had some slack, leading to a wobbly dish.
Tightening a screw made that disappear but also increase power consumption. I measured the current and it was still ok for the dish.
Dish weight can also affect the needed currents.

In other words: problems can depend on various details. Other complicated cases include cascaded switches.

The good news is that with proper software, it is possible to make it all work, without having a huge speed penalty.
 

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
I have updated the kernel blindscan drivers. The number of fixes is small, so there is no need to upgrade
unless you experience problems, like some muxes not tuning from time to time.

If you do decide to upgrade, then why not keep your existing kernel en kernel modules? It enables you
to go back in case of problems. Linux is not windows and re-installing software or the OS is never the proper
way to fix things. You will only waste your time and risk making things worse.

If you do install from scratch, and if the installation instructions prove insufficient, then please report how you
installed and we can update the instructions for others.

The main changes are related to integrating the newest tbs changes (as implemented by crazycat) and
to support compiling on some outdated kernels, mainly ubuntu 23, which uses kernel 6.2.
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I have installed the blindscan drivers from github on the 13'th of december in fedora 38 and has also successfully build blindscan command line tools from GitHub - deeptho/blindscan: User space code for DVB blind scanning

I have tested with TBS6903-X. The blindscan and spectrum plot works very well but only as long as one input is connected. It seems like the two inputs on the card behave like a simple splitter. When I connect coax to the first adapter on the card I can get same signal on the second adapter without any cable connected. And if I connect cables from two different LNBs to the two F-connector inputs it does not work well at all.
And if I try to receive the same transponder on both inputs/adapters tsduck gives error message "FE_SET_TONE error"

So the simple question is if this is an expeted behavour?

Tsduck tslsdvb command lists the adapters in my system like this:
Code:
/dev/dvb/adapter0 (TurboSight TBS 6903 DVB-S/S2 , DVB-S, DVB-S2, DSS)
/dev/dvb/adapter1 (TurboSight TBS 6903 DVB-S/S2 , DVB-S, DVB-S2, DSS)
/dev/dvb/adapter2 (TurboSight TBS 6903x , DVB-S, DVB-S2, DSS)
/dev/dvb/adapter3 (TurboSight TBS 6903x , DVB-S, DVB-S2, DSS)
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I got both inputs working now with separate LNB& diseq. I have a 6903x V2 and I noticed that the tbsecp3-dvb.c file specify
Code:
.num_rf_inputs = 2,
.rf_inputs ={0,3}

So I got the second input to work by speficy --rf-in=3 ,and not --rf-in=1 as the second physical input.

Code:
neumo-blindscan  -c spectrum -U0 -C3 -a3  --rf-in=3 --spectrum-method fft --spectral-resolution 100

The spectrum fft scanning works great :)
 

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
I got both inputs working now with separate LNB& diseq. I have a 6903x V2 and I noticed that the tbsecp3-dvb.c file specify
Code:
.num_rf_inputs = 2,
.rf_inputs ={0,3}

So I got the second input to work by speficy --rf-in=3 ,and not --rf-in=1 as the second physical input.

Code:
neumo-blindscan  -c spectrum -U0 -C3 -a3  --rf-in=3 --spectrum-method fft --spectral-resolution 100

The spectrum fft scanning works great :)
Indeed rd_fin=3 is needed. That is because the card is wired that way.
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I have now tried a tbs6909 V2 card stid135-blindscan. It blindscans incredibily fast by using all eight adapters. But I notice that random transponders is not identified by the blindscan. I got the same problem when using only one adapter on TBS6909X V2 or using tbs6903x v1.2.

I can see the same behaviour on many different satellite positions like 28E,13E,19E etc. but for those positions I have a diseqc switch that is causing distorted spectrum which I assume can make it harder to identify the spectrum peaks.
For the 1-west satellite position I use no diseqc and the spectrum looks quite clean.

See attached jpg from 1-WEST which shows spectrum and two random transponders not identified during that spesific scan.
Btw. the blindscan is insane fast and completes in only 2 minutes for both pol and full L-band!

I can tune to those transponders missed by blindscan by using tsduck and SNR is around 12dB which should be more than enough. It also works in tsduck even if I deliberately set incorrect parameters for symbolrate,FEC,delivery system. I assume that means that the blindscan driver is able to identify those transponders without any problem.

Code:
stid135-blindscan -c blindscan --fft-size 256 --search-range 10000 -U0 -C0 -a 4 5 6 7 8 9 10 11 --rf-in=0 -pBOTH -s 10650000 -e 12750000 --spectral-resolution 100

Extract from the horisontal peaks_rf0_H.txt file shows those two transponders is not detected as peaks:
Code:
.
.
11784.600000 27700000
11822.800000 29100000
11861.300000 27700000
11899.100000 26900000
11937.800000 27900000
12014.600000 29500000
12091.400000 26700000
12129.000000 27100000
.
.

I get the same behaviour when I try with my TBS6903X- V1.2 card.

Is there some settings I can change to improve this ?

Is there some logs you need ?
 

Attachments

  • 1w_spectrum_blindscan.jpg
    1w_spectrum_blindscan.jpg
    305.6 KB · Views: 11

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
You should try neumoDVB as a comparison (if possible). It has a more recent peak finder,
whereas neumo-blindscan uses a version in the driver.

Also make sure you have the latest drivers installed (especially for diseqc problems).

The neumo-blindscan program is not often tested/updated. Maybe changing the search-range could help. Not sure.

Below is what I get right now on the H polarisation.
Looks very different from yours, but that could be due to some muxes being on different beams. For me they all muxes
are equally strong and all of them are found.
I can lock the mux at 10dB and it has also been detected automatically.

Regarding the V2 vs V1. There is very little difference between the cards. The V2 has an extra (unneeded) VGLA.
So it is logical you get the same results on both.

y.png
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
Neumodvb also misses a transponder. "Get Spectrum" did not list 12054V at 1-WEST as a candidate to blindscan. I have done several attempts but 12054V is never listed as a candidate to blindscan. I am at the edge of one of the beams and thats why there are different power for the various transponders. But SNR for 12054V is well above threshold at 11.5dB. 12054V tunes fast in neumodvb if I manually set frequency and polarization.

I am using a shell script that uses stid135-blindscan to create spectrum plot and list of transponders&parmeters. The script uses stid135-blindscan to automatically scan 10 satellite positions from my antennas continuously (cron job). So I prefer to use command line tool for that and neumodvb when I want to scan ad-hoc . I was hoping there was some way of solving this but it is not very annoying. Both neumodvb and stid135-blindscan detects 99% of the transponders as long as spectrum is not distorted.

stid135-blindcan performs quite bad on 28E but I assume it may be caused by diseqc switch causing lots of reflections which distorts the spectrum. Neumodvb is doing much better and is able to identify all the candidate frequencies to blindscan at 28E but neumodvb blindscan crashes. I think it did crash on GSE data transponder 11740V SR 31419 (SNR 8.4dB/ BER 0 when I tune manually in neumodvb).
 
Last edited:

deeptho

Specialist Contributor
Joined
Apr 7, 2006
Messages
697
Reaction score
420
Points
63
Age
57
My Satellite Setup
Wavefrontier T90, Laminas 120cm, 2 other dishes; tbs 5927, tbs6904, tbs6909x, tbs6903x, tbs5990, tbs6981,tbs5927
My Location
Europe
Neumodvb also misses a transponder. "Get Spectrum" did not list 12054V at 1-WEST as a candidate to blindscan. I have done several attempts but 12054V is never listed as a candidate to blindscan. I am at the edge of one of the beams and thats why there are different power for the various transponders. But SNR for 12054V is well above threshold at 11.5dB. 12054V tunes fast in neumodvb if I manually set frequency and polarization.
If you send me the spectrum files produced by neumoDVB I can have a look.

One important unasnwered question is if you use the latest drivers (and latest neumoDV:cool:

I am using a shell script that uses stid135-blindscan to create spectrum plot and list of transponders&parmeters. The script uses stid135-blindscan to automatically scan 10 satellite positions from my antennas continuously (cron job). So I prefer to use command line tool for that and neumodvb when I want to scan ad-hoc . I was hoping there was some way of solving this but it is not very annoying. Both neumodvb and stid135-blindscan detects 99% of the transponders as long as spectrum is not distorted.
Yes I understand. There is nothing wrong with commandline tools.

stid135-blindcan performs quite bad on 28E but I assume it may be caused by diseqc switch causing lots of reflections which distorts the spectrum.
I doubt that. More likely, the switch needs more time to powerup or something like that.
If there are reflections then that point to a bad cable or connector.

Neumodvb is doing much better and is able to identify all the candidate frequencies to blindscan at 28E but neumodvb blindscan crashes. I think it did crash on GSE data transponder 11740V SR 31419 (SNR 8.4dB/ BER 0 when I tune manually in neumodvb).
It does not crash for me. Ina ny case, without log files there is nothing I can do.
 

Bobben_no

Member
Joined
Dec 12, 2009
Messages
21
Reaction score
4
Points
3
Age
51
My Satellite Setup
Topfield 7700 HDPVR,Fibo120cm and a lot of other receivers and antennas.
My Location
Norway
I installed the blindscan driver from github on the 13'th of December 2023 and I assume that is the newest drivers ?

When I got some more time I will make new scans with neumodvb and provide scan files and also log.

I will try new RG6 coax and new connectors to see if that works better. It may not be reflections that distorts the spectrum but too low isolation between inputs in the diseqc switch.
 
Top