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.
Glad it's been found! Things are pretty warm down here in Boston so I won't need it for a few months but pass it onto Severine if you get a chance (I'll be going to Hudson at some point). Otherwise, the Adirondacks were beautiful and I may just get up in your parts again this summer - maybe I could pick it up then?
If we get around to winter and we still haven't passed it back maybe I'll humbly request a mailing!
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...
@Ben: I've included some extra explanations in the preparation steps of our build process. Feel free to write any critiques here or edit/reword as you see fit. And let me know if you have more questions or ideas of things that could still need explaining (just make sure it's not already on the to-do list at the bottom of the page)
Also, I've running Fido with a logic shifter currently and the communication runs a lot more reliably now. I will be running Fido all week and will hopefully have a fairly stable program ready for this weekend!
Awesome RJ - I like the questions!
What is the biggest challenge you are currently facing with the current Fido design?
Now that the code has been slimmed down to actually fit onto the Arduino, my biggest challenge is the cell phone. The Arduino and the cellphone talk at different voltages and I think that that is the origin of the current inconsistencies in behavior.
What do you think your next two steps will be developing the design for Fido?
Currently, a voltage divider brings the Arduino's 5V down to 3.3V. This does the trick but I think makes the device very fickle. I am going to try to do the same connection with a chip called a logic shifter instead and see if that resolves the issue. If it fails, then I'll know that there is a fundamental issue in the library I wrote for the cell phone and I will try tweaking that again
Comments
Clock Speed
Woohoo!
There are still some
triangulatetrilaterate. 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...@Ben: I've included some
Developer Questions