1-Wire (App Note) | LabJack
« Close

Datasheets and User Guides

App Notes

Software & Driver


Free Shipping for U.S. Orders $150+   |   5-year Warranty   |   Try Our Devices & Support for 60 Days, Risk Free  |   50 of 54 Products In-Stock Now

1-Wire (App Note)

This app note explains the operation and use of the 1-Wire bus in conjunction with LabJack products.


  • T4: All recent firmware versions.
  • T7/T7-Pro: All recent firmware versions.
  • UE9: Control Firmware v2.20 or later.
  • U6: Firmware v1.17 or later.
  • U3: Firmware v1.31 or later.
  • U12: Not supported.

Overview of 1-Wire

The basis of 1-Wire technology is a serial protocol using a single data line plus ground reference for communication. A 1-Wire master initiates and controls the communication with one or more 1-Wire slave devices on the 1-Wire bus. Each 1-Wire slave device has a unique, 64-bit ID, which serves as its address on the 1-Wire bus. Slave devices typically operate over the voltage rage of 2.8V to 5.25V.

Some 1-Wire devices require a separate power supply, but many take their energy directly off of the data bus line—this is called parasitic supply. Because of this unique parasitic supply, 1-Wire is the only voltage-based digital system that works with two contacts, data and ground for half-duplex bidirectional communication.

Using a LabJack as the Master

Before attempting communication with a 1-Wire slave through a LabJack, insure the following conditions are met:

  • 1-Wire compatibility with your LabJack
  • Only connect 1-Wire slave devices through EIO and CIO lines. The FIO lines have too much impedance to run 1-Wire properly*. Because EIO and CIO lines are only accessible through the DB15 connector, it may be helpful to purchase a CB15.
  • Parasitic or dedicated supply? Depending on power consumption the slave device may require a dedicated supply, or if it is a parasitic device, the correct pull-up and/or pull-down resistors need to be installed on the bus. Refer to the device datasheet for appropriate connections.

After the above conditions are met, it will be possible to initiate communication with 1-Wire slaves using a LabJack as the master.

UD-series devices: The low-level function for 1-Wire to handles byte array command/response, and can be integrated into any program that has access to the device commutation protocol (USB, Ethernet, etc.) An example in LabVIEW is detailed below.

T-series devices: The LJM multiple value functions make it easy to operate 1-Wire. For examples:

Search Algorithm

Using multiple devices on the 1-Wire bus requires that their 64-bit ROM codes be known. The codes can be found using a search algorithm. This search will identify the ROM codes of all devices on the bus, but will not reveal any information about the order they appear on the bus (physical location). The figure below represents 3 devices, and the branching that occurs during their discovery.

Each branch at a bit level denotes a difference in device ROM. These devices only have a 2-bit ROM.

Creating one of these search algorithms can be difficult, so when possible it is recommended to place a single device on the bus and use the master to identify its address. Based on design, if a 1-Wire slave device is alone on the bus, there will be no alternate branches for the master to search, so it will locate the device easily. After the device ROM is known, record it and identify the part with a marking or location.

More information on branching and search algorithms can be found in the following documents:


1. Overview

For this example a Maxim DS1822 digital thermometer is used to demonstrate the use of 1-Wire. The U3-LV running firmware v1.31 is configured as the master, and using a CB15; the 4 DS1822 temperature probes are connected to EIO6(DIO 14)**, VS, and GND. Below is a picture of the test setup.

1-Wire test using a LabJack U3-LV and 4 DS1822 temperature probes

2. Connections

Since 5V (VS) is readily available on the CB15, and the DS1822 can be powered either directly or off of the bus (parasitic), it was connected directly to VS. Based on the datasheet, when connected in this manner it is appropriate to also include a pull-up resistor on the bus line. A 4.7kΩ pull-up resistor is seen on the right side.

DS1822 datasheet: https://datasheets.maximintegrated.com/en/ds/DS1822.pdf

3. Search ROM address

The next step is to discover the ROM codes that are factory programmed into the DS1822s. As mentioned above, it is easiest to connect a single device on the bus, then run the Read ROM command [33h]. The slave device will then return its 64-bit ROM. For convenience, a LabVIEW program capable of discovering ROM addresses on the 1-Wire bus can be downloaded at the bottom of the page.

Searching the 1-Wire bus

Due to the way that 1-Wire devices may be used in practice, like in an expansive sensor network, it was decided that a search algorithm could greatly benefit our customers. The algorithm was developed in LabVIEW 6, and uses the Search ROM command [F0h] to investigate all of the branches necessary to reach each slave device. Once discovered, they are stored in memory and displayed on the control window. Although only tested in the above example, the algorithm executable can be downloaded below. The subVI is also available.

4. Reading The Temperature

After all of the ROM codes are known, simply use the Match ROM command [55h] followed by a 64-bit ROM code sequence to address a specific slave device on the bus. Before any communication can commence on the 1-Wire bus, the master will have to initiate this ROM command.

In order to capture the temperature data, one must carry out two additional command sequences; each one follows the Match ROM Command [55h].

  1. The first is to make the temperature probe convert a temperature reading into a binary number. The Function Command for this is [44h], and must be issued in the first Tx data byte. See the low-level function reference for Tx Byte 0 location. Also set Num Tx to 1, for number of bytes to transfer.
  2. The second sequence is required to read the binary temperature reading from the device memory. The associated Function Command is [BEh], and is also issued in the first Tx data byte. Again set Num Tx to 1, but this time it is also necessary to instruct the master to receive data. Set Num Rx to at least 2, because the first 2 bytes contain the binary temperature reading on the DS1822. Additional data can also be read from the device, see the datasheet for details.

For a complete communication description, reference DS1822 Operation Example 1 pg.18 in the datasheet. A simple LabVIEW program designed for reading the DS1822 can be downloaded below. Note that it will be necessary to know the ROM address of the slave probe before using the program.

5. Useful Code

These downloads were developed during testing, and were referenced in this app note. Please review the app note before use. All executables will require the LabVIEW 6.0 run time engine, which can be downloaded here (10.4 MB, save to desktop, right-click and do "extract here", run lvrteinstall.exe). SubVIs use some of the LabVIEW LJUD archive, so this will need to be downloaded and the appropriate subVIs referenced.

1 Wire Search.exe
Read DS1822.exe
1-Wire LJM Example .vi files


*The internal resistance on FIO lines could be reduced by changing the resistors, or using some form of dynamic pull up. We do not recommend modifying the LabJack; doing so may void your warranty.

**The DIO pin is important when using the downloadable subVIs and executables, insure correct number


Are these vi's useful for Labview 2010?

The VIs are LabVIEW 6. So, according to the LabVIEW compatibility chart you should be able to open and run the above VIs in 2010.

There are some recent drivers for different 1-Wire products available in the National Instruments LabVIEW user forum (www.ni.com). I have used them for interfacing the DS18B20 temperature transmitter through the DS9490R USB bridge. They work perfectly.

The DS9490R appears to be a dedicated USB to 1-wire adapter.  If all you need is 1-wire, then it looks like a good way to go as an alternative to a LabJack.

I am able to successfully read the temperature from a 18B20 chip, but after I read it the next command that usually works fails.  Then when I read the temperature I get it again. It's as if the 18B20 did not get all the commands it needed the first time and the other call resets it.

I issue the following to the LabJack

//Command array is a 64 byte array used with the 1-wire low level function
//First issue the convert temperature command
commandArray[11]=0x55;//Match ROM
commandArray[12]=Specific Device Rom Byte[0];
commandArray[19]=Specific Device Rom Byte[7];
commandArray[21]=1;//Num TX
commandArray[23]=0;//Num RX
commandArray[24]=0x44;//TX Byte 0
<Compute and fill in appropriate checksums here>
ljError = AddRequest(ljHandle, LJ_ioRAW_OUT, 0,64,(int)commandArray,0);
//Next issue the read temperature command
commandArray[11]=0x55;//Match ROM
commandArray[12]=Specific Device Rom Byte[0];
commandArray[19]=Specific Device Rom Byte[7];
commandArray[21]=1;//Num TX
commandArray[23]=2;//Num RX
commandArray[24]=0xBE;//TX Byte 0
<Compute and fill in appropriate checksums here>
ljError = AddRequest(ljHandle, LJ_ioRAW_OUT, 0,64,(int)commandArray,0);
ljError = AddRequest(ljHandle, LJ_ioRAW_IN, 0, 64(int)responseArray, 0);
ljError = GoOne(ljHandle);//Convert
ljError = GoOne(ljHandle);//Request Read
ljError = GoOne(ljHandle);//Read

I read the LSB and MSB from the response array and convert them to temperature and it appears to be correct when I get it.

The way I read the notes and the sensor document suggests I have to do something else before I issue the convert command but I am confused about what this is.

Can you tell me if I am missing something here or do I have a problem somewhere else?



Timing was in fact the problem.  Since I am using the LabJack power for the chips I now first request a conversion for all chips on the line and then start a 1s timer after which I read the temperature values.  I found that 750ms sometimes still resulted in bad readings but 1s is solid.

Thanks again for your great support and great product,



ElectroLund's picture

I can't seem to successfully read data from my DS18B20 temp sensor.  I can read it successfully with an iButton module, the LinkUSB adapter, so I know my hardware is good.

What I get in my response packet is only the first four bytes as non-zero.  I get valid checksum in [0], followed by 0xF81D3C (which apparently are a special 1-wire setup opcode).  The rest is all 0, which is surprising.  I would expect to get an error code in response byte 6, as defined here.

For that matter, if I disconnect all hardare and do a read, I get same results.

labjack support's picture

There should not be any error code returned from the 1-wire function, so the 0 return could perhaps make sense. The issue is likely that you are not getting any response (or at the right time). I would recommend you check the sensor power setup and make sure you give adequate time between the temperature conversion command (0x44) and temperature read (0xBE). The temperature conversion can take up to 750ms depending on the resolution setting.

RRguru's picture

The show case used in this app note uses UD-series device.

In the text is mentioned that there will be provided an Labview example.

Meanwhile all examples are for T- series devices and don't work with U6 that I'am using.

Is there the same example available for UD-series? 

Is it inside Labview for UD package?

If not where should I start?

labjack support's picture

We do have some UD examples on this app-note under the section "5. Useful Code". In fact, every example in that section except the files with "LJM" in their names are for UD devices. Please note that some of the SubVIs that we use in the LabVIEW examples depend on our LabVIEW archive, so if you are not using the pre-built executables then you will need our LabVIEW archive. See LabVIEW for UD here:


ElectroLund's picture

The example code mentioned above only contains 2 Python equivalents of the Read_DS1822.vi:


Both these files are basically identical, each being for 2 different ROM IDs.

I'm hoping you have example code for the search algorithm mentioned in the app note, "1Wire_Search.vi"

labjack support's picture

Unfortunately, we do not have another example with the search algorithm implemented. The algorithm with a C (would-be-pseudocode) example is available on the following page: