current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Arduino Stack Exchange is a question and answer site for developers of open-source hardware and software that is compatible with Arduino. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 0 down vote favorite
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.

share|improve this question
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 2 days ago
    
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! – da40flyer 2 days ago
up vote 2 down vote

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.

share|improve this answer
up vote 1 down vote

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)

share|improve this answer
    
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 2 days ago
up vote 1 down vote

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
  • ...
share|improve this answer
    
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. – da40flyer 2 days ago
    
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 2 days ago
    
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... – da40flyer 2 days ago
    
There will be plenty of time, it's more a question of what is the best strategy for using it. – Chris Stratton 2 days ago
    
Thanks Chris.... Thank you everyone.... – da40flyer 2 days ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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