[SOLVED] transponders failing (TBS5680 on a Synology DS 211)

[MarcoM]

I've recently bought a TBS 5680 along with a license for the DVBLink Software from DVBLogic. DVBLogic states on their website, that this combination is compatible with my DS 211 from Synology.
I've managed to get the Device itself working - but the Transponder Scan seems to be faulty.

My DVB-C cable provider is "Kabel BW" (Germany), the transponder list is checked by DVBLogic and 100% correct. But some transponders report "tuning failed" (unlucky for me, the more important private channels from germany are located on just those transponders not working)
However, those channels found are reported with a signal strength around 25% and quaility of 3-5% (apart from that, at least they are working flawless when being watched).

The List of failing transponders:
113000, 6900, QAM64
121000, 6900, QAM64


The same cable interface connected to a "normal receiver" does in fact work just as expected, signal and quality just fine, no failed transponders, all channels available.

I've allready contacted DVBLogic support. They allready know about this problem from other customers. According to the DVBLogic Team the issue is related to a driver problem. They also stated to be in touch with you disussing the issue, but cannot say anything about a possible ETA.
A quote of "Oberon", a staff member of the DVBLogic Support Forum (administrator):

[...]
Anyway, I am pretty sure that the issue is in linux drivers of TBS5680, more specific with tuning so called VHF frequencies (75-130 MHz range). The issue has to be fixed by TBS. We will contact them about it[...]

Right now, I have a theoretically working solution (The channels I could scan are working just fine even when watched streamed over wlan onto my tablett) but practically a total mess.
The TBS5680 is the only DVB-C Device WITH a CI Slot stated compatible to my Synology NAS (ARM Marvell based) using the DVBLink Software, therefore I would greatly appreciate any kind of solution, instead of just abort and sending everything back to the seller.

- edit -

As this might be a linux driver issue (according to DVBLogic), I'll attach the dmesg and the uname -a outputs (as requested in the announcement "How to report a problem with TBS Linux drivers". the command lsusb unfortunately is not installed on the used linux derivate.
uname -a =>
Linux IcePool 2.6.32.12 #3202 Fri Mar 1 01:04:14 CST 2013 armv5tel GNU/Linux synology_88f6282_211

the file

dmesg_log.zip

dmesg output

(6.92 KiB) Downloaded 309 times

Is there anything else I can provide or do in order to speed up the process?

[steven]

Hi MarcoM

Our Euro_support have answered you in the email,Please have a check,
and here is the detail information,maybe help others.

hi Marco,

i'm not sure why, but your post is the only one in the forum that
doesn't allow me to reply to it, i.e. it's missing "reply" button
altogether and thus i can't write to it in the forum. so, i will
appreciate if you can copy&paste my reply to you here in the forum and
make it public, because that will help sorting out the problem - in case
there are other users affected by it.

so, first of all i don't agree with what DVBLogic support explained to
you, as well it's nothing of what we actually discussed with DVBLogic
support - let me tell you the full story - several weeks ago we were
contacted by another user of TBS 5680 in Germany together with Synology
DS213 NAS and DVBLink software with basically the exact same complain as
yours - in his case actually the frequencies that can't be locked were:

a) 121 MHz, 6900 kSps, QAM64
b) 130 MHz, 6900 kSps, QAM64

i guess depending on the his area they contain the same channels as
what's on 113000 and 121000 Hz in your are.

so, we've done as much as possible detailed investigation of the case:
we acquired data steams from those frequencies of "Kabel BW" network and
using signal generator/modulator card tested them on PC running Linux
(i.e. the same drivers as the one that run in Synology NAS) and
everything works fine on our tests - i'm attaching picture of it:

* tbs5680_on_pc_scan_121mhz.png

so, from our point of view the problem is related to the NAS
configuration somehow - for example NAS hardware or DVBLink software and
not to our drivers. in fact the only way that real investigation can be
made is on the PC to be installed both Windows and Linux - we compare
the work of the drivers there and exclude the NAS hardware - that way
really the root cause of the problem can be narrowed down.

best regards,
constantine

Thanks

[cody]

it's fixed for me now and i can post too. so, here is the picture of our test:



so, please, anyone having such problem - contact us, we need someone to provide us PC with remote access to check on the real live signal. thank you.

[MarcoM]

sorry for that, the email was catched by my spam filter, don't know why...
For now I've whitelisted tbsdtv.com ...

I'll set up a sandbox pc with both windows and linux, and attach the TSB5680 directly to that pc and try them out. If the problem still occurs without Synology hardware beneath, I could provide you direct access to that machine - as requested.

In either case, I will post my results as soon as possible.


--- edit ---
I have completed by sandbox tests.
interesting enough, some transponder could not be found either on windows nor on linux.
On Windows the transponder on 370 MHz, 6900 kSps, QAM 256 wasn't responding - the ones on 113 and 121 MHz in fact WERE responding - strange
On Linux (Ubuntu 12.10 desktop edition with all available updates, and the newest driver available at your website [TBS5680 Linux Driver v130318] ) the situation is even worse than on my synology... without counting them exactly, a whole bunch of transponders did not work, stripping me off most of the channels.
however, after the scan, I made a dmesg with really interessing content.

the following lines can be found in the attached dmesg:
[ 890.556763] DVB: adapter 0 frontend 0 frequency 41800000 out of range (47000000..870000000)
[ 890.559232] DVB: adapter 0 frontend 0 frequency 42600000 out of range (47000000..870000000)
[ 890.564554] DVB: adapter 0 frontend 0 frequency 43400000 out of range (47000000..870000000)
[ 890.566567] DVB: adapter 0 frontend 0 frequency 44200000 out of range (47000000..870000000)
[ 890.568298] DVB: adapter 0 frontend 0 frequency 45000000 out of range (47000000..870000000)
[ 890.569501] DVB: adapter 0 frontend 0 frequency 45800000 out of range (47000000..870000000)
[ 890.570683] DVB: adapter 0 frontend 0 frequency 46600000 out of range (47000000..870000000)
[ 903.625363] DVB: adapter 0 frontend 0 frequency 39400000 out of range (47000000..870000000)
[ 903.627568] DVB: adapter 0 frontend 0 frequency 38600000 out of range (47000000..870000000)
[ 903.629068] DVB: adapter 0 frontend 0 frequency 40200000 out of range (47000000..870000000)
[ 903.629479] DVB: adapter 0 frontend 0 frequency 41000000 out of range (47000000..870000000)
[ 903.629897] DVB: adapter 0 frontend 0 frequency 37800000 out of range (47000000..870000000)
[ 903.630316] DVB: adapter 0 frontend 0 frequency 34600000 out of range (47000000..870000000)
[ 903.631963] DVB: adapter 0 frontend 0 frequency 35400000 out of range (47000000..870000000)
[ 903.633998] DVB: adapter 0 frontend 0 frequency 36200000 out of range (47000000..870000000)
[ 903.635982] DVB: adapter 0 frontend 0 frequency 37000000 out of range (47000000..870000000)
[ 903.638075] DVB: adapter 0 frontend 0 frequency 11300000 out of range (47000000..870000000)
[ 903.640089] DVB: adapter 0 frontend 0 frequency 12100000 out of range (47000000..870000000)
[ 928.017148] DVB: adapter 0 frontend 0 frequency 13000000 out of range (47000000..870000000)

the dmesg:

dmesgX86.zip

(18.63 KiB) Downloaded 324 times

Maybe I made a mistake, but I can't figure out where that might be. I've even checked the transponder config file (I can attach the file if needed). Also as said before, if this is of any help, I could provide you with a temporarily teamviewer session directly to the ubuntu machine.

[cody]

Hi and thank you for preparing such testing environment - you made real good progress and i believe the few new issues you faced on PC are easily resolvable - here are my suggestions:

a) in Linux "frequency X out of range" error message should be just error in your configuration file. so, here is how to test - the same way as i made the test on the picture here:

viewtopic.php?f=79&p=28314#p28361

so, the test is made with 'scan' and the exact command line is:

# scan dvbc.conf

where i'm putting here the content of "dvbc.conf" configuration file:

C 121000000 6900000 NONE QAM64

which was used with 'scan' during the test - you can change "121" to "130" or other frequency and test them one by one. also, on my test as result of 'scan' the following output is generated:

sixx:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:502:503:17504
SAT 1:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:202:203:17500
kabel eins:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:302:303:17502
ProSieben:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:602:603:17501
N24:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:402:403:17503

which can be copy&paste to "channel.conf" file for use with 'czap'.

b) please, note that 370 MHz is QAM256, while 121, 130 MHz, etc are QAM64. so, maybe on your test in Windows 370 MHz failed, because you didn't set modulation to QAM256. anyway, at the moment the question we need to answer is if on PC in Linux there is difference between Windows and Linux on those frequencies like 121 MHz - so i hope a) will help to make a test in Linux.

thank you!

[MarcoM]

I've tried out "a)" using scan with the suggested dvbc.conf.
Unfortunately the result wasn't as expected:

$ scan dvbc.conf
scanning dvbc.conf
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 121000000 6900000 0 3
>>> tune to: 121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64
WARNING: filter timeout pid 0x0011
WARNING: filter timeout pid 0x0000
WARNING: filter timeout pid 0x0010
dumping lists (0 services)
Done.


the dvbc.conf:

dvbc.conf.zip

dvbc test config file

(193 Bytes) Downloaded 359 times

I also tried using 113000000 as frequency, which generated the same warnings as shown above.

[cody]

that's actually quite good result, because it shows you have lock - what failed and caused "WARNING: filter timeout pid 0x0011" is the data transfer, which is initiated by 'scan' after lock is acquired - i guess that happened due to CAM inserted in the CI slot or something like that, because 'scan' is very simple tool and it can't control the CI.

so, your test basically confirmed 113 MHz and 121 MHz work on PC in Linux, which means the problem is isolated to something on the NAS and it's not our drivers which are the same in all Linux systems. anyway, in order to remove any doubt from the above test and that there is really lock on 113 MHz and 121 MHz, please, do the following further tests:

A) use DVBlast:

# dvblast -m qam_64 -f 121000000 -s 6900000

B) even simpler test than A) - create very basic "channel.conf" file with just one line:

test:121000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_64:1:1:1

and then use 'czap' with it:

# czap -c channel.conf "test"

and check if the output would be similar to (i.e. indicating FE_HAS_LOCK):

status 1f | signal 8585 | snr c0c0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

once again based on the error message "WARNING: filter timeout pid 0x0011", which has nothing to do with the lock, as i already mentioned, i expect both A) and B) will report signal lock, which means the whole issue is isolated to the NAS and it has nothing to do with us, because both 5680 hardware, as well it's Linux drivers can lock to those frequencies.

[MarcoM]

It seems correct that I can get a lock - at least as shown by the tests you'd mentioned.
Files:

dvbTest.zip

channel.conf and console log created while testing

(1.69 KiB) Downloaded 240 times

However there are some things which confuse me, maybe you could explain them to me as well:

- dvblast shows some output lines which are looking like errors to me, e.g.
* "debug: frontend has lost carrier"
* "debug: frontend has lost FEC"
* "debug: frontend has lost lock"
* "debug: - Bit error rate: 1048575"
a.s.o.
-> are these messages pointing to some kind of error?

- I don't have a QAM inserted into the CI Slot of the TBS5680
-> even if those filter timeouts result to failing CI as you suspected, how can that happen without a QAM all along?

- Why am I able to scan and get all Channels, including those on 113 MHz and 121 MHz when using windows - but not wenn using linux?
-> If I can get a Lock on those transponders, where do my problems come from? Just to remember: we are talking about the same X86 architecture (Intel Core 2 Duo) with just booting from different partitions.

[cody]

hmm, the things are not completely fine - i mean on your 'czap' log the lock is lost from time to time and it's the same on dvblast log as you pointed out. however, at least there is some signal lock, no matter it's unstable compared to the NAS, which means the problem on the NAS is something different. anyway, i'm more concern what happens on the PC and why you lose the lock from time to time. so, in Windows if you lock is it stable? that should be easy to check, because on your 'czap' log it seems lock lost is every few seconds. thanks.

[MarcoM]

unfortunately I'm not at home until friday. I'll test the lock using windows at weekend.
if I may ask, is there any tool available on windows similar to scan or dvblast on Linux?
the only way for testing purpose i know is using the tbsview software provided with your device.

at least, everything would be fine if I'm able to watch a channel located on one of the problematic transponders (eg 'RTL' at 113 mhz), wouldn't it?

what is also wondering me, how can that be a hardware issue to the nas, when most transponders work, and just those at 113-130 mhz do not? I thought tuning is the job done by the tbs box and everything else is handled at software level by the corresponding driver? I just want to completely understand what is going wrong, so that (maybe) i could work on that...
having a tv stream server within my network capable of viewing encrypted channels (in case i would buy a qam in the future) would be extremely nice to achieve...