Fast Update for GPS Peripherals

IIRC, the standard GPS updaterate with the NMEA protocol is 1Hz. Yes, a bit slow for a cruise missile.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Many vendors support fast update rates, but are much more expensive. Try Novatel for example.

I think the more feasible approach would be to augment the GPS info with inertial measurements for more immediate updates. If you really need that frequency of update, you probably want inertial backup, anyway, for short outages, whatever the reason.

Thad

That would be tough, given that the GPS signal itself only has a repetition rate of 1 Hz, AFAIK. IOW, anything beyond that isn't actual GPS data, but an interpolation, or has to come from some other measurement device. Either way, I'ld object to that being called a GPS peripheral with 64 Hz update rate.

Anyway: if you need it that fast, odds are you won't get it at all unless you're working with/for military applications.

Rough estimate: 3 meters accuracy, 64 Hz rate --> only makes sense at speeds of the order of 3*64=192 meters/second. That's 700 km/h, or, for the metrically impaired, Mach 0.5. Hardly anything non-military going that fast would ever need (or be allowed to rely on) GPS.

Uncle Sam doesn't want other parties to have the opportunity to build GPS controlled cruise missiles. So: challenge your customer what he thinks he needs this for.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

is as

only

[FWIW, I

I fully agree and have done that several times in the past, but for the aircraft on which this will fly there is no INS and they're quite expensive Norm

It has already been pointed out that higher rates will really be interpolated data. That said some vendors have models with docs that say that you can custom program their onboard ARM processor. I have not seen any more details on how much information they give you to add custom software to their system, but presumably you could do interpolation to estimate data at faster rates. Their are also inertial enhancement devices that connect to a GPS to provide more accurate data and projections when the GPS signal is unobtainable. So you have a couple of options at least.

Best Wishes

Looking at the normal C/A GPS signal, it is hard for me to figure out any 1 Hz repetition rate from it.

The actual navigational data message is flowing down at 50 bit/s, each word consisting of 30 bits, a sub frame consists of 10 words and a full frame of five sub frames. I don't find any 1 s repetition rate in these figures.

Since the satellite broadcasts the ephemerid of that particular satellite only every 30 s, of course the receiver must interpolate the position of the _satellite_ for any moment of time. Fortunately, the satellite moves in quite predictable orbits, so this is not a big issue :-).

However, the location of the receiver is determined by determine the distance to at least 4 satellites (with low quality receiver clock) using the code pseudo range. This is based on the 1023 bit PRN sequence, which repeats once every 1 ms.

I guess you should be able to get 1000 code pseudo range readings each second, but apparently several readings are integrated to reduce the error. Tracking the PRN is an other issue, if the distance changes very fast.

Apparently the 1 s update cycle in most systems is due to computational power and hence power consumption issues, since you have to track at least 4 satellites and most receivers also track up to 12 satellites for fast switch over. Also many applications are satisfied with the 1 PPS pulse outputs, so why calculate the position solution more frequently.

Paul

Standard issue cruise missiles do not have 19" rack space.. ;-)

Rob

I've

expensive

How about the MT9 3D motion sensor:

Pricing isn't too bad if you consider the uplift on anything to do with aircraft applications.

Rob

On Mon, 03 May 2004 18:19:56 GMT, Norm Dresner wrote: : I need to construct a system (more-or-less embedded even though it'll : actually be a rack-mounted PC) with a GPS peripheral whose update rate is as : fast as possible -- ideally the customer would like >64Hz. So far I've only : found one manufacturer whose devices go up to 4 Hz, not quite what the : customer (feels he) needs. Are there others which update faster? [FWIW, I : could probably "sell" a 16 Hz or so rate if I could find one].

The company formerly known as ashtech has or had not overly high priced boards with 10hz rates off the shelf.

vectors to the successor company's site.

...

I am not familiar with the market, but expect that if your have frequent updates of the GPS information as a base, you can use less-precision (less-expensive) inertial sensors since the deltas will be small.

Thad

But the positions of a [moderate speed] vehicle sampled at a 64 Hz rate contain _very_ highly correlated data.

Norm

The GPS satellites move at several km/s causing a large change in the code pseudo range and also in the doppler of the received signal. If the receiver also moves in _linear_ motion below a few Machs, that should not be to hard to compensate in the tracking loop, since you have to compensate for the satellite movement anyway.

The C/A signal chip rate is 1.023 MHz, so the signal propagates about

300 m during a single chip. Now it is a question of how accurately the edges of this chip clock can be detected in a low SNR environment and thus, how accurate the fix is. With a fast update rate, only a few samples can be integrated in (Kalman etc.) filters to average out random errors.

Now the question is, what the OP is trying to do with the 64 Hz update rate. Since consecutive position readings have quite a lot of error, trying to calculate the speed from the position differences between two consecutive samples would produce a highly varying speed and direction reading and trying to calculate accelerations from these speed readings would be quite hopeless.

If the main interest is speed reading, why not use the speeds relative to each satellite directly. Due to this speed, there is going to be a doppler shift in the frequency of the received RF signal (as well as on the chip clock rate). Compensating for the orbital movement of each satellite, the relative motion can be determined directly, without going through the position differences.

If the receiver sends out in addition to the calculated position also the raw pseudo ranges to each satellite and the speed relative to each satellite, this might be a better approach to get the speed and acceleration than trying to get the position reports at a high update rate.

Paul

"Norm Dresner" wrote in news:g3wlc.28181$ snipped-for-privacy@bgtnsc04-news.ops.worldnet.att.net:

Check

They advertize download of raw data as often as you like, only limited by the serial port throughput.

Sam