Z
ziadost
Guest
- Thread starter
- #41
same here... australian channel frequencies can be found at http://www.dba.org.au
not sure about UK though...
not sure about UK though...
New Zealand
A
Anonymous
Guest
- Thread starter
- #44
dman_lfc said:
I guess that's final, right? (unless Aver releases BDA drivers for the 771, of course)
Again, thanks for the effort.
(OT) Luckily enough yesterday I managed to run the card with Linux for the first time; I'll probably try to set up Mythtv instead.
Ciao
Luca
R
RaStr
Guest
- Thread starter
- #45
AVER T771 & DVICO drivers
Hi all, I've been playing with DVICO drivers and my Aver card about a week. Till now, I have the following results:
1. It is not a problem to make the drivers load and initialize
2. The DVICO drivers use the I2S serial interface to receive TS stream data, while my T771 uses parallel mode
3. The BDA driver is actually a wrapper to WDM driver, not a native BDA
4. The WDM driver is derivate of generic BT878 TS driver and is configurable via registry (at least seems to be, I have not tested this yet), so I have patched the .inf file accordingly
5. The tuner device (tin box) uses Infineon's PLL TUA6034, which seems to be compatible with Thomson's T7579 used on original DVICO card, only I2C address differs, but this is again selectable by patching the .inf
6. The DVICO's codecs and apps. are protected and actually the protection is based on the content of EEPROM content on the board, I can make some app. to overwrite the original EEPROM, but need to know the content of some "generic" dvico card, anyhow this is not so important to me for now, as I can use other drivers and software if BDA will work !
7. Yesterday I have finally made my I2C communication sniffer and started capturing the data on the card during channel scan. Suddenly I have had only limited lite version of capturing application available yesterday, so I was unable to capture the full sequence, but from what I have seen it is obvious that the drive is switching the OFDM decoder to serial data output !
8. I will continue today, but it seems to be pretty sure, that it cannot work until the driver will be patched on the software level, and I am not a good code cracker, so I am afraid that there will be no progress if I will not get the driver source, which is highly improbable !
Anyhow I will give it another try and I will capture the I2C commands from Aver's software for compare too, so wish me enough strength (I have been sleeping only two hours today because of that) and good luck !
Hi all, I've been playing with DVICO drivers and my Aver card about a week. Till now, I have the following results:
1. It is not a problem to make the drivers load and initialize
2. The DVICO drivers use the I2S serial interface to receive TS stream data, while my T771 uses parallel mode
3. The BDA driver is actually a wrapper to WDM driver, not a native BDA
4. The WDM driver is derivate of generic BT878 TS driver and is configurable via registry (at least seems to be, I have not tested this yet), so I have patched the .inf file accordingly
5. The tuner device (tin box) uses Infineon's PLL TUA6034, which seems to be compatible with Thomson's T7579 used on original DVICO card, only I2C address differs, but this is again selectable by patching the .inf
6. The DVICO's codecs and apps. are protected and actually the protection is based on the content of EEPROM content on the board, I can make some app. to overwrite the original EEPROM, but need to know the content of some "generic" dvico card, anyhow this is not so important to me for now, as I can use other drivers and software if BDA will work !
7. Yesterday I have finally made my I2C communication sniffer and started capturing the data on the card during channel scan. Suddenly I have had only limited lite version of capturing application available yesterday, so I was unable to capture the full sequence, but from what I have seen it is obvious that the drive is switching the OFDM decoder to serial data output !
8. I will continue today, but it seems to be pretty sure, that it cannot work until the driver will be patched on the software level, and I am not a good code cracker, so I am afraid that there will be no progress if I will not get the driver source, which is highly improbable !
Anyhow I will give it another try and I will capture the I2C commands from Aver's software for compare too, so wish me enough strength (I have been sleeping only two hours today because of that) and good luck !
Interesting...
Seems we may have different card types...
Anyway this link may help - also there is alot of Linux code fliying about for the AvermMedia 771 linux driver.
http://www.linuxtv.org/wiki/index.php/Supported_DVB_cards
You'll notice the PLL is 0x61 vs 0x60 on the Fusion Lite card which is the closest match to the AverMedia 771 since the bridge chip is the same as well as the demodulator.
The I2C address is also C2 vs C0 on the Fusion Lite tuner.
We need source code to make this work as the clock controls need adjustments between the tuner and the demodulator.
Hopefully Spectrum will be able to help us out since the Twinhan driver he wrote worked with the 878A fusion and the tuner driver was seperate.
DMAN
Seems we may have different card types...
Anyway this link may help - also there is alot of Linux code fliying about for the AvermMedia 771 linux driver.
http://www.linuxtv.org/wiki/index.php/Supported_DVB_cards
You'll notice the PLL is 0x61 vs 0x60 on the Fusion Lite card which is the closest match to the AverMedia 771 since the bridge chip is the same as well as the demodulator.
The I2C address is also C2 vs C0 on the Fusion Lite tuner.
We need source code to make this work as the clock controls need adjustments between the tuner and the demodulator.
Hopefully Spectrum will be able to help us out since the Twinhan driver he wrote worked with the 878A fusion and the tuner driver was seperate.
DMAN
I got this email back from AverMedia today...
Dear Sir,
Thanks for supporting AverMedia product.
We are sorry that caused your inconveneince and this product (DVB-T card) could support BDA driver.
But we will let our product manager and engineer know your good suggestion . If any good news , will inform you soon.
Sorry for unhelpful to you.
~~Visit us at CeBIT 2005 March 10~16. AVerMedia booth: Hall 23, A37~~
Customer Service Dep
Tel:02-22263630 ext 840 or 842
Fax:02-22263808
E-mail:support@avermedia.com.tw
AVerMedia Technologies,Inc.
I suggest more people mail them asking for a BDA driver or to help us develop one.
DMAN
Dear Sir,
Thanks for supporting AverMedia product.
We are sorry that caused your inconveneince and this product (DVB-T card) could support BDA driver.
But we will let our product manager and engineer know your good suggestion . If any good news , will inform you soon.
Sorry for unhelpful to you.
~~Visit us at CeBIT 2005 March 10~16. AVerMedia booth: Hall 23, A37~~
Customer Service Dep
Tel:02-22263630 ext 840 or 842
Fax:02-22263808
E-mail:support@avermedia.com.tw
AVerMedia Technologies,Inc.
I suggest more people mail them asking for a BDA driver or to help us develop one.
DMAN
R
RaStr
Guest
- Thread starter
- #48
dman_lfc said:
I have seen this before, but was no much helpfull, as I don't understand the values mentioned there, but at least I have choosen the closest much to AV 771, which is DVBT Lite
dman_lfc said:
I don't know what the number 0x61 means, but I believe it is the device ID or something like that, as the DVICO uses Thomson7579 and Aver uses TUA6034, suddenly I have not datasheet of Thomson 7579 for a compare ! For those of you who care, I have made some pictures of my card, with removed and opened tin-box (as the PLL is located on the backside) here: http://www.althan.cz/A771
Anyhow, yesterday I have had a bad luck, my main PC with Aver card suddenly died after my water-cooling pump failed. But I was able to make a capture of I2C communication during ChannelScan with DVICO driver, but currently the registry setting for that driver were not 100% correct as I have played with them the day before. What seems to be evident is that the DVICO driver is using hard-coded I2C address for PLL chip equal to hC0, which is the main reason why the driver cannot tune ! The calculated frequency divisor seems to be correct and also some other setup data for a MT352 ODFM decoder are loaded with datasheet's defaults. The other main problem (despite of I2C address of PLL chip) is with datamode of MT352, which is configured by the driver for a serial communication, while my card seems to like parallel communication instead. I have intended to capture I2C setup sequence from Aver drivers too, but my PC failed too soon
! As it will take maybe a month to make it operational, I am not sure, when I could continue, maybe I will have to "steal" some PC from my job for that :roll: ! Then I could try to send a proper I2C commands to the MT352 using my external I2C sniffer and to tune it "manualy" this way, to check the data path and the rest of the driver. Of course I will try to patch the driver in the mean time !So wish me a luck and goodbye for today !
R
RaStr
Guest
- Thread starter
- #50
I2C address
, which corresponds to my assumption that it is hardcoded somewhere else in the driver. There is one more problem I have found yesterday, I have used ScanChannelsBDA.exe for a test and I have entered 506000kHz as a frequency and 8Mbps as a bandwidth, but in the sequence I have captured were data for a 7M bandwidth, but I am not sure it this is not a problem within the ScanChannelsBDA.exe itself or not. What was great, the PLL divider seems to correspond to a desired frequency 506MHz (minus the 36.167MHz IF) which is correct !
I am leaving for home now, and taking other PC with me, so I could continue my research .
I am not sure if this will be enought, there are two bytes of configuration for a PLL chip and those have to be checked with the data comming out from Aver driver (as I have not datasheet for a tinbox and some of the PLL parameters depend on the PCB layout, etc.) and finally there is the problem with data transfer mode (serial vs. parallel), but if the PLL will opereate the mt352 have to lock on the channel and this will be indicated by the driver. I have spent three hours now looking at the DVICO's code, I expect that "our" part will be in the zulutune.sys, I have found something, which seems to be an initialisation according the registry, but there is no C0 anywhere theredman_lfc said:
, which corresponds to my assumption that it is hardcoded somewhere else in the driver. There is one more problem I have found yesterday, I have used ScanChannelsBDA.exe for a test and I have entered 506000kHz as a frequency and 8Mbps as a bandwidth, but in the sequence I have captured were data for a 7M bandwidth, but I am not sure it this is not a problem within the ScanChannelsBDA.exe itself or not. What was great, the PLL divider seems to correspond to a desired frequency 506MHz (minus the 36.167MHz IF) which is correct !I am leaving for home now, and taking other PC with me, so I could continue my research
.