Alas,  I haven't subscribed yet!

On 3/31/06, Charles Thurston <cthurston@...> wrote:
> Hello Tom,
>
> Check Page 15 in the April 2006 Servo Magazine. I just read the
> article on doing this.
>
> Friday, March 31, 2006, 10:08:18 PM, you wrote:
>
> > Hi all,
>
> > I'm doing a project where I'm interfacing a PIC to a PC keyboard, as
> > well as emulating a keyboard on a PC's PS/2 port.  Right now I just
> > got comms working between the PIC and the keyboard, I think.  I'm
> > getting valid data, it's just that the bitstream as well as all the
> > keycodes are completely from all the standards that I've found online.
> >  www.beyondlogic.org  states that data from the keyboard comes as:
>
> --
> Best regards,
>  Charles                            mailto:cthurston@...
>
>
>

I asked a similar set of questions on another forum back in 1998. Below (in
a fairly random order) is what I was told

You probably have all this info already but you never know ...

It's a bit long so it might get chopped. I can send it to you personally if
it does.

Peter
===================================================

Hi Everyone

Does anyone know how the keyboard talks to the PC? I've been asked to
design a replacement keyboard for a special job.

So far, from some ancient XT circuit diagrams I reckon that the wires are
power, ground, chassis ground, clock and data. There may be an extra Reset
on some keyboards but I'm not sure if it's mandatory. Which are which on an
XT and PS2 connector?

Clock and data are open collector so either PC or kbd can send or receive.
Both are normally high of course.

When a key is pressed, eleven negative-going pulses are generated on clock.
Some "data" is generated on data. I think I should read the data on the
falling edge of clock but I'm not sure.

And what are the eleven bits? They look like they might be Start=0, 8-data,
odd-parity, stop=1.

My old text book says "the keyboard sends a scan-code to the pc when the
key is pressed and scan-code+128 when the key is released". But what I see
using an oscilloscope doesn't seem to have the right bit values. They look
more like 4-bit row and 4-bit col addresses. And key-up is $0F followed by
the key-value.

And what does the PC send to query kbd? The BIOS obviously sends something
because my PC complains if I try to boot without a kbd plugged in.

Any information will be gratefully receieved.

Thanks.

Peter


===================================================
Bob

I just re-read your message in more detail.

> Also note that the keyboard always controls the clock line, regardless of
the data direction.

How does that work? How does the Keyboard know when to start clocking? Does
it watch the PC pull the clock line low then take over? Or does the PC
start by lowering the Data line? The book I found is a bit vague on the
subject.

Also, what happens after line contention? They both back off but what then
- random wait time and try again? Or is there a special code transmitted?

BTW, how come you know all this stuff? :-)


Thanks

Peter

=======================================================
Thanks Trevor

I've just located a 1984 Technical Reference describing the AT keyboard.
Some of it is a bit
ambiguous but a few experiments and the web page you suggest might
disambiguate things.

It sure is complicated!

Hopefully the web page will tell me whether the PS/2 keyboard differs.

Peter
===========================================================
Thanks Bob

Who'd have thought there was an entire book on keyboards!

It sure is complicated!

I have managed to find a 1984 Technical Reference describing the AT
keyboard. Some of it is a bit ambiguous but a few experiments might
disambiguate things.

It's good to know that the PS/2 is the same.

Peter

=============================================================
Hi Brian

Thank you for the data. It's very useful, where did you find it?

It's more modern than any information I'd found so far - the best I could
do was 1984!

I've connected an old keyboard to my printer port and managed to talk to
it. Next I'll try eavesdropping on a PC as it boots.

Thanks

Peter

==================================================================
Don

>>I think I have some specs for an AT keyboard out in the garage.  IF you
need them, I'll be happy to lend them to you.  (If they really exist).<<

Thanks.

I've since found a book with a copy of the AT keyboard h/w design and a
little about the inteface specification.

Also I'm in Edinburgh, Scotland so it's probably a long way from your
garage to here.

My client is now worrying about the high price I've quoted him so the
project is on hold. I'd originally been enthisiastic to him about how easy
it would be - I'd guessed the kbd would use a simple serial interface.

Why _do_ IBM have to overcomplicate everything?

Peter




===========================================================================
Bob

Thanks. I think I now understand enough now to start doing some real
experiments.

>> BTW, how come you know all this stuff? :-) <<

> PC joysticks. ... when they need to send a character, they gate the real
keyboard offline

So the real keyboard can repsond to many of the commands.

I've been asked to put a barcode reader between the PC and the keyboard.
(Yes, I know such things exist but they cost more than my client wants to
pay and he's expecting to sell hundreds or, hopefully, thousands.)

The problem is that he wants it to work whether the keyboard is there or
not so I'll have to implement _all_ the keyboard commands. My worry is that
if I get one wrong, the PC will simply say "Keyboard error" and give me no
further clues.

When the client saw how many zeroes I put in my cost estimate, he said he'd
go away and think about it.

> the 0x0F break you're seeing is probably just because the bits are
backwards on a 'scope.

Yes, that was it. I can now connect a kbd to my printer port and decode the
keystrokes as they arrive.

Thanks.

Peter

===========================================================================
===========
I have just found a 1984 Technical Reference describing the AT keyboard.
Some of it is a bit ambiguous but a few experiments
might disambiguate things.

It sure is complicated!

Does anyone know whether the PS/2 keyboard differs?

Thanks

Peter



=========================================================================

Hi,

>> Does anyone know how the keyboard talks to the PC? <<

Try http://www.holtek.com/docum/Computer/6542b.htm, there are data sheets
explaining the protocol.

  -TrevK

http://ourworld.compuserve.com/homepages/tkellaway/

=========================================================================


Hi Peter,

Does anyone know how the keyboard talks to the PC? I've been asked to
design a replacement keyboard for a special job.

>> So far, from some ancient XT circuit diagrams I reckon that the wires
are power, ground, chassis ground, clock and data.
There may be an extra Reset on some keyboards but I'm not sure if it's
mandatory. Which are which on an XT and PS2
connector? <<

That's pretty much it. The reset line should normally be grounded, I don't
think there are many keyboards that actually respond to
it. Also, be aware that XT keyboards only worked with XTs. The later AT
keyboards wired somewhat differently and used
different scancodes. Connections are:

   Pin       AT           PS/2
    1        Clock        Data
    2.       Data         N/C
    3.       N/C          Signal Gnd
    4.       Signal Gnd   +5VDC
    5.       +5VDC        Clock
    6.                    N/C

Also, the pins are in kind of a wierd arrangement, i.e. they aren't
numbered in order as you go around the connector. The signals
for a PS/2 and an AT keyboard are identical, it's just a different
connector.

>> Clock and data are open collector so either PC or kbd can send or
receive. Both are normally high of course. <<

Yes.

>> When a key is pressed, eleven negative-going pulses are generated on
clock. Some "data" is generated on data. I think I
should read the data on the falling edge of clock but I'm not sure. <<

Keyboard to PC, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and a
Stop Bit (High). Data is valid on the falling edge of the
clock.

PC to Keyboard, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and
and Acknowledge bit. Data is valid on the positive clock.
The Ack bit is actually a tri-state from the PC, the Keyboard sends that so
the PC knows it got the transfer. Also note that the
keyboard always controls the clock line, regardless of the data direction.

For the keyboard to send, both clock and data must be high at the
beginning. The PC will pull the clock line low if it's busy, and
will pull the data line low when it wants to send a command to the
keyboard. Normally, if the PC sends a command (and there
are several), the keyboard will acknowledge with an 0xfa byte.

>> And what are the eleven bits? They look like they might be Start=0,
8-data, odd-parity, stop=1. <<

Yes.

>> My old text book says "the keyboard sends a scan-code to the pc when the
key is pressed and scan-code+128 when the key
is released". But what I see using an oscilloscope doesn't seem to have the
right bit values. They look more like 4-bit row and 4-
bit col addresses. And key-up is $0F followed by the key-value. <<

That correct, except the keyup code is 0xF0, not 0x0F. Also, there are some
anomalies with the 'gray' cursor keys that showed
up on the 101-key boards that through an 0xE0 into the mix. The
'high-bit-set' code is what it looks like once it gets to the BIOS. I
can send you a list of the raw keycodes if you like.

>> And what does the PC send to query kbd? The BIOS obviously sends
something because my PC complains if I try to boot
without a kbd plugged in. <<

The BIOS sends a reset command and expects a particular response, keyboard
ID or something like that.

The best book I've found on the subject is "PC Keyboard Design" by Gary J.
Konzak. Published by Annabooks, ISBN 0-929392-
12-4.

Hope this helps!

- Bob

=========================================================================


Bob

I just re-read your message in more detail.

> Also note that the keyboard always controls the clock line, regardless of
the data direction.

How does that work? How does the Keyboard know when to start clocking? Does
it watch the PC pull the clock line low then
take over? Or does the PC start by lowering the Data line?

ALso, what happens after line contention? They both back off but what then
- random wait time and try again?

BTW how come you know all this stuff? :-)


Thanks

Peter

=========================================================================


8042 - Keyboard Controller  (AT,PS/2)

%       8042 Status Register (port 64h read)

         ³7³6³5³4³3³2³1³0³  8042 Status Register
          ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ output register (60h) has data for system
          ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ input register (60h/64h) has data for 8042
          ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ system flag (set to 0 after power on reset)
          ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ data in input register is command (1) or data (0)
          ³ ³ ³ ÀÄÄÄÄÄÄÄÄ 1=keyboard enabled, 0=keyboard disabled (via
switch)
          ³ ³ ÀÄÄÄÄÄÄÄÄÄ 1=transmit timeout (data transmit not complete)
          ³ ÀÄÄÄÄÄÄÄÄÄÄ 1=receive timeout (data transmit not complete)
          ÀÄÄÄÄÄÄÄÄÄÄÄ 1=even parity rec'd, 0=odd parity rec'd (should be
odd)

%       Port Mode                 Description

         64h  read   8042 status register. Can be read at any time.  See
                     table above for more information.
         64h  write  8042 command register.  Writing this port sets Bit 3
                     of the status register to 1 and the byte is treated
                     as a controller command.  Devices attached to the
                     8042 should be disabled before issuing commands that
                     return data since data in the output register will
                     be overwritten.
         60h  read   8042 output register (should only be read if Bit 0 of
                     status port is set to 1)
         60h  write  8042 data register.  Data should only be written if
                     Bit 1 of the status register is zero (register is
empty).
                     When this port is written Bit 3 of the status register
                     is set to zero and the byte is treated as a data.  The
                     8042 uses this byte if it's expecting data for a
previous
                     command, otherwise the data is written directly to the
                     keyboard.   See ~KEYBOARD COMMANDS~ for information on
                     programming the actual keyboard hardware.


8042 Commands Related to PC Systems  (Port 64h)

%       Command                    Description

          20   Read 8042 Command Byte: current 8042 command byte is placed
               in port 60h.
          60   Write 8042 Command Byte: next data byte written to port 60h
is
               placed in 8042 command register.  Format:

              ³7³6³5³4³3³2³1³0³  8042 Command Byte
               ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ 1=enable output register full interrupt
               ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ should be 0
               ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ 1=set status register system, 0=clear
               ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ 1=override keyboard inhibit, 0=allow inhibit
               ³ ³ ³ ÀÄÄÄÄÄÄÄÄ disable keyboard I/O by driving clock line
low
               ³ ³ ÀÄÄÄÄÄÄÄÄÄ disable auxiliary device, drives clock line
low
               ³ ÀÄÄÄÄÄÄÄÄÄÄ IBM scancode translation 0=AT, 1=PC/XT
               ÀÄÄÄÄÄÄÄÄÄÄÄ reserved, should be 0

          A4   Password Installed Test: returned data can be read
               from port 60h;  FA=password installed, F1=no password
          A5   Load Security: bytes written to port 60h will be read
               until a null (0) is found.
          A6   Enable Security: works only if a password is already loaded
          A7   Disable Auxiliary Interface: sets Bit 5 of command register
               stopping auxiliary I/O by driving the clock line low
          A8   Enable Auxiliary Interface: clears Bit 5 of command register
          A9   Auxiliary Interface Test: clock and data lines are tested;
               results placed at port 60h are listed below:

                 00  no error
                 01  keyboard clock line is stuck low
                 02  keyboard clock line is stuck high
                 03  keyboard data line is stuck low
                 04  keyboard data line is stuck high

          AA   Self Test: diagnostic result placed at port 60h, 55h=OK
          AB   Keyboard Interface Test:  clock and data lines are tested;
               results placed at port 60h are listed above with command A9
          AC   Diagnostic Dump: sends 16 bytes of 8042's RAM, current input
               port state, current output port state and 8042 program status
               word to port 60h in scan-code format.
          AD   Disable Keyboard Interface: sets Bit 4 of command register
               stopping keyboard I/O by driving the clock line low
          AE   Enable Keyboard Interface: clears Bit 4 of command register
               enabling keyboard interface.
          C0   Read Input Port: data is read from its input port (which is
               inaccessible to the data bus) and written to output register
               at port 60h;  output register should be empty before call.

                ³7³6³5³4³3-0³  8042 Input Port
                 ³ ³ ³ ³ ÀÄÄÄÄ undefined
                 ³ ³ ³ ÀÄÄÄÄÄ 1=enable 2nd 256K of motherboard RAM,
0=disable
                 ³ ³ ÀÄÄÄÄÄÄ 1=manufacturing jumper not installed,
0=installed
                 ³ ÀÄÄÄÄÄÄÄ 1=primary display is MDA, 0=primary display is
CGA
                 ÀÄÄÄÄÄÄÄÄ 1=keyboard not inhibited, 0=keyboard inhibited

          C1   Poll Input Port Low Bits: Bits 0-3 of port 1 placed in
               status Bits 4-7
          C2   Poll Input Port High Bits: Bits 4-7 of port 1 placed in
               status Bits 4-7
          D0   Read Output Port: data is read from 8042 output port (which
is
               inaccessible to the data bus) and placed in output register;
               the output register should be empty.  (see command D1 below)
          D1   Write Output Port: next byte written to port 60h is placed in
               the 8042 output port (which is inaccessible to the data bus)

                 ³7³6³5³4³3³2³1³0³  8042 Output Port
                  ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ system reset line
                  ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ gate A20
                  ³ ³ ³ ³ ÀÄÁÄÄÄÄÄÄ undefined
                  ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄ output buffer full
                  ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ input buffer empty
                  ³ ÀÄÄÄÄÄÄÄÄÄÄÄ keyboard clock (output)
                  ÀÄÄÄÄÄÄÄÄÄÄÄÄ keyboard data (output)

          D2   Write Keyboard Output Register: on PS/2 systems the next data
               byte written to port 60h input register is written to port
60h
               output register as if initiated by a device; invokes
interrupt
               if enabled
          D3   Write Auxiliary Output Register: on PS/2 systems the next
data
               byte written to port 60h input register is written to port
60h
               output register as if initiated by a device; invokes
interrupt
               if enabled
          D4   Write Auxiliary Device: on PS/2 systems the next data byte
               written to input register a port at 60h is sent to the
               auxiliary device
          E0   Read Test Inputs: 8042 reads its T0 and T1 inputs; data is
               placed in output register;  Bit 0 is T0, Bit 1 is T1:

                 ³1³0³  Test Input Port Bits
                  ³ ÀÄÄÄÄ keyboard clock
                  ÀÄÄÄÄÄ keyboard data

          Fx   Pulse Output Port: Bits 0-3 of the 8042 output port can be
               pulsed low for 6 æs;  Bits 0-3 of command indicate which
               Bits should be pulsed; 0=pulse, 1=don't pulse; pulsing
               Bit 0 results in CPU reset since it is connected to system
               reset line.

         - PC systems previous to the AT use the 8255 PPI as a keyboard
           controller and use the keyboard's internal 8048.
         - the keyboard's internal controller buffers up to 16 bytes of
           make/break code information.  This is common among all PC systems
           and shouldn't be confused with the (32 byte) keyboard buffer
           maintained by the BIOS.
         - see  ~KEYBOARD COMMANDS~ for information on programming the
           keyboards internal microprocessor











Keyboard Commands & Responses

Commands System Issues to Keyboard (via 8042 port 60h)

         ED  Set/Reset Mode Indicators, keyboard responds with ACK then
             waits for a following option byte.  When the option byte is
             received the keyboard again ACK's and then sets the LED's
             accordingly.  Scanning is resumed if scanning was enabled.
             If another command is received instead of the option byte
             (high bit set on) this command is terminated.  Hardware
             defaults to these indicators turned off.

             ³7-3³2³1³0³ Keyboard Status Indicator Option Byte
               ³  ³ ³ ÀÄÄÄ Scroll-Lock indicator  (0=off, 1=on)
               ³  ³ ÀÄÄÄÄ Num-Lock indicator  (0=off, 1=on)
               ³  ÀÄÄÄÄÄ Caps-Lock indicator  (0=off, 1=on)
               ÀÄÄÄÄÄÄÄ reserved (must be zero)

         EE  Diagnostic Echo, keyboard echoes the EE byte back to the system
             without an acknowledgement.
         F0  PS/2 Select/Read Alternate Scan Code Sets, instructs keyboard
             to use one of the three make/break scan code sets.   Keyboard
             responds by clearing the output buffer/typematic key and then
             transmits an ACK.  The system must follow up by sending an
             option byte which will again be ACK'ed by the keyboard:

               00  return byte indicating scan code set in use
               01  select scan code set 1  (used on PC & XT)
               02  select scan code set 2
               03  select scan code set 3

         F2  PS/2 Read Keyboard ID, keyboard responds with an ACK and a two
             byte keyboard ID of 83AB.
         F3  Set Typematic Rate/Delay, keyboard responds with ACK and waits
             for rate/delay byte.   Upon receipt of the rate/delay byte the
             keyboard responds with an ACK, then sets the new typematic
             values and scanning continues if scanning was enabled.

             ³7³6³5³4³3³2³1³0³  Typematic Rate/Delay Option Byte
              ³ ³ ³ ÃÄÅÄÅÄÅÄÅÄÄÄÄ typematic rate indicator (see ~INT 16,3~)
              ³ ³ ³ ³ ³ ÀÄÁÄÁÄÄÄ A in period formula (see below)
              ³ ³ ³ ÀÄÁÄÄÄÄÄÄÄÄ B is period formula (see below)
              ³ ÀÄÁÄÄÄÄÄÄÄÄÄÄÄ typematic delay
              ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ always zero

             delay = (rate+1) * 250   (in milliseconds)
             rate = (8+A) * (2**B) * 4.17  (in seconds, ñ 20%)

             Defaults to 10.9 characters per second and a 500ms delay.  If a
             command byte (byte with high bit set) is received instead of an
             option byte this command is cancelled.
         F4  Enable Keyboard, cause the keyboard to clear its output buffer
             and last typematic key and then respond with an ACK.  The
             keyboard then begins scanning.
         F5  Default w/Disable, resets keyboard to power-on condition by
             clearing the output buffer, resetting typematic rate/delay,
             resetting last typematic key and setting default key types.
             The keyboard responds with an ACK and waits for the next
             instruction.
         F6  Set Default, resets to power-on condition by clearing the
output
             buffer, resetting typematic rate/delay and last typematic key
             and sets default key types.  The keyboard responds with an ACK
             and continues scanning.
         F7  PS/2 Set All Keys to Typematic, keyboard responds by sending an
             ACK, clearing its output buffer and setting the key type to
             Typematic.   Scanning continues if scanning was enabled.  This
             command may be sent while using any Scan Code Set but only has
             effect when Scan Code Set 3 is in use.
         F8  PS/2 Set All Keys to Make/Break, keyboard responds by sending
an
             ACK, clearing its output buffer and setting the key type to
             Make/Break.  Scanning continues if scanning was enabled.  This
             command may be sent while using any Scan Code Set but only has
             effect when Scan Code Set 3 is in use.
         F9  PS/2 Set All Keys to Make, keyboard responds by sending an ACK,
             clearing its output buffer and setting the key type to Make.
             Scanning continues if scanning was enabled.  This command may
             be sent while using any Scan Code Set but only has effect when
             Scan Code Set 3 is in use.
         FA  PS/2 Set All Keys to Typematic Make/Break, keyboard responds by
             sending an ACK, clearing its output buffer and setting the key
             type to Typematic Make/Break.  Scanning continues if scanning
             was enabled.  This command may be sent while using any Scan
Code
             Set but only has effect when Scan Code Set 3 is in use.
         FB  PS/2 Set Key Type to Typematic, keyboard responds by sending an
             ACK, clearing its output buffer and then waiting for the key ID
             (make code from Scan Code Set 3).  The specified key type is
then
             set to typematic.   This command may be sent while using any
             Scan Code Set but only has effect when Scan Code Set 3 is in
use.
         FC  PS/2 Set Key Type to Make/Break, keyboard responds by sending
an
             ACK, clearing its output buffer and then waiting for the key ID
             (make code from Scan Code Set 3).  The specified key type is
then
             set to Make/Break.   This command may be sent while using any
Scan
             Code Set but only has effect when Scan Code Set 3 is in use.
         FD  PS/2 Set Key Type to Make, keyboard responds by sending an ACK,
             clearing its output buffer and then waiting for the key ID
(make
             code from Scan Code Set 3).  The specified key type is then set
             to Make.  This command may be sent while using any Scan Code
Set
             but only has effect when Scan Code Set 3 is in use.
         FE  Resend, should be sent when a transmission error is detected
             from the keyboard
         FF  Reset, Keyboard sends ACK and waits for system to receive it
             then begins a program reset and Basic Assurance Test (BAT).
             Keyboard returns a one byte completion code then sets default
             Scan Code Set 2.


Keyboard Responses to System (via 8042 port 60h)

         00  Key Detection Error or Overrun Error for Scan Code Set 1,
             replaces last key in the keyboard buffer if the buffer is full.
         AA  BAT Completion Code, keyboard sends this to indicate the
keyboard
             test was successful.
         EE  Echo Response, response to the Echo command.
         F0  Break Code Prefix in Scan Code Sets 2 and 3.
         FA  Acknowledge, keyboard sends this whenever a valid command or
             data byte is received (except on Echo and Resend commands).
         FC  BAT Failure Code, keyboard sends this to indicate the keyboard
             test failed and stops scanning until a response or reset is
sent.
         FE  Resend, keyboard request resend of data when data sent to it is
             invalid or arrives with invalid parity.
         FF  Key Detection Error or Overrun Error for Scan Code Set 2 or 3,
             replaces last key in the keyboard buffer if the buffer is full.
         id  Keyboard ID Response, keyboard sends a two byte ID after
ACK'ing
             the Read ID command.  The byte stream contains 83AB in LSB, MSB
             order.  The keyboard then resumes scanning.

     - command F7 through FD are NOP's on the AT and are ACK'ed but not
           acted upon


=========================================================================
Hi Paul,

>> How does that work? How does the Keyboard know when to start clocking?
Does it watch the PC pull the clock line low then
take over? Or does the PC start by lowering the Data line? The book I found
is a bit vague on the subject. <<

For a PC->Keyboard transfer, the keyboard watches for the PC (actually the
8042 in the PC) to pull the Data Line low while the
clock line is high. The PC just waits at that point for the Keyboard to
start clocking, then sends out the data.

For a Keyboard->PC transfer, the keyboard just checks that both clock and
data are high, then starts transmitting. During
periods when the PC can't respond, it will hold the clock low and that
stops the keyboard from beginning a transmission.

>> Also, what happens after line contention? They both back off but what
then - random wait time and try again? Or is there a
special code transmitted? <<

As I mentioned above, the PC holds the clock line low if it can't respond
to the keyboard for some reason, maybe servicing a
PS2 mouse or whatever. The Keyboard is supposed to check each time it
releases the clock line to supply a high clock (up to
the tenth bit, I think). If the PC has started doing
something else, it will clamp the clock to ground and the keyboard can see
that
it doesn't float high when released. In that case, the keyboard aborts the
transmission. Also, if either end detects a character
error or illegal command, it can request a resend. The keyboard does that
in place of the ACK that it normally sends when it
receives a command. The PC can do it anytime it gets a garbled character.

>> BTW, how come you know all this stuff? :-) <<

I spent about 4 years designing circuits and coding microchips for
programmable PC joysticks. They connect between the PC
and the keyboard, when they need to send a character, they gate the real
keyboard offline and control the clock/data lines
themselves to generate the characters, then reconnect the keyboard. The
also downloaded the stick program through the
keyboard port (there's some real fun<g>). Anyway, I got to know the AT/PS2
keyboard interface pretty well.

BTW, it occurred to me that the 0x0F break you're seeing is probably just
because the bits are backwards on a 'scope. It sends
things LSB first.

- Bob

=========================================================================

Check the book "the Indispensable PC Hardware Book" by Messmer. ISBN
0-201-40399-4.

=========================================================================
>>Hopefully the web page will tell me whether the PS/2 keyboard differs.

Winn Rosch's Hardware bible lists the PS/2 connector as:
   Pin   Description   Direction
    1    Data           In
    2    Reserved       N/A
    3    Ground         N/A
    4    +5v            Out
    6    Reserved       N/A
    Shield  Ground      N/A

                   |<---Notch
                   ^
                 5   6
               3       4
                 1   2

An excellent reference on everything keyboard related:

http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

See section 11.3 Keyboard Controller Commands to see how the PC reads the
keyboard and tells it to self test, etc.

Ed Okerson

> I asked a similar set of questions on another forum back in 1998. Below
> (in
> a fairly random order) is what I was told
>
> You probably have all this info already but you never know ...
>
> It's a bit long so it might get chopped. I can send it to you personally
> if
> it does.
>
> Peter
> ===================================================
>
> Hi Everyone
>
> Does anyone know how the keyboard talks to the PC? I've been asked to
> design a replacement keyboard for a special job.
>
> So far, from some ancient XT circuit diagrams I reckon that the wires are
> power, ground, chassis ground, clock and data. There may be an extra Reset
> on some keyboards but I'm not sure if it's mandatory. Which are which on
> an
> XT and PS2 connector?
>
> Clock and data are open collector so either PC or kbd can send or receive.
> Both are normally high of course.
>
> When a key is pressed, eleven negative-going pulses are generated on
> clock.
> Some "data" is generated on data. I think I should read the data on the
> falling edge of clock but I'm not sure.
>
> And what are the eleven bits? They look like they might be Start=0,
> 8-data,
> odd-parity, stop=1.
>
> My old text book says "the keyboard sends a scan-code to the pc when the
> key is pressed and scan-code+128 when the key is released". But what I see
> using an oscilloscope doesn't seem to have the right bit values. They look
> more like 4-bit row and 4-bit col addresses. And key-up is $0F followed by
> the key-value.
>
> And what does the PC send to query kbd? The BIOS obviously sends something
> because my PC complains if I try to boot without a kbd plugged in.
>
> Any information will be gratefully receieved.
>
> Thanks.
>
> Peter
>
>
> ===================================================
> Bob
>
> I just re-read your message in more detail.
>
>> Also note that the keyboard always controls the clock line, regardless
>> of
> the data direction.
>
> How does that work? How does the Keyboard know when to start clocking?
> Does
> it watch the PC pull the clock line low then take over? Or does the PC
> start by lowering the Data line? The book I found is a bit vague on the
> subject.
>
> Also, what happens after line contention? They both back off but what then
> - random wait time and try again? Or is there a special code transmitted?
>
> BTW, how come you know all this stuff? :-)
>
>
> Thanks
>
> Peter
>
> =======================================================
> Thanks Trevor
>
> I've just located a 1984 Technical Reference describing the AT keyboard.
> Some of it is a bit
> ambiguous but a few experiments and the web page you suggest might
> disambiguate things.
>
> It sure is complicated!
>
> Hopefully the web page will tell me whether the PS/2 keyboard differs.
>
> Peter
> ===========================================================
> Thanks Bob
>
> Who'd have thought there was an entire book on keyboards!
>
> It sure is complicated!
>
> I have managed to find a 1984 Technical Reference describing the AT
> keyboard. Some of it is a bit ambiguous but a few experiments might
> disambiguate things.
>
> It's good to know that the PS/2 is the same.
>
> Peter
>
> =============================================================
> Hi Brian
>
> Thank you for the data. It's very useful, where did you find it?
>
> It's more modern than any information I'd found so far - the best I could
> do was 1984!
>
> I've connected an old keyboard to my printer port and managed to talk to
> it. Next I'll try eavesdropping on a PC as it boots.
>
> Thanks
>
> Peter
>
> ==================================================================
> Don
>
>>>I think I have some specs for an AT keyboard out in the garage.  IF you
> need them, I'll be happy to lend them to you.  (If they really exist).<<
>
> Thanks.
>
> I've since found a book with a copy of the AT keyboard h/w design and a
> little about the inteface specification.
>
> Also I'm in Edinburgh, Scotland so it's probably a long way from your
> garage to here.
>
> My client is now worrying about the high price I've quoted him so the
> project is on hold. I'd originally been enthisiastic to him about how easy
> it would be - I'd guessed the kbd would use a simple serial interface.
>
> Why _do_ IBM have to overcomplicate everything?
>
> Peter
>
>
>
>
> ===========================================================================
> Bob
>
> Thanks. I think I now understand enough now to start doing some real
> experiments.
>
>>> BTW, how come you know all this stuff? :-) <<
>
>> PC joysticks. ... when they need to send a character, they gate the real
> keyboard offline
>
> So the real keyboard can repsond to many of the commands.
>
> I've been asked to put a barcode reader between the PC and the keyboard.
> (Yes, I know such things exist but they cost more than my client wants to
> pay and he's expecting to sell hundreds or, hopefully, thousands.)
>
> The problem is that he wants it to work whether the keyboard is there or
> not so I'll have to implement _all_ the keyboard commands. My worry is
> that
> if I get one wrong, the PC will simply say "Keyboard error" and give me no
> further clues.
>
> When the client saw how many zeroes I put in my cost estimate, he said
> he'd
> go away and think about it.
>
>> the 0x0F break you're seeing is probably just because the bits are
> backwards on a 'scope.
>
> Yes, that was it. I can now connect a kbd to my printer port and decode
> the
> keystrokes as they arrive.
>
> Thanks.
>
> Peter
>
> ===========================================================================
> ===========
> I have just found a 1984 Technical Reference describing the AT keyboard.
> Some of it is a bit ambiguous but a few experiments
> might disambiguate things.
>
> It sure is complicated!
>
> Does anyone know whether the PS/2 keyboard differs?
>
> Thanks
>
> Peter
>
>
>
> =========================================================================
>
> Hi,
>
>>> Does anyone know how the keyboard talks to the PC? <<
>
> Try http://www.holtek.com/docum/Computer/6542b.htm, there are data sheets
> explaining the protocol.
>
>  -TrevK
>
> http://ourworld.compuserve.com/homepages/tkellaway/
>
> =========================================================================
>
>
> Hi Peter,
>
> Does anyone know how the keyboard talks to the PC? I've been asked to
> design a replacement keyboard for a special job.
>
>>> So far, from some ancient XT circuit diagrams I reckon that the wires
> are power, ground, chassis ground, clock and data.
> There may be an extra Reset on some keyboards but I'm not sure if it's
> mandatory. Which are which on an XT and PS2
> connector? <<
>
> That's pretty much it. The reset line should normally be grounded, I don't
> think there are many keyboards that actually respond to
> it. Also, be aware that XT keyboards only worked with XTs. The later AT
> keyboards wired somewhat differently and used
> different scancodes. Connections are:
>
>   Pin       AT           PS/2
>    1        Clock        Data
>    2.       Data         N/C
>    3.       N/C          Signal Gnd
>    4.       Signal Gnd   +5VDC
>    5.       +5VDC        Clock
>    6.                    N/C
>
> Also, the pins are in kind of a wierd arrangement, i.e. they aren't
> numbered in order as you go around the connector. The signals
> for a PS/2 and an AT keyboard are identical, it's just a different
> connector.
>
>>> Clock and data are open collector so either PC or kbd can send or
> receive. Both are normally high of course. <<
>
> Yes.
>
>>> When a key is pressed, eleven negative-going pulses are generated on
> clock. Some "data" is generated on data. I think I
> should read the data on the falling edge of clock but I'm not sure. <<
>
> Keyboard to PC, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and a
> Stop Bit (High). Data is valid on the falling edge of the
> clock.
>
> PC to Keyboard, it's Start Bit (low), 8 Data Bits, 1 Odd Parity Bit, and
> and Acknowledge bit. Data is valid on the positive clock.
> The Ack bit is actually a tri-state from the PC, the Keyboard sends that
> so
> the PC knows it got the transfer. Also note that the
> keyboard always controls the clock line, regardless of the data direction.
>
> For the keyboard to send, both clock and data must be high at the
> beginning. The PC will pull the clock line low if it's busy, and
> will pull the data line low when it wants to send a command to the
> keyboard. Normally, if the PC sends a command (and there
> are several), the keyboard will acknowledge with an 0xfa byte.
>
>>> And what are the eleven bits? They look like they might be Start=0,
> 8-data, odd-parity, stop=1. <<
>
> Yes.
>
>>> My old text book says "the keyboard sends a scan-code to the pc when
>>> the
> key is pressed and scan-code+128 when the key
> is released". But what I see using an oscilloscope doesn't seem to have
> the
> right bit values. They look more like 4-bit row and 4-
> bit col addresses. And key-up is $0F followed by the key-value. <<
>
> That correct, except the keyup code is 0xF0, not 0x0F. Also, there are
> some
> anomalies with the 'gray' cursor keys that showed
> up on the 101-key boards that through an 0xE0 into the mix. The
> 'high-bit-set' code is what it looks like once it gets to the BIOS. I
> can send you a list of the raw keycodes if you like.
>
>>> And what does the PC send to query kbd? The BIOS obviously sends
> something because my PC complains if I try to boot
> without a kbd plugged in. <<
>
> The BIOS sends a reset command and expects a particular response, keyboard
> ID or something like that.
>
> The best book I've found on the subject is "PC Keyboard Design" by Gary J.
> Konzak. Published by Annabooks, ISBN 0-929392-
> 12-4.
>
> Hope this helps!
>
> - Bob
>
> =========================================================================
>
>
> Bob
>
> I just re-read your message in more detail.
>
>> Also note that the keyboard always controls the clock line, regardless
>> of
> the data direction.
>
> How does that work? How does the Keyboard know when to start clocking?
> Does
> it watch the PC pull the clock line low then
> take over? Or does the PC start by lowering the Data line?
>
> ALso, what happens after line contention? They both back off but what then
> - random wait time and try again?
>
> BTW how come you know all this stuff? :-)
>
>
> Thanks
>
> Peter
>
> =========================================================================
>
>
> 8042 - Keyboard Controller  (AT,PS/2)
>
> %       8042 Status Register (port 64h read)
>
>         ³7³6³5³4³3³2³1³0³  8042 Status Register
>          ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ output register (60h) has data for system
>          ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ input register (60h/64h) has data for 8042
>          ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ system flag (set to 0 after power on reset)
>          ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ data in input register is command (1) or data
> (0)
>          ³ ³ ³ ÀÄÄÄÄÄÄÄÄ 1=keyboard enabled, 0=keyboard disabled (via
> switch)
>          ³ ³ ÀÄÄÄÄÄÄÄÄÄ 1=transmit timeout (data transmit not complete)
>          ³ ÀÄÄÄÄÄÄÄÄÄÄ 1=receive timeout (data transmit not complete)
>          ÀÄÄÄÄÄÄÄÄÄÄÄ 1=even parity rec'd, 0=odd parity rec'd (should be
> odd)
>
> %       Port Mode                 Description
>
>         64h  read   8042 status register. Can be read at any time.  See
>                     table above for more information.
>         64h  write  8042 command register.  Writing this port sets Bit 3
>                     of the status register to 1 and the byte is treated
>                     as a controller command.  Devices attached to the
>                     8042 should be disabled before issuing commands that
>                     return data since data in the output register will
>                     be overwritten.
>         60h  read   8042 output register (should only be read if Bit 0 of
>                     status port is set to 1)
>         60h  write  8042 data register.  Data should only be written if
>                     Bit 1 of the status register is zero (register is
> empty).
>                     When this port is written Bit 3 of the status register
>                     is set to zero and the byte is treated as a data.  The
>                     8042 uses this byte if it's expecting data for a
> previous
>                     command, otherwise the data is written directly to the
>                     keyboard.   See ~KEYBOARD COMMANDS~ for information on
>                     programming the actual keyboard hardware.
>
>
> 8042 Commands Related to PC Systems  (Port 64h)
>
> %       Command                    Description
>
>          20   Read 8042 Command Byte: current 8042 command byte is placed
>               in port 60h.
>          60   Write 8042 Command Byte: next data byte written to port 60h
> is
>               placed in 8042 command register.  Format:
>
>              ³7³6³5³4³3³2³1³0³  8042 Command Byte
>               ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ 1=enable output register full interrupt
>               ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ should be 0
>               ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄ 1=set status register system, 0=clear
>               ³ ³ ³ ³ ÀÄÄÄÄÄÄÄ 1=override keyboard inhibit, 0=allow
> inhibit
>               ³ ³ ³ ÀÄÄÄÄÄÄÄÄ disable keyboard I/O by driving clock line
> low
>               ³ ³ ÀÄÄÄÄÄÄÄÄÄ disable auxiliary device, drives clock line
> low
>               ³ ÀÄÄÄÄÄÄÄÄÄÄ IBM scancode translation 0=AT, 1=PC/XT
>               ÀÄÄÄÄÄÄÄÄÄÄÄ reserved, should be 0
>
>          A4   Password Installed Test: returned data can be read
>               from port 60h;  FA=password installed, F1=no password
>          A5   Load Security: bytes written to port 60h will be read
>               until a null (0) is found.
>          A6   Enable Security: works only if a password is already loaded
>          A7   Disable Auxiliary Interface: sets Bit 5 of command register
>               stopping auxiliary I/O by driving the clock line low
>          A8   Enable Auxiliary Interface: clears Bit 5 of command register
>          A9   Auxiliary Interface Test: clock and data lines are tested;
>               results placed at port 60h are listed below:
>
>                 00  no error
>                 01  keyboard clock line is stuck low
>                 02  keyboard clock line is stuck high
>                 03  keyboard data line is stuck low
>                 04  keyboard data line is stuck high
>
>          AA   Self Test: diagnostic result placed at port 60h, 55h=OK
>          AB   Keyboard Interface Test:  clock and data lines are tested;
>               results placed at port 60h are listed above with command A9
>          AC   Diagnostic Dump: sends 16 bytes of 8042's RAM, current input
>               port state, current output port state and 8042 program
> status
>               word to port 60h in scan-code format.
>          AD   Disable Keyboard Interface: sets Bit 4 of command register
>               stopping keyboard I/O by driving the clock line low
>          AE   Enable Keyboard Interface: clears Bit 4 of command register
>               enabling keyboard interface.
>          C0   Read Input Port: data is read from its input port (which is
>               inaccessible to the data bus) and written to output register
>               at port 60h;  output register should be empty before call.
>
>                ³7³6³5³4³3-0³  8042 Input Port
>                 ³ ³ ³ ³ ÀÄÄÄÄ undefined
>                 ³ ³ ³ ÀÄÄÄÄÄ 1=enable 2nd 256K of motherboard RAM,
> 0=disable
>                 ³ ³ ÀÄÄÄÄÄÄ 1=manufacturing jumper not installed,
> 0=installed
>                 ³ ÀÄÄÄÄÄÄÄ 1=primary display is MDA, 0=primary display is
> CGA
>                 ÀÄÄÄÄÄÄÄÄ 1=keyboard not inhibited, 0=keyboard inhibited
>
>          C1   Poll Input Port Low Bits: Bits 0-3 of port 1 placed in
>               status Bits 4-7
>          C2   Poll Input Port High Bits: Bits 4-7 of port 1 placed in
>               status Bits 4-7
>          D0   Read Output Port: data is read from 8042 output port (which
> is
>               inaccessible to the data bus) and placed in output register;
>               the output register should be empty.  (see command D1 below)
>          D1   Write Output Port: next byte written to port 60h is placed
> in
>               the 8042 output port (which is inaccessible to the data bus)
>
>                 ³7³6³5³4³3³2³1³0³  8042 Output Port
>                  ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄÄ system reset line
>                  ³ ³ ³ ³ ³ ³ ÀÄÄÄÄÄ gate A20
>                  ³ ³ ³ ³ ÀÄÁÄÄÄÄÄÄ undefined
>                  ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄ output buffer full
>                  ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ input buffer empty
>                  ³ ÀÄÄÄÄÄÄÄÄÄÄÄ keyboard clock (output)
>                  ÀÄÄÄÄÄÄÄÄÄÄÄÄ keyboard data (output)
>
>          D2   Write Keyboard Output Register: on PS/2 systems the next
> data
>               byte written to port 60h input register is written to port
> 60h
>               output register as if initiated by a device; invokes
> interrupt
>               if enabled
>          D3   Write Auxiliary Output Register: on PS/2 systems the next
> data
>               byte written to port 60h input register is written to port
> 60h
>               output register as if initiated by a device; invokes
> interrupt
>               if enabled
>          D4   Write Auxiliary Device: on PS/2 systems the next data byte
>               written to input register a port at 60h is sent to the
>               auxiliary device
>          E0   Read Test Inputs: 8042 reads its T0 and T1 inputs; data is
>               placed in output register;  Bit 0 is T0, Bit 1 is T1:
>
>                 ³1³0³  Test Input Port Bits
>                  ³ ÀÄÄÄÄ keyboard clock
>                  ÀÄÄÄÄÄ keyboard data
>
>          Fx   Pulse Output Port: Bits 0-3 of the 8042 output port can be
>               pulsed low for 6 æs;  Bits 0-3 of command indicate which
>               Bits should be pulsed; 0=pulse, 1=don't pulse; pulsing
>               Bit 0 results in CPU reset since it is connected to system
>               reset line.
>
>         - PC systems previous to the AT use the 8255 PPI as a keyboard
>           controller and use the keyboard's internal 8048.
>         - the keyboard's internal controller buffers up to 16 bytes of
>           make/break code information.  This is common among all PC
> systems
>           and shouldn't be confused with the (32 byte) keyboard buffer
>           maintained by the BIOS.
>         - see  ~KEYBOARD COMMANDS~ for information on programming the
>           keyboards internal microprocessor
>
>
>
>
>
>
>
>
>
>
>
> Keyboard Commands & Responses
>
> Commands System Issues to Keyboard (via 8042 port 60h)
>
>         ED  Set/Reset Mode Indicators, keyboard responds with ACK then
>             waits for a following option byte.  When the option byte is
>             received the keyboard again ACK's and then sets the LED's
>             accordingly.  Scanning is resumed if scanning was enabled.
>             If another command is received instead of the option byte
>             (high bit set on) this command is terminated.  Hardware
>             defaults to these indicators turned off.
>
>             ³7-3³2³1³0³ Keyboard Status Indicator Option Byte
>               ³  ³ ³ ÀÄÄÄ Scroll-Lock indicator  (0=off, 1=on)
>               ³  ³ ÀÄÄÄÄ Num-Lock indicator  (0=off, 1=on)
>               ³  ÀÄÄÄÄÄ Caps-Lock indicator  (0=off, 1=on)
>               ÀÄÄÄÄÄÄÄ reserved (must be zero)
>
>         EE  Diagnostic Echo, keyboard echoes the EE byte back to the
> system
>             without an acknowledgement.
>         F0  PS/2 Select/Read Alternate Scan Code Sets, instructs keyboard
>             to use one of the three make/break scan code sets.   Keyboard
>             responds by clearing the output buffer/typematic key and then
>             transmits an ACK.  The system must follow up by sending an
>             option byte which will again be ACK'ed by the keyboard:
>
>               00  return byte indicating scan code set in use
>               01  select scan code set 1  (used on PC & XT)
>               02  select scan code set 2
>               03  select scan code set 3
>
>         F2  PS/2 Read Keyboard ID, keyboard responds with an ACK and a two
>             byte keyboard ID of 83AB.
>         F3  Set Typematic Rate/Delay, keyboard responds with ACK and waits
>             for rate/delay byte.   Upon receipt of the rate/delay byte the
>             keyboard responds with an ACK, then sets the new typematic
>             values and scanning continues if scanning was enabled.
>
>             ³7³6³5³4³3³2³1³0³  Typematic Rate/Delay Option Byte
>              ³ ³ ³ ÃÄÅÄÅÄÅÄÅÄÄÄÄ typematic rate indicator (see ~INT 16,3~)
>              ³ ³ ³ ³ ³ ÀÄÁÄÁÄÄÄ A in period formula (see below)
>              ³ ³ ³ ÀÄÁÄÄÄÄÄÄÄÄ B is period formula (see below)
>              ³ ÀÄÁÄÄÄÄÄÄÄÄÄÄÄ typematic delay
>              ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ always zero
>
>             delay = (rate+1) * 250   (in milliseconds)
>             rate = (8+A) * (2**B) * 4.17  (in seconds, ñ 20%)
>
>             Defaults to 10.9 characters per second and a 500ms delay.  If
> a
>             command byte (byte with high bit set) is received instead of
> an
>             option byte this command is cancelled.
>         F4  Enable Keyboard, cause the keyboard to clear its output buffer
>             and last typematic key and then respond with an ACK.  The
>             keyboard then begins scanning.
>         F5  Default w/Disable, resets keyboard to power-on condition by
>             clearing the output buffer, resetting typematic rate/delay,
>             resetting last typematic key and setting default key types.
>             The keyboard responds with an ACK and waits for the next
>             instruction.
>         F6  Set Default, resets to power-on condition by clearing the
> output
>             buffer, resetting typematic rate/delay and last typematic key
>             and sets default key types.  The keyboard responds with an ACK
>             and continues scanning.
>         F7  PS/2 Set All Keys to Typematic, keyboard responds by sending
> an
>             ACK, clearing its output buffer and setting the key type to
>             Typematic.   Scanning continues if scanning was enabled.  This
>             command may be sent while using any Scan Code Set but only has
>             effect when Scan Code Set 3 is in use.
>         F8  PS/2 Set All Keys to Make/Break, keyboard responds by sending
> an
>             ACK, clearing its output buffer and setting the key type to
>             Make/Break.  Scanning continues if scanning was enabled.  This
>             command may be sent while using any Scan Code Set but only has
>             effect when Scan Code Set 3 is in use.
>         F9  PS/2 Set All Keys to Make, keyboard responds by sending an
> ACK,
>             clearing its output buffer and setting the key type to Make.
>             Scanning continues if scanning was enabled.  This command may
>             be sent while using any Scan Code Set but only has effect when
>             Scan Code Set 3 is in use.
>         FA  PS/2 Set All Keys to Typematic Make/Break, keyboard responds
> by
>             sending an ACK, clearing its output buffer and setting the key
>             type to Typematic Make/Break.  Scanning continues if scanning
>             was enabled.  This command may be sent while using any Scan
> Code
>             Set but only has effect when Scan Code Set 3 is in use.
>         FB  PS/2 Set Key Type to Typematic, keyboard responds by sending
> an
>             ACK, clearing its output buffer and then waiting for the key
> ID
>             (make code from Scan Code Set 3).  The specified key type is
> then
>             set to typematic.   This command may be sent while using any
>             Scan Code Set but only has effect when Scan Code Set 3 is in
> use.
>         FC  PS/2 Set Key Type to Make/Break, keyboard responds by sending
> an
>             ACK, clearing its output buffer and then waiting for the key
> ID
>             (make code from Scan Code Set 3).  The specified key type is
> then
>             set to Make/Break.   This command may be sent while using any
> Scan
>             Code Set but only has effect when Scan Code Set 3 is in use.
>         FD  PS/2 Set Key Type to Make, keyboard responds by sending an
> ACK,
>             clearing its output buffer and then waiting for the key ID
> (make
>             code from Scan Code Set 3).  The specified key type is then
> set
>             to Make.  This command may be sent while using any Scan Code
> Set
>             but only has effect when Scan Code Set 3 is in use.
>         FE  Resend, should be sent when a transmission error is detected
>             from the keyboard
>         FF  Reset, Keyboard sends ACK and waits for system to receive it
>             then begins a program reset and Basic Assurance Test (BAT).
>             Keyboard returns a one byte completion code then sets default
>             Scan Code Set 2.
>
>
> Keyboard Responses to System (via 8042 port 60h)
>
>         00  Key Detection Error or Overrun Error for Scan Code Set 1,
>             replaces last key in the keyboard buffer if the buffer is
> full.
>         AA  BAT Completion Code, keyboard sends this to indicate the
> keyboard
>             test was successful.
>         EE  Echo Response, response to the Echo command.
>         F0  Break Code Prefix in Scan Code Sets 2 and 3.
>         FA  Acknowledge, keyboard sends this whenever a valid command or
>             data byte is received (except on Echo and Resend commands).
>         FC  BAT Failure Code, keyboard sends this to indicate the keyboard
>             test failed and stops scanning until a response or reset is
> sent.
>         FE  Resend, keyboard request resend of data when data sent to it
> is
>             invalid or arrives with invalid parity.
>         FF  Key Detection Error or Overrun Error for Scan Code Set 2 or 3,
>             replaces last key in the keyboard buffer if the buffer is
> full.
>         id  Keyboard ID Response, keyboard sends a two byte ID after
> ACK'ing
>             the Read ID command.  The byte stream contains 83AB in LSB,
> MSB
>             order.  The keyboard then resumes scanning.
>
>     - command F7 through FD are NOP's on the AT and are ACK'ed but not
>           acted upon
>
>
> =========================================================================
> Hi Paul,
>
>>> How does that work? How does the Keyboard know when to start clocking?
> Does it watch the PC pull the clock line low then
> take over? Or does the PC start by lowering the Data line? The book I
> found
> is a bit vague on the subject. <<
>
> For a PC->Keyboard transfer, the keyboard watches for the PC (actually the
> 8042 in the PC) to pull the Data Line low while the
> clock line is high. The PC just waits at that point for the Keyboard to
> start clocking, then sends out the data.
>
> For a Keyboard->PC transfer, the keyboard just checks that both clock and
> data are high, then starts transmitting. During
> periods when the PC can't respond, it will hold the clock low and that
> stops the keyboard from beginning a transmission.
>
>>> Also, what happens after line contention? They both back off but what
> then - random wait time and try again? Or is there a
> special code transmitted? <<
>
> As I mentioned above, the PC holds the clock line low if it can't respond
> to the keyboard for some reason, maybe servicing a
> PS2 mouse or whatever. The Keyboard is supposed to check each time it
> releases the clock line to supply a high clock (up to
> the tenth bit, I think). If the PC has started doing
> something else, it will clamp the clock to ground and the keyboard can see
> that
> it doesn't float high when released. In that case, the keyboard aborts the
> transmission. Also, if either end detects a character
> error or illegal command, it can request a resend. The keyboard does that
> in place of the ACK that it normally sends when it
> receives a command. The PC can do it anytime it gets a garbled character.
>
>>> BTW, how come you know all this stuff? :-) <<
>
> I spent about 4 years designing circuits and coding microchips for
> programmable PC joysticks. They connect between the PC
> and the keyboard, when they need to send a character, they gate the real
> keyboard offline and control the clock/data lines
> themselves to generate the characters, then reconnect the keyboard. The
> also downloaded the stick program through the
> keyboard port (there's some real fun<g>). Anyway, I got to know the AT/PS2
> keyboard interface pretty well.
>
> BTW, it occurred to me that the 0x0F break you're seeing is probably just
> because the bits are backwards on a 'scope. It sends
> things LSB first.
>
> - Bob
>
> =========================================================================
>
> Check the book "the Indispensable PC Hardware Book" by Messmer. ISBN
> 0-201-40399-4.
>
> =========================================================================
>>>Hopefully the web page will tell me whether the PS/2 keyboard differs.
>
> Winn Rosch's Hardware bible lists the PS/2 connector as:
>   Pin   Description   Direction
>    1    Data           In
>    2    Reserved       N/A
>    3    Ground         N/A
>    4    +5v            Out
>    6    Reserved       N/A
>    Shield  Ground      N/A
>
>                   |<---Notch
>                   ^
>                 5   6
>               3       4
>                 1   2
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Hello all

I’m still learning to write in bascom-avr and working
on a PC to AVR serial communication. The problem I
have is sending data and working with the ASCII
conversions. Can some one recommend a tool for sending
data from the PC to the AVR that allows me to send
zero to 32 (like “0 = nul” “8 = back space”)….. and
128 to 255 (the extended codes).  I am able to send
info back and forth but need to send all things from 0
to 255. There must be an easy tool? Right

Thanks
Brian


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

http://bray.velenje.cx/avr/terminal/


On 4/3/06, brian r <barip100@...> wrote:
> Hello all
>
> I'm still learning to write in bascom-avr and working
> on a PC to AVR serial communication. The problem I
> have is sending data and working with the ASCII
> conversions. Can some one recommend a tool for sending
> data from the PC to the AVR that allows me to send
> zero to 32 (like "0 = nul" "8 = back space")….. and
> 128 to 255 (the extended codes).  I am able to send
> info back and forth but need to send all things from 0
> to 255. There must be an easy tool? Right
>
> Thanks
> Brian
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>
>
>
>
>

TESTING Email ...please ignore....

--
.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
[My Corner of Cyberspace                     http://ragooman.home.comcast.net/ ]
[Pittsburgh Robotics Society     Got Robot?        http://www.pghrobotics.org/ ]
[Pittsburgh Vintage Comp.Society http://groups.yahoo.com/group/pghvintagecomp/ ]
.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.5/300 - Release Date: 4/3/2006

Hi all,

I wondered if any one can suggest the optimal way for my outdoor robot
to actually use the data from the devontech compass.  Do you make
constant corrections in your path, or periodic ones?  What kind of
tolerance is acceptable for the deviation to be considered negligeable?

Thanks!

Chris from Arizona

watch for metal near the robot.
even running over concrete can cause errors.  (rebar)


Chris Schur wrote:

>Hi all,
>
>I wondered if any one can suggest the optimal way for my outdoor robot
>to actually use the data from the devontech compass.  Do you make
>constant corrections in your path, or periodic ones?  What kind of
>tolerance is acceptable for the deviation to be considered negligeable?
>
>Thanks!
>
>Chris from Arizona
>
>
>
>
>
>
>Visit the SRS Website at http://www.seattlerobotics.org
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>

hello,

   i wanna control PIC16f84 (8-bit) with Visual Basic via RS232 serial
communication (full duplex).
   could you please help me do this?
   thanx a lot

   serdar ates
   ates_serdar@...


---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

[Non-text portions of this message have been removed]

Another thing to watch for is the vertical component of the earth's magnetic
field.  If the devantech compass is tilted much more than 10 degrees (though
I heard this number somewhere) you will start seeing an effect of the vert
part of things.  As per your questions on deviation, I'd look for trends and
not the deviation in the readings.  Much like fitting a line through a
scatter plot of points.  You should be able to then work out some of the
error.  I think the data sheet says ±2 degrees of error.
If you are attemting a dead reckoning in your navigation, you may find that
using the compass and odometry will still accumulate error.
I most people will agree that you can get some good robot behaviors even
from limited amounts and accuracy of data and processing.
Robin from Utah

----- Original Message -----
From: "Chris Schur" <comets133@...>
To: <SeattleRobotics@yahoogroups.com>
Sent: Wednesday, April 05, 2006 11:51 AM
Subject: [SeattleRobotics] How to use a Devontech compass


> Hi all,
>
> I wondered if any one can suggest the optimal way for my outdoor robot
> to actually use the data from the devontech compass.  Do you make
> constant corrections in your path, or periodic ones?  What kind of
> tolerance is acceptable for the deviation to be considered negligeable?
>
> Thanks!
>
> Chris from Arizona
>
>
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

Thanks, Ill mount it about 2 feet from the motors, and probably will
average the readings before I attempt a course correction.

Chris

--- In SeattleRobotics@yahoogroups.com, "Robin Bailey" <robin@...>
wrote:
>
> Another thing to watch for is the vertical component of the earth's
magnetic
> field.  If the devantech compass is tilted much more than 10
degrees (though
> I heard this number somewhere) you will start seeing an effect of
the vert
> part of things.  As per your questions on deviation, I'd look for
trends and
> not the deviation in the readings.  Much like fitting a line
through a
> scatter plot of points.  You should be able to then work out some
of the
> error.  I think the data sheet says ±2 degrees of error.
> If you are attemting a dead reckoning in your navigation, you may
find that
> using the compass and odometry will still accumulate error.
> I most people will agree that you can get some good robot behaviors
even
> from limited amounts and accuracy of data and processing.
> Robin from Utah
>
> ----- Original Message -----
> From: "Chris Schur" <comets133@...>
> To: <SeattleRobotics@yahoogroups.com>
> Sent: Wednesday, April 05, 2006 11:51 AM
> Subject: [SeattleRobotics] How to use a Devontech compass
>
>
> > Hi all,
> >
> > I wondered if any one can suggest the optimal way for my outdoor
robot
> > to actually use the data from the devontech compass.  Do you make
> > constant corrections in your path, or periodic ones?  What kind of
> > tolerance is acceptable for the deviation to be considered
negligeable?
> >
> > Thanks!
> >
> > Chris from Arizona
> >
> >
> >
> >
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

You may get better results if you take a magnetic compass and play with it
around your bot. Some people have found that placing the compass directly
between your motors (and elevated) will give you the best results. Use a
hand held compass to find the best location on your bot before you mount
anything.

JIMc

At 01:07 PM 4/6/2006, you wrote:
>Thanks, Ill mount it about 2 feet from the motors, and probably will
>average the readings before I attempt a course correction.
>
>Chris
>
>--- In SeattleRobotics@yahoogroups.com, "Robin Bailey" <robin@...>
>wrote:
> >
> > Another thing to watch for is the vertical component of the earth's
>magnetic
> > field.  If the devantech compass is tilted much more than 10
>degrees (though
> > I heard this number somewhere) you will start seeing an effect of
>the vert
> > part of things.  As per your questions on deviation, I'd look for
>trends and
> > not the deviation in the readings.  Much like fitting a line
>through a
> > scatter plot of points.  You should be able to then work out some
>of the
> > error.  I think the data sheet says ±2 degrees of error.
> > If you are attemting a dead reckoning in your navigation, you may
>find that
> > using the compass and odometry will still accumulate error.
> > I most people will agree that you can get some good robot behaviors
>even
> > from limited amounts and accuracy of data and processing.
> > Robin from Utah
> >
> > ----- Original Message -----
> > From: "Chris Schur" <comets133@...>
> > To: <SeattleRobotics@yahoogroups.com>
> > Sent: Wednesday, April 05, 2006 11:51 AM
> > Subject: [SeattleRobotics] How to use a Devontech compass
> >
> >
> > > Hi all,
> > >
> > > I wondered if any one can suggest the optimal way for my outdoor
>robot
> > > to actually use the data from the devontech compass.  Do you make
> > > constant corrections in your path, or periodic ones?  What kind of
> > > tolerance is acceptable for the deviation to be considered
>negligeable?
> > >
> > > Thanks!
> > >
> > > Chris from Arizona
> > >
> > >
> > >
> > >
> > >
> > >
> > > Visit the SRS Website at http://www.seattlerobotics.org
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>
>Visit the SRS Website at http://www.seattlerobotics.org
>Yahoo! Groups Links
>
>
>
>

JIMc
x22661
National
Ignition
Facility



[Non-text portions of this message have been removed]

hello there!

   is there anyone here who can help me transfer the video image or picture with
CMUCam via RF to the computer that has a GUI coded with Visual Basic?

   thanx a lot
   best wishes

   serdar ates
   ates_serdar@...


---------------------------------
Blab-away for as little as 1¢/min. Make  PC-to-Phone Calls using Yahoo!
Messenger with Voice.

[Non-text portions of this message have been removed]

Jim, thats a great idea, I can set it up outside on a table with so
the track doesent touch, and run the motors with a normal compass.
Excellent.

Chris

--- In SeattleRobotics@yahoogroups.com, Jim McBride <mcbride7@...>
wrote:
>
> You may get better results if you take a magnetic compass and play
with it
> around your bot. Some people have found that placing the compass
directly
> between your motors (and elevated) will give you the best results.
Use a
> hand held compass to find the best location on your bot before you
mount
> anything.
>
> JIMc
>
> At 01:07 PM 4/6/2006, you wrote:
> >Thanks, Ill mount it about 2 feet from the motors, and probably
will
> >average the readings before I attempt a course correction.
> >
> >Chris
> >
> >--- In SeattleRobotics@yahoogroups.com, "Robin Bailey" <robin@>
> >wrote:
> > >
> > > Another thing to watch for is the vertical component of the
earth's
> >magnetic
> > > field.  If the devantech compass is tilted much more than 10
> >degrees (though
> > > I heard this number somewhere) you will start seeing an effect
of
> >the vert
> > > part of things.  As per your questions on deviation, I'd look
for
> >trends and
> > > not the deviation in the readings.  Much like fitting a line
> >through a
> > > scatter plot of points.  You should be able to then work out
some
> >of the
> > > error.  I think the data sheet says ±2 degrees of error.
> > > If you are attemting a dead reckoning in your navigation, you
may
> >find that
> > > using the compass and odometry will still accumulate error.
> > > I most people will agree that you can get some good robot
behaviors
> >even
> > > from limited amounts and accuracy of data and processing.
> > > Robin from Utah
> > >
> > > ----- Original Message -----
> > > From: "Chris Schur" <comets133@>
> > > To: <SeattleRobotics@yahoogroups.com>
> > > Sent: Wednesday, April 05, 2006 11:51 AM
> > > Subject: [SeattleRobotics] How to use a Devontech compass
> > >
> > >
> > > > Hi all,
> > > >
> > > > I wondered if any one can suggest the optimal way for my
outdoor
> >robot
> > > > to actually use the data from the devontech compass.  Do you
make
> > > > constant corrections in your path, or periodic ones?  What
kind of
> > > > tolerance is acceptable for the deviation to be considered
> >negligeable?
> > > >
> > > > Thanks!
> > > >
> > > > Chris from Arizona
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Visit the SRS Website at http://www.seattlerobotics.org
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >Visit the SRS Website at http://www.seattlerobotics.org
> >Yahoo! Groups Links
> >
> >
> >
> >
>
> JIMc
> x22661
> National
> Ignition
> Facility
>
>
>
> [Non-text portions of this message have been removed]
>

Caveat: Hunting around for a dead spot using a compass is a great idea,
but the needle in a mechanical compass is a relatively massive object
which may not appear to react to the magnetic fields produced by high
frequency drive currents. As you indicated earlier, Chris, you may still
need to average several readings in order to reject any noise
transients. I would run a test program to take continuous readings an
barf them out to a file for analysis, both with and without the motors
running to see if there are any noise problems.

Stephen

Chris Schur wrote:
> Jim, thats a great idea, I can set it up outside on a table with so
> the track doesent touch, and run the motors with a normal compass.
> Excellent.
>
> Chris
>
> --- In SeattleRobotics@yahoogroups.com, Jim McBride <mcbride7@...>
> wrote:
>> You may get better results if you take a magnetic compass and play
> with it
>> around your bot. Some people have found that placing the compass
> directly
>> between your motors (and elevated) will give you the best results.
> Use a
>> hand held compass to find the best location on your bot before you
> mount
>> anything.
>>
>> JIMc
>>
>> At 01:07 PM 4/6/2006, you wrote:
>>> Thanks, Ill mount it about 2 feet from the motors, and probably
> will
>>> average the readings before I attempt a course correction.
>>>
>>> Chris
>>>
>>> --- In SeattleRobotics@yahoogroups.com, "Robin Bailey" <robin@>
>>> wrote:
>>>> Another thing to watch for is the vertical component of the
> earth's
>>> magnetic
>>>> field.  If the devantech compass is tilted much more than 10
>>> degrees (though
>>>> I heard this number somewhere) you will start seeing an effect
> of
>>> the vert
>>>> part of things.  As per your questions on deviation, I'd look
> for
>>> trends and
>>>> not the deviation in the readings.  Much like fitting a line
>>> through a
>>>> scatter plot of points.  You should be able to then work out
> some
>>> of the
>>>> error.  I think the data sheet says ±2 degrees of error.
>>>> If you are attemting a dead reckoning in your navigation, you
> may
>>> find that
>>>> using the compass and odometry will still accumulate error.
>>>> I most people will agree that you can get some good robot
> behaviors
>>> even
>>>> from limited amounts and accuracy of data and processing.
>>>> Robin from Utah
>>>>
>>>> ----- Original Message -----
>>>> From: "Chris Schur" <comets133@>
>>>> To: <SeattleRobotics@yahoogroups.com>
>>>> Sent: Wednesday, April 05, 2006 11:51 AM
>>>> Subject: [SeattleRobotics] How to use a Devontech compass
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I wondered if any one can suggest the optimal way for my
> outdoor
>>> robot
>>>>> to actually use the data from the devontech compass.  Do you
> make
>>>>> constant corrections in your path, or periodic ones?  What
> kind of
>>>>> tolerance is acceptable for the deviation to be considered
>>> negligeable?
>>>>> Thanks!
>>>>>
>>>>> Chris from Arizona
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Visit the SRS Website at http://www.seattlerobotics.org
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Visit the SRS Website at http://www.seattlerobotics.org
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>> JIMc
>> x22661
>> National
>> Ignition
>> Facility
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>

--
Stephen Noel
Pronetiq Consultation
networks - systems - infrastructure
http://www.pronetiq.com
(514) 926-4700

I know I remember seeing an article mounting sonar on a turret in the last two
years.  I have searched and searched, both in the mags I have and online,
looking for this article.  Could it have been an advertisement instead?  I did
find an article with a "one eye" sonar on a servo about mapping, but what I
thought I remembered was one of those Devantech "two eye" units and a "how to"
article.

If you can help me locate this, I would appreciate it!

My older robotics team is competing in Robofest, it's only 3 weeks away, and
they have asked me to find one and teach them how to use sonar to detect their
obstacles.  (Two liter bottles covered with white paper.)  So I either need very
clearcut instructions and explanations or an article like this that leads me
through it and shows me how to use it.

We're short on time, entered the contest late.  They are going great though, I'm
really proud of them.  They are doing most everything from scratch, disassembled
my classbots for parts (I'm glad we have pictures, lol) and are learning an
awful lot - this is the first total robot they've put together as a team.  I do
so want them to qualify at least, they are working so hard!

And we got a sponsor for the contest!  Who gave us some money!  So we have money
burning holes in our pockets and I have a shopping list although time is really
tight to learn something new:
-- sonar on a servo for the cleanupbot which is supposed to find and push those
bottles off the field;
-- stronger geared motors to replace our little twin Tamiya gearboxes for the
musclebot which has to drag some fairly heavy (4 to 6oz) wooden 2x2's back up a
ramp;
-- and I'm thinking of a serial LCD if we've got any left.

We don't have encoders, I should have put that on the wish list.

But right now, the chassis work is going great, and they've got a good "arm"
made of K'nex and a servo running on a separate BS2 homework board for the
musclebot, talking back to our PIC16f877a based controller boards.  They can
actually see the obstacles with the IR boards we've got if they have to and have
designed a sweeping scoop to move the bottles and two forms of bumpers with
switches all on their own.  I am so proud of them!

Our challenge is line-following.  They are not using interrupts yet.  (The
problem is neither am I!)  Can we do this without?  They keep missing the line
and going off in the weeds -- and we have to eventually follow a dashed line
instead of a solid.  The playing field is white melamine boards with black
electrical tape.  We have those little  trapezoidal sensors like the ones on the
Mark III for floor sensors. QRB1134? (Sorry they're off at a student's home.)
They've mounted 3 right now.  I was reading again and found the Encoder article
on using the difference between left and right sensors as a form of centering,
but our first challenge is actually finding the line!

I'm the beginner leading the beginners.  Help!
Susan

Jim,

I suggest you visit www.thinktink.com (search think and tinker on
Google), then click on PCB fab and follow to through hole process.
They really describe (and sell products for) the whole home pcb
fabrication process.  I reget not including a reference to them in
my article.  They use a semiresistive ink to get the copper a
surface to hang on.

Good Luck, Jim K.



--- In SeattleRobotics@yahoogroups.com, Jim McBride <mcbride7@...>
wrote:
>
> Nice to see this up again.
> I just read the PCB article. One of the steps mentioned is to
plate or
> rivet the vias.
> Is there a semi-easy way to plate through holes at home?
>
> At 05:13 PM 3/28/2006, you wrote:
> >The Encoder is finally alive again.  We have a number of great
> >articles from previous authors like Kenneth Maxon as well as
newcomers
> >to the group.  I think there will be broad interest in these
> >articles.  SRS meeting notes are also included and are searchable
> >using the Google engine.
> >
> >My thanks to all who contributed.  I'm already working on the next
> >Encoder edition so I'd love input from all you budding and
experienced
> >authors.  See the SRS website for article guidelines.  We just
love to
> >hear about your projects and techniques.
> >
> >Thanks Again, Jim K, Encoder Editor.
> >
> >
> >
> >
> >
> >Visit the SRS Website at http://www.seattlerobotics.org
> >Yahoo! Groups Links
> >
> >
> >
> >
>
> JIMc
> x22661
> National
> Ignition
> Facility
>
>
>
> [Non-text portions of this message have been removed]
>

George,

Have you been to the Alphatronics Store yet (Supertronics reborn)?
They claim to have all the old Supertronics stock which was fairly
complete, at least for passives.  If we don't support them they will
probably also go bye-bye.

Alphatronics
1073 Andover Park E.
Tukwila, 98188
206-957-5550
M-F 9-5, Sat 10-4.

Jim K.



--- In SeattleRobotics@yahoogroups.com, George Lawrence Storm
<Keencoyote@...> wrote:
>
> 1) I was at Vetco yesterday, the manager said they are probably
going
> to drop sales of small components (resistors, caps, transistors
> etc.)  by the end of this week. Says there is no profit in it. He
did
> say they are going to be adding things like PIC processor boards.
> They still will carry surplus motors & such.
>
> 2) By way of another local news group I received word that Alaska
> Copper & Brass has eliminated their bar stock sales at the
Seattle
> location, apparently no longer offer cut to length, have
increased
> the minimum purchase to $100 and the new location does not have a
> cashier, so you pay in Seattle with cash and drive to the new
> location for pickup, or have an account (or CC?). They still have
> some cutoffs at the Seattle location (no minimums), however as
the
> sales of bar stock has moved to one of their locations somewhere
> below Seattle they do not expect to see any more cutoffs in the
future.
>
> They were the ONLY place in the city where you could find good
> exotics like aluminum bronze!
>
> -----
>
> George Lawrence Storm
> Macintosh Applications Development
> Edmonds (Seattle), Washington
> E-mail: <keencoyote@...>
>
>
> [Non-text portions of this message have been removed]
>

Please let me rephrase and simplify my questions:

-- I looked at pinouts for the sonar sold on the MarkIII website.  It seems
simple.  Is sonar difficult to work with or similar to using our IR?  (We're
short on time to learn something new.)  Which sonar would you recommend for
finding 2liter bottles which are wrapped with white paper?  Our playing field is
maybe 3' by 4' but can be bigger.

--I think I have figured out interrupts.  Will they be absolutely necessary with
a PIC16F877A for line following?  I think by the time they see the line they
have overshot it.



Thanks, Susan
~~~~~

HI Susan,

On 4/10/06, Susan M <slmccain@...> wrote:
> Please let me rephrase and simplify my questions:
>
> -- I looked at pinouts for the sonar sold on the MarkIII website.  It seems
> simple.  Is sonar difficult to work with or similar to using our IR?  (We're
> short on time to learn something new.)  Which sonar would you recommend for
> finding 2liter bottles which are wrapped with white paper?  Our playing field
is
> maybe 3' by 4' but can be bigger.

Most of the sonar units have a fairly wide field of view (typically
around 90 degrees). While IR has a fiarly narrow field of view (like 5
degrees for the GP2D12 and family).

There is also a new sonar unit called the MaxSonar-EZ1
http://www.sparkfun.com/commerce/product_info.php?products_id=639
It has analog outputs and ratiometric outputs (measure the width of a pulse).

The MaxSonar supposedly has a narrower field of view, but I just
started playing with mine and haven't tried to see what the field of
view is.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

Thanks, Dave.  I had not realized the field of view would be an issue with
sonar.  That seems to make it inappropriate for our use.

(It's certainly a complication at this late date.  I thought if I were able to
use that article I remember, it would help the learning curve.  The kids just
got interested in it...)


Susan

Can the FOV not be restricted by using some sort of hood or waveguide?

Stephen

Susan M wrote:
> Thanks, Dave.  I had not realized the field of view would be an issue with
> sonar.  That seems to make it inappropriate for our use.
>
> (It's certainly a complication at this late date.  I thought if I were able to
> use that article I remember, it would help the learning curve.  The kids just
> got interested in it...)
>
>
> Susan
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>

--
Stephen Noel
Pronetiq Consultation
networks - systems - infrastructure
http://www.pronetiq.com
(514) 926-4700

Susan,

The Polaroid sonar (now SenseComp) have a field of view of about 15
degrees.  My SR04 robot uses a pair for locating coke cans for the
DPRG CanCan contest.  Here's a posting on how it uses the sonar to
identify the cans, which should be very similar to your plastic bottles:

<--http://www.geology.smu.edu/~dpa-www/robots/doc/stsonar.txt>

Here's a video of the robot locating a couple of cans:

<http://www.geology.smu.edu/~dpa-www/robots/mpeg/twocans.mpg>

best
dpa


- In SeattleRobotics@yahoogroups.com, Stephen Noel <snoel@...> wrote:
>
> Can the FOV not be restricted by using some sort of hood or waveguide?
>
> Stephen
>
> Susan M wrote:
> > Thanks, Dave.  I had not realized the field of view would be an
issue with
> > sonar.  That seems to make it inappropriate for our use.
> >
> > (It's certainly a complication at this late date.  I thought if I
were able to
> > use that article I remember, it would help the learning curve.
The kids just
> > got interested in it...)
> >
> >
> > Susan
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> > Yahoo! Groups Links
>

--- In SeattleRobotics@yahoogroups.com, "dpa_io" <dpa@...> wrote:
>
> Susan,
>
> The Polaroid sonar (now SenseComp) have a field of view of about 15
> degrees.  My SR04 robot uses a pair for locating coke cans for the
> DPRG CanCan contest.

Thanks, Dave, very much.  When we started this contest, someone at the
SRS chat pointed us toward the SR04.  The whole team watched the
movies and I at least read some of the pages.  I'm afraid since I
started teaching (if you can call it that) at co-op, I suffer from
only remembering the latest of much of what is presented to me.  In
the latest panic, I did not think of going back to the SR04 and
looking at the sonar!  (blush)  I appreciate the text discussion and
links, have printed it, and will go back and look again.
Many thanks!
Susan
(The team member with the arm running on the Basic Stamp got it all
working in concert with the  drive and navigation controller today --
we are all tickled!  So much for them to do still.  And I have figured
out interrupts but am not sure the kids are ready for them yet.)

The Polaroid sonar are very nice sensors and work from about
6" to 32 feet.  They are a bit complex to drive, requiring
4 I/O bits for each sensor and some fancy timing, and kind of
pricy.  Maybe you can get by with something simpler.

I started wondering if the coke-can recognition method used on
SR04 can be done for your bottles with just a pair of IR rangers,
like the Sharp GP2D12 IR proximity detectors, angled slightly
outward from center just like the sonar.

The algorithm for can collecting is really just an edge detector
made of two sensors, one looking slightly left and one looking
slightly right, that finds opposite edges of the can or bottle.

Seems like that might work as well using the Sharp detectors,
and they would probably be easier to interface.

best,
dpa



--- In SeattleRobotics@yahoogroups.com, "slmccaina" <slmccain@...> wrote:
>
> --- In SeattleRobotics@yahoogroups.com, "dpa_io" <dpa@> wrote:
> >
> > Susan,
> >
> > The Polaroid sonar (now SenseComp) have a field of view of about 15
> > degrees.  My SR04 robot uses a pair for locating coke cans for the
> > DPRG CanCan contest.
>
> Thanks, Dave, very much.  When we started this contest, someone at the
> SRS chat pointed us toward the SR04.  The whole team watched the
> movies and I at least read some of the pages.  I'm afraid since I
> started teaching (if you can call it that) at co-op, I suffer from
> only remembering the latest of much of what is presented to me.  In
> the latest panic, I did not think of going back to the SR04 and
> looking at the sonar!  (blush)  I appreciate the text discussion and
> links, have printed it, and will go back and look again.
> Many thanks!
> Susan
> (The team member with the arm running on the Basic Stamp got it all
> working in concert with the  drive and navigation controller today --
> we are all tickled!  So much for them to do still.  And I have figured
> out interrupts but am not sure the kids are ready for them yet.)
>

One of the members of the http://www.robomo.com group posted this on
our forum and I know you have at least a couple of B9 fans...

http://www.lostinspacerobot.com/newsletter_06.html

By the way... didn't someone want some other stuff laser cut? I can't
remember. (Old age I guess.)

Jerry
http://www.rutherford-robotics.com
askjerry@...
(Put ROBOT in the subject.)

Hi,

> The Polaroid sonar are very nice sensors and work from about
> 6" to 32 feet.  They are a bit complex to drive, requiring
> 4 I/O bits for each sensor and some fancy timing, and kind of
> pricy.  Maybe you can get by with something simpler.
>
> I started wondering if the coke-can recognition method used on
> SR04 can be done for your bottles with just a pair of IR rangers,
> like the Sharp GP2D12 IR proximity detectors, angled slightly
> outward from center just like the sonar.
>
> The algorithm for can collecting is really just an edge detector
> made of two sensors, one looking slightly left and one looking
> slightly right, that finds opposite edges of the can or bottle.
>
> Seems like that might work as well using the Sharp detectors,
> and they would probably be easier to interface.

I use two Sharp sensors pointing straight ahead on my mini-sumos. It
works quite well for homing in on the opponent. The Sharp sensor have
such a narrow angle, that you can get away with having them point
straight ahead.

The GP2Y0A02YK is the same electronics as the GP2D12, but with
different optics, and can range out to 150 cm.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

> > Seems like that might work as well using the Sharp detectors,
> > and they would probably be easier to interface.
>
> I use two Sharp sensors pointing straight ahead on my mini-sumos.

Thank you both for the help.  There are two of the Sharp sensors on
the Mark III (someone sold me used to give me a head start on
programming), I can let them see what they can do with them before
ordering.

The IRPD100 boards we have (from Doug Evans / Compubotics) do work
well.  They have two emitters and one IR Panasonic detector and a
little chip, LED feedback and signals for left and right detect, a
long range and short range setting.  They can see the bottles when set
on short range which I seem to remember is 25 inches;  the kids told
me if they set it to long range, there is a lot of noise from the
room.  These boards have been great for the kids, they understand them.

We'll compare using one of them with the Sharp sensors -- hmm, I may
even have a couple of those Sharp GP2D12 sensors in my drawer, a
stocking stuffer I totally forgot about.  10 to 80 cm should be enough
for this.

Thanks!  Susan
(So much to do! )

Hi, I would like to implement closed-loop back EMF control (for either
constant velocity or constant position) and I would like to know the
best circuit to measure a 9v motor output and take readings from a 0 - 5
V ADC. Some methods I see online just use a simple voltage divider with
resistors, but if the motor ever generates something like 12 v, wouldn't
that damage the ADC ?
Thank you in advance.
Regards,
   Gustavo

Take a look at this. No need for an ADC.
http://www.romanblack.com/encoder.htm

JIMc

At 11:25 AM 4/11/2006, you wrote:
>Hi, I would like to implement closed-loop back EMF control (for either
>constant velocity or constant position) and I would like to know the
>best circuit to measure a 9v motor output and take readings from a 0 - 5
>V ADC. Some methods I see online just use a simple voltage divider with
>resistors, but if the motor ever generates something like 12 v, wouldn't
>that damage the ADC ?
>Thank you in advance.
>Regards,
>   Gustavo
>
>
>Visit the SRS Website at http://www.seattlerobotics.org
>Yahoo! Groups Links
>
>
>
>

JIMc
x22661
National
Ignition
Facility



[Non-text portions of this message have been removed]