5.2.23 - 1-Wire [U6 Datasheet] | LabJack
« Close

Datasheets and User Guides

App Notes

Software & Driver


5.2.23 - 1-Wire [U6 Datasheet]

This function performs 1-Wire communication.

Firmware 1.17 or higher is required to use this function.

For additional information on how to use this function, please see the 1-Wire App Note


Table 5.2.23-1. 1-Wire Command Response

0 Csum8  
1 0xF8  
2 0x1D  
3 0x3C  
4 Csum16 L  
5 Csum16 H  
6 Options  
    Bit 0: DPU Control Enable
    Bit 1: DPU Polarity
    Bit 2: DPU Idle
7 Reserved  
8 Sense Pin  
9 DPU Pin  
10 Reserved  
11 ROM Function  
12 ROM0 (LSB)  
13 ROM1  
14 ROM2  
15 ROM3  
16 ROM4  
17 ROM5  
18 ROM6  
19 ROM7 (MSB)  
20 Reserved  
21 Num TX  
22 Reserved  
23 Num RX  
24 TX Byte 0  
63 TX Byte 39  
0 Csum8  
1 0xF8  
2 0x1D  
3 0x3C  
4 Csum16 L  
5 Csum16 H  
6 Error Code  
7 Reserved  
8 Reserved  
9 Warnings  
    Bit 0: No Devices Detected
    Bit 1: Type 1 interrupt (Not Tested)
    Bit 2: Type 2 interrupt (Not Supported)
10 Reserved  
11 Reserved  
16 Data 0  
63 Data 47  

Options: This byte provides control of the dynamic pull-up.
Bit 0: enables control of the DPU line.
Bit 1: sets the polarity of the switch. 1 = high on the specified DIO turns the switch on.
Bit 2: sets the idle state. 1 = DPU on while IDLE.
Sense Pin: This is the DIO on the LabJack that is connected to the data line of the 1-wire bus.
DPU Pin: This is the DIO line that will control the dynamic pull-up if enabled in the options byte.
ROM Function: This byte specifies the function to be performed on the 1-wire bus.
ROM[0:7]: This is the ROM of the target device or search path.
Num TX: This is the number of data bytes to transmit.
Num RX: This is the number of data bytes to receive.

Depending on the ROM function used the data returned can have different meanings. Refer to the following table for data definitions.

Table 5.2.23-2.

    Parameter Data Returned  
ROM Function: Number ROM Bytes 0-7 Bytes 8-15
Search ROM 0xF0 List of branches to take. Discovered ROM Code 1s indicate detected branches.
Read ROM 0x33 None ROM read from device  
Match ROM 0x55 The specific ROM    
Skip ROM 0xCC      
Alarm Search 0xEC      


This table is confusing because of the two words Dara(=Data?) and Bytes are really the same = Data.

Data 0-7 (bytes 16-23 of the response) returns the discovered ROM

Data 8-15 (bytes 24-31 of the response) returns the branches.

I verified this with two 1-wire devices connected.


Hi Jeff,

Thank you for pointing that out. The typo has been fixed.


ElectroLund's picture

How are the checksums calculated?  There are three total in both the Command and Response packets at the following byte indexes.

Byte   0 Csum8 4 Csum16 L 5 Csum16 H

On the general low-level protocol page, there is more detail about computation and affected byte range, but those ranges don't match up with the specific SPI packet defined here on this page.

So I'm just wondering:

  1. What bytes does the Csum8 target?
  2. What bytes do the L/H Csum16 target?
  3. Are the computations the same method as listed on the general protocol page? 
labjack support's picture

The 8-bit checksum follows the extended command format (and associated 8-bit checksum calculation) seen in Table 5.1-2 on the low level general protocol page.

  1. In this case, the 8-bit checksum targets bytes 1-5. Note that this includes the 16-bit checksum, so there should not be any need to verify the 16-bit checksum directly.
  2. The 16-bit checksum should target the data words section exclusively.
  3. The computations should match those on the general protocol page.
ElectroLund's picture

I need a bit more clarification.  What bytes do the 16-bit checksums target?  You say "data words"'; I assume as per the low-level page, 5.1, "Get the subarray consisting of bytes 6 and up."  If there are fewer than 64 bytes transferred, would only include the bytes sent?

Also, does the LabJack do its own checksum checking and issue errors?

labjack support's picture

The 16-bit checksum targets bytes 6 and up. It would only run the checksum algorithm on the bytes sent in the command.

The device does verify the checksum and will return a particular response when a bad checksum is detected:


ElectroLund's picture

Thanks for the checksum functions. They work nicely!

Next up is the dynamic DPU.  I don't see much here or on the app note page about how to wire this.  I'm assuming I need better parasitic power in my circuit, as my packets look like this coming from the LabJack:


I have a DS18B20 EEPROM which is wired to +5V power. On the same data bus is a DS2431 temp sensor with no pullup.

I'm assuming that the DPU options would allow another Labjack pin to act as the weak pullup?  So I connect that pin to my data pin?

labjack support's picture

The DPU settings are intended for an external driver circuit where the DPU pin controls a transistor switching circuit for the pull-up such as is shown in the schematic in the following application note:


The DPU pin may still work by itself as a pullup to 3.3V, but I would recommend adding an external resistor as the resistance would otherwise only be a few hundred ohms as described in the output impedance specifications of the DIO: