jbd

I believe Louis was indicating that we *could* do positioning without GPS; which is technically correct but not necessarily desirable, and assumes we know exactly where the anchor points (aka base stations) are located. Synchronization of the end points (ear tags) with the anchor point is no longer required since the anchor point will be sending the signal to the end points (ear tags), which will just echo it back; and all timing (with a 700 MHz clock) occurs on the anchor point. However, synchronization of the anchor points will be required for the reasons you pointed out. Since all the anchor points will have GPS's on them, this can be done with reasonable accuracy, and be checked/re-done frequently. Latency in the radio, GPS, and CPU (deterministic and non-deterministic) will have to be empirically determined. And we'll have to re-run the tests with every new batch of processors, CPUs, GPSs and XBees. Sigh.

The differential times are all that's needed from the anchor points to calculate the distances, so it would make the logic/coding a lot easier.

I like the two way transmission idea. The anchor point doesn't have to be quite as fast - but still needs to be able to sense the departure and return times within 300 microseconds. And we can "fake" a signal by wiring the TX to the RX on the ear tag. I too am making the assumption that turn-around time is constant - at least between the XBees. We'll need to empirically test how much latency the mesh network adds too. I'll start looking at a device driver to do this (because it needs to be done at interrupt level to keep the OS from introducing latency). Once I get the driver done and tested, we'll need more beaglebones and XBees to test/write the trilateralization logic. Oh, I guess we'll be needing the GPS interface logic written too. That is critical for translating the "local" positioning info into global positions. So, I guess the real next step is software architecture planning.