I want to have 4 sensors transmitting information to a microcontroller ie

4-bit Encoder -> Transmitter >>>>>>>>>>>> Receiver - > Decoder -> MCU

The problem I have is that if I use 4 transmitters and one receiver it will not be possible to alternatively get data from each sensor because there will be no easy way ( or at least it seems ) to make the transmitters transmit in turns.On the other hand if I use 4 transmitters and 4 receivers the 4 transmitter/receivers will interfere because they will be trying to transmit on at the same frequency and I would also have the problem of having to use 16 I/O ports on just getting sensor data into the MCU.Does anyone have an idea on the best/easiest way to solve this problem?

The problem is similar to this one, except that I want to transmit data from 4 different locations and not only one.

  • \$\begingroup\$ Distances between transmitters and receiver? \$\endgroup\$ Feb 23, 2013 at 12:15
  • 2
    \$\begingroup\$ @Leon The distance is 12 '>' characters, obviously.. :-) \$\endgroup\$
    – m.Alin
    Feb 23, 2013 at 12:25
  • \$\begingroup\$ The distance between them will be around 10-20m. \$\endgroup\$
    – KillaKem
    Feb 23, 2013 at 12:33
  • \$\begingroup\$ Does it matter if you lose a reading now and again? How frequently do you want readings? \$\endgroup\$
    – pjc50
    Feb 23, 2013 at 12:36
  • \$\begingroup\$ You probably should add the total time each transmission will take and how frequently you need to send data to the question, but this is a reasonable question and will have a solution as long as the transmitter can be assigned a unique number. They'll be an algorithm that assures they're unlikely to collide after a given number of transmissions, although I don't know it myself. \$\endgroup\$
    – PeterJ
    Feb 23, 2013 at 12:38

2 Answers 2


The suggestions about retries are good ones. With RF generally one can never count upon a clear channel free of noise so that there will always be a finite probability of a missed transmission at the receiver due to interference or noise.

Having the transmitter use of FEC (generally better probability of reception per bit sent) but more complex) and/or unconditional retransmissions (worse than a well designed FEC though good against RF interference that may overpower the channel for longer than a packet duration) allow a unidirectional link a high probability of success. You can also use some kind of unique spreading code such as FHSS DSSS or similar to create CDMA channels for your transmitters such that they will not interfere even if they all transmit at the same time. That can be done in the baseband or at RF carrier frequency.

Use of TDMA techniques is often a simple expedient whereby you assign time slots such as A = 0s...15s, B = 15s...30s, C=30s...45s, D = 45s...60s out of 1 minute (for instance, though of course you can scale the time slot frequency and duration arbitrarily) and use a clock within each transmitter to schedule its periodic transmission windows such that it'll never transmit at the same time as its peers. Going slower e.g. 0...15 minutes etc. out of the hour would work even better. The problem with half duplex scheduled transmissions is clock drift between the transmitters. 10 days is very approximately roundable to 1,000,000 seconds. So a 20ppm clock drift will equal about 20 seconds maximum error over 10 days, so if your devices are to transmit for months on a schedule, you can see that over time their clocks will become off by up to minutes magnitude. Applying first order compensation for measured crystal frequency offsets at the center of the expected operating temperature range will enable to get low single digit PPM clock accuracy in practice with a reasonably accurate and stable 32kHz crystal oscillator timebase. Applying a temperature compensation to the clock rate will help too if your operating temperature drift and range are large enough to warrant it.

Of course if you have bidirectional (RX as well as TX) capability at the nodes you can use packet acknowledgements as well as listen-before-talk synchronication and synchronization / time broadcasts to help the communication succeed.

If you use FDM you'll also be able to have unidirectional transmitters broadcast independently of each other, though some possibility for external interference / noise related errors will still exist.

If you can transmit audio bandwidth baseband you can just use FDM in the baseband by assigning different subcarrier frequencies like 697Hz, 770Hz, 852Hz, 1209Hz to the different transmitters and recovering the information by a DFT or Goertzel resonator bank at the receiver.

You can use common CDMA ICs like car lock / alarm transmitters or garage door openers or similar so that you get the benefit of the CDMA circuitry's interference suppression as well as the inexpensive hardware due to mass production.

If you use a protocol like Bluetooth Low Energy or Zigbee for the communications you'll get the "built in" layers of reliability, error detection/correction, transmission reliability, protocol implementation, modem integration, et. al. They're intended for low energy sensor networks and take all your stated needs into account, and though they're probably excessive for your needs, the benefits of an highly optimized, highly efficient, highly reliable, off the shelf, inexpensive solution sometimes make them attractive for the simplest of needs.

As for there being no easy way to get the transmitters to transmit in turns, well, a small RTC or $0.50 8/16 bit MCU could help a lot there to implement TDM or LBT (listen before talk) or a reliable transmission protocol, but that's up to your implementation. At the least if you're not using FDM you'll probably need to send unique IDs / node serial numbers or unique codes from each otherwise identical node so the receiver knows which 'identical' node the transmission came from. Typically for low power battery powered nodes you'd have to only activate their transmitters at a low duty cycle such that they're saving power most of the time and transmitting only so many times per minute / hour / day / week. If that is the case then coordinating the transmissions may be architecturally not that far removed from the existing scheduling algorithms/circuitry.

The final option I'll mention could involve using directional antennas at the receiver pointed to each node to make it less likely that other nodes or interfering fixed transmitters will cause problems in a given reception. Of course that adds complexity to the receiver setup but can be quite effective depending on one's system design and environment. I'd possibly do this in conjunction with other techniques, not usually instead of them.

  • \$\begingroup\$ Added additional problem statement \$\endgroup\$
    – KillaKem
    Feb 26, 2013 at 9:15

Assuming your sensor messages have sufficient error-checking to allow collisions to be reliably detected (and rejected), transmitting at random intervals (with a Poisson distribution) works surprisingly well. Carl Huben did a pretty good writeup of this in Circuit Cellar back in 1999.

  • \$\begingroup\$ +1 Nice one. For anyone else not familiar with Circuit Cellar you might not get a lot of info from that link but I just read the original article (I have every edition) and it is an excellent magazine. \$\endgroup\$
    – PeterJ
    Feb 23, 2013 at 13:13
  • \$\begingroup\$ Do you know where I can read the article?, the link you provide just leads to code samples of something. \$\endgroup\$
    – KillaKem
    Feb 23, 2013 at 14:22
  • \$\begingroup\$ Sorry about that. The index that I linked to used to have links to where you could order back issues, but with recent changes to the Circuit Cellar website, they became invalid and had to be removed. I think if you go here, you can order indiidual articles (but only as far back as 2005?) or entire issues. \$\endgroup\$
    – Dave Tweed
    Feb 23, 2013 at 14:50
  • \$\begingroup\$ @DaveTweed this is why links should only be used as a reference and your answer should cover the critical details itself. \$\endgroup\$
    – Kortuk
    Feb 26, 2013 at 16:33

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