3

I'm currently designing a sensor network that will have small ATtiny85 probes that each have a temperature sensor, a barometer, and a humidity sensor. I think I will use these (http://goo.gl/TqaDjl) to communicate as they are low cost and don't need much range. Im not sure though how I will get the probes to communicate with the main control, as the transmitter transmits digitally and I will have +20 probes that all need to send data without signals overlapping or getting messed up every minute. I think the easiest way would be to time the probes so that they don't overlap in transmission but I'm not sure. Questions:

-Is using RF the cheapest and best option for this system?

-How can I prevent communication overlapping?

-What is the easiest way to send data digitally from an arduino (or ATtiny85)?

Dragongeek
  • 263
  • 1
  • 5
  • 23
  • I can't stop thinking about the price: 1.29 for two circuit boards?!? I don't care that they are just a tiny number of components, the price is incredible. Nobody else can ship you an empty envelope at that price -- I say yes, this is _cheapest_. You should upgrade to the ER99 for 1.33 $ a pair, because those come with free shipping ?! from China ?! – jdr5ca Jul 31 '13 at 02:30
  • I know the ludicrous price is what interested me, normally communications are one of the most expensive parts (ie Xbee) – Dragongeek Jul 31 '13 at 17:33

3 Answers3

3

I guess I'm late to the party, but I'll offer some insight into collision control with a ton of chattering transmitters on one link, a la 802.11. This is somewhat packetized.

If two transmitters try to transmit at the same time, you're bound to get a mangled mess of rotten bacon at the receivers.

A simplified version of WiFi-style collisions would be good. Basically, it uses preambles that can be detected, and for longer transmissions that have a higher chance of conflicting, it can use shorter request/clear to send packets.

While this is likely overkill, I'd go for preambles. Start by transmitting a steady stream of something recognizable, like in hex, 555533330f0f00ff which is basically alternating 1s and 0s but with changing frequency(0101, then 0011, then 00001111, and so on), a readily recognizable pattern that is unlikely to be given off by stray radiation or noise.

This pattern could undergo a shift so there's a finite set of other preambles that should be bitwise-shifted relative to the original.

If a transmitter detects this preamble, it should STOP and wait. If you limit all packets to a certain temporal length, collisions should not occur if you wait sufficient time between packets. If during the time of one packet, a preamble is heard, then your station should wait for the full length of the transmission(listening to its length and other header fields so it knows how long to wait). Once the packet is done, your station can transmit its preamble.

This is where the WiFi resemblance stops and simpler protocols take over.

Note that if 2 stations are waiting on a packet they can start their preambles almost simultaneously. To resolve this, each station should have a different zero bit flipped in its preamble. If it detects a 1 for that bit, it sees that there's another station preambling, and should back off.

Each station should wait a certain delay(up to you) after each packet so other stations can start their transmissions.

A few sketches of the communication patterns show that this is sufficient for your needs.

Now if it's a master-slave-style system as long as you only have one network it should be easier since there should only be one outstanding request that would involve a slave transmitting.

nanofarad
  • 40,330
  • 4
  • 86
  • 117
1

Those will be by far the cheapest method. As for the best method, there are a variety of choices much better, but more expensive. A network of Xbee modules comes to mind, but those are much more expensive than $1.25 a pair.

Using the RF modules is very do-able however. To prevent communication overlapping, put a RF transmitter and receiver on each sensor node and the main hub. The main hub can send "hey sensor1 give me your data", which gets broadcasted to all of the sensors. However, only sensor1 will realize "hey I am sensor 1, here is my data" which the hub will listen for. Then, the hub will go on and say "hey sensor2 send me your data" and so on and so forth.

user2461391
  • 1,433
  • 3
  • 16
  • 26
1

I think your original approach may be best. The approach of putting a Tx and Rx on every device may be affordable, but I question if it will work. With 20 devices transmitting on the same frequency, which one will the receiver "hear". Most important, how will a device receive any remote transmitter's signal when its own transmitter is very close? Keep in mind: these are AM radios and will "send" a carrier even if not sending any data. Get a small number of transmitters before trying to go full scale.

To avoid the problem of receiving the one active transmitter among the soup of inactive transmitters, you want only 1 transmitter powered at 1 time. You would control Vcc to one transmitter, turn it on, send the burst of data, and then power it off.

-How can I prevent communication overlapping?

You can't -- you have to accept that there will be occasional overlaps. Add a CRC to the transmitted data so that the receiver can detect garbage.

The timing of the multiple transmitters is surely a project in itself. You surely don't want to run them all at the same transmission period. They may not collide at the beginning, but when two devices did drift together and start colliding, they would stay together and collide for a long time, until the clocks drifted apart.

I would start with something simple. For example with three devices, run the transmissions at 2000 ms, 2200 ms, 2400 ms period (use EEPROM to configure). That way, if a pair happens to collide at one data point, then next transmissions that pair will be 200 ms apart.

jdr5ca
  • 2,809
  • 14
  • 25