RF Transcievers, Network Protocol

Hello Guys,

I'm a completly new user of Arduino, and before buying some materials I wanna know you point of view. I'm really interrested in building my own domotic system using Arduinos and sensors. I'm sorry to ask the question again, but there's some black dots in my thinking.

The main aim of my project is to build a main "central collector" using a Arduino Uno and Ethernet Shield which will be in charge of collecting information from wireless sensors and presents the results in a web page.
This first part doesn't seem to be really difficult but for the wireless sensors...

I would have little, cheap, and low power consumers wireless sensors. My choice is perhaps to use Arduino Nano cards, with the sensor of my choice. To communicate with the main "central", I thought about RF Transcievers from Sparksfun. The main problems stays when there's is more than two sensors, to allow them to communicate easily and to be identified.

I thought about two ways of implementing this solution and as daily arduino users, I wanna know your point of view.

Solution 1 : To allow sensors to communicate easily without interfering with others, each sensors has to be alone to transmit. Using time slots division, each half seconds could be reserved for each sensors. When a new sensor is connected it has to be synchronized using the same clock. When some of them has something to say, they just use their dedicated slot. Main central will be able to recognize the sensors by the slot on which its sending information.
Problem : when there's a lot of sensors... waiting times could be long...

Solution 2 : The central and sensors can play a Master/Slave game. The central could ask sensors one by one if one of them has someting to transmit, and if it's the case, the sensor sends information.
Problem : each sensor is periodically waked up...

What could be, for you the best solution ? Whatever the solution, I think I will only need Arduino Nano + Dedicated Sensor + RD Transciever. This is the cheapest solution I found. I find xBee, Bluetooth or Wifi solution too heavy and too expansive to build what I want.

Thanks a lot in advance for your replies,

Sleashe

The cheapest wireless hardware you can get is probably this kind of modules:
http://www.electrodragon.com/?product=433m-rf-wireless-receiver-module
http://www.electrodragon.com/?product=433m-rf-wireless-transmitter-module
They are available at some chinese stores and all over eBay and can be used with the VirtualWire library for Arduino.

If you build your own standalone ATmega328p based sensors/transmitters you can save some money by not purchasing Arduino boards with USB interfaces and all. You can still program them using the Arduino software.

I would go for a one-way system with transmitters that can only send data to the central and then sleep most of the time.
I don't think it's possible to make it collision proof this way but you can make sure that two or more transmitters don't collide all the time.
Add some randomization to the sleep periods so that they don't wake up at the same interval all the time and don't send data too often. That should leave enough silence for quite a lot of sensors.

Thanks for you response and the links you gave. I'll wait for other responses/point of views but, thanks a lot, i'll have a look.

Do the sensors require bidirectional transmission ?
Its relatively easy to make small lightwight unidirectional transmitters, but as soon as you go to bidirectional transmission
the power consumption drastically goes up, as receivers have to be on all the time .

Sleashe:
The main problems stays when there's is more than two sensors, to allow them to communicate easily and to be identified.

Simply give each their own little unique ID that they send out along with their data.

I would have little, cheap, and low power consumers wireless sensors. My choice is perhaps to use Arduino Nano cards, with the sensor of my choice. To communicate with the main "central", I thought about RF Transcievers from Sparksfun.

You can get away with using even smaller, standalone microcontrollers if your sensors don't need to do much more than collect and send data like I've done here:

ATTiny84 for ~$2 and a RFM12B transceiver for ~$6. You could also spring for a cheaper wireless module like the nRF24L01.

I am working on a system that is sounds very similar to yours. I am planning on having 3-4 sensor modules measuring temperature and humidity and one central collection module. I did quite some research and what I came up with so far is pretty much what perhof suggested. Using a ATmega328P (or ATtiny84V) without an Arduino board for the sensors and cheap 434 MHz modules for one-way communication. As a collection module, I am planning on using another ATmega328P connected via UART to a Raspberry Pi. The MCU is going to filter the messages (since there is quite some noise to be expected) and the Raspberry Pi will store the data and provide a web interface.

I am planning on having the sensor modules send every 20 minutes with a small random delay to avoid constant collision. The sensor modules will send a source and a destination address with every measurement for filtering the messages. I realise that there might be some collisions with this set-up and that I might not receive all messages. However, I decided that it was acceptable for my use-case to loose some measurements.

So far, I have a test set-up running where one ATmega328P sends messages to another ATmega328P. Since I am also new to the field, I am taking it fairly slow and do a lot of testing. If you are interested in more details let me know and I can share more of my research with you.

Cheers,
Hannes

If you go for the nRF24L01+ modules, I think it would be possible for your central controller to 'ask' each sensor to give its data instead of the whole collision taking place since these are transceivers. I don't know about the power requirements though. I also don't know the sleep/wake up states of the RF modules as I haven't toyed with them. If your setup has only the central system connected to power and all others on battery, I think your best bet would to be periodically wake them up. I haven't really thought about this, but I'm sure there's got to be a more power efficient design.