From: psfales@intgp1.att.com
Date: Tue, 12 Oct 93 08:58 CDT
Subject: Universal Remote Control Interface


The following is the results of my investigation into the hardware and
software needed to connect a PC serial port to the Universal Electronics
"OneForAll 12" (URC-5000-2).  I have reason to believe that the information
is similar, but not identical for the URC-5000-1, the URC-4000-1, and
the URC-4000-2.

I purchased the following items from Home Automation Laboratories:

URC-5000-2 - OneForAll 12 (HAL 2582)
Interface Cable  (HAL 2579)
EMIT software (HAL ???)

The EMIT software works fine, but does not provide direct access to the
protocol.  If you want to have another program interface to the remote,
the recommended method of invoking EMIT.EXE by "shelling" to DOS is
somewhat painful.  I wanted to be able to talk to the device directly
so I began some investigation.

Physical Interface
==================

The interface to the URC-5000 is set of three contacts located on the
PC board next to the battery compartment.  The connector is accessible
(unfortunately) only when the battery compartment cover is removed.

It looks something like this:

            ----------- Transmit (From PC to URC)
            | --------- Ground
            | | ------- Recv (From URC to PC)
            | | |
            v v v
          ---------
        --| o o o |--
        |-----------|
        || Battery ||
        |-----------|
        || Battery ||
        |-----------|
        || Battery ||
        |-----------|
        || Battery ||
        |-----------|
        -------------

The send  and receive signals are TTL levels, 4800 baud, 8 data bits, no
parity, one stop bit, but the sense of one is inverted from the other.
The send line "rests" low and goes high for the start bit.  The receive
line rests high and goes low for the start bit.

The interface cable contains active circuitry to do the RS-232 to TTL
level conversion, and apparently takes power from the DTR line on the
PC serial port.

Protocol
========

This information was generated by hooking a logic analyzer to the port
sending commands via the EMIT software.  As a result it may not be a complete
picture, and it is not clear how critical the timing is, but it seems to
work.

To send a command, the following steps are used:

1) Assert DTR and send a "break."  DTR provides power to the interface and
        sending "break" causes the send line to go high.
2) Wait 80 milliseconds and Remove the "break."  This returns the send line
        to the normal idle state and apparently wakes up the remote, because
        approximately 50 milliseconds later the remote sends the character
        0x6e.
3) Transmit a 0xbc.
4) Remote responds with 0xc3
5) Wait 170 milliseconds, then send the function command to the remote. (See
        the table below)
6) Wait another 180 milliseconds and remove DTR.

I don't know how critical the timings are, as the signals sent by
the EMIT software vary somewhat.  In particular the "170 millisecond"
delay is about 60 milliseconds longer - probably one tick of the 
PC's 18.2 Hz clock.  However, the algorithm just described seems to work
well.

The complete picture looks something like this:

                     ______          BC                 Command
 To Remote      ____/      \_________|__________________|___________________

                     ___________________________________________________
 From Remote    ____/              |   |                                \___

                                   6E  C3
                    |<-80->|<-50-->|   |<---170 msec--->|<--180 msec--->|

The above logic is incorporated into following Turbo-C program:
======================================================================

#include <stdio.h>
#include <dos.h>
#define COM2 0x2f8
#define COM1 0x3f8

main(int argc, char *argv[])
{
        unsigned char c;
        unsigned char s1;
        unsigned val;
        union REGS r;

        if ( argc != 2 ) {
                printf("Need an argument\n");
                exit(1);
        }
        else if ( sscanf(argv[1],"%x",&val) != 1 ) {
                printf("Illegal argument\n");
                exit(2);
        }

        outportb(COM1+3,0x80);  /* Access Divisor Reg */
        outportb(COM1+1,0);     /* Hi byte = 0 */
        outportb(COM1+0,0x18);  /* Lo byte = 4800 baud */
        outportb(COM1+3,0x43);  /* no parity, 1 stop bit, 8 data bits, break */

        outportb(COM1+4,1);     /* Turn on DTR */
        delay(80);
        outportb(COM1+3,0x3);   /* Turn off break */

        while ( ! kbhit() ) {
                if ( inportb(COM1+5) & 0x1 ) {
                        c = inportb(COM1);
                        if ( c == 0x6e ) {
                                outportb(COM1,0xbc);
                        }
                        if ( c == 0xc3 ) {
                                delay(170);
                                outportb(COM1,val);
                                delay(180);
                                break;
                         }
                }
        }
        outportb(COM1+4,0);     /* DTR OFF */
}
=============================================================================
The following functions are supported by the URC-5000-2:

Function        Transmit Code

Power           05
TV              1F
VCR             17
Cable           0F
Sat             07
Aux             1E
Amp             16
Tuner           0E
CD              06
A               1D
Audio           15
Video           0D
Rec             25
Rew             3B
Stop            34
Pause           33
Play            32
FF              3B
Mute            01
Vol-            02
Vol+            03
Ch-             22
Ch+             21
Enter           28
Recall          38
Sleep           3D
Display         35
A/B             2E
Pgm             26
F1              3E
F2              3F
F3              2F
F4              27
0               30
1               1A
2               13
3               0B
4               19
5               11
6               0A
7               18
8               10
9               08

The following functions are supported by the URC-5000-1:

Function        Transmit Code

Power           07
VCR1            1F
VCR2            1E
Cable           1C
CD              16
TV              0F
DO1             0E
DO2             06
Rec             1C
TV/VCR          14
<<              1A
<               13
Stop            0C
Pause           04
Play            0B
>>              03
Mute            02
Vol-            20
Vol+            01
Ch-             23
Ch+             22
Enter           2A
Recall          2B
Do              3C
A               3B
B               3E
C               35
D               37
E               2E
F               2F
G               2G
H               27
0               32
1               18
2               10
3               08
4               38
5               30
6               28
7               39
8               31
9               29

The following functions are supported by the URC-4000

Function        Transmit Code

Power           06
VCR             15
Cable           0D
TV              0E
Rec             3D
TV/VCR          35
<<              3E
<               37
Stop            2E
Pause           26
Play            2F
>>              27
Mute            03
Vol-            20
Vol+            01
Ch-             23
Ch+             22
Enter           2A
Recall          2B
A               3A (1E on URC-4000-1)
B               3B (16 on URC-4000-1)
C               05
0               30
1               1A
2               13
3               0B
4               19
5               11
6               0A
7               18
8               10
9               08
Aux1            1E (URC-4000-2 only)
Aux2            1D (URC-4000-2 only)
CD              16 (URC-4000-2 only)

Peter Fales, peter.fales@att.com 10/12/93

From: dave@solog.com (David T. Byrd)
Date: Wed, 13 Oct 93 00:45:10 EDT
Subject: Universal Remote


Congratulations to Peter Fales at a brilliant job of deducing
the operation of the One-For-All serial protocol.

Although Peter's data is empirically derived, and therefore probably
more accurate than information I could provide, I did manage to obtain
a document from Universal Electronics entitled "Serial Port Keyboard
Control Specification." (REV 1.2 April 21 1989).  I'm afraid I don't
remember or have notes on the guy I spoke with who finally sent it to
me, but the document wasn't hard to locate once I called U.E. and
started asking questions.

Since there is no Copyright Notice on the document, I assume I am
not violating the wishes of U.E. by providing excerpts from it here.

(Peter:  I know of the URC-5000 product, also called "One For All 12,"
 and I know of the URC-4000 called "One For All 6."  What is the
 URC-5000-1 and -2? )
 

The unit I have has only three plated through holes in the circuit
board to attach the cable to.  That is, there is not a bona fide
CONNECTOR on the URC-5000.  I had to disassemble the entire case,
extract the circuit board, solder the pins on the cable to the
URC-5000, and reassemble.  Obviously, you can't remove the cable once
you've done this, so it ceases to be a portable device.

The manual indicates that power is taken both from DTR, which must be
held high, and from RTS, which must be held low.

Basically, the protocol is a little envelope of communication that
achieves the functional equivalency of pushing a single button on the
remote.  Unfortunately, each button push requires a complete envelope
starting with a power up, and ending with a power down, all of which
takes, as Peter shows, a good half second.


The documentation I have differs from Peter's experience slightly.

According to this document, the protocol is described as follows:

0.  start with the All-In-One in "sleep" mode, DTR low, RTS low.
1.  Power up URC-5000;  assert DTR.
2.  send a break condition for at least 50ms; 100ms to be "ultra safe"
    (Peter's figure of 80ms is probably an excellent duration)
    This will cause the URC-5000's multi-color LED to turn on yellow.
3.  Wait for the unit's Wake up ACKnowledge byte (0x6E)

4.  Send the Serial Execute command (0xBC); LED will go out.
5.  Wait for the Serial Acknowledge byte;  My docs say that this 
    byte will be 0x6F, but Peter really got 0xC3,   The manual
    says:
	       "The SAK Acknowledge byte of ONE-FOR-ALLs and UNiWANDs
		is 0x6F.  There are versions of the Homer* which use
		different acknowledge bytes.  In fact, it is the
		acknowledge byte which identifies the version of the
		Homer communicating equipment.
		
    *Homer is the internal name U.E. seems to use for various universal
    remote products.
		
6.  Send the byte for the desired key you wish to transmit.
    (See Peter's lists or the table below)
7.  Wait for an echo of the command.  This byte will usually be the
    same byte as the one sent in step 6, except when the key pressed
    results in the execution of a macro sequence, in which case the echo
    character is the code of the last key in the macro.

8.  Power down the unit; clear DTR.  
((  9.  wait 200ms, then back to step 1 for next command  ))

If you intend to send another command immediately, you must be sure
to leave DTR low for at least 200ms.

To augment Peter's diagram with info from the manual:

                     break
                     _________       BC   Command
 To Remote      ____/         \______|____|_____________________
             DTR on                                     DTR off

                     ___________________________________
 From Remote    ____/              |   |             |  \________
                                   6E  6F           echo
                    |<50-100ms>|           |<depends>|  |<200ms>|


Keycode Commands

The table below is apparently accurate for any URC unit.  The table
maps key positions to key codes, the labels associated with these keys
are specific to each remote.

Row     Col 1	Col 2	Col 3	Col 4
-------------------------------------
1	1f	17	of	07
2	1e	16	0e	06
3	1d	15	0d	05
4	1c	14	0c	04
5	1a	13	0b	03
6	19	11	0a	02
7	18	10	08	01
8	38	30	28	20
9	39	31	29	21
10	3a	32	2a	22
11	3b	33	2b	23
12	3c	34	2c	25
13	3d	35	2e	26
14	3e	37	2f	27


DISCLAIMER

I have not yet written any programs to drive this baby, so I can only
report what the manual says, not what actually works.

dave byrd

dave@solog.com


From: psfales@intgp1.att.com
Date: Wed, 13 Oct 93 15:54 CDT
Subject: More on universal remote control interfaces

Thanks to Dave Byrd for providing the additional information on the
OneForAll protocol.  My response/clarification follows:

BIG QUESTION:  Dave, does your information say anything about programming new
information into the remote?  Several people have asked me about this.


> (Peter:  I know of the URC-5000 product, also called "One For All 12,"
>  and I know of the URC-4000 called "One For All 6."  What is the
>  URC-5000-1 and -2? )

The following is from the documentation for the HAL "EMIT" software.  It
also has no visible copyright notice, so here's what it says:

URC-5000-1	The Original URC-5000
URC-5000-2	The "New" URC-5000 (it's a new one if it includes SUR
			button[SIC])
URC-4000-1	The Original URC-4000
URC-4000-2	The "New" URC-4000 (it's a new one if it includes the CD
			button)

> The unit I have has only three plated through holes in the circuit
> board to attach the cable to.  That is, there is not a bona fide
> CONNECTOR on the URC-5000.  I had to disassemble the entire case,
> extract the circuit board, solder the pins on the cable to the
> URC-5000, and reassemble.  Obviously, you can't remove the cable once
> you've done this, so it ceases to be a portable device.

Sorry if I didn't make this clear.  Mine also has only three holes.  The
connector from HAL has a molded plastic shell whichs fits around the
battery and three pins which fit (very loosely!) in the holes.  With this
connector in place the battery compartment door cannot be closed - kind
of ugly.

> The manual indicates that power is taken both from DTR, which must be
> held high, and from RTS, which must be held low.

I'll check again.  The software I have does not seem to do anything with
RTS, but it may leave it low all the time.  My private software leaves
RTS low all the time - I guess I was lucky that I just happened to do it
this way.

Peter Fales			  AT&T, Room 9C-242
N9IYJ            		  2000 N. Naperville Rd.
UUCP:	...att!intgp1!psfales	  Naperville, IL 60566
Internet: peter.fales@att.com 	  work:	(708) 979-8031


 