Standard Precision Service (SPS) for GPS is open to the general public
and all information related to it should be unclassified, although some
is For Official Use Only (FOUO). Pres Bill Clinton made a Presidential
Decree, when he was in office, that gave undiluted precision of SPS to
the public. SPS is presented in C/A code, which is a pseudo-random
code, on the L1 band and is separate from military & Precise Position
Service (PPS). As long as only SPS and C/A code is used there
/*should*/ be no problem.
The only possible hang-up I can think of is there /*may*/ be a rule that
imposes an altitude that consumer gps devices must fail to output
positioning data above... but I can't remember. Also a copy of the C/A
code or the design of the Feedback Registers that generate the C/A code
would have to be obtained. That should be public information though.
Any GPS radio used should probably be able to also receive on the L2
band, in case we decide to try and implement our own tropospheric
compensation algorithms to improve precision. That isn't too big a deal
though, because nav & almanac data would be good enough for most cases.
-Jeremiah
Kyle Bassett wrote:
Curiosity prevails:
I do see a few benefits to a device which is just a GPS radio, like
what Ian has stated. Would their be any legal ramifications to a
reverse-engineered open source binary interpreter for the GPS radio?
I saw a few people mention government concerns with having access to a
very accurate GPS device, but what about Global Locate's license
agreement (if any) by using their hardware? I think a "GPS radio"
would make an excellent open source project; allowing access to the
specifics of GPS (theory) not available with closed firmware.
I wouldn't mind working on this project.
-Kyle
On Nov 29, 2007 9:46 PM, Ian Stirling <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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.
_______________________________________________
OpenMoko community mailing list
[email protected] <mailto:[email protected]>
http://lists.openmoko.org/mailman/listinfo/community
------------------------------------------------------------------------
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
