1

I am looking for ideas on how to connect 12 sensors to an Arduino wirelessly. The sensors will be about 10ft from the Arduino. They need to send one byte of data every 100ms-250ms to the Arduino in an organized manner.

  • I have investigated MQTT and pubsubclient, but have not found a way to make an Arduino a Broker, and have been told it is very inefficient for my application.
  • I have looked at NRF24L01, but it appears to be limited to just 6 pipes to receive data in an organized fashion.
  • I researched Xbee, but have been told that it cannot keep up with the data rate.

Other suggestions are appreciated... Thank you.

Improve this question
4
  • 1
    You can do it with an NRF24L01 using just a single pipe. Simplest would probably be to actively query each node for data by including a node number in the query packet, but you can also have them identify themselves with a node number, transmit at slightly varied or random intervals, and perhaps put a reading number in each packet too so that they can transmit each reading more than once to generally accommodate any collisions on the occasions where the transmissions from two overlap.
    – Chris Stratton
    Mar 15 '16 at 13:22
  • Chris, would you happen to have any example Arduino code to do this, or a pointer to a reference, showing both the client and the server side? This sounds like it may be the simplest solution... I did not specifically mention in my original post that each sensor is wired directly to an arduino. Thank you!
    – user19216
    Mar 15 '16 at 13:36
  • Did you got the things working? I am looking for - how to receive wireless data from four sensors with 512 Hz data rate(for each sensor and simultaneously) ? thank you.
    – AbhIoT
    Sep 22 '16 at 15:05
  • Can any one help me in getting the Arduino code that how I can receive data from 6 sensors simultaneously on single master nrf24lo1...... Thanks in advance
    – Wajhee uddin
    Nov 9 '18 at 12:55
2

I would recommend the nRF24L01.

You don't need one pipe per node - just one pipe.

Each pipe is effectively an address that a node responds to - having multiple pipes means you can have multiple addresses on one node (like aliases) - but of course you only need one address per node, and hence one pipe per node.

The range is more than adequate (with the antenna version I have managed to get hundreds of meters no problem) and the price is so low as to be negligible.

Improve this answer
1

It might be easiest to send a UDP packet over WiFi. There is no extra packet overhead for this "connectionless" protocol: no OPEN, no ACK/NAK, no CLOSE, etc. The incremental cost for additional bytes is very small, so if you decide you need to send 2 bytes, or even 100 bytes, it won't affect the throughput very much.

If you can "batch" the bytes, that would be even better. For example, could you send 8 bytes per node, once every 800ms-2000ms? If not, WiFi speeds should allow the single-byte UDP packet to get through without much latency. Do you know what latency the receiver can accommodate? You might get lower average latency with batched packets, depending on the network access time (i.e., how long it takes to hop on to the air).

A roll-your own approach would be to use a raw RF transmitter/receiver with something like VirtualWire. With proper synchronization from the "master", the slaves could each have their own time slot, avoiding collisions (which keeps the network access time low)

Improve this answer
1
  • WIFI is going to add a lot of register-with-the-access-point type setup overheard before you can do that. Probably the reason for considering it would not be any inherent advantages (its quite disadvantageous compared to the alternatives) but the ready, inexpensive availability of ESP8266 boards as sensor nodes on which the poster can run Arduino-style firmware. It can also function as the sensor hub and if needed the AP - either in cooperation with the existing Arduino or potentially replacing it.
    – Chris Stratton
    Mar 15 '16 at 13:19
1

Use nRF24L01. To avoid collisions you can query the sensors (as Chris suggested in comment). The setup would be: Each sensor would have unique address. Central unit would transmit request and sensor node would respond to it. Central unit would have different address and all sensors would transmit to that address. You can also use data in ack to pack response.

  • Central node (Addr0) -> Sensor 1 (Addr1): Request
  • Sensor 1 (Addr1) -> Central node (Addr0): Response, sensor data
  • Central node (Addr0) -> Sensor 2 (Addr2): Request
  • Sensor 2 (Addr2) -> Central node (Addr0): Response, sensor data
  • Central node (Addr0) -> Sensor 3 (Addr3): Request
  • Sensor 3 (Addr3) -> Central node (Addr0): Response, sensor data
  • ...
Improve this answer
5
  • Thank you all again. I am just becoming comfortable with programming the Arduino. Would you have a link or example Arduino code to do this? All the examples I have found just show a one-to-one communication.
    – user19216
    Mar 15 '16 at 14:26
  • Essentially all that is happening here is one-to-one communication, it's just that the hub has such an interchange with each node in turn. One thing you will need to think about though is how long to wait for a reply, before moving on to try the next node.
    – Chris Stratton
    Mar 15 '16 at 15:51
  • Ahh... understood. What sort of delay/wait time would be typical? Am I even going to be able to meet my data rate of 250ms? That is, within 250ms I would need to obtain a reading from all 12 sensors...
    – user19216
    Mar 15 '16 at 15:57
  • There will be plenty of time, it's more a question of what is the best strategy for using it.
    – Chris Stratton
    Mar 15 '16 at 16:20
  • So how to connect the sensor? directly via I2C to the nRF24L01 transceiver, with another transceiver at the microcontroller end? Wouldn't you need a microcontroller at each end?
    – brianlmerritt
    Nov 15 '17 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy