[ntp:questions] garmin 18x and linux

Rob nomail at example.com
Mon Sep 5 17:26:03 UTC 2011

Chris Albertson <albertson.chris at gmail.com> wrote:
> The cause?   My theory is that it can't be in the GPS data.  It is
> where then the computed location would "Bounce" over a two kilometer
> circle.  I think the error is in the conversion of internal data to
> ASCII.  This requires many conversions of floating point internal
> numbers to ASCII and in a low-powered micro controller the time to
> convert one number depends on the value of the number.  For example
> let's look at small integers.  To convert "7" to ASCII we first load
> the hex value of ascii zero into a register.  then we scan the bits in
> the number to be converted and add in a power of two (or  not) based
> on if the bit is a one or zero.  In the case of "7" we add 4, 2 and 1.
>   If we convert a "4" we would only add "4".  The variability is much,
> much more with floating point.   Remember the little processor in the
> Garmin is tiny and runs slow.  The thing is designed to run on battery
> power.

I don't think this is the reason.

I think it is this: the processor on the GPS receiver runs a multitasking
operating system.  It runs several tasks to control the hardware, to
extract data from the receiver, to calculate a GPS fix based on that
data, to calculate NMEA messages, and to send them to the serial line.

There is no hard synchronization between those tasks, each task just
sees what work it can do and then sleeps for some time.  The rate at
which the tasks sleep and wakeup determines a jitter that occurs between
the calculated fix and the emitted messages.

(emitting the messages probably also isn't the highest priority for
the receiver's operating system)

The processor in a GPS receiver usually is a quite powerful 32-bit
embedded processor, that could do binary-ascii conversions much quicker
than the datarate of the serial port.

More information about the questions mailing list