RE: stk7700d problem
Apologies for resending. Mailing list bounced the email the first time becuase it wasn't plain text format. I have a dual USB DVB-T tuner which is sold under the brand Kaiser Baas KBA 01004 but under the hood looks pretty much the same as the Emtec s830 http://linuxtv.org/wiki/index.php/Emtec_S830 Whilst the device is recognised and seems to load ok, locally the only station that it seems to be able to tune is the a community TV station which transmits on QPSK. All the other TV stations are detected but the BER is too high which to me would imply that the devices LNA is proably not being turned on correctly. In heading down that path I have sat and captured the USB communications both under windows and Linux with the intent to compare the two and work out which gpio is being used to turn on the LNA under windows and then duplicate that under Linux. Well that was the intent but the behaviour I am seeing under Linux is a bit strange and I think resolving that might explain why the device has not worked in the past. Specifically, the device is identified as 1164:1e8c and within dib0700_devices.c proceeds to do a stk7700d_frontend_attach. This tries to set GPIOs 6,9,4 and 7 to 1, then it tries to set GPIO10 to 0 before resetting it to 1 and then finally tries to set GPIO 0 to 1. The driver reports no problem doing this but when you drill deeper you find that it does not seem to be doing what it is supposed to. That is, irrespective of which GPIO is set to 1 or 0 the same message is sent to the device over the USB interface. Specifically the USB message as seen in wireshark is 40 0C 00 00 00 00 03 00 00 00 00. Drilling further still I can see that stk7700d_front_end_attach calls dib0700_set_gpio within dib0700_core.c. Within dib0700_set_gpio the main data seems to be loaded into st-buf. The contents of st-buf seem to be ok. That is, when setting any of the GPIOs st-buf[0] is always 0x0C, st-buf[1] follows the GPIOs eg GPIO6=8, GPIO9=14, GPIO4=5, GPIO7=10, GPIO10=15 and GPIO0=0 and finally st-buf[3] is 0x80 when setting GPIO10 to 0 and 0xC0 when setting any of the GPIOs to 1. dib0700_set_gpio subsequently calls dib0700_ctrl_wr within dib0700_core.c but it was at this point I decided that surely this part of the code is pretty robust as it seems to be common for a number of devices and a problem would have been spotted long ago. My question is whether any one has any ideas why I am seeing the same USB message irrespective of which GPIO is being set/reset? Patrick, I have CC'd you specifically as your fingerprints seem to be all over the Dibcom code and presumably you are very familiar with it. Happy to run additional tests and captures as required. Regards Pete -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Dib7000/mt2266 help
Hi Patrick, Thank you for replying. In answer to your questions: Are you sure it is a driver problem? No but given the very same device on the very same antenna system works ok under Windows it seemed like a good place to start. If the BER stays at this value it could also mean that the channel-configuration is wrong. Are you using a channels.conf which has all parameters set, or are you doing a channel-scan-like tune (all values are set to AUTO). I have attached a copy of the channels.conf file I have been using. It was generated by hand based because the scan and w_scan commands would time out for all stations except C31. The information was obtained from a variety of sources on the internet but mostly from http://igorfuna.com/dvb-t/australia/ I am located in Melbourne Australia. Looking in the file you can see that most paramaters are defined except for inversion which is left as auto. There are usually some adaptations board-designing companies do to improve reception quality (adding external LNAs and things like that) that are of course handled by the Window-driver, because it is created by the manufacturer and not by the Linux-driver, because (in this case) the driver was released by the chip-manufacturer. I agree this could be the case and indeed changing the force_lna_activation module parameter seemed to do nothing which would make me suspect that the lna control GPIO on this device is not that same as what is implemented in the driver. Challenge is there seems to be no information around about the DIB7000 or the MT2266 otherwise I would just trace the connections manually using device pinouts. Is the device toggling between FE_HAS_LOCK and no FE_HAS_LOCK or does it stay constantly at The device stays constantly on FE LOCK after the initial tune. Attached are brief snapshots of tuning using tzap for the different frequencies. Whilst this only shows a few seconds worth of data, the output is more or less the same over an extended period. Please try whether you can achieve the BER lowering by moving the antenna or using a better one. If this helps, it really means that the windows-driver does something more the board. Not really practical to move the antenna its up on a mast and indeed as the existing analogue stations are still transmitting from the same tower I know that I have a good signal with no multipath. Other TV sets with digital tuners on the same antenna also report excellent signal levels. I doubt that the chip-driver needs to be changed, more likely the GPIOs of the dib0700 (in dib0700_core.c) or of the dib7000 are used to turn on or off a frequency switch or a LNA. Yes, I suspect that you are right. Challenge is that without any documentation on the devices you are flying blind to reverse engineer the design. Good point, what are the frequencies you're tuning ? The frequencies I have been tuning are listed below but also of interest is that they all use 64QAM whereas the station that works uses QPSK which to me says this is a signal problem and as you state above, probably tied in with a LNA as QPSK is more robust in comparison to 64QAM which is why it has probably been used by C31 as they don't have the need for the higher throughput and have a more modest transmission power compared to the others.So they get more bang for their buck but have the down side of only a single SD stream. C31 557.625 MHz QPSK Works ok. ABC 226.5 MHz 64QAMDoesn't work 7 177.5 MHz 64QAMDoesn't work 9 191.625 MHz 64QAMDoesn't work 10219.5 MHz 64QAMDoesn't work SBS 536.625 Mhz 64QAMDoesn't work Happy to hear your or anyone else's thoughts. Regards Pete From: pboettc...@kernellabs.com To: peter_tille...@hotmail.com; linux-media@vger.kernel.org Subject: Re: Dib7000/mt2266 help Date: Sat, 12 Mar 2011 16:47:40 +0100 Hi Peter, (adding back the list to CC) On Saturday 12 March 2011 11:48:38 Peter Tilley wrote: Hi Patrick, My sincerest apologies for coming to you directly but I have tried the Linux mailing list and received no response and noticed you seem to have been heavily involved with much of the Dibcom driver development. I have an issue with a dual tuner which is sold under the brand of Kaiser Baas KBA01004 but identifies itself as 1164:1e8c which is a Yaun device and this device seems to have already been included in the driver files. It loads ok and reports not problems. It tunes ok and reports FE lock on all channels however on all but one channel upon receiving FE lock the BER stays at 1 instead of dropping to a low number which would indicate I am not getting viterbi. The device is fitted with pairs of MT2266 and DIB7000 which I have positive identified by opening the USB stick. am more than happy to try and work this out myself however the amount of detail around in support of the Linux drivers is extremely
USB DVB-T too much signal?
I have a USB DVB-T dual digital TV reciver which has the branding Kaiser Baas KBA 01004 on it. The device consists of a pair of DIBCOM DIB7000Ps and a pair of Microtune MT2266F tuners to provide dual tuner functionality. The USB device identities are 1164:1e8c which has been seen before in a range of devices and seems to have been supported by the V4L drivers for a while. I am using it with kernel version 2.6.35 (Ubuntu 10.10) The device is recognised ok and successfully loads the 1.20 release firmware. On the surface checks of syslog, etc everything seems to be ok. However used under Linux it demonstrates issues which do not appear when used with Windows. That is, when used with an external antenna, etc on Windows the unit functions fine whereas when used with Linux and using the DVButils scan, w_scan and tzap I am able to successfully tune only 1 out of 6 stations. Coincidently that station is the only one tranmitting with QPSK whereas all the others are using 64QAM. I live in an area with good signal level and I get the feeling that maybe the Linux agc implementation is not all it should be as you will see from the attached tzap screen dumps I have lots of signal, low SNR but high BER which is causing me to not get viterbi on any station using 64QAM. I can receive the local community tv station which is using QPSK. I have a hunch that maybe the frontend is being overdriven and the Linux agc implementation is not driving down the input signal. With QPSK being a more robust transmission mode in comparison to 64QAM, I suspect I am getting away with the high signal level and also the community TV station transmits with lower power and therefore is probably not hitting the front end with quite as much signal in the first place anyway. I do not believe this is a firmware issue as in addition to using the 1.20 firmware I have also complied and used Hans-Frieder Vogt's firmware extraction tool to pull the firmware out of the windows driver this uses and after after renaming it to replace the existing 1.2 firmware the same issues remain. The attached channels.conf file was constructed by hand as neither scan or W_scan were able to create entries for ither than C31. They would just time out for other stations. Does anyone have any suggestions or comment on my thoughts and how the agc is implemented? I was thinking I would probably have to tweak the settings for this device in dib0700_devices.c The other issue I have is that to make sure that I had the latest and greatest drivers and tried to rebuild them from the latest git using the basic approach at http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers The problem I found was that when I ran the build script it ran for a while and then came back and complained I was missing some source files. See attachment. If anyone has any pointers on this they would be greatly appreciated. Regards Pete peter@Garage2:~/media_build$ ./build.sh * This script will download the latest tarball and build it* * Assuming that your kernel is compatible with the latest * * drivers. If not, you'll need to add some extra backports,* * ./backports/kernel directory. * * It will also update this tree to be sure that all compat * * bits are there, to avoid compilation failures* Note: requires git/perl/make/gcc/patch/perl-Digest-SHA1/patchutils packages to work git pull git://linuxtv.org/media_build.git master From git://linuxtv.org/media_build * branchmaster - FETCH_HEAD Already up-to-date. make -C linux/ download make: Entering directory `/home/peter/media_build/linux' wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 -O linux-media.tar.bz2.md5.tmp --2011-03-03 19:05:21-- http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 Resolving linuxtv.org... 130.149.80.248 Connecting to linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 93 [application/x-bzip2] Saving to: `linux-media.tar.bz2.md5.tmp' 100%[==] 93 --.-K/s in 0s 2011-03-03 19:05:22 (5.36 MB/s) - `linux-media.tar.bz2.md5.tmp' saved [93/93] --2011-03-03 19:05:22-- http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2 Resolving linuxtv.org... 130.149.80.248 Connecting to linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3573711 (3.4M) [application/x-bzip2] Saving to: `linux-media.tar.bz2' 100%[==] 3,573,711 541K/s in 8.5s 2011-03-03 19:05:32 (411 KB/s) - `linux-media.tar.bz2' saved [3573711/3573711] make: Leaving directory `/home/peter/media_build/linux'
