TBSDTV Community Forum

no problem, test when you have time - currently your testing environment is the best lead we have to solve the problem. so, let me explain - we're trying to understand what's going on, but the idea the NAS is related is that maybe it interference with 5680 on hardware level, i.e. it generates noise that affects tuner performance of 5680 on those frequencies. another option and what i'm trying to rule out at the moment is that some driver setting affects the tuner performance on those problematic frequencies - for example that if you have 8 dB signal in Windows you can still lock, but let's say for example in Linux you need 10 dB due to those software settings - that's just one idea, because as you can see from the screenshot i posted before those frequencies can be locked - what we need to find out is if in Windows, Linux and on the NAS it needs the same dB level to lock or not - that will explain if NAS generates noise and induces in 5680 tuner somehow, there is setting in the Linux drivers that affects the tuner performance or both - from my experience strange problems are always caused, not by single, but by few different problems combining. anyway, we're in a right direction - with your current test environment we should be able to understand it and fix it. thank you.

BTW, when you test in Windows, please, double check and make sure that modulation (QAM) value set in Windows is the same as in Linux, because the driver can't auto-detect that and it entirely depends on what the application software tells about the modulation. one another idea i have is that maybe different modulation is set in your Windows tests - maybe even more correct one than QAM64 we used on the Linux tests.

Hello,

i'll try to install the same configuration as Marco, and i have the same issues with my Synology DS212j. My cable provider is Unitimedia (Germany). On my tv i have a signalstrenght of 90% and a signal quality of nearly 100%, but on the TBS 5680 i only have a strengh of approx 25% and a quality of approx 5%. An the quality of the tuned channels is partly very poor and a lot of channels are missing.
Currently i didn't try it on a Windows System, but i will do it during the next days, but i think that i have the same issues as Marc before.

So i'm very interested about your results of your tests.

Regards
Thomas

Hello Thomas, those values for signal strength and quality are sounding familiar to me... It is quite interesting that the same connection on a TV shows a so much better signal (or at least seems to) than on the 5680.
But apart from that, the poor signal appears on windows as well as on linux, with the only difference, that on windows the 'missing channels' just work fine.

okay, now to my tests and their results...

at first I have to mention that my last results are possibly invalid. All of a sudden my windows installation lost the signal every now and then, similar to the linux dvblast results (lock lost). In the end I've got more of a "picture show" (in this area we call it a "Dia show") than of a "moving image"...
After that I checked the connection cable - long speech short sense, it got broken on one side...

After replacing the cable with a brand new one (of course high quality, digital compatibilty aproved) I have redone all tests on both operating systems.

On Windows absolutely everything is fine. all channels could be scanned, no signal lost, no tuning failures. Every channel found is working, I even watched one of the '113-er channels' for at least 15-20 minutes with not a single problem. (apart from the already reported signal strength of max. 25% and quality of around 5%)

On Linux I've got tuning failures again.
In short, at 113 and 121 MHz nothing changed, other frequencies mostly worked out.
Also signal locks were lost on dvblast as well, but at least not that frequent as it did last week. It got lost every 4-5 seconds (last week it was nearly one lock lost per second)


I have attached the files and logs of all tests to this post.



Is there anything else I could do?
(As requested I have compared the transponder lists and modulations used for windows and linux, especially for the transponders not working on linux, they match.)


PS: It should be noted that, when using a working frequency, like 346 MHz, other frequencies were automatically discovered and tested. See scan_346.log for example. What you can see in the log is, that when jumping to 130 MHz, scan uses a modulation of QAM_256 instead of the QAM_64 you mentioned earlier. No need to say that it failed.... I even tried a scan manually using a QAM_64 - it failed either...

Marco, thank you for the test details and my first comment is actually to both Thomas and you - please, do not mistake signal statistics in percentage (as your TV sets do), which is meaningless compared to statistics in dB, dBm, AGC or even in 'raw' values from the hardware, which at least Linux drivers for 5680 reports. so, the drivers can be set always to report 100% when there is good signal present (as you TV set most like does), but that will be even more meaningless. in fact most devices that report statistics in percentage, report something fake to make it look good from user point of view. so, 5680 driver reports 'raw' SNR (or 'quality') values in Linux, which allows to calculate real dB and because those 'raw' values are only 2-digits and value in Linux for SNR is 4-digit, the drivers put together that value 2 times next to each other. i don't know how good i'm explaining it, but for completeness let me give example and it will involve a little hexadecimal digits too from Marco's own logs:

status 1f | signal 5050 | snr 1212

you see SNR value is the same number repeated 2 times, as i've just explained - that means the 'raw' SNR value is 0x12 in hexadecimal or 18 in decimal and that after calculation, which i will save here, gives 29dB signal, which is indeed very strong. also, please, note that calculation for QAM64 and QAM256 signal is different, but basically all frequencies that Marco can lock and works good give around 29dB.

so, there is nothing wrong with 5680 and the signal levels it receives - what Marco last tests confirm and suggest that Linux driver do some different setting for frequency range around 120-160 Mhz, which results in the same dB level can be lock stable in Windows, but the lock is unstable in Linux. i'm already comparing the settings, but that's quite a lot of work and it will take time - i probably can tell more and even hopefully provide fixed driver in about 1 week time or so from this moment.

also, what Marco said when he scans frequencies that can be locked that all other frequencies are found and scanned automatically is correct and what should happen - that's the so called "network scan".

anyway, bottom line is, because Marco made all tests in the same computer system just switching between Windows and Linux that proves indeed there is some different setting in the 2 drivers that affects the performance for those frequencies around 120-160 Mhz. also, i hope my long comment about SNR helps you understand what Linux driver reports as SNR and why calculation like (1212 / ffff) * 100 in percent has no meaning and it's actually wrong. so, the whole problem is some tuner setting in the driver and not that reception of 5680 hardware is bad.

so, i want to thank one more time Marco for his tests, because they are very helpful, since when we modulate/generate such signal with frequencies around 120-160 Mhz in our lab it's very good and it can be locked, as i showed here:

viewtopic.php?f=80&t=8299#p28361

which now is proved is not the case with live signal.

cody wrote:[...]i don't know how good i'm explaining it[...]

perfectly fine, thank you.
In fact I didn't look for the units, my tv indeed provides "percentages"... -> a totally clear ' '

Anyway, thanks for your ongoing support. Hopefully those tests will prove to be helpfull enough to find a solution in the end.
Good luck cody

Marco, i spent most of the time today investigating different tuner settings in Windows and Linux driver - i found one that seem relevant, because it affects frequencies lower than 190 MHz and both yours and that reported by Thomas are in that range. so, hopefully, that's what wrong, but if the test driver i prepare is still not working, please, don't be disappointed - it may require several trials and errors in case it's not a single wrong setting, but multiple. most important is that thanks to your previous tests, now it's clear for what to look, because before it was just shooting in the dark - it could be anything, but now it's quite clear it's some tuner setting wrong.

so, i uploaded the test drivers here:

"tbs5680fe_v130413_01.zip"
http://www.basicupload.com/llt0bh1m5yu8

"tbs5680fe_v130413_02.zip"
http://www.basicupload.com/lfdfokb1ekzt

how to test:

1. copy files from "tbs5680fe_v130413_01.zip" to:

linux-tbs-drivers/v4l

2. re-build and re-install the driver as how it's done the usual way

3. after reboot to load the new driver, plug and unplug your 5680 box from the power - that in order to lost all settings from the previous driver and the new one initialize it

4. lock some working frequency and check 'dmesg' output for:

"TBS5680 TEST V130413_01"

that in order to confirm you're really running the test driver

5. now test the problematic frequencies like 121 MHz

6. if we're lucky problematic frequencies like 121 MHz like will work - in such case, please, repeat the above test steps with "tbs5680fe_v130413_02.zip" - it's similar to "tbs5680fe_v130413_01.zip", but it's further optimized

when you had the time to do the test and have some results, please, report them here. thank you.

I have tried to get the first driver archive "tbs5680fe_v130413_01.zip" working following your instructions.
Allthough you had not requested that, I allowed myself to log stdout and errout of make and make install into txt files.
the used command:

Code: Select all

$ make >tbsmake/make.log 2>tbsmake/make_error.log && make install >tbsmake/install.log 2>tbsmake/install_error.log

After rebooting the system, the problems started.
there seems to be a poblem with your drivers, because when starting with the device connected all other usb devices won't get powered on when the login screen appears - rendering me unable to log into my computer (having a usb keyboard). As soon as I disconnect the TBS5680 from Power or from the USB port, my computer and it's peripherals start to respond.
When I reconnect the device after loggin in, the other devies stay active, but I cannot use the tuner.
scan tells me "WARNING: >>> tuning failed!!!" - no matter which frequency I use
czap tells me "ERROR: frontend device is not a QAM (DVB-C) device"

The dmesg output:

Code: Select all

$ dmesg | grep -i tbs

dmesg wrote:[ 156.213547] dvb-usb: found a 'TBS 5680 CI USB2.0' in cold state, will try to load a firmware
[ 156.223481] dvb-usb: downloading firmware from file 'dvb-usb-tbsqbox-id5680.fw'
[ 156.225527] tbs5680: start downloading TBS5680 CI firmware
[ 156.344012] dvb-usb: found a 'TBS 5680 CI USB2.0' in warm state.
[ 156.344077] DVB: registering new adapter (TBS 5680 CI USB2.0)
[ 156.344079] tbs5680: read eeprom failed.
[ 156.354771] tbs5680fe: attach failed : 01
[ 156.354775] dvb-usb: no frontend was attached by 'TBS 5680 CI USB2.0'
[ 156.354882] dvb-usb: TBS 5680 CI USB2.0 successfully initialized and connected.
[ 156.354940] usbcore: registered new interface driver tbs5680
[ 156.364339] dvb-usb: TBS 5680 CI USB2.0 successfully deinitialized and disconnected.
[ 158.128820] usb 1-2: Product: TBS 5680
[ 158.128822] usb 1-2: Manufacturer: TBS-Tech
[ 158.129099] dvb-usb: found a 'TBS 5680 CI USB2.0' in cold state, will try to load a firmware
[ 158.130801] dvb-usb: downloading firmware from file 'dvb-usb-tbsqbox-id5680.fw'
[ 158.133207] tbs5680: start downloading TBS5680 CI firmware
[ 158.252026] dvb-usb: found a 'TBS 5680 CI USB2.0' in warm state.
[ 158.252256] DVB: registering new adapter (TBS 5680 CI USB2.0)
[ 158.463281] IP: [<f8c24558>] tbs5680fe_attach+0x68/0xf0 [tbs5680fe]
[ 158.463295] Modules linked in: tbs5680fe(PO) dvb_usb_tbs5680(O) dvb_usb(O) usb_storage joydev hid_generic usbhid hid vesafb tda1004x(O) saa7134_dvb(O) videobuf_dvb(O) dvb_core(O) saa7134_alsa(O) rfcomm bnep bluetooth parport_pc ppdev snd_hda_codec_hdmi tda827x(O) snd_hda_codec_analog fglrx(PO) tda8290(O) tuner(O) ir_lirc_codec(O) lirc_dev(O) ir_mce_kbd_decoder(O) rc_asus_pc39(O) ir_sony_decoder(O) saa7134(O) ir_jvc_decoder(O) coretemp kvm_intel ir_rc6_decoder(O) kvm ir_rc5_decoder(O) ir_nec_decoder(O) rc_core(O) videobuf_dma_sg(O) videobuf_core(O) v4l2_common(O) videodev(O) media(O) snd_seq_midi snd_rawmidi snd_hda_intel snd_hda_codec snd_hwdep snd_seq_midi_event asus_atk0110 snd_pcm snd_seq snd_timer snd_seq_device tveeprom(O) microcode mac_hid snd x38_edac edac_core soundcore lp parport serio_raw lpc_ich snd_page_alloc firewire_ohci sky2 pata_jmicron firewire_core crc_itu_t
[ 158.463366] EIP is at tbs5680fe_attach+0x68/0xf0 [tbs5680fe]
[ 158.463413] [<f8841e1b>] tbs5680_frontend_attach+0x5b/0x1f0 [dvb_usb_tbs5680]
[ 158.463438] [<f8841039>] tbs5680_probe+0x29/0x40 [dvb_usb_tbs5680]
[ 158.463629] EIP: [<f8c24558>] tbs5680fe_attach+0x68/0xf0 [tbs5680fe] SS:ESP 0068:f7631b50

I had retried the installation process 2 times, and validated the usb problems when starting the system at least 5 times.
Anything else I could do or try out?


PS: Don't worry, I know the Try & Error procedures necessary when doing integration tests from my own profession - I didn't expect things to work immediately

i didn't request collecting logs during the build, installation and loading of the drivers, because no problems were expected there since no changes in those parts were made in the drivers - the changes made are executed after you run some application software and try to lock, not during load, when the crash occurs for you. that's why the new problem you have makes no sense - in fact i already re-tested and the drivers do not crash and load fine for me. so, maybe some other changes occurred in your test system in the mean time - if you revert back to old "retail" driver you was using for testing - are they still load and work fine for you? that's really totally unexpected and surprising new problem considering what changes were made to the drivers. so, i have no other ideas for the time being except at least to confirm the "retail" drivers you installed before the new test drivers still work in your system or now they fail too.

Marco, i'm quite confident the last problem is something isolated to your environment and most likely the change that occurred in your environment will cause the same problem with the old release driver you successfully installed and tested before. i'm that sure, because i even make on completely different test computer clean installation of Linux and the new test driver and there were no any crashes. so, i believe it doesn't worth more time in investigating that last problem - it's better just install new test environment and that way you can even make it as close as possible to mine - i believe it won't take more than 30 minutes to setup it:

1) install "ubuntu-12.10-desktop-amd64.iso" and setup your Internet connection (i don't install any updates, just waste of time for a fast test and also could be some of those updates causes the crash problem)
2) install kernel-headers and dvb-apps (which install 'czap'):

# sudo apt-get update
# sudo apt-get install linux-headers-$(uname -r)
# sudo apt-get install dvb-apps

3) build and install the test drivers and test