An interesting related approach to open source remote sensing and high resolution geolocation, precision ag. The presentations from their ISOBlue day are a really nice walk through of their work.
http://www.isoblue.org/
Just received the equipment for the SARE part of this project, and discovered that the BeagleBone Black is nice and fast, but its serial port interface is completely different from the older version (the BeagleBone "white").
So now I have to spend extra time researching how to access the ports and rewriting the device interface for the XBee's. Sigh.
Then I can make the changes to the serial device driver that will capture the times the data transfers took place.
This project has received SARE 2014 funding under the name of "Livestock tracking system". We are hoping this will give us enough resources to produce a working prototype before 2015.
Some references used in this project are:
I've empirically determined that one has to use RTS/CTS flow control with the GPS module - it simply produces data faster than the Beaglebone can process it.
This just means that we'll be using more pins. And with the Beaglebone's multiplexed I/O system, it could mean that the processor spends more time handling the device than running the application software. However, this will need more testing to be sure.
With ever more detailed reading of the XBee specifications, I've determined that we can't get the address of the ear tag without using the API mode of the XBee. Further reading leads me to believe that each XBee has to be pre-configured to use either the API mode or the direct mode. The default (from the factory) is the direct mode, and it seems the API mode can only be enabled by using Digi's xctu utility to upload the correct firmware to the XBee.
This adds additional complexity to the project and requires a MS-Windows system to run the xctu utility.
It looks like the version of Angstrom that is on the prototype does not have a real-time scheduler. This means that things like cron jobs, page swapping, ... could interfere with proper detection of time-of-flight. So its beginning to look like we need to use statistical analysis instead of measurement of a few samples. This means longer times to deduce the distance of an animal (I'm hoping just a few seconds), and more battery drain (since we have to send a bunch of transmissions instead of one or two).
And, sigh, statistics isn't my strong point.
Here are some kids report on using the technique we were talking about. Resolution 5 meters. Not what we want. But read the discussion after the article.
I've been reading the Zigbee spec sheets and it looks like the mesh networking will be introducing too much latency for accurate speed-of-light measurements between the anchor points and the ear tags. For now, we'll "turn it off" by simply not having any router nodes in the network. For security reasons, we need to be able to turn off mesh networking entirely.
My origninal thoughts about locating cattle, etc. were to use the method we use for locating underwater devices: triangulation of three angles derived from the phase relationships of signals sent from the tracked object to three (or more) base stations. This method is in contrast to JBD's method of calculating position by the tracked object of time differences of signals sent from the base stations. The time difference (again using phase relationships) give distances. Three distances (like three angles) from base stations with known positions will give a location.