The task fell on me to realize a wireless, daisy chained communication system. The communication must be wireless, esp. via infrared diodes. The end of the chain is connected to a PC (wired). The whole system consists of n members. Each member has two sides with a sending and receiving diode.


The target is:

  • The PC must be able to send an initialization command and the system containing of n members must figure out how many modules are installed ("find n").
  • The PC must be able to send a command to all modules
  • The PC must be able to send a command to a certain module
  • The modules are close together, but the distance must be able to vary between about 1 and 3 inches.

My approach so far:

  • The PC sends a command to module 1. Module 1 sends back its presence to the PC, as well as wirelessly to the second module. Until now the PC knows that 1 module is present. When module 2 receives the init command it sends back its acknowledgement to the first module which transfers 2's message to the PC. Also, module 2 sends the init command further to module 3, and so forth. The init phase ends, when the last module (n) gets the init command and its presence message reaches the PC. After that no more message arrives at the PC's side and it knows that n modules are present.
  • Further commands contain a header byte addressing the "destination" module. Or, if all modules are meant, the command starts with a "zero"-byte (0x00).

The challenge is:

  • Physically: I don't know how to prevent the fact that module x could "talk" to module x+1 and x+2 simultaneously (cross-talking) by reflections or mirroring. I need to get the system self-learning. Until now, I dim the diodes until they can only reach a very small distance. But this isn't very fault tolerant.
  • Logically: Day light and other sources of infrared light cause a lot of fuzzy and gibberish messages. Real messages are currently preceded or even disturbed by external influences.
  • \$\begingroup\$ Does each module know what "n" it is? Or are they all identically programmed and they have no idea about their own orientation? \$\endgroup\$
    – Tim
    Commented Apr 2, 2013 at 23:45
  • \$\begingroup\$ Daisy chains are not fault tolerant for any reasonable definition of "fault tolerant". If any link in the chain stops working, then the network is split into two, which cannot communicate. "fault tolerant" means that some element fails, but the system as a whole works, with full functionality. For instance RAID storage is fault-tolerant. A disk drive dies, but complete availability of all data continues. A distributed service is fault tolerant. A server goes down, but clients find another. \$\endgroup\$
    – Kaz
    Commented Apr 3, 2013 at 0:20
  • \$\begingroup\$ You can add a measure of fault tolerance by using a hardware pass-through. That is to say, any node which is not communicating can release the infra-red fabric, and the hardware itself passes the signals across to complete the chain. This means that even if a module crashes, so long as its infra-red hardware has power, it will continue to pass signals. So even while devices are rebooting, being flashed with firmware updates, or completely hung, they pass data. \$\endgroup\$
    – Kaz
    Commented Apr 3, 2013 at 0:23
  • \$\begingroup\$ Maybe.... Try and "find" the farthest (or is that furthest?) module in the link. This should normally be the module that does not get a response when it retransmits the init command. It will recognize the lack of response and deem itself the farthest. The problem with trying the find the nearest is that several modules may respond believing they are closest. Hopefully, the farthest module can be defined this way. But, there is trouble with this system if there are two (or more) modules believing they are 2nd farthest because they received the farthest's "I am here" response. Interesting! \$\endgroup\$
    – Andy aka
    Commented Apr 3, 2013 at 7:55
  • \$\begingroup\$ Does the system need to be a daisy chain? Can you, instead, broadcast from the primary to all "clients", then accept responses (repeatedly transmitted with random delays until acknowledged by primary) from each, with its randomly generated unique ID, enumerate those, and thus arrive at both a device count and an address book? IR signals such as from TV remotes do traverse several meters successfully. \$\endgroup\$ Commented Apr 3, 2013 at 10:13

2 Answers 2


IR signals bounce around : get attenuated, or occasionally reflected in unexpected ways. As you said, this has to be catered for.

If these devices are in a room, devices 2 and n-1 may both see the same signal from device 1 and respond at the same time : what happens then?

It seems to me that you will first need to discover devices and build a network, then structure messages to use the network.

For example:
stage 1) Network discovery. I assume (a) you know how many (n) is, (b) you can program variations into each individual device (c) each device can measure signal strength (or signal quality somehow).

Device 1 transmits a broadcast message. All receiving devices wait - a different time in each case to prevent collisions - and reply with the signal strengths. Some messages get back to it, others don't.

Device 1 now has a list of stations it can talk to reliably, sorted by 2-way signal quality, and which ones it can't reach. Call the strongest one "Device 2".

Now it asks Device 2 to do the same, and send back its list. This puts more load on Device 1 or the host computer to build the most efficient routes to each device, and fallbacks.

stage 2) Network use : Each message includes 2 addresses : the ultimate destination and the immediate target (usually Device 2, from Device 1). Only the immediate target will reply to the message, preventing collisions without needing the delays used in network discovery.

  • \$\begingroup\$ Variation on stage 2: PC instructs 2nd tier devices which 3rd tier devices are allocated to it. Then when it comes to networking, the PC doesn't have to worry about the "shape" of the network or who is in-charge of who - it just sends a message and expects it to get-through. Distributed intelligence? \$\endgroup\$
    – Andy aka
    Commented Apr 3, 2013 at 12:05
  • \$\begingroup\$ @Andy : good idea. First the 2nd tier devices have to report all the devices they can see (because the PC doesn't know that!) then the PC instructs them how to route. \$\endgroup\$
    – user16324
    Commented Apr 3, 2013 at 16:26

Give each unit its own unique intrinsic hard coded node ID, that will help certain problems and algorithms. Or you could generate one "randomly" if you want like a GUID.

Give each "message" a unique "message ID" and that can help you decide whether a given message has been seen / processed / forwarded one or more times or not by a given node.

Give each message a "type" such as "INIT COMMAND REQUEST", "INIT COMMAND RESPONSE", "BEACON TRANSMISSION", whatever.

Use flags such as "forwarded message", "original message" if you like.

Use message payload data such as "forwarded hop count" (increments every time it gets forwarded), "time to live" (number of forwarding episodes before a message will expire) if you like.

Use algorithms such as nodes only forward to certain other nodes or nodes in a given sequence if you like.

Of course you could probably use XBEE or WiFly modules or something like that if you want to give up IR for RF. Or you could do something fun (over the top, yes, but fun) like use TinyOS, Contiki, UDP or whatever if you wanted and used sufficiently powerful nodes. Or you could port SimpliciTI or similar. Port any of the network layers to use the infrared medium.

As for environmental noise -- use IR filtered phototransistors, that'll cut down on non IR noise. If baseband IR noise is still a problem use IRDA modules which have optical and baseband filtering to help. Or you can use AC modulation on an infrared analog carrier and receive the data in analog or digital. You could evey do multiple FDM channels if you wanted between 1kHz and 10kHz or whatever. In analog you could use a PLL tone decoder like the NE567 or HC4046 to receive FM modulation, but why bother if doing some digital filters is only a few lines of MCU code. Heck use DTMF, there's source code out there for that. Or PWM FSK output and digital filter to receive.

Forward error correction could help message verification and integrity. Or a simple checksum or CRC.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.