measuring 10 km with 1m accuracy
in [Embedded]
|
Prev: CfP: Workshop on Isolation and Integration for Dependable Systems (IIDS)
Next: %%% top 10 Lovely place for Lovers %%%%
From: Paul Keinanen on 17 Feb 2010 02:40 On Tue, 16 Feb 2010 17:17:38 -0800 (PST), rickman <gnuarm(a)gmail.com> wrote: >On Feb 16, 3:16�pm, Paul Keinanen <keina...(a)sci.fi> wrote: >> On Tue, 16 Feb 2010 13:52:30 +0100, "Boudewijn Dijkstra" >> >> >> >> <sp4mtr4p.boudew...(a)indes.com> wrote: >> >Op Mon, 15 Feb 2010 19:22:25 +0100 schreef Paul Keinanen <keina...(a)sci.fi>: >> >> On Mon, 15 Feb 2010 04:13:09 -0800 (PST), Surinder Singh >> >> <gogreenmi...(a)gmail.com> wrote: >> >> >>> What would be best technology (GPS,IR,Radio/freq,ultrasonic etc) for >> >>> doing distance measurements upto 10km with accuracy of 1 meter? >> >> >> So the accuracy requirement is 100 ppm. >> >> >> Is this measurement in vacuum or in the atmosphere and if so, what is >> >> the refractive index during the measurement. Any mirages ? >> >> >> Even when using lasers or some microwave measuring devices, the >> >> propagation in typical atmospheric conditions will bend the beam >> >> slightly downwards, thus forming an arc and thus the reading would >> >> also be slightly too big. >> >> >Unless you would compensate for this predictable effect. >> >> >> The speed of light is about 300 ppm lower at sea level than in vacuum, >> >> so also the elevation and hence air density will affect the speed of >> >> light and this may also cause errors. >> >> >Unless you would compensate for this predictable effect. >> >> Perfectly true, if you do temperature and humidity measurements along >> the path to determine the refractive coefficient. >> >> Unfortunately, in practice, this is the hard part. > >The total effect from vacuum to sea level air is 300 ppm you say. So >how much is it going to vary at sea level. I think the OP required >100 ppm accuracy, no? I wouldn't expect the 300 ppm effect to vary >more than 10, 20, maybe 30 ppm. Do you disagree? > >Rick On average, the drop in refractive index is about 40 ppm/km, but when you are seeing mirages, the drop is more than 157 ppm/km. Thus, on average, staying below 2.5 km and the error budget will be acceptable, however, even on ground level, the error margin of 100 ppm could be exceeded in special climatological conditions.
From: Mark Borgerson on 17 Feb 2010 11:12 In article <EsednVC4aJDCfefWnZ2dnUVZ_uSdnZ2d(a)giganews.com>, nospam(a)nowhere.com says... > > > linnix wrote: > > > On Feb 15, 7:27 pm, rickman <gnu...(a)gmail.com> wrote: > > > >>On Feb 15, 3:12 pm, Tim Wescott <t...(a)seemywebsite.com> wrote: > >> > >> > >> > >> > >>>On Mon, 15 Feb 2010 11:26:06 -0800, rickman wrote: > >>> > >>>>On Feb 15, 2:07 pm, Jim Stewart <jstew...(a)jkmicro.com> wrote: > >>>> > >>>>>Paul Keinanen wrote: > >>>>> > >>>>>>On Mon, 15 Feb 2010 09:29:10 -0600, Vladimir Vassilevsky > >>>>>><nos...(a)nowhere.com> wrote: > >> > >>>>>>>While ago I did a plot of a common GPS module readings taken at > >>>>>>>every second. The distribution was clearly not Gaussian; it was > >>>>>>>asymmetrical and skewed. I am not sure if it would be possible to > >>>>>>>improve the accuracy by averaging and how much of averaging it would > >>>>>>>take. > >> > >>>>>>How did the displayed elevation behave ? > >> > >>>>>>If it is violently jumping up and down, this may be a symptom of a > >>>>>>ground reflection., i.e. the distance to one (or more) satellites > >>>>>>would appear to bee too large, i.e. going through the ground > >>>>>>reflection. > >> > >>>>>Does this really happen or are you speculating? No disrespect intended, > >>>>>I've just never heard of this issue. > >> > >>> -- snip -- > >>> > >>>>A GPS works by measuring the time of flight from the visible satellites > >>>>and triangulating. Clearly if one or more measurements are off because > >>>>of reflections, it will mess up the results. I don't know how they > >>>>compensate for this, or if they even do. > >> > >>>I suspect that the cheap handheld units don't -- the cost of the logic > >>>would go up as something like N^1 or N^2 as the size of the time window > >>>increased, and to catch a reflection you need a time window big enough to > >>>see it and the 'correct' signal, or you need a multiplicity of receive > >>>channels. > >> > >>>>I would think they would toss > >>>>out one or two outliers if they had more than half a dozen or so > >>>>satellites in view. > >> > >>>One hopes. But a $150 GPS receiver is a pretty amazing exercise in cost > >>>reduction already -- I wouldn't count on it. > >> > >>>>I think it takes a minimum of 4 to get a 3D fix and > >>>>the more measurements included in the calculations, the better the > >>>>result... as long as they are not reflections. > >> > >>>Yes. The receiver has to solve for three spatial dimensions and time. > >>>Solving those four equations demands four unknowns. Height is generally > >>>known to a much lesser accuracy than horizontal position, because the > >>>slant angle to the satellites is often quite shallow, which makes it > >>>harder to resolve height. > >> > >>>--www.wescottdesign.com > >> > >>$150? I have $50 bluetooth GPS and I have seen $25 GPS modules that > >>use nothing more than an ARM7 to do the actual calculations for a > >>fix. I can't imagine that it would take a significantly more > >>expensive CPU to do the culling of outliers. In fact, one of the > >>vendors we considered supported the sharing of the CPU to run > >>application code potentially saving an MCU in an application. That > >>shows even in a little ol' ARM7 there are CPU cycles to spare. > >> > >>But then I don't know diddly about the actual calculations being > >>done. So I can's say for sure. > >> > >>Rick > > > > > > Just convolutions and trigonometry. Nothing heavy. 10 to 20MIPS > > should work. > > The initial solution of the GPS system of equations starting from zero > knowledge requires a lot of number crunching. It could take several > minutes on the 10 MIPS machine without FPU. > With no initial information, the GPS set also has to receive enough almanac data to get information on the visible satellites. IIRC, it can take up to 20 minutes for the full almanac transmission. Mark Borgerson
From: rickman on 17 Feb 2010 19:35 On Feb 17, 1:47 am, Paul Keinanen <keina...(a)sci.fi> wrote: > On Tue, 16 Feb 2010 17:19:57 -0800 (PST), rickman <gnu...(a)gmail.com> > wrote: > > >On Feb 16, 3:34 pm, Paul Keinanen <keina...(a)sci.fi> wrote: > >> While I understand that in the old days, in the worst case, it takes > >> quite a long time (several minutes) for a single channel GPS receiver > >> to try out all the 32 PRN sequences in order to lock into at least > >> _one_ GPS satellite and then wait until the whole GPS satellite > >> constellation _almanac_ has been downloaded and after that, lock into > >> at least 4 satellites to get the fix. > > >> However, these days, with a multichannel receivers, each "receiver" > >> can search for a specific satellite PRN sequence in parallel and > >> perform the required navigational calculations, without waiting for > >> the satellite almanac. > > >Can you do the calculations without the almanac? Why would the older > >systems require the downloading of the almanac if it isn't required? > > The almanac contains coarse keplerians for all satellites, > sufficiently accurate for determining if a particular satellite is > high enough above the horizon, so it is worth trying to lock into it. > > Once you know which satellites look promising, you also know which > their PRN sequence and it is easier to search for those sequences > only. > > In old single channel receivers, you had to try out all the 1023 > "phase shifted" versions of a specific PRN sequence before lock, which > may take some time. With the almanac, you can narrow the test to those > interesting (above horizon) PRN sequences (satellites), which will > speed up the startup on old receivers. > > The message from an individual message will contain the exact > keplerians for that particular satellite, so the orbit and hence > position of that satellite can be determined exactly for navigation > purposes. > > A modern multichannel receiver will search for all possible PRN > sequences (satellites) in parallel and once four satellite positions > (with sufficiently geometry between each other and sufficiently high > above horizon), the receiver position can be determined exactly. > > The satellite almanac is intended to help old single channel receivers > (dominant when the system was designed) performing a reasonable fast > cold start. My experience with modern GPS receivers is that they often take 10 minutes to get a lock after a full reset which wipes all the satellite information. This is a unit I bought new about 3 years ago with some 16 or 20 channels. I think it may be based on the SiRF III chip. So it appears that searching for *all* possible PRN sequences is still not common. Am I wrong? Or do you have a different definition of "modern"? Rick
From: Tauno Voipio on 18 Feb 2010 02:24 rickman wrote: > > My experience with modern GPS receivers is that they often take 10 > minutes to get a lock after a full reset which wipes all the satellite > information. This is a unit I bought new about 3 years ago with some > 16 or 20 channels. I think it may be based on the SiRF III chip. So > it appears that searching for *all* possible PRN sequences is still > not common. Am I wrong? Or do you have a different definition of > "modern"? The full almanac data cycle is 12,5 minutes, which will be the worst case lock-in time, regardless of the time taken for PRN sequence synchronization. -- Tauno Voipio tauno voipio (at) iki fi
From: Boudewijn Dijkstra on 18 Feb 2010 05:15
Op Wed, 17 Feb 2010 01:00:10 +0100 schreef Andy <jonesandy(a)comcast.net>: > On Feb 15, 3:00 pm, Paul Keinanen <keina...(a)sci.fi> wrote: >> >> Take a look what happens to the elevation display, when you walk below >> a bridge, that obscures at least some of the satellites. > > Walking under a bridge selectively I wonder what it could be like to walk under a bridge unselectively... > also blocks out satelites at higher > angles above the horizon, which as stated earlier, increases the error > in the elevation calculation. Unless you compensate by using data collected from an accelerometer. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail) |