TBS6903X problems with DVB-S2 MIS/PLS

[mrwish7]

I recently bought a TBS6903X, and I'm having a strange issue with it using the tbsdtv drivers. System is Ubuntu 22.04 LTS with latest linux_media/media_build, but the same problem happened with Ubuntu 20.04 LTS.

After tuning to a transponder using multistream (MIS) with PLS, it becomes impossible to tune 'plain' DVB-S2 until reloading the tbsecp3 driver or rebooting the machine. I have been testing using the Italian and French multistream transponders on Eutelsat 5°W, as detailed in this thread on the official TBSDTV forum, from post #6 onwards - https://www.tbsdtv.com/forum/viewtopic.php?f=181&t=25844

There is also an additional problem, in that the Italian Rai MIS/PLS transponders such as e.g. 5°W 11013 V 35300 PLS ROOT+16416 / GOLD + 131070 ISI 3 lock but the data stream is then corrupt with missing packets (also detailed in that thread). Oddly, the French transponder 12732V 29500 PLS GOLD + 50416 MIS1/4/6 works OK with no corrupt packets.

I have since tried the deeptho branch of these drivers - https://github.com/deeptho/linux_media/ This seems to fix the issue of DVB-S2 not locking after locking MIS/PLS. Transponders now all lock successfully without having to reboot/reload the drivers. However, the problem with the Italian Rai multistream is still present, with dropped TS packets -

Comparing the amount of corrupt/dropped packets with the same test performed with the tbsdtv drivers (screenshot in the TBSDTV thread linked above), I would say that the deeptho drivers improve the situation but there is still some problem as you can see in the above screenshot - the amount of dropped packets is less but still more than 0 (with image/sound glitching).

The signal level is adequate for perfect lock (~10dB C/N with modulation: 8PSK and FEC: 2/3), and my older TBS6905 card has no issues with locking these transmissions when connected to the same satellite dish.

I thought this may be a faulty hardware problem, but I've since had it confirmed by a contact who also owns a TBS6903X device and uses the deeptho drivers that they also get glitching on this Italian Rai transponder on 5°W.

So in summary there seem to be two bugs - the first is the problem with locking plain DVB-S2 after locking PLS/MIS which seems to exist in this version of the drivers but not the deeptho fork. The second bug is the dropped packets on some PLS/MIS transponders - specifically Rai on 5°W 11013 V 35300. This bug is present in both this version and the deeptho fork, but possibly worse in this version.

Any help would be greatly appreciated!

Many thanks, Adam

[crazycat69]

Strange issues. Your card with "capacitor mod" ?

[deeptho]

The lost packets problem is probably not a bug: I just tested this mux, with tbs6909x, which has exactly the same drivers. It works perfectly. I did not test tbs6903x.

Are you sure your disk is fast enough? Try capturing to /tmp (which is on ramdisk).

When running neumodvb or the "neumo-tune" program, capturing can be done with dvbsnoop -adapter 1 -s ts -tsraw -b > /tmp/test.ts

and analysis with tsanalyze /tmp/test.ts

(part of tsduck)

[mrwish7]

Thanks both,

I haven't made any mod to the card, but I will get chance tomorrow to take it out of the machine and take a picture. I will post that on here.

The disk should be fast enough - but to be certain, I've just tried recording to /tmp/rai.ts as described above - the file is still corrupt. Transedit in Windows shows the missing packets, and you can see the corruption in the video streams when playing the file back in VLC -

Oddly, tsanalyze doesn't show any corrupt packets for either of the recorded files, so I guess the packets in question must actually be completely missing.

|  TRANSPORT STREAM ANALYSIS REPORT                                           |
|=============================================================================|
|  Transport Stream Id: ........ 183 (0x00B7)  |  Services: ............. 11  |
|  Bytes: ....................... 134,968,960  |  PID's: Total: ......... 41  |
|  TS packets: ...................... 717,920  |         Clear: ......... 41  |
|     With invalid sync: .................. 0  |         Scrambled: ...... 0  |
|     With transport error: ............... 0  |         With PCR's: ..... 4  |
|     Suspect and ignored: ................ 0  |         Unreferenced: ... 0  |
|-----------------------------------------------------------------------------|

I've just also re-tested the French MIS transponder (12732V 29500), and I'm actually getting the packet dropping problem on there too. Again, the signal level is OK - 13.5dB C/N (greater than the just under 11dB required for 8PSK 8/9).

[deeptho]

Stream corruption does not detect corrupt packets, but missing packets. You should check for continuity errors (also in the driver logs, but use my drivers). Check the tsduck manual (continuity plugin: tsp -P continuity; or tsanalyze --error-analysis)

Do you have any settings in /etc/modprobe.d/tbsecp3.conf or /etc/modprobe.d/stid135.conf?

[mrwish7]

There's nothing for tbsecp3.conf but stid135.conf has the following -

options stid135 mis=1 ts_nosync=0

I was having general locking problems (timeout) specifically with TVHeadend using the deeptho drivers, so I moved back to this branch which works OK (other than MIS still of course). I will try again and run those continuity tests though. I may have had some settings wrong to be causing that additional problem, the TBS6903X seems to generally be causing me headache for some reason!

[crazycat69]

media: dvb-frontends/stid135: Optimized ts_nosync option.

mis option removed, forced TS FIFO Minimum latence mode only when ts_nosync=1 (especial for Eumetcast users)

P.S. try ts_nosync=1, maybe this help

[mrwish7]

Thanks, I changed the option to ts_nosync=1 and removed mis=1 (as the option was removed).

I still have the same problem of the card refusing to lock any other "plain" DVB-S2 after locking MIS/PLS.

TVHeadend seems to be able to successfully lock the French channels on 5°W 12732 MIS1/4/6 without any dropped or corrupt packets - so that doesn't seem to be a problem. However, the Italian muxes e.g. 11179V have continuity errors and dropped packets in TVHeadend (like with tsduck as tried earlier). This is the case both when using ROOT+16416 or GOLD+131070 PLS values, there is always lots of corruption in the stream. The signal level is around 11dB C/N, so well above the threshold for perfect reception.

Reloading the TBSECP3 driver is still the only way to make plain DVB-S2 work again after tuning MIS/PLS.

[crazycat69]

look like stid135 driver issue, fixed https://github.com/tbsdtv/linux_media/commit/16a874b68e3f0e66b369bdca5befc0859cbddbc7

[crazycat69]

About RAI TS corruption - maybe wrong max LLR auto-setup in get_current_llr() Please check kernel log when lock RAI transponder. Some like this:

06.09.2023 22:59 Current LLR = 64 MLLR/s 06.09.2023 22:59 Max LLR allowed = 90 MLLR/s

[mrwish7]

Thanks, I can confirm that the stid135 driver fix solves the problem of not being able to lock DVB-S2 after locking PLS - plain DVB-S2 now successfully locks after tuning PLS without a driver reload.

The switch is a little slow, for example with a few seconds wait between leaving 12732 V 29500 MIS 1 PLS and tuning 11461 H 5780 (plain DVB-S2), but the service does then start to play successfully after this.

The Rai mux glitching still persists, and switch from MIS -> MIS seems slow and a little glitchy, it sometimes takes two attempts (this may be related to the bug with the Rai muxes as I'm testing switching Rai to French mux and vice versa). Here's the kernel log -

Sep 11 20:49:26 mediacentre kernel: [  459.480546] i2c i2c-1: stid135_read_status: fe_stid135_get_signal_info error 7 !
Sep 11 20:50:05 mediacentre kernel: [  498.748173]
Sep 11 20:50:05 mediacentre kernel: [  498.748173] Bit rate = 28 Mbits/s
Sep 11 20:50:05 mediacentre kernel: [  498.748188] Current LLR  = 32 MLLR/s
Sep 11 20:50:05 mediacentre kernel: [  498.749024] Max LLR allowed = 90 MLLR/s
Sep 11 20:50:05 mediacentre kernel: [  499.032738]
Sep 11 20:50:05 mediacentre kernel: [  499.032738] Bit rate = 28 Mbits/s
Sep 11 20:50:05 mediacentre kernel: [  499.032752] Current LLR  = 32 MLLR/s
Sep 11 20:50:05 mediacentre kernel: [  499.033623] Max LLR allowed = 90 MLLR/s
Sep 11 20:50:13 mediacentre kernel: [  506.573786]
Sep 11 20:50:13 mediacentre kernel: [  506.573786] Bit rate = 21 Mbits/s
Sep 11 20:50:13 mediacentre kernel: [  506.573801] Current LLR  = 31 MLLR/s
Sep 11 20:50:13 mediacentre kernel: [  506.574850] Max LLR allowed = 90 MLLR/s
Sep 11 20:50:49 mediacentre kernel: [  542.798458]
Sep 11 20:50:49 mediacentre kernel: [  542.798458] Bit rate = 69 Mbits/s
Sep 11 20:50:49 mediacentre kernel: [  542.798473] Current LLR  = 104 MLLR/s
Sep 11 20:50:49 mediacentre kernel: [  542.800869] Max LLR allowed = 129166666 MLLR/s
Sep 11 20:50:52 mediacentre kernel: [  546.112511]
Sep 11 20:50:52 mediacentre kernel: [  546.112511] Bit rate = 77 Mbits/s
Sep 11 20:50:52 mediacentre kernel: [  546.112540] Current LLR  = 87 MLLR/s
Sep 11 20:50:52 mediacentre kernel: [  546.114706] Max LLR allowed = 129166666 MLLR/s
Sep 11 20:51:04 mediacentre kernel: [  557.968200]
Sep 11 20:51:04 mediacentre kernel: [  557.968200] Bit rate = 28 Mbits/s
Sep 11 20:51:04 mediacentre kernel: [  557.968216] Current LLR  = 32 MLLR/s
Sep 11 20:51:04 mediacentre kernel: [  557.969033] Max LLR allowed = 90 MLLR/s
Sep 11 20:51:06 mediacentre kernel: [  559.183995]
Sep 11 20:51:06 mediacentre kernel: [  559.183995] Bit rate = 11 Mbits/s
Sep 11 20:51:06 mediacentre kernel: [  559.184010] Current LLR  = 15 MLLR/s
Sep 11 20:51:06 mediacentre kernel: [  559.184880] Max LLR allowed = 90 MLLR/s
Sep 11 20:51:20 mediacentre kernel: [  573.182887]
Sep 11 20:51:20 mediacentre kernel: [  573.182887] Bit rate = 21 Mbits/s
Sep 11 20:51:20 mediacentre kernel: [  573.182903] Current LLR  = 31 MLLR/s
Sep 11 20:51:20 mediacentre kernel: [  573.183831] Max LLR allowed = 90 MLLR/s
Sep 11 20:51:38 mediacentre kernel: [  591.181815]
Sep 11 20:51:38 mediacentre kernel: [  591.181815] Bit rate = 70 Mbits/s
Sep 11 20:51:38 mediacentre kernel: [  591.181830] Current LLR  = 105 MLLR/s
Sep 11 20:51:38 mediacentre kernel: [  591.184374] Max LLR allowed = 129166666 MLLR/s
Sep 11 20:51:38 mediacentre kernel: [  591.941909]
Sep 11 20:51:38 mediacentre kernel: [  591.941909] Bit rate = 11 Mbits/s
Sep 11 20:51:38 mediacentre kernel: [  591.941918] Current LLR  = 15 MLLR/s
Sep 11 20:51:38 mediacentre kernel: [  591.942659] Max LLR allowed = 90 MLLR/s

The stid135 error was the first time on tuning Rai. The very high MLLR values do seem to occur when the Rai mux is tuned -

Sep 11 20:56:13 mediacentre kernel: [  866.304241] Current LLR  = 105 MLLR/s
Sep 11 20:56:13 mediacentre kernel: [  866.306839] Max LLR allowed = 129166666 MLLR/s

The French MIS transponder has consistently low values in contrast, with no glitches.

[mrwish7]

The long wait time MIS -> MIS does seem to be related to the problem with the Italian MIS transponders.

Switching from French MIS to another French MIS is fairly quick and works fine - both the separate streams on the same transponder (e.g. 12732V MIS1 -> 12732V MIS6) and also between the two transponders (e.g. 12732V MIS1 -> 12648V MIS2).

[crazycat69]

https://github.com/tbsdtv/linux_media/commit/0a3fbba551ddc2cf6a74ff5d4b9077be7aad0e36

[mrwish7]

Thanks @crazycat69 , sorry for the delay - I will try this. I haven't had the time recently.

I will report back.

[mrwish7]

I can confirm the latest changes to LLR calculation seem to fix Rai multistream on 5°W. Thanks!

MIS -> DVB-S2 switching and vice versa now seems to work well. I now seem to have the opposite problem though, trying to lock plain DVB-S seems to crash the driver in a way that causes TVHeadend to totally crash! This isn't so much of a problem as not much that I want to tune is left in DVB-S. This issue like the DVB-S2 issue only seems to happen if MIS has been tuned beforehand. The second tuner on the card is connected to a 19.2°E LNB which doesn't ever need to tune MIS/PLS (as there is none!), and DVB-S works OK on that one.

Thanks again for your help

[crazycat69]

check kernel log after switch from DVB-S2 MIS/PLS transponder to DVB-S

[ikor7]

After tuning to a transponder using multistream (MIS) with PLS, it becomes impossible to tune 'plain' DVB-S2 until reloading the tbsecp3 driver or rebooting the machine. I have been testing using the Italian and French multistream transponders on Eutelsat 5°W, as detailed in this thread on the official TBSDTV forum, from post #6 onwards - https://www.tbsdtv.com/forum/viewtopic.php?f=181&t=25844

The same problem occurs even if I scan the data transponder. For example, Eutelsat 16A, freq. 12507 H. Subsequently, nothing can be scanned from DVB-S2 transponders. Only a driver reset will help. There is no problem with DVB-S.

[crazycat69]

https://github.com/tbsdtv/linux_media/commit/bf63058ea6207875dd5e856af91d11376334d052

[crazycat69]

https://github.com/tbsdtv/linux_media/commit/a2daf45472b598d845a24b37e8295d56890954c6

[mrwish7]

For the DVB-S issue it seems to be muxes with lower symbol rates that just don't lock. Here I tried the following on 30°W -

11329 H 9141 DVB-S2 PLS GOLD+174526 single stream - locked OK, shown in the kernel log 11643 V 4000 DVB-S - did not lock, nothing shown in kernel log 12548 V 29600 DVB-S2 plain - locked OK, shown in the kernel log

Then I moved the dish to 7°E and tried -

10722 V 27500 DVB-S - locked OK, nothing shown in kernel log. 12567 V 17015 DVB-S2 plain - locked OK, shown in kernel log

Nov 13 15:51:08 mediacentre kernel: [254398.462212] Symbol rate = 9141 Ks
Nov 13 15:51:08 mediacentre kernel: [254398.462228] Current LLR  = 28 MLLR/s
Nov 13 15:51:08 mediacentre kernel: [254398.463372] Max LLR allowed = 90 MLLR/s
Nov 13 15:52:23 mediacentre kernel: [254473.646890] Symbol rate = 9141 Ks
Nov 13 15:52:23 mediacentre kernel: [254473.646905] Current LLR  = 28 MLLR/s
Nov 13 15:52:23 mediacentre kernel: [254473.647952] Max LLR allowed = 90 MLLR/s
Nov 13 15:53:43 mediacentre kernel: [254553.027243] Symbol rate = 29599 Ks
Nov 13 15:53:43 mediacentre kernel: [254553.027258] Current LLR  = 89 MLLR/s
Nov 13 15:53:43 mediacentre kernel: [254553.028420] Max LLR allowed = 90 MLLR/s
Nov 13 15:55:10 mediacentre kernel: [254640.485774] Symbol rate = 17016 Ks
Nov 13 15:55:10 mediacentre kernel: [254640.485789] Current LLR  = 35 MLLR/s
Nov 13 15:55:10 mediacentre kernel: [254640.486888] Max LLR allowed = 90 MLLR/s

Switching Italian MIS -> French MIS on 5°W does now seem to work OK, not perfectly but to a usable level. After tuning an Italian MIS mux, trying to tune one of the French ones fails at first but then locks successfully when TVHeadend automatically retries. Kernel log for this, it seems like it does tune on the first attempt but TVHeadend doesn't receive any data until the second attempt (at 16:03:37) -

Nov 13 16:03:22 mediacentre kernel: [255132.865001] Symbol rate = 35293 Ks
Nov 13 16:03:22 mediacentre kernel: [255132.865010] Current LLR  = 106 MLLR/s
Nov 13 16:03:22 mediacentre kernel: [255132.867080] Max LLR allowed = 129 MLLR/s
Nov 13 16:03:28 mediacentre kernel: [255138.680701] Symbol rate = 29499 Ks
Nov 13 16:03:28 mediacentre kernel: [255138.680734] Current LLR  = 89 MLLR/s
Nov 13 16:03:28 mediacentre kernel: [255138.681612] Max LLR allowed = 90 MLLR/s
Nov 13 16:03:37 mediacentre kernel: [255147.976440] Symbol rate = 29499 Ks
Nov 13 16:03:37 mediacentre kernel: [255147.976455] Current LLR  = 89 MLLR/s
Nov 13 16:03:37 mediacentre kernel: [255147.977365] Max LLR allowed = 90 MLLR/s

[crazycat69]

https://github.com/tbsdtv/linux_media/commit/d0a7e44358f28064697e0eed309db03166dcd83b

[mrwish7]

Still some DVB-S issues with TVHeadend. 30°W is the test case I can always replicate it with.

TVHeadend fails to tune both 11644 V 4000 DVB-S and 12519 V 1481 DVB-S. If I disable the tuner and use tune-s2, this then also fails (timeout with no signal lock after several seconds).

If I then run rmmod tbsecp3 and modprobe -a tbsecp3 to reload the module, both frequencies will tune fine using tune-s2, but then if I re-enable the tuner in TVHeadend, they both stop working again.

When the driver has been reloaded, there's no signal problem as you can see -

 tune-s2 12519 V 1481 -system DVB-S -lnb UNIVERSAL
LNB: low: 9750 high: 10600 switch: 11700
opening: /dev/dvb/adapter0/frontend0
frontend: (TurboSight TBS 6903x (Dual DVB-S/S2/S2X))
fmin 950 MHz
fmax 2150 MHz
min_sr 100 Ksps
max_sr 520000 Ksps
HIGH band
22khz ON

Tuning specs:
System:     DVB-S
Frequency:  12519 V 1481
22khz:      ON
Modulation: QPSK
FEC:        AUTO
Inversion:  AUTO
Rolloff:    AUTO
Pilot:      AUTO
Tuned specs:
System:     DVB-S 5
Frequency:  12519 V 1481
22khz:      ON
Modulation: QPSK 0
FEC:        3/4 3
Inversion:  ON 1
Rolloff:    35 0
Pilot:      ON 2
FRAME_LEN:  LONG 0
Bandwidth:  1.9994 MHz
Data Rate:  2.0473 Mbps
CN Failure: 5.5 dB

status Locked | signal -49.7 dBm | snr 11.3 dB | ber 0 | FE_HAS_LOCK

[crazycat69]

https://github.com/tbsdtv/linux_media/commit/a4014d983535748bb82748007ce269ca8365a905

[mrwish7]

Thanks @crazycat69 , that seems to work much better. DVB-S consistently locks now.