I would like to have (10+) Arduinos read from their own temperature sensors - fine, I've done that.

Now, I would like to have the Arduinos (transmitter) send the temperature sensor data over RF to a SINGLE Raspberry Pi (receiver). I am very confused, would this work:


Would I have to have all of the receivers (not what I want) or would all the transmitters work with just one receiver?

After getting the comms working, how can I get the Arduino to send a string over RF - is there a library for it? A library for Python (Raspberry Pi end) would be great too!

  • I can't help myself, but try having a word with the guys at Ciseco - they're experts with RF and the Raspberry Pi - twitter.com/Cisecoplc
    – recantha
    Commented May 20, 2014 at 8:05
  • All the senders just need a transmitter since they will just send data once in a while. You can fit a TRANSCEIVER (Receiver/Transmitter in one) All the data in the air is on the shame channel (frequency) so the receiver has to know what node it is, and what data it is sending. Build a model like {node:x123, temp:yyy, humid:zzz, more:123, evenmore, abc} and send it as plan ASCII in the air. JSON is built to be human readable, lightweight and easy to compress!
    – WillyWonka
    Commented May 21, 2014 at 13:20
  • possible duplicate of Cheap COTS transceivers that work with Raspberry Pi?
    – WillyWonka
    Commented May 21, 2014 at 13:37
  • Here is a good youtube video demonstrating that using NRF24L01+ youtube.com/watch?v=_68f-yp63ds
    – akhmed
    Commented May 26, 2016 at 2:01

2 Answers 2


Don't buy those crap receivers and transmitter. At least pick one that has a crystal. The ones you linked to just provide the modulation of the signal. You'll have to implement a protocol yourself.

Better go with the NRF24L01. These chips do all the heavy lifting. The can both send and receive. Just push some data to the chip using SPI, and the chip will create a package and send it. The receiving chip listens for packages and converts the signal back into a your data. It also does error correction. You can even have it setup, so that if a packet is resend if the sender doesn't get an ACK from the receiver.

There are some nice libraries for these chips for arduino. At least one of them is ported to Raspberry; https://github.com/stanleyseow/RF24.

If you need more range, you can get these modules with an external antenna. Since they are on a higher frequency 2.4Ghz the range is in theory less than with 433Mhz.

I am using these modules to transmit power-meter data. Currently my arduino is reading the data. But the plan is to connect it to my Pi, and create some nice graphs on it. Since my power-meter sensor runs on batteries I had to mess around a bit to turn off the auto-retransmit feature.

PS. the internal temperature sensor on the atmega328 is not very accurate, and gets heated by the cpu itself. Just buy these cheap temperature and humidity sensors, while you are on eBay.

  • Ok, I'll look into those. Would one then work with the Raspberry Pi even though it's not great at timing? Also, if I use these, would they be able to identify themselves to the receiver or is it easier to just add an ID number at the end of the string? Also, could you possibly add a wiring diagram for the Pi, arduino and the transceivers?
    – developius
    Commented May 21, 2014 at 11:17
  • 2
    I like thos 2.4Ghz modules. They came very cheap now. THey used to be like $25, then $15 and now $1.5 :) They are better than sub gigahertz because you can send megabits per seconds with better error correction. But you are not allowed to amplify them, where sub gigahertz, some countries allow you to go miles and miles! :)
    – WillyWonka
    Commented May 21, 2014 at 13:22
  • SPI sends it's own clock signal, so timing is not a issue. These modules send data to an address. You have to set the receiver to listen to that address. This way you don't accidentally get any messages from other systems using the same chip. You can set 6 addresses to listen to. But you can also have set it up so that it only checks the first few bytes of the address. In the later setup you can have on receiver, get data from multiple senders. You CAN read the senders address, to determine where it came from. I myself currently add a id to the package, because it's easier.
    – Gerben
    Commented May 21, 2014 at 14:33
  • First link on the github page tells how to connect these modules
    – Gerben
    Commented May 21, 2014 at 14:34

They look like they all run on the same frequency, so they should be able to run together. You would have to make sure, however, that you run it in some way that allows all of the transmitters to share the connection without drowning each other out. Synchronizing these would be difficult, so you may need to have each transmitter also have a receiver. It looks like they come together anyway, so I don't think you'd be wasting money.

I'm no expert, and I didn't look at how it works too closely, but it looks as if the TX/RX modules don't really concern themselves with sending data; they just make a "virtual wire" for extending connections. So what you need is a connection protocol that will allow for multiple sensors to civilly report their readings and synchronize themselves. Something like SPI or I2C would work, but they require multiple wires, so it's out.

The Arduino's serial connection uses one transmitter (TX) and one receiver (RX) line to establish two-way communication, which can (I think) use the transmitter and receiver part of your RF modules. This could be the way to go, but I don't know whether it's possible for multiple devices to use the same connection. If it's possible to just broadcast a "Calling Sensor 7" message and have only Sensor 7 respond, then this would work. However, I am guessing (and I don't know) that there is some sort of handshaking that has to go on to establish this connection, so having multiple devices all share the same connection might be hard, because they might all try to respond to any message sent. Your job, then, would be to learn more about the serial protocol (UART) and figure out whether multiple devices could listen and chime in. In the likely case that that's not possible, you would either have to find another existing protocol or roll your own. With the hardware, it should be possible.

One last thing: you'll almost certainly want to have an Arduino on the receiving end instead of a Pi. Pi's are usually terrible at timing-critical things like communications protocols, so it would be a lot easier for you to have one more Arduino to act as the master and receive all the data and then send it to the Pi over a USB connection.

This is as much as I can offer; I don't think I know enough to do it myself, but I wanted to point you in the right direction. Good luck.

PS—Look at this question, if you haven't already.

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.