Re: [linux-dvb] fmd1216 integration
On Fri, 16 Mar 2007, Hartmut Hackmann wrote: Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? I only have the datasheet. Things look like P4 needs to be one to make the tda9887 accessible. The problem is that according to the TUA datasheet, this I wish I had a fmd1216 tuner, this would be easy to test. Try turning P4 off and see if the tda9887 stop responding to i2c reads. When P4 is turned back on, is the power-on-reset bit set in the tda9887? If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. ACK. changing the dvb tuning code will not affect this. The only important issue is to set the tuner to analog mode when dvb goes to sleep. Otherwise the first analog tuning attempt will fail because the tda9887 will not listen. dvb-pll will need to be extended to do this. Right now, it can only send a two-byte sequence for the sleep command. In order to set both the AGC byte and the port control byte, a 4-byte message is necessary. The TUA603x datasheet doesn't say you can send CB-AB-CB-BB, but it doesn't say you can't, and I've tested it and it works. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi, Trent Piepho schrieb: On Wed, 14 Mar 2007, Hartmut Hackmann wrote: How does that happen? I figured P4 just changed the SAW filters, but it enables/disables the tda9887 too? I have no idea why and how this is done, i just observed that... I wonder if this is a problem for the v4l tuner module. If one doesn't start and then stop the dvb frontend before using analog, how does the tda9887 get turned on? It is a BIG problem. The tuner initialization code turns the tda9886 on, but now things depend on the module initialization order whether the tda is found or not. I haven't used my board in analog mode after the tda9887 merge but things look like it doesn't work any more :-( Unfortunately i know about at least one board that needs the opposite load order. In the datasheet for the Philips TUV1236D tuner, it describes how the TDA9885 is turned on and off by one of the GPIO pins of the NXT2004 demodulator. The same pin also powers off and on the digital IF section, whatever that is exactly (obviously the NXT2004 isn't powering itself down with its own GPIO pin). I imagine this is a big problem for v4l, needing to talk to the ATSC demodulator to turn the analog demodulator on. Anyway, the FMD1216ME datasheet doesn't say anything about turning the TDA9887 on or off. Still, it stands to reason that Philips would have added the ability to do this for the same reason they added it to the TUV1236D. Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? I only have the datasheet. Things look like P4 needs to be one to make the tda9887 accessible. The problem is that according to the TUA datasheet, this bit is 0 after power on. The initialization code turns it on but if probing for the tda is already done, this chip will not be found. Unloading and reloading the tuner module will help but this is not a nice workaround. If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. ACK. changing the dvb tuning code will not affect this. The only important issue is to set the tuner to analog mode when dvb goes to sleep. Otherwise the first analog tuning attempt will fail because the tda9887 will not listen. I wonder how the other users of the fmd1216, in the cx88 and cxusb driver, work in analog mode? Maybe they don't? I think so. The problem lies in the tuner module. But please let me test this again. This will take some time since i modified my card for better DVB reception. The impact is that i always need to patch the driver for analog mode. My plan was to come up with a patch that converted all the users of fmd1216 at once. Ok, less work for me. If you want, I can make a simple patch that fixes the bug in fmd1216me_sleep quickly to apply first. I already did so. I just removed the static declaration. I will ask Mauro to pull soon. Best regards Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
I've been told that the fmd1216 uses the TUA6034. But in this case it doesn't really matter, all these I2C PLLs work this way. I have an 11 year old datasheet for a Philips tuner, and it's the same way. Ack I'd like to proceed this way: - first i correct the bug in the sleep function. - When your changes in dvb-pll are in mainstream, i will adapt the code in saa7134-dvb. (you might decide to kick me) OK? My plan was to come up with a patch that converted all the users of fmd1216 at once. FMD1216ME was recently replaced by the FMD1216MEX. Not sure if this impacts on your plans. I don't have the datasheet off hand but I'm told FM tuning has changed slightly. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Steven Toth wrote: My plan was to come up with a patch that converted all the users of fmd1216 at once. FMD1216ME was recently replaced by the FMD1216MEX. Not sure if this impacts on your plans. I don't have the datasheet off hand but I'm told FM tuning has changed slightly. That shouldn't make a difference. If the tuner is different enough that it needs a different configuration, then it will just need to be added as a new tuner type. Shouldn't make any difference to existing users of the fmd1216me. Of course I'm sure the card makers will switch tuners without changing their model numbers! Leading to the problem of how do you tell which tuner the card has? Maybe they'll be so kind as to stick the tuner on a different i2c address as well as put something in the eeprom. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi
Trent Piepho schrieb:
On Wed, 14 Mar 2007, Hartmut Hackmann wrote:
Trent Piepho schrieb:
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
That's new for me. But if the data go to the upper bytes first, you are
right.
The way the PLL works is that if the first bit of data sent is a 1, then
the next two bytes are CB+BB (or CB+AB). If the first bit is a 0, then the
next two bytes are the divisor bytes. You can send the divisor first then
the control bytes (as dvb-pll does), or the control bytes first and then
the divisor bytes. Or just the control bytes, or just divisor bytes.
If you look in the v4l tuner module, there is a special case hack to send
the divisor first or second depending on if the new frequency is less than
or greater than the old frequency.
I found the datasheet. Right, its documented there (but was new for me).
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
Ratio bits are 1,0 so 167kHz. But i don't think ath this is so important..
No, they are 1,1.
CB is 0x86 = 1 0 000 11 0
^ identifies this as the control bytes
^ selects low charge pump current
^^^ sets the test mode to normal mode
^^ Ratio select 1,1 = 62.5 kHz
^ Turn the tuning voltage on
I was in the wrong area, sorry. I had 0x9c in mind.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I have no idea why and how this is done, i just observed that...
I wonder if this is a problem for the v4l tuner module. If one doesn't
start and then stop the dvb frontend before using analog, how does the
tda9887 get turned on?
It is a BIG problem. The tuner initialization code turns the tda9886 on,
but now things depend on the module initialization order whether the tda
is found or not. I haven't used my board in analog mode after the tda9887
merge but things look like it doesn't work any more :-(
Unfortunately i know about at least one board that needs the opposite
load order.
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
If this is the used PLL chip, i should have a look.
Did you check whether it is allowed to cut off the lo?
I've been told that the fmd1216 uses the TUA6034. But in this case it
doesn't really matter, all these I2C PLLs work this way. I have an 11 year
old datasheet for a Philips tuner, and it's the same way.
Ack
I'd like to proceed this way:
- first i correct the bug in the sleep function.
- When your changes in dvb-pll are in mainstream, i will adapt the code in
saa7134-dvb. (you might decide to kick me)
OK?
My plan was to come up with a patch that converted all the users of fmd1216
at once.
Ok, less work for me.
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
That shouldn't make a difference. If the tuner is different enough that it needs a different configuration, then it will just need to be added as a new tuner type. Shouldn't make any difference to existing users of the fmd1216me. Of course I'm sure the card makers will switch tuners without changing their model numbers! Leading to the problem of how do you tell which tuner the card has? Maybe they'll be so kind as to stick the tuner on a different i2c address as well as put something in the eeprom. You are correct. However, I know Hauppauge identify it as a new tuner type in the eeprom, that will help a little. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Hartmut Hackmann wrote: How does that happen? I figured P4 just changed the SAW filters, but it enables/disables the tda9887 too? I have no idea why and how this is done, i just observed that... I wonder if this is a problem for the v4l tuner module. If one doesn't start and then stop the dvb frontend before using analog, how does the tda9887 get turned on? It is a BIG problem. The tuner initialization code turns the tda9886 on, but now things depend on the module initialization order whether the tda is found or not. I haven't used my board in analog mode after the tda9887 merge but things look like it doesn't work any more :-( Unfortunately i know about at least one board that needs the opposite load order. In the datasheet for the Philips TUV1236D tuner, it describes how the TDA9885 is turned on and off by one of the GPIO pins of the NXT2004 demodulator. The same pin also powers off and on the digital IF section, whatever that is exactly (obviously the NXT2004 isn't powering itself down with its own GPIO pin). I imagine this is a big problem for v4l, needing to talk to the ATSC demodulator to turn the analog demodulator on. Anyway, the FMD1216ME datasheet doesn't say anything about turning the TDA9887 on or off. Still, it stands to reason that Philips would have added the ability to do this for the same reason they added it to the TUV1236D. Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. I wonder how the other users of the fmd1216, in the cx88 and cxusb driver, work in analog mode? Maybe they don't? My plan was to come up with a patch that converted all the users of fmd1216 at once. Ok, less work for me. If you want, I can make a simple patch that fixes the bug in fmd1216me_sleep quickly to apply first. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
hi
Trent Piepho schrieb:
On Tue, 13 Mar 2007, Hartmut Hackmann wrote:
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
Jep
I've made patches to do this, I'll send them to the list later.
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
That's new for me. But if the data go to the upper bytes first, you are right.
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
AFIK the v4l tuner driver can't do this since init is called only one at
module initialization. Maybe the sequence is overdone but the intention is:
Yeah, V4L should do it, but doesn't. I think there is a special case hack
for some tuners where on every tune, they take the 4-byte command, send it
once, then modify the last two bytes to set AGC, and then send it again.
- set up RF AGC
- set the PLL to a valid frequency. I was told that this is important.
If you just send two bytes, then it's not necessary to change the frequency
from what it was at before.
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
Ratio bits are 1,0 so 167kHz. But i don't think ath this is so important..
- turn on the tda9887. This is invisible on the I2C bus in DVB mode.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I have no idea why and how this is done, i just observed that...
I am not aware that the tuner actually has a sleep mode. I used the sleep
call be cause it simply was there.
If you set the low bit of CB, it disables the tuning voltage. That's
probably the closest thing to sleep mode there is.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
Hm, the sequence is incomplete.. Do you have more information about the
PLL chip?
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
If this is the used PLL chip, i should have a look.
Did you check whether it is allowed to cut off the lo?
Are you aware that there is also the td1316?
One tuner at a time
Ack
I'd like to proceed this way:
- first i correct the bug in the sleep function.
- When your changes in dvb-pll are in mainstream, i will adapt the code in
saa7134-dvb. (you might decide to kick me)
OK?
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi.
Trent Piepho schrieb:
On Mon, 12 Mar 2007, Hartmut Hackmann wrote:
On Sunday 11 March 2007 09:40, Trent Piepho wrote:
In dvb-pll, the frequency offset, which is the IF frequency the tuner will
output at, is set to 36.21 MHz. It looks like this code was written
about two years ago by Patrick as part of the reverse engineered cxusb
driver.
In saa7134-dvb, there is some totally different code from programming
fmd1216 tuners, and it uses an IF frequency of 36.13 MHz.
So, why the difference?
After looking at dvb-pll some more, I'm pretty sure the difference between
the saa7134 and the dvb-pll IF frequency is that the dvb-pll version has
1/2 the step size added in, so the result will be rounded correctly.
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
Jep
I wrote the code in saa7134-dvb. The FMD1216 has an integrated SAW filter
for DVB-T, the data sheet says 36.13MHz. This is strange because the
data sheet also recommends a tuning step size of 167 kHz (4 MHz / 24),
so it should be 36.167MHz
Maybe the person who picked the SAW filter and the person who recommended
the step size should have talked to each other...
When i started writing it, there was no dvb-pll module. And the reason
why i didn't move to dvb-pll yet is that this module has no means to
control the RF AGC. Philips recommends different setting for analog and
DVB-T.
dvb-pll can do this now. These are the notes I've made about converting
fmd1216 to use dvb-pll wrt the saa7134 driver.
ok that's new
saa7134 driver
tda10046 demod, driver supports IF 36.13 Mhz (used here) or 36.17 MHz
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
tuner_ops.init = philips_fmd1216_tuner_init
tuner_ops.sleep = philips_fmd1216_tuner_sleep
tuner_ops.set_params = philips_fmd1216_tuner_set_params
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
philips_fmd1216_tuner_set_params() does not use dvb_pll_configure(), but is
totally different code. I've looked through it, and it will end up sending
almost the same data to the tuner. The only difference is that dvb-pll
uses a IF frequency of 36.21 MHz while the code in saa7134 uses 36.13
MHz. In this case, I think dvb-pll is wrong. It looks like the 26.213 MHz
value was written by Patrick Boettcher in 2005 when he wrote the cxusb
driver. Actually, what I think now is that the dvb-pll value is offset by
stepsize/2 for rounding, since dvb-pll rounds down while saa7143 rounds to
nearest. I should make a patch to fix rounding in dvb-pll.
philips_fmd1216_tuner_sleep() is buggy! The _first_ time it is called
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
AFIK the v4l tuner driver can't do this since init is called only one at
module initialization. Maybe the sequence is overdone but the intention is:
- set up RF AGC
- set the PLL to a valid frequency. I was told that this is important.
- turn on the tda9887. This is invisible on the I2C bus in DVB mode.
I am not aware that the tuner actually has a sleep mode. I used the sleep
call be cause it simply was there.
After the first time it is called, philips_fmd1216_tuner_sleep() will just
send {0x0b, 0xdc, 0x86, 0x54} twice! The array the sequence is in
shouldn't be static, or there should just be two static arrays for each
sequence. IMHO, using static locals that are not const is almost always
wrong in the kernel.
Thats right, it is a bug.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
Hm, the sequence is incomplete.. Do you have more information about the
PLL chip?
I will be happy to remove the tuning code from saa7134-dvb as soon as
dvb-pll fulfills the needs - and things look like we are close to this.
Are you aware that there is also the td1316?
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Tue, 13 Mar 2007, Hartmut Hackmann wrote:
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
Jep
I've made patches to do this, I'll send them to the list later.
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
AFIK the v4l tuner driver can't do this since init is called only one at
module initialization. Maybe the sequence is overdone but the intention is:
Yeah, V4L should do it, but doesn't. I think there is a special case hack
for some tuners where on every tune, they take the 4-byte command, send it
once, then modify the last two bytes to set AGC, and then send it again.
- set up RF AGC
- set the PLL to a valid frequency. I was told that this is important.
If you just send two bytes, then it's not necessary to change the frequency
from what it was at before.
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
- turn on the tda9887. This is invisible on the I2C bus in DVB mode.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I am not aware that the tuner actually has a sleep mode. I used the sleep
call be cause it simply was there.
If you set the low bit of CB, it disables the tuning voltage. That's
probably the closest thing to sleep mode there is.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
Hm, the sequence is incomplete.. Do you have more information about the
PLL chip?
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
Are you aware that there is also the td1316?
One tuner at a time
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] fmd1216 integration
I've been looking into integrating fmd1216 tuner support fully into dvb-pll and removing the various code used in some drivers. I've mostly figured out what the effect will be on the various users of fmd1216 tuners, but there is something I'm not sure of. In dvb-pll, the frequency offset, which is the IF frequency the tuner will output at, is set to 36.21 MHz. It looks like this code was written about two years ago by Patrick as part of the reverse engineered cxusb driver. In saa7134-dvb, there is some totally different code from programming fmd1216 tuners, and it uses an IF frequency of 36.13 MHz. So, why the difference? The fmd1216 datasheet says the DVB-T IF frequency is 36.13 MHz. But the IF frequency is something also determined by the demodulator. There are several different demods using a fmd1216. The cx22702 is used by a number of cards, the product brief says it uses an IF of 36.17 MHz or 44.1 MHz. There is a card using an mt352, which is using 36.16667 MHz in this case (no code to re-program the IF frequency registers). There are also two cards using the tda10046 demod, which according to the driver is using a 36.13 MHz IF. It seems like 36.13 MHz (probably 36 1/8 rounded to two digits) or 36.16667 (clearly 36 1/6) are the correct values. So where did 36.21 MHz come from? It is supposed to be 36.13 plus 1/2 of the 1/6 MHz step size? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi, On Sunday 11 March 2007 09:40, Trent Piepho wrote: In dvb-pll, the frequency offset, which is the IF frequency the tuner will output at, is set to 36.21 MHz. It looks like this code was written about two years ago by Patrick as part of the reverse engineered cxusb driver. In saa7134-dvb, there is some totally different code from programming fmd1216 tuners, and it uses an IF frequency of 36.13 MHz. So, why the difference? Usually a (DVB-T) Demod has an capture area of +/- 1MHz relative to the programmend IF and also in most Demods the IF could be moved with certain register settings. I don't know the FMD1216, but in many designs you have a third element which determines the IF frequency, the SAW filter between the tuner and the demod. So depending on which SAW-filter you are using you choose also an certain IF. Epcos for example sells filters with 35.1, 35.825, 36, 36.125, 43.75 MHz and much more. So if you find a SAW-filter on your device, maybe have a look an the datasheet and you will find the right IF. For example, the X6872D which could be found in some DVB-T sticks, has a center frequency of 36.125MHz. (And 6.9MHz bandwidth) If the IF is shifted around 100kHz bit to the center frequency of the SAW-filter and you have a good reception, you wont see much degration in the quality because there are some provision. But if the conditions will go worser, this would make your quality degration a little bit more worse. Kind regards, Thomas Pinz ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi, Thomas Pinz schrieb: Hi, On Sunday 11 March 2007 09:40, Trent Piepho wrote: In dvb-pll, the frequency offset, which is the IF frequency the tuner will output at, is set to 36.21 MHz. It looks like this code was written about two years ago by Patrick as part of the reverse engineered cxusb driver. In saa7134-dvb, there is some totally different code from programming fmd1216 tuners, and it uses an IF frequency of 36.13 MHz. So, why the difference? Usually a (DVB-T) Demod has an capture area of +/- 1MHz relative to the programmend IF and also in most Demods the IF could be moved with certain register settings. I don't know the FMD1216, but in many designs you have a third element which determines the IF frequency, the SAW filter between the tuner and the demod. So depending on which SAW-filter you are using you choose also an certain IF. Epcos for example sells filters with 35.1, 35.825, 36, 36.125, 43.75 MHz and much more. So if you find a SAW-filter on your device, maybe have a look an the datasheet and you will find the right IF. For example, the X6872D which could be found in some DVB-T sticks, has a center frequency of 36.125MHz. (And 6.9MHz bandwidth) If the IF is shifted around 100kHz bit to the center frequency of the SAW-filter and you have a good reception, you wont see much degration in the quality because there are some provision. But if the conditions will go worser, this would make your quality degration a little bit more worse. Kind regards, Thomas Pinz I wrote the code in saa7134-dvb. The FMD1216 has an integrated SAW filter for DVB-T, the data sheet says 36.13MHz. This is strange because the data sheet also recommends a tuning step size of 167 kHz (4 MHz / 24), so it should be 36.167MHz When i started writing it, there was no dvb-pll module. And the reason why i didn't move to dvb-pll yet is that this module has no means to control the RF AGC. Philips recommends different setting for analog and DVB-T. I don't know how big the impact on the performane is but i think its good to stay as close a possible to the recommendations of the manufactor. Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On 3/11/07, Thomas Pinz [EMAIL PROTECTED] wrote: Hi, On Sunday 11 March 2007 09:40, Trent Piepho wrote: In dvb-pll, the frequency offset, which is the IF frequency the tuner will output at, is set to 36.21 MHz. It looks like this code was written about two years ago by Patrick as part of the reverse engineered cxusb driver. In saa7134-dvb, there is some totally different code from programming fmd1216 tuners, and it uses an IF frequency of 36.13 MHz. So, why the difference? Usually a (DVB-T) Demod has an capture area of +/- 1MHz relative to the programmend IF and also in most Demods the IF could be moved with certain register settings. I don't know the FMD1216, but in many designs you have a third element which determines the IF frequency, the SAW filter between the tuner and the demod. So depending on which SAW-filter you are using you choose also an certain IF. Epcos for example sells filters with 35.1, 35.825, 36, 36.125, 43.75 MHz and much more. So if you find a SAW-filter on your device, maybe have a look an the datasheet and you will find the right IF. For example, the X6872D which could be found in some DVB-T sticks, has a center frequency of 36.125MHz. (And 6.9MHz bandwidth) The TU1216 's have an external SAW filter in comparison to the internal SAW filter on the FMD1216 linuxtv.org BL my DNS for no reason, thanks to johannes for a timely fix. manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Mon, 12 Mar 2007, Hartmut Hackmann wrote:
On Sunday 11 March 2007 09:40, Trent Piepho wrote:
In dvb-pll, the frequency offset, which is the IF frequency the tuner will
output at, is set to 36.21 MHz. It looks like this code was written
about two years ago by Patrick as part of the reverse engineered cxusb
driver.
In saa7134-dvb, there is some totally different code from programming
fmd1216 tuners, and it uses an IF frequency of 36.13 MHz.
So, why the difference?
After looking at dvb-pll some more, I'm pretty sure the difference between
the saa7134 and the dvb-pll IF frequency is that the dvb-pll version has
1/2 the step size added in, so the result will be rounded correctly.
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
I wrote the code in saa7134-dvb. The FMD1216 has an integrated SAW filter
for DVB-T, the data sheet says 36.13MHz. This is strange because the
data sheet also recommends a tuning step size of 167 kHz (4 MHz / 24),
so it should be 36.167MHz
Maybe the person who picked the SAW filter and the person who recommended
the step size should have talked to each other...
When i started writing it, there was no dvb-pll module. And the reason
why i didn't move to dvb-pll yet is that this module has no means to
control the RF AGC. Philips recommends different setting for analog and
DVB-T.
dvb-pll can do this now. These are the notes I've made about converting
fmd1216 to use dvb-pll wrt the saa7134 driver.
saa7134 driver
tda10046 demod, driver supports IF 36.13 Mhz (used here) or 36.17 MHz
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
tuner_ops.init = philips_fmd1216_tuner_init
tuner_ops.sleep = philips_fmd1216_tuner_sleep
tuner_ops.set_params = philips_fmd1216_tuner_set_params
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
philips_fmd1216_tuner_set_params() does not use dvb_pll_configure(), but is
totally different code. I've looked through it, and it will end up sending
almost the same data to the tuner. The only difference is that dvb-pll
uses a IF frequency of 36.21 MHz while the code in saa7134 uses 36.13
MHz. In this case, I think dvb-pll is wrong. It looks like the 26.213 MHz
value was written by Patrick Boettcher in 2005 when he wrote the cxusb
driver. Actually, what I think now is that the dvb-pll value is offset by
stepsize/2 for rounding, since dvb-pll rounds down while saa7143 rounds to
nearest. I should make a patch to fix rounding in dvb-pll.
philips_fmd1216_tuner_sleep() is buggy! The _first_ time it is called
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
After the first time it is called, philips_fmd1216_tuner_sleep() will just
send {0x0b, 0xdc, 0x86, 0x54} twice! The array the sequence is in
shouldn't be static, or there should just be two static arrays for each
sequence. IMHO, using static locals that are not const is almost always
wrong in the kernel.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
