Can't change channels using PAL tuner

I just spent the last couple of nights replacing the NTSC tuner with a PAL version. A friend of mine pulled an ALPS TMDG2 tuner out of a VCR and donated it. From memory, my tuner was labelled TMDG2-602 and the howto doc shows a tuner with TMDG2-805A.

The good news is that I can view channel 2 fine (even the sound decoder worked ok), but unfortunately I can't change channels. ie. I pressed the [Channel Up] button and the Tivo displayed the banner for channel 7 but the channel didn't change.

I'm assuming that the I2C bus is working ok in order to be able to view any channel. Of course, I've got no idea what the difference between the -602 and -805A tuners are, but presumably the -602 isn't supported by the Tivo firmware.

Can anyone offer any suggestions as to how to debug what's going on ?
Are there any log files related to communicating with the internal tuner ?

Hi Steve

That's a more detailed question than you emailed me so I will elaborate here more than just the "I dunno" I gave you in my email.

It is possible that the tuner you are using is only defaulting to "VHF low band" and nothing else. Some tuners need command switching between VHF low (Ch0 to Ch5), VHF high (Ch5a to CH11) and UHF. However unless you can land some documents on your particular tuner then I am tipping 99% it is not the same as the ALPS TMDG2 805A that are used in the UK Thompson TiVo and that I recommend for use in PAL tuner conversions. If you can get the documents then you could probably make a driver for it, otherwise you are probably stuck to channel 2 reception only.

Arghhhhh!
Can you believe that I just installed the ALPS TMDG2-805A tuner and it's doing the same thing as the -602 that I originally installed. I can receive channel 2, but can't change channels.

Obviously this seems to be working for alot of other people, so I must have done something wrong. Maybe I'll just read the howto document for the hundredth time to see if there was something I missed.

Does anyone have any info on the tuner interface in order to debug what's going on ? eg. Are the channels changed via the I2C interface.
Is there some specific source code that I should be looking at ?

Here's hoping someone will be able to help...

Hi Steve. Apologies for the belated reply I've been taking a break!

Yes these tuners DO work. I do 3-5 conversions a week no problems.

You *have* run palmod_config and set it for "Samsung" tuner I assume, rather than the usual mistake of picking "Philips" because "that's what the badge on the front of my TiVo says"? Don't laugh I get that line more often than I care to remember!

Other than that there is nothing more to it except following the how-to. Remember that's the ALPS tuner how-to and NOT the Samsung tuner how-to.

If you require the assistance of someone to glance over it send me an email and I'll be happy to discuss.

I was just browsing the source for palmod.o and am tempted to try it with DEBUG enabled/defined.
I'd like to be able to confirm that the Tivo is actually trying to send the I2C commands to the tuner. There are various printk() calls which might give me some hints as to what's going on.
Given that my linux box is currently in a state of disrepait, does anyone feel like compiling a version of palmod.o with DEBUG defined ?

If the logs show that the I2C commands are being sent, then I guess I'll have to drag out the cro and see whether anything is happening on the lines.
Does anyone have the pinouts for the tuner ?

I've probably done something stupid during the mod, but unfortunately it looks like I've got to climb Mt.Everest to find out what.

Hi Stephen

Pinouts for the tuner are in the hardware how-to area on OzTiVo. Basically if you are following the how-to document anyway they are pins 11 and 12 on the tuner that you jumper to pins 3 and 5 to get the RF output going, and as a guide you can clearly see them in that picture regarding getting RF output in the document. One is Serial Clock and the other is Serial Data. The tuner datasheet is in the how-to zip package on Minnie (that's the OzTiVo website, not the OzTiVo forums) in the how-to hardware section.

I can tell you that the big square ASIC chip with the TiVo logo on it pumps out the I2C serial clock and serial data signal for the tuner on dedicated pins that are not related to the I2C bus that is used elsewhere in the TiVo. Therefore you could have a dead I2C tuner bus, but that would be highly unlikely IMHO. There are a couple of resistors in series from the ASIC to the tuner so one of these may be open. It's something you are going to have to trace like you have mentioned you are going to do anyway.

HTH

Aha! It's time to start blaming some software instead of the hardware.

I recompiled palmod.o with DEBUG turned on and found that each time I pressed the channel up/down buttons, the kernel log would show that it's always trying to set the tuner to channel 2 even though the banner displayed on the TV shows the correct channel. This certainly explains why I'm only ever seeing channel 2! It also presumably means that the tuner and the I2C bus is ok.

Here's a snippet from the kernel log file:
Oct 7 00:10:08 (none) kernel: PALMOD: Tmdh2Tune_x channel=2
Oct 7 00:10:08 (none) kernel: PALMOD: tuned to 0x06728e01 for chan 2 adj=0
Oct 7 00:10:08 (none) kernel: &fpga_get_channel= 2
Oct 7 00:10:08 (none) kernel: fpga_hw_ioctl: a1=807d6c00 a2=8045ba68 a3=1000 a4=7fffb458
Oct 7 00:10:08 (none) kernel: PALMOD: Tmdh2Tune_x channel=2
Oct 7 00:10:08 (none) kernel: PALMOD: tuned to 0x06728e01 for chan 2 adj=0
Oct 7 00:10:08 (none) kernel: &fpga_get_channel= 2
Oct 7 00:10:08 (none) kernel: fpga_hw_ioctl: a1=807d6c00 a2=8045ba68 a3=1000 a4=7fffb458
Oct 7 00:10:08 (none) kernel: PALMOD: Tmdh2Tune_x channel=2
Oct 7 00:10:08 (none) kernel: PALMOD: tuned to 0x06728e01 for chan 2 adj=0
Oct 7 00:10:08 (none) kernel: &fpga_get_channel= 2
Oct 7 00:10:08 (none) kernel: fpga_hw_ioctl: a1=807d6c00 a2=8045ba68 a3=1000 a4=7fffb458
Oct 7 00:10:08 (none) kernel: PALMOD: Tmdh2Tune_x channel=2
Oct 7 00:10:08 (none) kernel: PALMOD: tuned to 0x06728e01 for chan 2 adj=0
Oct 7 00:10:08 (none) kernel: &fpga_get_channel= 2
Oct 7 00:10:08 (none) kernel: fpga_hw_ioctl: a1=80fee800 a2=8045bab0 a3=10000 a4=7fffb5a8
Oct 7 00:10:08 (none) kernel: tuning:lock 1

There were hundreds of these entries in the log. I don't know whether that's attributed to my fault condition, or whether it's just normal for the kernel log ???

My real question though, where can I look to see what calls the hook functions like: Tmdh2Tune_x() and fpga_hw_ioctl_x().
I've got no idea about kernel programming, and I hope someone can shed some light for me. If you'd like to delve through my logfile for more info, you're more than welcome - just email me.

Thanks,
Steve

Here's an update:

I just did a quick test and set the input signal to be 'RF Channel 4' from within the GS. Quite understandably, it responded stating that there is 'No Video Signal' on channel 4.
I then rebooted, tried to change the channel a few times and noticed in the kernel log that it was now always trying to change to channel 4 instead of 2.
So it seems the channel that palmod.o is being asked to use is related to the RF channel selected during the GS.

The howto docs for both the GS and the palmod don't make any mention of selecting the input signal (ie. RF ch2, 3 or 4) via the GS. Was I not supposed to do this ?
How else do you configure the tivo to use the internal tuner instead of the AV inputs (eg set-top box) ?

Ok, so I'm a goose!
It appears as though if you have ever selected 'Have Cable Box' it remains like that even if you later select 'Haven't got a cable box'.
When I originally setup my tivo, I had it connected to my sony vcr.
When I installed the tuner, I redid the setup and selected 'Haven't got a cable box'. This didn't seem to make a difference.

I just cleared the entire disk and redid the setup this time selecting 'Haven't got a cable box' and it works!!!!!
I should have checked the 'System Information' screen which shows that it was still trying to use a cable box.

I guess I should try it again in order to identify whether it's a bug or was just me.