Status:

Open date: July 7, 2004
Close date: <Month, day, year>

Participants:

Reported by Kael Hanson

Symptoms:

See email below

Approach:

TBD

Solution:

TBD.

Summary:

TBD

Other supporting information:


This should probably go to icebug

-----Original Message-----
From: Nobuyoshi Kitamura
Sent: Friday, July 09, 2004 5:33 PM
To: Thorsten Stezelberger; Arthur Jones
Cc: Chuck McParland; Kael Hanson
Subject: 803e669850000029

Hi:

I realize that this is an inconvenient timing, but Kael says it should
be fixed.  Is the thread below still alive?

Thank you,

Nobuyoshi

-----Original Message-----
From: Nobuyoshi Kitamura 
Sent: Wednesday, July 07, 2004 4:23 PM
To: Arthur Jones; Thorsten Stezelberger
Cc: Chuck McParland; Kael Hanson
Subject: hvid


Arthur and Thorsten:

I noticed something that I should have long long time ago.
If you look at the Dallas DS2401 datasheet (attached), the response to
hvid should be

CRC(1 byte) + serial_num (6 bytes) + family_code(1 byte).

Family_code identifies DS2401 and should always be 0x01.

Here is what I got by "hvid type"-

803e669850000029
8040e6985000004b
8005c698500000ff
80ce169850000048

If we suppose that each nibble is inverted and the whole byte order is
inverted at the same time, "80" looks like the family code.  Or, the
entire bit order is reversed...  Or, some other variation.

This is not critical for either dom or icecube operation, as long as we
know what the returned code means and that it passes the CRC test. But
unless we know what the code means, nobody can do the CRC test.

Preferably, the dommb program/firmware(?) should be fixed so that the
command response is according to the Dallas standard format.  Otherwise,
the format of the returned code should be documented somewhere in
icecube space.

Thank you,

Nobuyoshi