Prev: CfP: Workshop on Isolation and Integration for Dependable Systems (IIDS)
Next: %%% top 10 Lovely place for Lovers %%%%
From: Jim Stewart on 16 Feb 2010 12:59 rickman wrote: > $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. Years and years ago SGS published a booklet that explained in detail how to write the firmware to drive their GPS frontend chips and decode the data. It was very interesting reading but alas, I lost my copy. Anyone seen a pdf version around?
From: dbd on 16 Feb 2010 13:05 On Feb 15, 7:29 am, 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. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com To improve accuracy by averaging you need to average over samples with independent errors. With GPS that can require collecting samples over a long enough period to collect from different sets of satellites in view. How many years did you plot? If you have the time you can measure continental drift: http://sideshow.jpl.nasa.gov/mbh/series.html For an example plot see: http://sideshow.jpl.nasa.gov/mbh/all/AML5.html Dale B. Dalrymple
From: Vladimir Vassilevsky on 16 Feb 2010 13:13 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. VLV
From: Paul Keinanen on 16 Feb 2010 15:16 On Tue, 16 Feb 2010 13:52:30 +0100, "Boudewijn Dijkstra" <sp4mtr4p.boudewijn(a)indes.com> wrote: >Op Mon, 15 Feb 2010 19:22:25 +0100 schreef Paul Keinanen <keinanen(a)sci.fi>: >> On Mon, 15 Feb 2010 04:13:09 -0800 (PST), Surinder Singh >> <gogreenmiles(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.
From: Paul Keinanen on 16 Feb 2010 15:34
On Tue, 16 Feb 2010 12:13:54 -0600, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >linnix wrote: > >> On Feb 15, 7:27 pm, rickman <gnu...(a)gmail.com> wrote: >> >> 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. 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. |