Does Girder support the Hauppauge WinTV remote ?

[Ron]

I have sent an email to hauppage asking for some documentation for making a plugin. So stay tuned!

-Ron

[Ron]

Mabye a dumb question, but how do i access the I2C bus ?

<font size=-1>[ This Message was edited by: RonB on 2001-05-24 16:28 ]</font>

[Ron]

Wow,.. looks like the exact thing we need. Would you be interested in converting this into a Girder plugin ?

[Yvonus]

Rather than flaming Hauppauge, let's get Ron some tv cards with remotes so that he'll felt like he's got a debt toward us and code the support for such remote ;)

Btw, the RealMagic remote (which is bundled sometimes with the Hollywood+ but can be bought separeately) is perfectly handled by Girder.

[Yvonus]

Hi there .. bumping up this topic as the DScaler team is thinking about new features and changes for version 4. And IR support has been talked about.

My opinion was that it was better to leave this remote control things to dedicated proggies that already do that perfectly.

However, as capture card are the core of DScaler code, temptation exists to try to support the remotes (not serial port related, gpio or I2C related instead) bunlded with those cards.

A new plugin for those cards in Girder would be for sure a strong point in that direction.

Allow me to remind that Girder is shown as the definite tool of choice to remote control DScaler http://www.dscaler.org/FAQ.htm

The topic in the developper forum is here http://www.girder.nl/phpBB/viewtopic.php?topic=124&forum=3

Come on coders ! :wink:

[Yvonus]

Hey Moose, nice trick here :wink:

This will certainly be easier with a directsupport from a Girder's plugin that this technique does the trick for sure.

Congratulations on this nice one.

Could you post this same message in the "Tips & tricks" section ? Maybe something like "Trick to usage Hauuppauge WinTV remote within Girder"

[mcguyton]

Does this help?

http://www.burdell.org/~admkirk/bin/haup10.zip

I tried it on my computer. It has some kind of bug that makes the sound card go into an endless loop... drives me crazy!

But there may be something here that can be salvaged.

[Edited by mcguyton on 05-05-2001 at 11:07 AM GMT]

[mcguyton]

More Help for programming for Hauppauge:
(I know it's long, but it's juicy!)

Hauppauge IR Remote Control Spec version 1
Roger Hardiman
roger@cs.strath.ac.uk
roger@freebsd.org

The following information was gained in two ways
1) By myself from trial and error.
2) By exchange of emails with Hauppauge.

INTRODUCTION
The Hauppauge IR Remote contol is the easiest of the bt848 TV card remote control units to program for. This is because the receiver is accessed via the i2c bus. On other boards (eg AverMedia) the receiver is interfaced to several GPIO pins.

Hauppauge Bt878 based TV cards had a new type of S-Video socket, which included the S-Video pins, power and the i2c data bus. This allows external devices to be added to the i2c bus of the Hauppauge cards. (I have not seen the i2c databus on the s-video socket on any of the Hauppauge bt848 cards I own)


I2C INTERFACE
The external IR receiver is at i2c address 0x34 (0x35 for reads). Future Hauppauge cards will have an internal receiver at 0x30 (0x31 for reads). In theory, both can be fitted, and Hauppauge suggest an external overrides an internal.
I have no idea if external and internal will use the same IR Handset. If the handsets differ (in design or in the infra red signal), it would be possible to use both at the same time.

The chip on the i2c bus is designed by Hauppauge so there are no databooks on it.
The chip ignores i2c writes and only reponds to reads.

DATA PROTOCOL
The protocol is a read of 2 or 3 bytes from 0x35. eg
<START> <WRITE 0x35> <READ BYTE1> <READ BYTE2> <READ BYTE3> <STOP>
<START> <WRITE 0x35> <READ BYTE1> <READ BYTE2> <STOP>

The data bytes are
BYTE 3 - The firmware version on the IR receiver. ( 0x2 on my receiver)

BYTE 2 - The last key pressed by the user.
Note, the receiver only remembers the last key pressed. There is no buffering, and two keys cannot be pressed at the same time. Therefore the reciever must be polled repeatedly at a fast enough rate to capture user key presses.

BYTE 1 - Toggle Byte. As we poll the receiver repeatedly, we need to know when new data is available. After pressing a button on the remote contol, the next i2c read will give us <192> <keypress> or <224> <keypress>. (192/224 explained later)

If we read the receiver again, before the next keypress, we get <0> <0> or <255> <255>. This indicates there is no data to be read from the receiver or that the receiver chip was busy and could not process the i2c request.

The 192/224 is a toggle code. It alternates for each user keypress. A typical sequence of reads (excluding reads of <0><0> and <255><255> would be

example 1
<192><key #6> <- key 6 pressed
<224><key #1> <- key 1 pressed
<192><key #4> <- key 4 pressed
<224><key #3> <- key 3 pressed
<224><key #3>
<224><key #3>
<224><key #3> <- the toggle code has not changed, this means the user has pressed and held down key 3 for a 'long time'. Note - if we sample at 20 times a second, a 'long time' is only 3/20th of a second which is a short time in human terms

example 2
<192><key #4> <- key 4 pressed
<224><key #4> <- key 4 again. But the toggle is different. The user has pressed #4 twice in a row. They must want channel 44.

RED LED
There is a Red LED on the front of the external IR receiver module. This is lit when the user presses a key on the remote handset. It goes out after 5 i2c reads. If the LED went out after just 1 i2c read, the human user would never see the LED come on. Assuming we poll at 20 times a second, the LED would only be lit for 1/20th of a second. The human user would miss this. By having a delay of 5 read cycles, this lengths the LED period to 5/20ths of a second (1/4 of a second). Long enough for the user to see the LED light up and then go out.


POLL FREQUENCY
You can poll at any reasonable rate. My sample code polls at 20 Hz. Hauppauge code polls at 18.2 Hz (a value which comes from the PC system clock).


KEY SEQUENCES.
BYTE 2 contains the last key pressed. The mapping is
#define REMOTE_0 0
#define REMOTE_1 4
#define REMOTE_2 8
#define REMOTE_3 12
#define REMOTE_4 16
#define REMOTE_5 20
#define REMOTE_6 24
#define REMOTE_7 28
#define REMOTE_8 32
#define REMOTE_9 36
#define REMOTE_RADIO 48
#define REMOTE_MUTE 52
#define REMOTE_TV 60
#define REMOTE_VOL_PLUS 64
#define REMOTE_VOL_MINUS 68
#define REMOTE_RESERVED 120
#define REMOTE_CHAN_PLUS 128
#define REMOTE_CHAN_MINUS 132
#define REMOTE_SOURCE 136
#define REMOTE_MINIMIZE 152
#define REMOTE_FULL_SCREEN 184


SAMPLE CODE
This code is taken from a test program developed by Roger Hardiman. It also shows single keypress and auto-repeat key press for the Volume. IOCTLs are to a test driver, but they map closely to the FreeBSD and Linux i2c bus code.

char * keyname(unsigned char v){
switch (v) {
case REMOTE_0: return "0";
case REMOTE_1: return "1";
case REMOTE_2: return "2";
case REMOTE_3: return "3";
case REMOTE_4: return "4";
case REMOTE_5: return "5";
case REMOTE_6: return "6";
case REMOTE_7: return "7";
case REMOTE_8: return "8";
case REMOTE_9: return "9";
case REMOTE_RADIO: return "Radio";
case REMOTE_MUTE: return "Mute";
case REMOTE_TV: return "TV";
case REMOTE_VOL_PLUS: return "Vol +";
case REMOTE_VOL_MINUS: return "Vol -";
case REMOTE_RESERVED: return "Reserved";
case REMOTE_CHAN_PLUS: return "Chan +";
case REMOTE_CHAN_MINUS: return "Chan -";
case REMOTE_SOURCE: return "Source";
case REMOTE_MINIMIZE: reeturn "Minimize";
case REMOTE_FULL_SCREEN: return "Full Screen";
default: printf("Error, invalid key %d",v);
return "";
}
}
void main(void) {

int t; /* tuner device */
int times_per_second = 20;
/* open tuner device */
t = open("/dev/tuner0", O_RDONLY);
if (t < 0) {
printf("cannot open tunern");
exit(1);
}

printf("tuner openn");

/* try and read the Remote Control DData */
{
unsigned char b1, b2, b3;
unsigned char address=0x35; /*i2c location for read */
unsigned char last_valid_b1 = 0;
for(;;){
ioctl(t, BT848_I2C_START);
ioctl(t, BT848_I2C_SEND_BYTE, &address);
ioctl(t, BT848_I2C_READ_BYTE_SEND_ACK, &b1);
ioctl(t, BT848_I2C_READ_BYTE_SEND_ACK, &b2);
ioctl(t, BT848_I2C_READ_BYTE_SEND_NACK, &b3);
ioctl(t, BT848_I2C_STOP);

//printf("%d %d %dn",b1,b2,b3);
if ((b1 == 224) || (b1 == 192)) {
/* most keys do not have auto repeat except the volume */
if ((b2 == REMOTE_VOL_PLUS) || (b2 == REMOTE_VOL_MINUS)) {
printf("%sn",keyname(b2));
last_valid_b1 = 0; }
else if (b1 != last_valid_b1) { printf("key %sn",keyname(b2));
last_valid_b1 = b1; }
}
usleep(1000000 / (float) times_per_second);
} /* end for */
}
}


AKNOWLEDGEMENTS
Many thanks to Ken and Fred at Hauppauge who provided some of the information in the document - mainly the reason for the toggle byte (192/224), the LED lit time of 5 read cycles and the details of the internal receiver. I'll not give Ken and Freds full names or email, to prevent them being
distributed.
If you want to contact them, you can do so via Roger Hardiman
roger@cs.strath.ac.uk or roger@freebsd.org

<font size=-1>[ This Message was edited by: mcguyton on 2001-05-24 16:28 ]</font>

[mcguyton]

Eek. I was afraid you were going to ask that (since I don't know the answer) :smile:

So I'm guessing the "generic driver" thing you mentioned at http://www.girder.nl/phpBB/viewtopic.php?topic=124&forum=3 is still in the works?

There are libraries called hcwi2c.dll and hcwi2c32.dll for Hauppauge. Would they be helpful?

<font size=-1>[ This Message was edited by: mcguyton on 2001-05-24 16:41 ]</font>

[mcguyton]

This is from the maker of a program called "Satellite".
------------------------------------------
The "Hardware-Engine" works as follows:

1. the driver will be initiated (located in hardware/driver.cpp:
- the driver loads the needed driver file (satdrv.sys for Win2k, satdrv.vxd for Win9x)
- for Win2k the driver installs a temporary Service
2. Satellite looks for the bt8x8 capture chips (located in hardware/capchip.cpp)
3. the bt8x8 capture chip will be initiated (hardware/bt8x8/bt8x8.cpp)
4. the I2C bus will be initiated (hardware/i2c.cpp)
My implementation of the remote control can be found in hardware/bt8x8/btremote.cpp.
----------------------

The source can be found at http://www.mit.edu/~mcguyton/sat0.5.0.e-source.zip

Let me know what you think.

[mcguyton]

"The problem with the remote control program from Hauppauge, is that you also need to have their drivers installed"

If I build a generic serial-IR receiver, are there drivers from Hauppauge which I can then uninstall? Don't I have to continue using those drivers for my TV card to function as a TV card?

Or are there separate Hauppauge remote control drivers which you're talking about?

Thank you for the clarification.

[kizkoool]

Because I searched actively a software for my remote bundled with the Hauppauge WinTV primio TV card and haven't found one.

Do u know if a plugin who support this remote exist for Girder ? Or if someone is working on it ?

[kizkoool]

I found another remote control tool called uICE (Universal Infrared Control Engine).
It supports the Hauppauge WinTV remote and lots of others.
It's a very nice and handy tool .... unfortunately it's shareware :(

The uICE website:
http://www.mediatexx.com

[didi]

Maybe we should start a petition?
What e-mail at hauppauge would be best to use?

I'd really like to see this plugin happen.

[didi]

The problem with the remote control program from Hauppauge, is that you also need to have their drivers installed. As mentioned in another thread, those drivers have ACPI problems, so suspend&resume won't work. So direct support from girder to read the i2c bus would be much better. Is anyone working on this? It does sound complicated to me, but then I know nothing about these things. It's just that under linux lirc works perfectly with my Hauppauge WinTV remote.

[MooseAreFun]

I have got Girder to respond to my WinTV remote control.

You can do this by editing "c:windowsirremote.ini" so this section changes like so

[Applications]
Default=
;Win/TV+=
;Win/TV=
WinTV32=
Girder= <<<<---(Insert that)
FullScreen=
*task*=
*suspend*=
;Debug=

Then, just below this section (just before the line [Default]) put this;

[Girder]
1={ctrl}s

Save, restart the IR software (close it in the system tray, and go to start->programs->startup->AutostartIR) or restart your PC.

Load Girder, create a command, set it to do something (popup text perhaps) and click "learn state" - press CTRL-S instead of a remote button.

Now press number 1 on your hauppauge remote. If the above was done correctly, the hauppauge software will send "CTRL-S" to Girder, Girder will 'catch' it and run the command.

This editing of the irremote.ini file can be used to control almost any application directly (winamp, say), but only foreground applications. Look for tutorials on the web for more info.

[agilo]

hallo,

to control the computer with a haupauge remote you don't need girder.

on the page of haupauge you'll find a good program. if you aren't able to understand german it will be hard.

http://members.tripod.de/AndreasBernhofer66/irsetup2/html/files/ir20.exe

mfg agilo

[Evinyatar]

I would too very much like to use my WinTV with Girder. I'm having annoying problems with Hauppauge's app in that it occasionally ignores the front application and sends the IR commands to the 'Default' configuration instead. Quite annoying when suddenly PowerDVD starts up when you really wanted to switch to teletext mode in DScaler :P