So, what you’re saying is the concept is valid but implementation is going to be a bitch! 
Good luck, Bob!
Plan B: Attach a tape measure between the master and children and let the master “read” the distance
Here’s and interesting project for indoor location mapping using radio and ultrasound.
A company i work for is about to implement an indoor location system with an accuracy of 15cm which uses Ultra Wide Band radio using trilateration, time of flight etc which as noted before requires something with a wee bit more speed than C# can achieve.
I do know that some PICs clam to be able to measure pulse lengths with 1ns resolution. They charge a capacitor for the length of time you want to measure, then they measure the voltage that the capacitor charged to.
I have been looking for a fast amplifier circuit so I can try and built a laser range finder with such a PIC, but have not seen anything I can use, and I don’t have access to the type of equipment required to test and validate the amplifier… 
In the end RF/light time of flight range measurement is not to be attempted at home…
@ GMod(Errol) - what about this: Webcam Based DIY Laser Rangefinder - Todd Danko
I recon that can be converted into a Gadgeteer module…
You would get about the same accuracy with a Sharp IR range sensor, which works on the same principle, which does all the hard work for you, and suffers from all the same problems like the fact that you accuracy diminishes logarithmically with range.
@ ransomhall and I are discussing putting together an Ultrasonic module. I know GHI is working on one now as well. I have the HC-SR04 rangefinders [1] working with MakeBread and Extender modules now. I am working on a servo-driven version as well to pan and give you more than one distance reading from the same sensor - this would also reduce the number of sensors required to do any spread distance and could potentially give you a 3d view of distance using two sensors on the same plane. Check out this thread [2] where someone turned a sensor into a “1 pixel camera” to do 3d mapping - wouldn’t work real time due to the number of pixels it has to capture and render.
I’ve been looking into IR as well, but more for motion detection that distance detection.
For my rovers, I’m planning on using GPS positioning, wheel encoders and optional RFID markers to get “known” points to calculate how far they are away from the corners of the area they are programmed to roam in and the IR to keep them from running into dogs, kids and other rovers. I had thought about trying to use Bluetooth, cell tower or WiFi triangulation but can’t rely on those in all cases and it also drastically increases the price of each rover. Ultrasonic sensors are 8-15 each, so you can easily have 4-5 of those for the price of the cheapest of those 3 modules.
[1] http://www.amazon.com/Onite-HC-SR04-Ultrasonic-Distance-Arduino/dp/B0085MXZH0/ref=sr_1_2?rps=1&ie=UTF8&qid=1344797144&sr=8-2&keywords=HC-SR04
[2] doh, I can’t find it - will update the link as soon as I can locate it again
Oh, and for sound defintely since it is slower, light/radio don’t have as much affect since they are faster, you also need to feed in the ambient air temperature to get a more precise reading.
From your description Bob, sounds like you may be doing some sort of aerial swarm “programming”, so don’t know that you would have access to know RFID points on terra firma or wheel encoders.
Either way, be interested to find out more and definitely help out if I can.
First let me say thank you for the great dialog and advice. I have learned a lot and enjoyed the reading! You have seriously influenced my thinking. Based upon the dialog, I would like to propose the following revised solution for your comments.
The combination of Gadgeteer C# overhead and RTC accuracy makes it impossible to accurately measure distances of less than 20 feet between two devices. However, due to cost, time, and labor constraints, the revised approach is to use off-the-shelf Gadgeteer technology to measure total response times for a sufficiently large set of pings sent between two devices. The ping sets would be designed to have a typical response time of less than a second, and measured using the RTC. This would provide a measure of proximity/distance.
This approach is at the sacrifice of increasing the total time it takes for one device to ping the other six devices. For instance, if each ping set takes about 0.5 seconds it would take 3 seconds to poll all six devices. This also means it becomes necessary for each device to be able to autonomously initiate a set of pings to six devices, as well as concurrently managing multiple devices sending pings of their own. Using autonomous interaction the entire network of seven devices can complete their computations within 3 seconds. This important if the system is to retain sense of real-time autonomous device reactions.
This approach also eliminates the need for IR technology, RTC synchronization, and the concern for system overhead. The system overhead (C#, RTC, pings) is basically the same for all devices, and is simply included as part of the total response time. It also allows for expansion of the number of devices within the system.
pings using what off-the-shelf Gadgeteer technology? Network pings over WiFi? Ultrasonic “pings”?
It’s a non-starter. You can’t measure accurately enough with these devices (even in native code…) to work with radio or light. Multiplying your “pings” will simply multiply your error. Your signal-to-noise ratio here (where signal is the travel time, and noise is the uncertain parts, processing time, GC delays, BT module latency, retransmits because of collisions, etc) is so extremely low, that all you will get is a giant pile of frustration.
1 Like
Bob, I suspect the answer is no but is it an option to have en external camera array do the coordinating? This is how the swarms of quadcopters are usually coordinated. You would need a high power PC to handle the image analysis but if your devices are in a constrained area then this could be your best option.
For those that are interested, here’s a google calculator link that gives the time scales we’re dealing with here:
Yes, we’re talking round-trip travel times on the order of 0.04 MILLIONTHS of a second for a 20-foot distance.
1 Like
Or 40 Billionths of a second… 
Which isn’t very long…
I’ve used the Grove Ultrasonic RangeFinder http://www.seeedstudio.com/depot/grove-ultrasonic-ranger-p-960.html?cPath=144_149 with the Grove Expansion Module http://www.seeedstudio.com/depot/grove-expansion-net-gadgeteer-compatible-p-1084.html?cPath=203 but @ stevepresley I’d much rather have a native UltraSonic Gadgeteer module so I’m very interested in your proposed module as I am in just about any new module including IR modules.
Almost as fast as Usane Bolt 
1 Like
First I should explain this is a sophisticated Hobby level exercise. It is not a major R&D effort for a customer. I am not trying to knock down aircraft traveling at Mach 2 using Fast Fourier Transforms (-;
I am talking about using Bluetooth to send a set of pings from one device to another. A RTC start time would be obtained at the beginning and a RTC end time would be obtained at the end of the set. The difference would be the Total Response Time. So the accuracy is a function of the sample size. For purposes of illustration, lets assume the set of pings was designed to take took 60 seconds on average. Therefore, some might take 50 seconds and some might take 70 seconds. These times would allow the system to determine the relative promimity of one device to another. One is 70 seconds away and the other is 50 seconds away. I dont understand why the Total Response Time would not be sufficient to measure the relative promimity of one device to another? Of course, I am suggesting that the actual sample size be designed to have an average Total Response Times of 1 maybe 2 seconds. It would seem this set of pings will contain a large enough sampe size to come up a useable result for this project. Any “out of bounds” pings could be accounted for.
@ stevepresley -
Steve, the pings would simply be Bluetooth message betwen two devices.
Maybe we’re beating a dead horse here, but I think everyone is going to reply back that using light/radio waves (i.e. BlueTooth) to get that kind of accuracy isn’t feasible with the processing available. Unless you switch to ultrasonic, just don’t see it happening with this platform.