Community Update

Ian Stirling OpenMoko at mauve.plus.com
Fri Nov 30 03:46:17 CET 2007


Doug Sutherland wrote:
> Mikko wrote:
>> 2) Yes, it can make sense not to have a bazillion CPUs on board from
>> various perspectives.
> 
> I evaluated no less than 25 different GPS modules some years ago
> and compared them in all important aspects. Every single one had 
> a microcontroller onboard. I do not agree that it makes any sense
> at all not to choose one of these types. They are down to the size
> of a thumbnail almost. Is the microcontroller a CPU, technically 
> yes, but it's part of the receiver, and you want to do all this fancy
> GUI and not suck the life of the battery from ARM9 usage. It is
> a good thing they ditched that GPS. It is now standard that any 
> GPS module does have a microcontroller inside, most commonly
> some variant of ARM7, super low power, you never deal with 
> any firmware. 

(sorry for the late response)

To clarify why it might be nice - yes there are simplicity benefits
from just using a GPS with a NMEA output (or at least with that as an 
option)

If the existing hardware had an open-source driver (there was some 
progress towards such, but this has stalled since it was announced it 
would not be used in GTA02) then many of these objections go away.

The following is based on preliminary work that has not been completed, 
and due to the lack of work on the current GPS may never be.

The device is basically only a software radio, that does the absolute 
minimum to enable the host to avoid having to do hard-real time stuff, 
115200 baud serial is just fine.
As I understand it, the following things are possible, which are 
difficult to do with 'normal' chipsets.

Wakeup once every 3 minutes for 1s, to maintain lock on satellites, 
keeping a reasonable (say 50m) position accuracy, with the GPS totally 
off in the interim. This (with the mobile phone part off) uses a very 
small amount of power, enough to track for around 8 months.

Logging all parameters of the signal that the chip measures in hardware, 
  so that the track can be post-processed for better accuracy.

The option of delaying the output of the signal by 10s+, and being able 
to smooth the output based on the 'future' movement, not just the past. 
(this can dramatically improve tracks round sharp corners)

Being able to feed in information from the accelerometers to go into the 
position solution. (this is mainly useful in cars - the accels give you 
good turn rate info)

Using even 'failed' GPS satellites as position sources, with the aid of 
  AGPS (however, this is unlikely to be of use unless the GPS system 
stops being maintained)

Easy tradeoffs between output noise and update frequency - few devices 
support updates faster than 1Hz.

User-provided AGPS correction information.





More information about the community mailing list