TBS6902 - High BER on single MUX

[avgeeklucky]

Bit of a strange bug this, but 11067.5V DVB-S2 on Astra 2G, has been showing a high BER and often fails to lock on. Other MUXes work fine.

I tried to isolate the problem a little bit, a separate satellite receiver box has no problem with channels on that MUX, so that rules out problems with the cable and LNB. The leaves the TBS6902 card and drivers.

It doesn't happen consistently, at the moment it successfully captures about 1 out of 10 times. After doing a fresh upgrade and (compile and reboot) earlier this week seemed to fix the problem, but since yesterday it's back to mostly not working again.

I think that these problems started when I updated debian from buster with a 4.19. kernel, to bullseye with a 5.10. kernel.

uname -a:

Linux 9f3f949d72db 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux`

lsb_release -a:

Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye

Git details: linux_media: tbsdtv/linux_media@910a6099073f0ec1271e5cd888067aa83e421242 media_build: tbsdtv/media_build@945eea79087069a56c4989288c935a2602b3fd92

Relevant lspci -vvv:

02:00.0 Multimedia controller: TBS Technologies DVB Tuner PCIe Card
    Subsystem: Device 6902:0002
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 41
    Region 0: Memory at fe900000 (32-bit, non-prefetchable) [size=256K]
    Capabilities: [50] Power Management version 3
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [70] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Address: 00000000fee01004  Data: 4025
    Capabilities: [90] Express (v1) Endpoint, MSI 00
        DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
        DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
            RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
            MaxPayload 128 bytes, MaxReadReq 512 bytes
        DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
        LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited
            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
        LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
            TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
    Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
    Kernel driver in use: TBSECP3 driver
    Kernel modules: tbsecp3

Output of femon -H with mux in question tuned using TVHeadend:

status       | signal  55% | snr  54% | ber 32406 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  47% | ber 32517 | unc 0 | 
status       | signal  55% | snr  54% | ber 32537 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  46% | ber 32479 | unc 0 | 
status       | signal  55% | snr  54% | ber 32184 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  48% | ber 32392 | unc 0 | 
status       | signal  55% | snr  54% | ber 32518 | unc 0 | 
status       | signal  55% | snr   0% | ber 32578 | unc 0 | 
status       | signal  55% | snr  46% | ber 32262 | unc 0 | 
status       | signal  55% | snr  54% | ber 32206 | unc 0 | 
status       | signal  55% | snr   0% | ber 32228 | unc 0 | 
status       | signal  55% | snr  54% | ber 32460 | unc 0 | 
status       | signal  55% | snr  53% | ber 32466 | unc 0 | 
status       | signal  55% | snr   0% | ber 32270 | unc 0 | 
status       | signal  55% | snr  54% | ber 31780 | unc 0 | 

One of the slow, but successful captures on 11067.5V:

status       | signal  55% | snr  54% | ber 32571 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  46% | ber 32475 | unc 0 | 
status       | signal  55% | snr  54% | ber 32458 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  46% | ber 32363 | unc 0 | 
status       | signal  55% | snr  54% | ber 16214 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  46% | ber 32492 | unc 0 | 
status       | signal  55% | snr  53% | ber 32534 | unc 0 | 
status       | signal  55% | snr   0% | ber 32506 | unc 0 | 
status       | signal  55% | snr  54% | ber 32524 | unc 0 | 
status       | signal  55% | snr  53% | ber 31983 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status       | signal  55% | snr  47% | ber 32512 | unc 0 | 
status       | signal  55% | snr  54% | ber 32496 | unc 0 | 
status       | signal  55% | snr   0% | ber 0 | unc 0 | 
status SCVYL | signal  55% | snr  47% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  55% | snr  55% | ber 15119 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  55% | snr  55% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  55% | snr  54% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  55% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK

Switching to a channel on 11225V DVB-S2, tuned within a second:

status SCVYL | signal  52% | snr  56% | ber 7681 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  55% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  57% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  52% | snr  56% | ber 0 | unc 0 | FE_HAS_LOCK

[OldAVman]

Just to confirm your findings. I'm also using a TBS6902 card with this driver on Fedora 34 with kernel 5.13.6-200.fc34.x86_64. I've been viewing this transponder for a long time with no issues at all. It suddenly went off about 3 weeks ago and subsequent scans fail to find anything at all. I'm in the UK and have good signal to noise. All the other transponders are working fine including the UHD tests on Astra 2F. Because of this I assumed a satellite fault but could find no reports of changes or faults on the web. It seems you've confirmed the transponder is still working on other equipment. I think I have another make of card somewhere so I'll try this in another machine to see if the problem is specific to the TBS6902. I guess it's possible the transponder has a fault and is running on lower power so is only receivable on more sensitive equipment?

[deeptho]

I do not have this card, but I have another one which I think uses the same driver: tas2101 That mux is working well here.with an SNR of 15dB. It is difficult to interpret your percent values, so I do not know if your signal is strong, but you report good results on other receivers, so the signal is probably fine. There is also nothing special on this mux.

A possible reason for problems is an offset in the local oscillator of the LNB. This makes it more difficult to capture the signal and leads to similar problems as you describe. In theory it should then happen on all muxes, but in my experience more problems occurred on specific muxes.

There can be other reasons for the problem of course, such as interference from other satellites (depending on your location)

You could check using my drivers and software: these report the actual frequency tuned to https://github.com/deeptho/neumodvb https://github.com/deeptho/linux_media You could be the first user on debian ;->

You could also try with the standard drivers tuning 1 Mhz below or above the correct frequency and see if it makes a difference.

In general: you will need to capture some kernel driver debug messages, which may involve some experimenting, because by default the drivers may not produce a lot of output. However, I expect these messages to not produce much useful information for your problem. They will probably tell you what you already know: tuning fails, but you never know.

[OldAVman]

Just to update: I have tried another box which has an older TBS8922 PCI card connected to the same dish and lnb and it scanned the transponder instantly with good reception on all the channels. Unfortunately when I reverted to the original box with the TBS6902 that too is now working properly again. Nothing has changed in terms of s/n etc so I'm left with no explanation. Until now I haven't been able to find anything on that frequency for a couple of weeks. All the other frequencies have been completely reliable throughout. Just have to see if it fails again and try to dig a bit deeper if it does.

[deeptho]

That is an annoying problem. Other possible cause is a temporary glitch in voltage or diseqc setting. tvheadend has some options to add delays between commands.

Things taht could help find the problem when it next occurs -run a spectrum scan (requires my drivers) -check if a reboot fixes the problem -check if a complete poweroff (wait 30 seconds before turning pc back on) fixes the problem

[avgeeklucky]

A day after writing this issue, 11067.5V started working fine for me again. Nothing has changed in the mean time. The weather has improved a bit, but usually that effects everything, not just one mux.

I do not have this card, but I have another one which I think uses the same driver: tas2101

dmesg mentions TBSECP3 ... I don't know 🤷‍♂️

That mux is working well here.with an SNR of 15dB. It is difficult to interpret your percent values, so I do not know if your signal is strong, but you report good results on other receivers, so the signal is probably fine. There is also nothing special on this mux.

Currently getting SNR of 11dB (56%) and strength of -45.3dBm (55%). Percentages about the same as before.

Unfortunately when I reverted to the original box with the TBS6902 that too is now working properly again

So maybe there was some issue with the transponder on the sat. Currently just hoping it keeps working.

[OldAVman]

Still working for me. I too am leaning towards a fault but as that particular transponder carries, amongst other things, some important ITV regions I would have expected to find many reports of an outage on the internet. I'm using my own software (based on the V4L code) for tuning and scanning but have not had any other problems for some years. I had tried scanning +- 0.5 MHz with no result. I have a bigger dish than is usual for my region as I sometimes look at other satellites, so s/n has not been a problem even in bad weather. The weather was not unusual during the outage period. All very strange.

[SpeedProg]

I have similar problems with some tuners just not working properly. I even can sometimes lock a mux on one of the tuners on the same card (TBS 6902) and can't do it on the other tuner. Using unicable. Setting wrong frequencies for the MUX (like 11523000 instead of the actual 11523250) does some times make it work on both. Then at other times, they can just all work with the proper frequency set.

[deeptho]

Some things you can check: 1) be sure that it is not a diseqc problem (i.e., a mux from another sat) 2) If the problem happens, does it go away if you reload the driver? 3) and does it go away after a reboot. 4) is the problem occuring more often if you send diseqc commands more than once in quick succession *e.g., with tvheadend)?

I recently had something somewhat similar (some muxes failing to tune, but dvbs qpsk ones working) with another card after working on my dish (disconnecting cable). That problem was triggered by sending diseqc command multiple times. There is no good reason for that, and I am not sure what is the problem: the card, the switch or the lnb.

In the past I also had such a problem when an lnb started to fail.

This is all speculation, but who knows it could lead to a better diagnosis.

[OldAVman]

Just an update to my report: Despite my box being used practically every day (main household TV) this problem has not recurred on either the original 11067.5 or indeed any other Astra 28 frequency. I can only think that in my case at least the original problem was indeed at the satellite end. I've made no changes to the dish, software or hardware in the meantime. As several months have passed I think something would have shown up by now if my problem was with the card or driver.

[SpeedProg]

thanks. I replaced the LNB nothing got better. But then I redid all the cables and splitter and now there hasn't been problems for weeks. So I guess there was something bad in there.