Blindscan on linux with tbs cards

[Bobben_no]

This solved diseqc issues for my Si2183 based cards:

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]

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]

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.

 

[deeptho]

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]

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]

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]

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.

 

[deeptho]

How to install?

Read the instructions at
GitHub - deeptho/media_build: media_build for compiling the neumoDVB media_tree on this site

 

[Bobben_no]

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:

/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]

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

.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.

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

The spectrum fft scanning works great

 

[deeptho]

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

.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.

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]

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.

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:

.
.
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 ?

 

[deeptho]

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.

 

[Bobben_no]

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).

 

[deeptho]

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

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]

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.

 

[deeptho]

I have uploaded new drivers on github.
The list of changes in release-1.2 is below. They mainly affect stid135 cards and the manin
novelty is to support tbs61916, to introduce sysfs (will be documented later).

The drivers also have a small improvement for tvheadend: it is not possible to attach arbibtrary
demods to specific tuner inputs. For instance, this means that you can configure adapter0 to be
a master tuner, and all other adapters to be slave tuners. All of these tuners will be connected
to the same cable at input 0. This is handy if you have only one cable connected to the card
and then allows to view 8 different muxes in the same satellite band (e.g., low horizontal).

For instance
echo 0 | sudo dd of=/sys/module/stid135/card0/chip0/demod1/default_rf_in
connects demodulator 1 to rf input 0.
And the corresponding adapter is 2, as can be found from:
$cat /sys/module/stid135/card0/chip0/demod1/state nr=1 adapter_no=2 default_rf_in=1 selected_rf_in=-1 llr_in_use=0 freq=0 lock=0 fec=0 demod=0 error=0 signal=0 carrier=0 viterbi=0 sync=0 timedout=0 timing=0 freq=0 sym_rate=0 power=-0.0dBm cnr=0/0dB ber=0

The strange numbering of adapters and demods is due to specifying in /etc/modprobe.d/tbsecp3.conf:
options tbsecp3 adapter_nr=0,2,4,6,1,3,5,7
This basically renumvers the adapters: adapter2 corresponds to the second demodulator, which demod1

Changes
* Added sysfs entries in /sys/modules/stid135/
* Allow setting the default rf input for each demod, for use with tvheadend. This allows more than one slave
tuner to use the same rf input connector on the card.
* Incorporated changes from the official tbs drivers up to July 11 2024.
* Improved determination of card mac addresses and generating fake mac addresses should the card not have one set.
* Support for the tbs6916 card.
* Bug: stid135 based cards sends out 21kHz tone and diseqc base frequency instead of 22kHz and this causes some
diseqc switcches to sometimes ignore commands.
* Provide additional ioctls to support "syncrhonized" calls, where one adapter can wait on another adapter
to finish setting voltages, tones and sending diseqc commands
* Protection against drivers which blindly assume name to be of size 128.
* Bug: fe_read_status should not return -1 on timeout.
* stv091x: fix isi scan.
* Bug: tuning loop runs to early when diseqc is sent but no tuning info is present yet.

 

[deeptho]

Note that there is still some bug in this version, which can cause a deadlock (then you need to reboot).
I will fix...

 

[deeptho]

Should be fixed now.

 

[tasoss]

Hello.
I'm having a problem with the drivers of 6909x.
This is the stack trace. Let me know if you need something more.
Thanks!

2024-10-04T23:14:24.917198+03:00 tasossTest kernel: Linux version 6.8.0-45-generic (buildd@lcy02-amd64-115) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 (Ubuntu 6.8.0-45.45-generic 6.8.12)

<TASK>
dump_stack_lvl+0x76/0xa0
dump_stack+0x10/0x20
ChipSetField+0x99/0x160 [stid135]
? __pfx_process_timeout+0x10/0x10
Oxford_CalVCOfilter+0x3a/0xd0 [stid135]
Oxford_ClockStartUp+0x81/0xd0 [stid135]
Oxford_AfeInit+0x78/0xb0 [stid135]
FE_STiD135_TunerInit+0x74/0x120 [stid135]
fe_stid135_init+0x16f/0xd30 [stid135]
? prb_read_valid+0x1c/0x30
? console_unlock+0x83/0x100
stid135_probe+0x146/0x910 [stid135]
? __pfx_max_set_voltage+0x10/0x10 [tbsecp3]
stid135_attach+0x51f/0x7c0 [stid135]
tbsecp3_frontend_attach.isra.0+0x24d1/0x3f70 [tbsecp3]
tbsecp3_dvb_init+0x1fd/0x480 [tbsecp3]
tbsecp3_probe+0x22c/0x5e0 [tbsecp3]
local_pci_probe+0x44/0xb0
pci_call_probe+0x55/0x1a0
pci_device_probe+0x84/0x120
really_probe+0x1c4/0x410
__driver_probe_device+0x8c/0x180
driver_probe_device+0x24/0xd0
__driver_attach+0x10b/0x210
? __pfx___driver_attach+0x10/0x10
bus_for_each_dev+0x8a/0xf0
driver_attach+0x1e/0x30
bus_add_driver+0x14e/0x290
driver_register+0x5e/0x130
? __pfx_tbsecp3_driver_init+0x10/0x10 [tbsecp3]
__pci_register_driver+0x5e/0x70
tbsecp3_driver_init+0x23/0xff0 [tbsecp3]
do_one_initcall+0x5b/0x340
do_init_module+0x97/0x290
load_module+0xba1/0xcf0
? security_kernel_post_read_file+0x75/0x90
init_module_from_file+0x96/0x100
? init_module_from_file+0x96/0x100
? filemap_read+0x3f7/0x470
idempotent_init_module+0x11c/0x2b0
__x64_sys_finit_module+0x64/0xd0
x64_sys_call+0x1d6e/0x25c0
do_syscall_64+0x7f/0x180
? rseq_ip_fixup+0x90/0x1f0
? restore_fpregs_from_fpstate+0x47/0xf0
? switch_fpu_return+0x55/0xf0
? syscall_exit_to_user_mode+0x89/0x260
? do_syscall_64+0x8c/0x180
? syscall_exit_to_user_mode+0x89/0x260
? __seccomp_filter+0x368/0x570
? ext4_llseek+0xc3/0x130
? ksys_lseek+0x7d/0xd0
? syscall_exit_to_user_mode+0x89/0x260
? do_syscall_64+0x8c/0x180
? restore_fpregs_from_fpstate+0x47/0xf0
? switch_fpu_return+0x55/0xf0
? syscall_exit_to_user_mode+0x89/0x260
? do_syscall_64+0x8c/0x180
message repeated 2 times: [ ? do_syscall_64+0x8c/0x180]
? exc_page_fault+0x94/0x1b0
entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7c9ce512725d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48
RSP: 002b:00007ffcaa36b668 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 00005c570f756e40 RCX: 00007c9ce512725d
RDX: 0000000000000000 RSI: 00007c9ce532b07d RDI: 0000000000000023
RBP: 00007ffcaa36b720 R08: 0000000000000040 R09: 00007ffcaa36b6b0
R10: 00007c9ce5203b20 R11: 0000000000000246 R12: 00007c9ce532b07d
R13: 0000000000020000 R14: 00005c570f74f660 R15: 00005c570f758df0
</TASK>