Community Update

[Jeremiah Flerchinger]

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 <OpenMoko at mauve.plus.com 
> <mailto:OpenMoko at mauve.plus.com>> 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
>     community at lists.openmoko.org <mailto:community at lists.openmoko.org>
>     http://lists.openmoko.org/mailman/listinfo/community
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20071130/ff745720/attachment.htm