Main Site Documentation

Chainable Sensor Array


Electronics Gurus,

I’m looking for some advice/ideas. I’m wanting to build a product that will have a chainable array of sensor nodes. I don’t know in advance how many nodes will be needed and I’d like to avoid having to configure addresses for each node. I can probably get by with a max of a dozen or so sensors in a chain. However, putting 128 in a single chain would be really cool. The nodes could be separated by inches or feet (probably no more than 2’-3’). Also, each “node” will actually be an array of sensors (temperature, humidity, light, etc.). Also, each node will need to be very small and powered via the cabling.

So, my question is what’s the best way to do this? Is there already an established standard for this type of sensor chaining? Of course, my mind went directly to DaisyLink when I first started thinking of this… But, I’m not sure the state of that technology and it was never really used outside of Gadgeteer that I’m aware of. Due to the distances, I think I probably need something based on RS-485 or CAN. So, before I start reinventing the wheel is anyone aware of existing technology/patterns that I can build upon and possibly get more re-use from?



Good luck!


dht11 and dht22 are not one wire they have specific protocol from 40-41 byte.


digital signal via MaxDetect 1-wire bus

It’s in the datasheet.


MaxDetect 1-wire bus is specially designed by MaxDetect Technology Co., Ltd. for their purpose,

it’s different from Maxim/Dallas 1-wire bus, so it’s incompatible with Dallas 1-wire bus (known also as one wire protocol).


So he’ll have to use 2 wires if he wants to mix both those devices in his environment.


Actually, one-wire is a good idea for the protocol. I’ll have to implement it myself since I’ll most likely end up with a small board with a tiny micro that combines all the data from several sensors into a single node packet of data. I looked into one-wire sensors a few weeks ago when I was looking for an off the shelf solution but the primary problem was that everything available has a hardwired address. So, it wasn’t possible to use more than one w/o creating some sort of MUX circuit and plugging them all into different sockets on a mainboard. Any thoughts on how to handle auto-addressing with one-wire?


In the case of the

Each DS18S20 has a unique 64-bit serial code, which allows multiple DS18S20s to function on the same 1-Wire bus. Thus, it is simple to use one microprocessor to control many DS18S20s distributed over a large area.


Cool. Sounds like I’m going to have to explore this further. Thanks.


Not selling anything but maybe this will give you some ideas.

My first thought was how would you terminate all the cabling?
(Not that I know how)

I just remember all the problems using the old AppleTalk. All kinds of signal reflections going on.


use arduino mini or attiny8 with RS485

and all those you manage from master “.NET board”


I’ve used 1-wire extensively for applications like this, (currently able to talk to over 600 temperature / humidity sensors attached to a single processor in under 1 minute), and have a few suggestions.

  1. A small Diode can be placed at the end of any stubs, to prevent ringing on the lines.
  2. A Dallas DS28E17 1-WIRE-to-I2C Master can be used to interface to most sensors.
  3. The “DH” series of Humidity sensors are of questionable reliability, especially over time, with low cost alternatives including:
    SHT2x or SHT7x
    BME280 M
    BME280 N
  4. A parasite power circuit may be made similar to patent “US 20130092432 A1” , although I’d use the DS28E17 instead of the DS28EA00.
  5. Capacitance is your biggest ENEMY in doing this, use low capacitance wire to connect the sensors together.
  6. A 4ma Constant Current supply will provide you with a much better result for large networks, than a simple pull up resistor.
  7. Each one wire device has a unique address laser etched into it during manufacturing. This combined with a low cost EEPROM on the bus would provide you with addressing. If you need additional addressing, you can set the “Trip high / Trip low” alarm function on any of the temperature sensors to provide a two byte address.

Maxim’s technology is definitely innovative, just be warned that if manufacturing at volume, that they typically will require longer lead times than most manufacturer’s.


@michaelb - thanks for the tips!


While I’ve extensive experience with 1-wire, I’ve none with FPGA’s, looking at cost reducing a new generation of sensors, (ie 1.8v), and looking at ways to integrate to reduce components, So, just floating the idea of working together, as FPGA’s are more about programming, and less about hardware, and the thought is to create 1 or 2 low cost FPGA’s to integrate higher quality sensors into designs at the same cost you see knockoffs out of china for…


I’m curious what you have in mind. I don’t typically associate “FPGA” and “low cost” as bedfellows. My primary needs are 1) small size and 2) low cost. High speed isn’t really important for me since my needs are only to poll every few minutes or hours. A tiny M0 (or smaller) will probably do everything I need. I suspect your needs are different.


Ironically, for the most part speed, isn’t something I’m looking at, (if I want speed, I just start multiple threads (1 for each pin, up to 12 currently supported till I take the dive into TinyCLR) in fact, that an FPGA would allow control over the timing, which would allow for slower speeds which = more sensors per line…
That said, I put the same question to Maxim, and waiting for clarification, as they responded that the DS28E17 already meets the requirements, (in direct contradiction to the datasheet)…

but who knows, I know that the DS18B20 can be calibrated (which it is said isn’t required), and 1 out of 10, is up to 3 times outside the published specs, as I used to re calibrate them because in a specific application, a 1/2 a degree off can equal thousands of dollars difference…

And yes, size is a consideration, trying to achieve temp / humidity, on a one wire bus, with up to 300’ per stub, with each sensor being in a package equal or smaller than a 3x2 2.54mm header, requiring only a signal & gnd wire.

Trying to do all of this without loosing hi-accuracy, at a cost of less than $4 per in 500-1k runs… In lower volumes, (ie, simply mouser pricing, if the info is correct, about $6.50 per sensor, including board & population)

And fyi, haven’t ever done anything with FPGA’s, was more exploratory with a quick mouser search showing low cost ones being in the right price range, and a reasonably simple application, was asking the question…