I'm working on a project which relies on wireless communication, and I'm looking for the best alternative. These are the design requirements:

  • Is easy to interface with Arduino
  • Works over a small range (5-6 metres at most)
  • Consumes little power - the least possible
  • Devices mustn't interfere with each other
  • Doesn't need to be real-time, the delay can be in the order of hundreds of milliseconds
  • In general, the devices aren't within sight of each other (meaning IR and similar solutions won't work)

The scenario is:

About 10 devices in the same room, communicating with each other, sending short (30 characters at most) messages to each other once in a while, for a few hours (without changing batteries).

The best I could find is Bluetooth (BLE, specifically), mostly because there are a few ready-made Arduino+Bluetooth modules and the promising "Low Energy" label (at most half the energy consumption of normal Bluetooth), but I'd love to get an opinion from people with more experience in this field.

  • 2
    \$\begingroup\$ I vote for Bluetooth. \$\endgroup\$
    – nidhin
    Jun 13, 2014 at 18:58
  • \$\begingroup\$ Give us some information about what you decided not to use, and your rationale. \$\endgroup\$ Jun 13, 2014 at 18:59
  • \$\begingroup\$ 5 to 6 metres at most - bluetooth can work further than this - is 6m the absolute must not go above limit? Very little power - how about you name and shame some numbers here. Mustn't interfere with each other - what does this mean precisely? \$\endgroup\$
    – Andy aka
    Jun 13, 2014 at 19:01
  • \$\begingroup\$ @Andyaka: No, what I mean is that the devices will be 6 metres apart at most, therefore there is no need for supporting greater distances. As for "very little power", I plan on running each device (Arduino + LCD + wireless module) on one or two AA batteries at most, and these devices should be able to communicate for at least one hour without changing batteries. \$\endgroup\$ Jun 13, 2014 at 19:05
  • 1
    \$\begingroup\$ Sounds like a Bluetooth piconet to me. \$\endgroup\$ Jun 13, 2014 at 19:37

6 Answers 6


Take a look the XBee line of tranceivers. There are various types depending on the transmission range and desired power rating.

These devices also interface with Arduino projects nearly trivially. The Serial library makes use of the AVR's UART hardware which is directly compatible with the Rx pin of the XBee. Also note that no level shifters are needed because the XBee Rx/Tx pin work with 5V!

DO note, however, that the XBee must be powered with 3.3V, so a simple 3.3V LDO voltage regulator can be used.


"Best" is hard to define, but I would look into an IEEE 802.15.4 transceiver.

I used an MRF24J40MA for a project (https://github.com/briksoftware/gradusnik). You can try to see if there is some code you can use there. The project is for PIC, but many things are actually platform independent (especially the other projects it depends from).

The module consumes about 20mA in rx/tx, which is not much. However, to get long battery time you need to put the module to sleep most of the time. You could use a beacon enabled network for this, with one device acting as the coordinator. The module consumes some µA in sleep mode (check the datasheet for exact numbers)

The only problem interfacing that with an Arduino is that you need a 5->3.3 level shifter (if Arduino still uses 5v).

Another popular transceiver for the IEEE 802.15.4 protocol is the XBee module, but it is much more expensive.


I don't see it as a wireless problem but more of a protocol problem.

If battery conservation is the name of the game and if one device can, thru appropriate programming, adopt the role of temporary "master" then each other device can be allocated a timeslot. Once the allocation is done then the temporary master can return to being a peer but the important thing is that a framework of time slots has been created and all peers will have bought into this framework.

What does this do? Having a timeslot means you can shut down the radio for hundreds of milliseconds and wake up to see if there is a transmission in progress intended to be received. When a peer wakes up it has to wait to see if any of the other 8 peers are sending a message to it. Timing is critical but if you want long battery life then concentrate on the protocol. This answer is just a whiff of an idea. The wake-up timeslot will be sub-divided into 8 other slots that each of the other 8 peers are allocated to transmit on and, if one is transmitting the others can listen first to check whether they can transmit. Something like this: -

enter image description here

The "next" slot allows new peers to join the group.

Low power transceivers are common place so I'm not going to look into this.


Try the cheap 433 mhz txrx modules. they come in handy and can be easily interfaced with arduino. I use them for my personal hobby robotics projects.


Just curious why the NRF24L01 2.4GHz Wireless Transceiver Module hasn't been mentioned? It is a low power unit, can be switched into a standby mode for even lower draw. It operates off of 3.3v, so can use either a low power arduino or a splitter, and best of all is pretty cheap?

Here is the nRF24L01+ product page along with a nRF24L01 How-To that contains information about interfacing one to an Arduino along with sample code.


The RFM12B comes to mind..


Some features:

  • SPI compatible interface
  • High data rate (up to 115.2 kbps in digital mode)
  • 2.2V-3.8V power supply
  • Automatic antenna tuning
  • 16-bit RX data FIFO
  • Programmable TX frequency deviation (from 15 to 240 kHz)
  • Programmable receiver bandwidth (from 67 to 400 kHz)
  • Analog and digital signal strength indicator
  • Clock and reset signal output for external MCU use

The SPI comms interface should be fairly to set up with Arduino.

The RFM12B-S2 model sells for under $7 these days.


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.