By Louis on
Topic Type
Event

This system will track objects like cattle, tractors and equipment on the farm. But it is more than just a tracker option. It can monitor activity and be used to transmit sensor data about the objects being tracked. The technology includes 3 moveable GPS anchor points which communcate with Beaglebone ARM 8 devices which are also Zigbee enabled. In the overlap of these three Zigbee ranges, any number of Zigbee nodes can roam and periodically emit a message; distance can be calculated based on Time Difference of Arrival; that is, the difference in arrival time to the three nodes can uniquely determine a location.

Finally, there will be a Gateway (also Beaglebone, possibly one of those anchors) which will be the Gateway; that is, it is the relay between the local Zigbee network and the Internet. The most straightforward method is to have the Gateway attached to your home network, but 3G options also be possible. A web front end will be used to filter and analyse appropriate and useful data.

People: Bruce Dawson, Carole Soule, Louis Thiery

Forums
Farm Hack Intervale / Essex 2012 - Vermont and New York
Forum comment

There should be a minimum of 3 anchor points; more are allowed for scaling up. The three anchor points provide for triangulation to determine the location of "slaves". The radio technology being used is likely to be [Zigbee](http://www.zigbee.org) (because it is more tolerant of errors; albeit with lower bandwidth than wifi or cellular). The "slaves" (need a better word) are also zigbee enabled and can communicate with the anchor points to transfer data (such as location, attached peripherals, internal data). The anchor points can be BeagleBone devices, which can use an Internet connection to communicate with and "optional" central server. That Internet connection can be (for example) Wifi, LAN, 4G, ...
Forum comment

There was some talk about the difficulty determining distance within this network. If there is triangulation from three known points it is direction and not distance that's needed to calculate position. How could this be achieved?
Forum comment

There are still some logistical questions that need to be resolved but, insofar as I can tell, the general theory works. Let me know if you foresee any problems. You have three reference nodes which GPS transmitters, thus you know their distance and direction from each other. Each of these reference nodes is also ZigBee enabled up to a certain range; the overlap of these three ranges is where we can accurately triangulate trilaterate. Any slave node roaming within the overlap of three node ranges emits a message and the distance can be calculated based on [Time Difference of Arrival](http://en.wikipedia.org/wiki/Multilateration); that is, the difference in arrive time to the three nodes can uniquely determine a location. I'm not sure where direction may become an issue...
Forum comment

I don't know much about how location is figured within a wireless network, I'm going to check out your link. I'm coming from a sailing background where we take a compass bearing from 2, or better 3, objects like water towers or light houses. By plotting these angles onto a chart from their known position, (it's marked on the chart) you can fix your position by finding where these lines meet. I guess that's where I'm coming from in thinking that triangulation has to do with compass direction and not distance.
Forum comment

Interesting read. So time of flight is based on trilateration and not triangulation. If a method of triangulation could be figured out, would this overcome the processor speed issues?
Forum comment

Thank you for the semantic check there! Trilateration is indeed the correct term. I imagine that triangulation might be able to get figured out but I have a hunch that we may sacrifice range by doing that. Insofar as the clock limits, let's say we want to be accurate within 1m. Since the speed of light is 3x10^8 m/s, we need a clock of 3x10^8 Hz, or 300 Mhz (I think?). The Beaglebone has a 720Mhz processor and that should work and hopefully we'll be able to utilize the full accuracy of that clock (I've never tried measuring how fast radio signals travel and haven't done all my research yet). I imagine that there will be some constants involved with sending and receiving a message before we can put a time stamp on it but I think that they can be calibrated those out since those will always be the same with the same hardware.
Forum comment

We can always transmit the data we get from the radios on the mobile units, upload it to the anchor points, and let a server do the computations. Supposedly the anchors are fixed positions (and may be GPS enabled). However, as I remember my radio theory, we will need a number of samples to get a reasonable approximation to use in differential distance computation to the anchor points. Each radio will have to be calibrated to determine what its "reasonable sample rate" would be. Or does the Zigbee already do this? (does it provide a signal strength, or do we have to get the analog strengths in real-time)? Or am I thinking too deeply?
Forum comment

Processor speed is a concern not for computational reasons but for timing - we need the difference in time of flight for the radio waves which travel at the speed of light so we need a fast enough clock for whatever accuracy we want. I think that once this type of system is established, it will give much more accurate and reliable readings then the other method we discussed. The other method, which I believe you are referring to, is to simply read the signal strength (already built into Zigbee) and extrapolate from there but as we discussed the other weekend, analog signals are noisy and this one in particular has many different variables affecting it other than distance. I think that it would be a quick and easy way to get ball park estimates but would be difficult to get very precise.
Forum comment

I purchased two XBee's, a beaglebone and their various accessories for development. Two XBee's are required to check the timing algorithm between a "cow" and one of the anchor points, one of the XBee's will be on the beaglebone (acting as an anchor point with a GPS), and another will be on my laptop/workstation (acting as a cow). At this stage of development, we're only concerned with getting the various components checked out and writing any low-end software required to interact with the hardware components. I've looked at the XBee specs, and although the power requirements for the Series 2 are in line with our needs, I suspect we'll need to add a high-resolution clock to the XBee to get sufficient accuracy in distance measurement. And I'm really concerned about weight and power draw - don't forget, these things have to be small enough to fit on an ear tag or (at most) a collar. I've got the GPS on backorder.
Forum comment

The GPS has arrived and I verified its operation on the beaglebone. Also, Ben Smith (from CCOM at UNH, and an old sailing buddy) has joined the project and briefed me on the PPS (Pulse Per Second) signal provided by most GPS's. Since, to keep cost of the "roving radios" down, we won't have much computational ability on the rovers (if any); rovers == cattle ear tags. I've noted that the chronodot has something similar to the PPS, but I don't know if it is tied to the "start of the second" like it is on most GPS devices. Iif it is, and if it gives us sufficient accuracy, then we can use it for sub-meter accuracy. (I'd really like to have 1-inch accuracy, but I'm willing to give up on that somewhat.) The chronodot is low power and relatively temperature insensitive, and we can probably get it to shut down every few seconds to improve the power consumption. I think the next steps are: 1. Prototype an "ear tag" rover with an XBee, battery, and chronodot. 2. Verify the rover can talk, over the XBee, to an anchor (Beaglebone with GPS and XBee).
Forum comment

Finally found some specs, and it looks like the oscillator on the Chronodot is only 23.768KHz. I believe we'll need at least 300MHz for 1 meter accuracy. So, even if the SQW on the Chronodot (a.k.a. Maxim DS3232) rises at the start of a second, it won't be accurate enough for us. Sigh.