There was some talk of a contest a couple of weeks ago that slowly
faded away because we all got silly with stories about how we were
all personal pals of Mick Jagger and Ringo Starr.

Well, this past weekend I came up with a real challenge with a
real prize.  Actually it's a ruse to get you smart guys to do a
little work cheap, but the "challenge" story sounds better.

Here's the deal.  I need to reverse engineer the algorithm used to
generate the check bytes on some messages that are being passed
back and forth between a PC program and an 8051-based board over a
standard RS-232 link.  I don't have any documentation or source
code, but I can easily capture the messages themselves.  Here are
a few examples of authentic messages (all numbers are in
hexadecimal):

    16 0B 10 47 58 41 57 20 20 3F 3B CB 86
    16 0B 10 47 59 41 57 FF FF B2 09 0B 3A
    16 09 10 47 4C 41 57 20 EE 31 CD
    16 09 10 47 4C 41 57 01 11 55 F2
    16 09 10 47 54 50 57 01 30 F7 7D
    16 09 10 47 54 50 57 01 9C 1F E9
    16 0C 10 47 56 56 57 04 45 DD E0 20 5E 36
    16 0C 10 47 56 56 57 04 45 DA C0 20 CA ED
    16 08 10 47 54 46 57 01 50 C5
    16 0B 10 47 54 4C 57 20 03 20 87 90 8D
    16 08 10 47 54 46 57 01 50 C5
    16 0B 10 47 54 4C 57 20 05 20 87 88 93
    16 08 10 47 54 46 57 01 50 C5

I'm pretty sure that the last two bytes in each message are check
bytes designed to verify the message's integrity.  The challenge
is to write a C function that looks at the first (n-2) bytes in each
message and correctly calculates the last two bytes from them.
The first person to post such a function gets a prize of $200 US
from me.  The prize offer is good until 4:00 PM Mountain Standard
Time (2300Z) on Wednesday, November 8.

To qualify for the prize, the same function must generate the
correct check bytes on all the messages given above.  I am not
trying to be tricky here; if your function doesn't work on one or
more of the messages because I typed something wrong, I will be
reasonable.  However, it's NOT good enough to find a function that
works with one or two of the messages and none of the others.  (I
have already done that!)

Here are some hints:

  - The first and third bytes of each message are always 16 and
    10, respectively.

  - The second byte of each message contains the number of bytes
    that follow it, including the two check bytes.

  - The check bytes may or may not depend on one or more of the
    first three bytes of the message.  I other words, if you come
    up with an algorithm that correctly calculates the check
    bytes, but ignores one or more of the first three message
    bytes, that's fine.

  - If you configure the CRC algorithm given in Section 17
    of this  document with this set of parameters:

        width:   16 (decimal)
        poly:    4003
        init:    0000
        refin:   FALSE
        refot:   TRUE
        xorot:   FFFF

    and apply it to the last message above, ignoring the first
    three bytes, it will compute the correct check bytes (50
    C5).  This leads me to believe that the check bytes may be
    calculated using some sort of CRC algorithm.  However, the
    same setup does not give the correct results for any of the
    other messages.  Therefore, the fact that it works on the last
    one may be just dumb luck and we may not be dealing with a CRC
    algorithm after all.

May the best geek win!

-- Russ