Why? Because in your case none of the swimmers are stationery, and even if they were, the orientation of the transceivers relative to the base station would be continuously variable, making the measured RSSI a variable variable, or variable^2.
I glanced over the pdf and got a general idea of what they're doing. Seems like quite an elaborate and complex calculation, and got the idea that the result is just a good guess of the unit's position. Also it seems with so much calibration taking place beforehand, it would only be suitable for transceivers that remain in a fixed location and orientation.
The only way to really know is to try it, but I'd surely place a phone call to TI and try and talk to the guy who wrote that document before I put a lot of time in it.
More thoughts on sonar (wish we knew more of the requirements of your application).
IF you can endure having a device placed at the shoreline, and IF the system only needs to compute distance over a short period of time, like for several minutes, you could do it without having to transmit from the swimmer. Start by having the swimmer near the shore unit at some known distance, and press a button on the swimmer's unit. This would cause the swimmer unit to lock onto the pulses coming from the shore unit and adjust its oscillator to get into sync. You should be able to trim a crystal oscillator to within a few parts per million. Then, as the swimmer gets farther away the pulses from the transmitter will lag your reference by an amount proportional to distance. If you could trim the oscillator to within, say, 5ppm, then after 10 minutes the time difference due to the oscillator error would only be 3 ms, or around 15 feet. 30 feet after 20 minutes.
Mmmmm... you never said if you wanted the SWIMMER to know his distance or the base station to know it. Which is it?
I kinda wish I had an application that needed this. But then again I should have never read BeNom's post - I've got other things to think about and this problem is stealing cycles from my project.
Let me know if I'm completely off track.
Now that I think about it, you could figure out exactly how long an 802.15.4 packet would take by reading the IEEE spec and finding how long it transmits per byte of information. Is that the sort of thing you're looking for? I can look it up and/or point you to that information if that indeed is what you're interested in.
Message Edited by Red Mountain on 2006-08-03 01:19 PM
First, thanks for help!
You are not confused , but my target is to find an efficient and simple way to measure the distanse between 2 trancievers.
I don't have the ZigBee trancievers so I can't do the tests by myself :smileysad:
I want to derive the distance from the equestion: D = C x T.
Where C is a speed of the signal (because we don't live in vacum it won't equel exactly to
speed of light but aprox. it does).
T - is an exact time the signal travels in the air.
I don't sure, but I think that times stated in IEEE 802.15.4 for frames proccecing are only in theory
but maybe you're right, it's worth to check this out...
It's intersting to know what are aprox. values of "parasite time" we are talking about...
I thought of the next method to calculate the real average "parasite time":
By placing 2 trancievers in 2 different places we get 2 equations:
time1 = T1 + "parasite time"
time2 = T2 + "parasite time"
I assume that average "parasite time" is the same and it's make sense because we
we use the same trancievers, the same firmaware and sending the same frames.
To decrease the error one may perform number of such measurements and calculate the average
of the "parasite time".
And now, when I have the "parasite time" I can derive the exact time T that the signal travels in the air,
and from the equation L = C x T we get the axact distance between 2 trancievers...
Sounds very nice in theory...
What do you think?
Unfortunately, I don't have a ZigBee tranciever to test it by myself :smileysad:
