we currently have an outdoor wired sensor network of ~20 nodes separated by 50m -> 300m per node.
one person sits in a vehicle at the start of the line of nodes (coordinator i guess), the other person drives out (for several kilometres, through paddocks) and drops the nodes on the ground.
the data collected is too much to transmit, so we store on the nodes. but currently we control the nodes via cable. lots of cable.
there are two separate things i would like to do with xbees.
initially i’d like to transmit gps data from the second vehicle back to the coordinator vehicle over the nodes, either polled or scheduled, by putting an xbee in each node.
once i’m happy that the xbee network is stable, i’d like to control the nodes directly (ie sleep, start aquiring data etc) via the xbees and get rid of the cable altogether.
we know which xbees are in vehicles. however we have no control of the order of the nodes on the ground.
my first question is if xbees are stable across long, linear arrays. i’m looking at XBee Pro 50mW RPSMA - Series 2 (ZB) for range. does xbee transmission rate drop off with distance? will we get 115kbaud of gps information if the truck is 6km away? (assuming node separation of 300m w/ line of sight between adjacent nodes)
my second question is, if we pre-configure the xbees properly, is it possible to drop nodes on the ground and have them automatically extend the network such that operators do not have to do any configuration?
Easiest answer first - Xbee (either ZigBee or DigiMesh) will happily create and maintain the routes (the hop-path) as you drop the nodes. There is no need to worry about order or preconfigure them.
As for sleeping, ZigBee nodes running in a long linear line like this won’t be able to sleep - they must be fully powered routers. DigiMesh offers sleeping routers, but all nodes need to wake or sleep in sync, plus you won’t get 115kbps sustained throughput if the mesh sleeps.
As for the sustained 115kbps throughput, this will drop as the ‘hops’ increase - simple example; A sees B but not C, B sees A & C, C sees B but not A. As packets move, node B in effect can only offer 1/2 of its throughput to C since it needs clear radio frequency time to ‘repeat’ C’s messages to A, so C needs to shut-up at least 1/2 of the time.
You didn’t mention hills, but my gut feeling is the Xbee will work fine for the ‘dropped nodes’, but you might want to consider a 2nd technology for the vehicle-to-vehicle link. For example Digi has the Xtend line which can travel (line of sight) up to 66km. This way your vehicle-to-vehicle comms has no impact on the node control. Baud rate is 9600 (about 1000 bytes per second), but you probably don’t need all of the GPS data.
There can’t be any direct way to estimate the reduction in bandwidth. Also, if you have 10 nodes you won’t actually have 9 hops from #1 to #10.
Some will get skipped over because likely Node #4 (as example) can hear 1, 2, or even 3 nodes in either direction. The routes won’t fully optimize, meaning you may end up with more hops than required (so 1 talks to 3 which talks to 5 which talks to 6 which talks to 10 despite the fact that maybe 3 could talk to 6 directly).
The Xbee do a kind of carrier-sense before talking, & do a small random backoff if the RF is busy. So they will try to move the packet as soon as the RF is free. You just need to avoid a situation where say your remote vehicle tries to saterate the RF as eventually, nodes will discard packets due to buffers being full. So try to design the system to have 1/2 or 1/3 of the RF free and unused. That’s just a guess on my part.
You might want to invest in an RF sniffer from Ember or another supplier so you can actually see how congested (or not) your RF channels are.