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
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