GPS performance issues on GTA02v5

Werner Almesberger werner at openmoko.org
Thu Apr 24 23:03:05 CEST 2008


Daniel Willmann wrote:
> provide one periodically. The reason I mention this is that when
> loading the data we need to set the time pretty accurately and that
> might pose a problem. Not sure about that yet.

We discussed this a bit on IRC. The problem you described was that
you need a sub-second resolution but our RTC only ticks in seconds.

There are many ways to work around this problem:

First of all, you need to know the offset the RTC's seconds have with
respect to GPS time. You can do this by waiting for the RTC tick (e.g.,
by setting an alarm, so you get an interrupt), then you retrieve the
exact time from GPS. If the RTC says, say, 17:55:37 and GPS says
17:55:38.347863, then you know that, when the RTC second changes,
tGPS = tRTC + 1347863us.

The unknown here is the time it takes to get the time from GPS. If you
can send an interrupt to latch the current time, that would be perfect.
In the worst case, you'd have GPS "push" the time, e.g., by asserting
some signal. (Note: I haven't looked at the mechanisms u-blox use. I'm
just assuming they have something that actually works, and the code
below is to illustrate some concepts that can be applied in a variety
of scenarios.)

In this case, you could use a precise hardware timer (counter) or
a calibrated loop to measure time on the CPU side with sub-second
granularity. Your code would look like this:

	t_rtc_s = read_rtc();
	set_alarm(t_rtc+1);
	wait_for_interrupt(rtc_interrupt);
	/*
	 * race conditions:
	 * - RTC ticks between read_rtc() and set_alarm(), so we
	 *   never get an interrupt
	 * - RTC ticks between set_alarm() and wait_for_interrupt(),
	 *   so we may get a slightly longer delay
	 */

	set_hw_timer(0);

	ask_gps_for_time();

	wait_for_interrupt(gps_interrupt);

	delta_us = get_hw_timer_microseconds();

	t_gps_us = read_gps_time_from_queue();

	t_rtc_offset = t_rtc_s*1000000+delta_us-t_gps_us;

The corresponding code for setting the GPS time from the CPU is left
as an exercise ;-)

> I understand the implications, but I prefer we look into it instead of
> just sticking our head in the sand and waiting for the problem to go
> away.

Oh, absolutely. I was referring to the suggestion of adding a battery
for GPS, not to debugging the sensitivity issues. The latter is
definitely something that's important.

- Werner



More information about the openmoko-devel mailing list