Openmoko - User contributions [en]

Wishlist/BuiltInScriptingLanguage

2007-08-21T17:44:10Z

Shadowjack: /* Feature matrix */

{{Wishlist}}
Many different scripting languages will be optionally available in the repository.
However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.

== Feature matrix ==
Since there are a lot of options, the main features of the candidates should be collected in a matrix.
Fill in and add to this if possible.
{| class="wikitable" style="background:#efefef;" cellspacing="0" cellpadding="3" border="1"
! align="center" |'''Language'''
! align="center" |'''Current Status'''
! align="center" |'''Disk Footprint'''
! align="center" |'''Memory Footprint'''
! align="center" |'''Compilable'''
! align="center" |'''Scriptable'''
|-style="background: #DDFFDD;"
! align="center" |Java
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT / gcj
|align="center" |?
|-
!align="center" |Python
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT(Psyco) / Pyrex
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |C#/mono
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |N
|-
!align="center" |Perl
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|-style="background: #DDFFDD;"
!align="center" |Haskell
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |Y
|align="center" |Y
|-
!align="center" |LUA
|align="center" |?
|align="center" |Light
|align="center" |Light
|align="center" |JIT(Lua-JIT)
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |Ruby
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/Boost/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.
# [http://opensource.nokia.com/projects/pythonfors60/ Example implementation] for Symbian. (whole thing under 600kb)

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

User:Shadowjack

2007-08-18T17:27:06Z

Shadowjack:

Dmitry Platonov

Skills: C, C++, Linux, GPS

Location: Russia, Moscow

User:Shadowjack

2007-08-18T17:26:02Z

Shadowjack:

Dmtiry Platonov

Skills: C, C++, Linux, GPS

Location: Russia, Moscow

User:Shadowjack

2007-08-18T17:25:50Z

Shadowjack:

Dmtiry Platonov
Skills: C, C++, Linux, GPS
Location: Russia, Moscow

Openmoko Local Groups: Moscow

2007-08-18T17:25:09Z

Shadowjack:

=== Possible Participants ===
{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:Shadowjack|Shadowjack]]
|C, C++, Linux, GPS
|High
|Moscow
|
|-
|}

Openmoko Local Groups

2007-08-18T17:22:24Z

Shadowjack: /* EU */

__TOC__
'''OpenMoko Local Groups...'''

* can be used for developers to meet and get to know each other
* can be used for developing
* may provide the room for real-life discussions away from mailinglists/wiki
* can support early support handling their GTA01Bv4 and exchange experiences
* fasten the community's cohesion
* give motivation

== EU ==

* Austria
** [[OpenMoko_Local_Groups: Vienna|Vienna]]

* Belgium
** [[OpenMoko_local_Groups: Antwerp|Antwerp]]

* Denmark
** [[OpenMoko_local_Groups: Copenhagen|Copenhagen]]

* Finland
** [[OpenMoko_Local_Groups: Helsinki|Helsinki]]

* France
** [[OpenMoko_Local_Groups: Paris|Paris]]
** [[OpenMoko_Local_Groups: Toulouse|Toulouse]]

* Germany
** [[OpenMoko_Local_Groups: Berlin|Berlin]]
** [[OpenMoko_Local_Groups: Braunschweig|Braunschweig]]
** [[OpenMoko_Local_Groups: Duesseldorf|Duesseldorf]]
** [[OpenMoko_Local_Groups: Frankfurt Main|Frankfurt Main]]
** [[OpenMoko_Local_Groups: OWL|OWL]]
** [[OpenMoko_Local_Groups: Ingolstadt|Ingolstadt]]

* [[OpenMoko_Local_Groups:_Netherlands|Netherlands]]
** [[OpenMoko_Local_Groups: Amsterdam|Amsterdam]]
** [[OpenMoko_Local_Groups: Den Haag|Den Haag/The Hague]]
** [[OpenMoko_Local_Groups: Eindhoven|Eindhoven]]
** [[OpenMoko_Local_Groups: Ede|Ede]]

* Italy
** [[OpenMoko_Local_Groups: Milan|Milan]]
** [[OpenMoko_Local_Groups: Turin|Turin]]

* [[OpenMoko_Local_Groups:_Norway|Norway]]
** [[OpenMoko_Local_Groups:_Oslo|Oslo]]
** [[OpenMoko_Local_Groups: Trondheim|Trondheim]]

* Poland
** [[OpenMoko_Local_Groups: Warsaw|Warsaw]]

* [[OpenMoko_Local_Groups:_Portugal|Portugal]]
** [[OpenMoko_Local_Groups: Braga|Braga]]

* Romania
** [[OpenMoko_Local_Groups: Bucharest|Bucharest]]

* Russia
** [[OpenMoko_Local_Groups: Moscow|Moscow]]

* Slovakia
** [[OpenMoko_Local_Groups: Bratislava|Bratislava]]

* Spain
** [[OpenMoko_Local_Groups: Madrid|Madrid]]

* Sweden
** [[OpenMoko_Local_Groups: Gothenburg|Gothenburg]]

* [[OpenMoko_Local_Groups: Switzerland|Switzerland]]
** [[OpenMoko_Local_Groups: Bern|Bern]]

* UK
** England
*** [[OpenMoko_Local_Groups: Birmingham|Birmingham]]
*** [[OpenMoko_Local_Groups: London|London]]
** Scotland
*** [[OpenMoko_Local_Groups: Fife|Fife]]
*** [[OpenMoko_Local_Groups: Edinburgh|Edinburgh]]

* Ukraine
** [[OpenMoko_Local_Groups: Lugansk|Lugansk]]

== Oceania ==

* Australia
** [[OpenMoko_Local_Groups: Adelaide|Adelaide]]
** [[OpenMoko_Local_Groups: Canberra|Canberra]]
** [[OpenMoko_Local_Groups: Melbourne|Melbourne]]
** [[OpenMoko_Local_Groups: Sydney|Sydney]]

* New Zealand
** [[OpenMoko_Local_Groups: Auckland|Auckland]]
** [[OpenMoko_Local_Groups: Christchurch|Christchurch]]

== Asia ==
* India
** [[OpenMoko_Local_Groups: Delhi|Delhi]]
* Singapore
** [[OpenMoko_Local_Groups: Singapore|Singapore]]

== USA ==
* Alabama
** [[OpenMoko_Local_Groups: Alabama|Alabama]]

* Arizona
** [[OpenMoko_Local_Groups: Arizona|Arizona]]

* California
** [[OpenMoko_Local_Groups: San Diego|San Diego]]
** [[OpenMoko_Local_Groups: San Francisco|San Francisco]]
** [[OpenMoko_Local_Groups: Sacramento|Sacramento]]

* Colorado
** [[OpenMoko_Local_Groups: Colorado Springs|Colorado Springs]]
** [[OpenMoko_Local_Groups: Denver|Denver]]

* District of Columbia
** [[OpenMoko_Local_Groups: Washington DC Metro | Washington DC Metro]]

* Florida
** [[OpenMoko_Local_Groups: Central Florida | Central Florida]]

* Georgia
** [[OpenMoko_Local_Groups: Atlanta | Atlanta]]

* Illinois
** [[OpenMoko_Local_Groups: Chicago|Chicago]]

* Indiana
** [[OpenMoko_Local_Groups: Bloomington|Bloomington]]

* Iowa
** [[OpenMoko_Local_Groups: Iowa-Ames | Iowa-Ames]]

* Massachusetts
** [[OpenMoko_Local_groups: Boston|Boston]]

* Michigan
** [[OpenMoko_Local_Groups: Detroit|Detroit]]

* New Jersey
** [[OpenMoko_Local_Groups: Stevens Institute of Technology, Hoboken NJ | Stevens Institute of Technology, Hoboken NJ ]]

* New York
** [[OpenMoko_Local_Groups: NYC Metro | NYC Metro]]

* North Carolina
** [[OpenMoko Local_Groups: Charlotte | Charlotte]]

* Ohio
** [[OpenMoko_Local_Groups: Cleveland|Cleveland]]

* Oregon
** [[OpenMoko_Local_Groups: Eugene|Eugene]]
** [[OpenMoko_Local_Groups: Portland|Portland]]

* Texas
** [[OpenMoko_Local_Groups: North Texas|North Texas]]
** [[OpenMoko_Local_Groups: Central Texas|Central Texas]]

* Utah
** [[OpenMoko_Local_Groups: Salt Lake|Salt Lake]]

* Virginia
** [[OpenMoko_Local_Groups: Virginia|Virginia]]

== Canada ==
* Alberta
** [[OpenMoko_Local_Groups: Calgary|Calgary]]
** [[OpenMoko_Local_Groups: Edmonton|Edmonton]]
** [[OpenMoko_Local_Groups: Pincher Creek|Pincher Creek]]
* British Columbia
** [[OpenMoko_Local_Groups: Vancouver|Vancouver]]
* Ontario
** [[OpenMoko_Local_Groups: Ottawa|Ottawa]]
** [[OpenMoko_Local_Groups: Toronto|Toronto]]
* Quebec
** [[OpenMoko_Local_Groups: Montreal|Montreal]]

== Colombia ==
* Bogotá
** [[OpenMoko_Local_Groups: Bogota|Bogotá]]

[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]

OpenMoko2007.2

2007-08-14T10:57:09Z

Shadowjack:

== FAQ ==
=== What is 2007.2? ===

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon (Aug 19).

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

=== What are differences between 2007.1 and 2007.2? ===

=== Where to get images? ===

=== Where are official images? ===

No official images yet.

=== My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

== How to build ==
'''Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a [http://en.wikipedia.org/wiki/Proprietary_software waste of time] of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.'''

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. Use Bitbake 1.8.6 not a SVN version from the stable branch (otherwise you will get problems with checking out repositories) and the ''org.openembedded.dev'' branch of OE.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

=== Flashing with MokoMakefile ===
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ==
[disclaimer]

'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
help2man \
libc6-dev libglib2.0-dev libtool libxext-dev\
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

Go build ;)
make openmoko-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==
http://ipkg.nslu2-linux.org/feeds/openmoko/images/

http://people.openmoko.org/mickey/images/ (Confirmed working)

http://buildhost.openmoko.org/tmp2/deploy/glibc/images/fic-gta01/

[[Category:OpenMoko2007.2| ]]

OpenMoko2007.2

2007-08-09T11:13:47Z

Shadowjack: /* Pre-built snapshot images */

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon.

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

== How to build ==
'''Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a [http://en.wikipedia.org/wiki/Proprietary_software waste of time] of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.'''

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. Use Bitbake 1.8.6 not a SVN version from the stable branch (otherwise you will get problems with checking out repositories) and the ''org.openembedded.dev'' branch of OE.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a dash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

=== Flashing with MokoMakefile ===
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ==
[disclaimer]

'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
libc6-dev libglib2.0-dev libtool \
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to downgrade to monotone 0.28.
sudo apt-get remove monotone #if there is one allready
sudo apt-get install \
libboost-date-time1.33.1 libboost-filesystem1.33.1 libboost-regex1.33.1
wget http://monotone.ca/downloads/0.28/monotone_0.28-dapper0.1_i386.deb
sudo dpkg -i monotone_0.28-dapper0.1_i386.deb
echo monotone "hold" | sudo dpkg --set-selections

Another possible solution for this is to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

Go build ;)
make openmoko-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==
http://ipkg.nslu2-linux.org/feeds/openmoko/images/

http://daxxar.slask.no/om/ (Confirmed working)

http://people.openmoko.org/mickey/images/ (Confirmed working)

[[Category:OpenMoko2007.2| ]]

OpenMoko2007.2

2007-08-08T12:39:42Z

Shadowjack:

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon.

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

== How to build ==
'''Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a [http://en.wikipedia.org/wiki/Proprietary_software waste of time] of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.'''

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. Use Bitbake 1.8.6 not a SVN version from the stable branch (otherwise you will get problems with checking out repositories) and the ''org.openembedded.dev'' branch of OE.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a dash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

=== Flashing with MokoMakefile ===
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ==
[disclaimer]

'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
libc6-dev libglib2.0-dev libtool \
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to downgrade to monotone 0.28.
sudo apt-get remove monotone #if there is one allready
sudo apt-get install \
libboost-date-time1.33.1 libboost-filesystem1.33.1 libboost-regex1.33.1
wget http://monotone.ca/downloads/0.28/monotone_0.28-dapper0.1_i386.deb
sudo dpkg -i monotone_0.28-dapper0.1_i386.deb
echo monotone "hold" | sudo dpkg --set-selections

Another possible solution for this is to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

Go build ;)
make openmoko-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==

http://daxxar.slask.no/om/ (Confirmed to work)

http://people.openmoko.org/mickey/images/

[[Category:OpenMoko2007.2| ]]

User:Shadowjack

2007-08-05T06:24:03Z

Shadowjack:

Dmtiry Platonov

Main Page

2007-08-05T05:50:56Z

Shadowjack: /* Hands-on Guides */ Added link to OpenMoko 2007.2 build page

{{Languages|Main_Page}}
<big>'''Welcome to the [[OpenMoko]] public Wiki'''</big> 

[[Image:FIC-neo1973_small.jpg|200px|right|frontside]]
OpenMoko is an [http://en.wikipedia.org/wiki/Open_source Open Source] project to create the world's first free mobile phone operating system.

The [[OpenMoko]] project is a community that anyone can join, to help design their ideal phone.

Eventually, phone software won't be tied to any particular phone. You can install any OpenMoko software over the whole range of [[Supported Hardware|supported phones]], and if you upgrade your phone, you don't lose that software. Bugs fixed on any phone are fixed on all.

'''Currently it is not suitable for users.''' The state of the software at the moment is pre-alpha. If you order a Neo1973, DO NOT expect to be able to use it as an everyday phone for several months.

The [[Neo1973]] from [[FIC]] is the first of many phones that OpenMoko will run on; indeed, some people erroneously use the terms Neo1973 and OpenMoko as interchangeable. If you are willing to have the alpha test experience, you can order Neo1973 hardware now from the [https://direct.openmoko.com/ Openmoko Online Shop]. You may wish to see the [[SH1 FAQ|Shipment 1 FAQ]].

Please join us in collaborating on the OpenMoko project through any of the [[Development resources | project resources]] including this OpenMoko wiki. Please see the [[Help:Contents | wiki editing help]] page for information on making contributions to this wiki. A [[Meet the Core Team | core team]] of developers funded by FIC, Inc. leads the project.

An [[introduction]] page is available, with [[Introduction#Photos|photos]] and [[Introduction#Videos|videos]]. Moreover, the usual [[FAQ | Frequently Asked Questions]] (FAQ) page might be helpful. Developers may find the [[ChangeLog | change log]] an important resource.

Update 2007-07-25: The [http://forums.makeopensource.com/ Unofficial OpenMoko Forums] are now open! Everyone is invited to participate!

The members of the OpenMoko community would like to thank FIC Inc. for showing leadership and initiating the OpenMoko project.

== OpenMoko Areas of Interest ==
* [[Basic End-user]] - Information for end users that want basic functionality and no surprises
* [[Advanced End-user]] - Information for advanced end-users that want advanced and experimental functionality but who are not programmers
* [[Development resources | Project Resources]] - Provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | communication tools]], and other software development oriented resources.
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board
* [[Current events]] - Information on both past and future events where FIC or OpenMoko had or will have a presence.
* [http://forums.makeopensource.com/ Unofficial OpenMoko Forums] - Everyone is invited to collaborate with OpenMoko users and developers on the forums.

== Developer's Documentation ==

=== Hands-on Guides ===
* [[Getting Started with your Neo1973]]
* [[MokoMakefile|Building OpenMoko using the MokoMakefile]]
* [[OpenMoko2007.2|Building OpenMoko 2007.2]]
* [[Building OpenMoko from scratch]]
** [[Building a hello world application]]
** Old [[Building OpenMoko from scratch (pre-BBT)]]
* [[Migration to bad block tolerant builds]]
* [[Running OpenMoko on PC]]
** [[Getting OpenMoko working on host with Xoo]]
** [[Getting OpenMoko working on host with Xephyr]]
** [[How to run OpenMoko Apps on PC]]
** [[OpenMoko under QEMU]]
** [[Test Openmoko Emulation with chroot image|Test Openmoko Emulation with a Prebuilt chroot Image]]
* [[Booting from SD]]

=== Hardware Reference Documentation ===
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].
* The [[Neo1973 Hardware]] page provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB photographs are also included. A [[Disassembling Neo1973 | photo disassembly story]] may be an interesting starting place.
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] is also provided.

=== Software Reference Documentation ===
* Architectural
** [[OpenMokoFramework]] - The OpenMoko Application Framework
* [[Neo1973 host software]]
* Device Software
** Low-Level
*** [[u-boot]] - The bootloader we use, including documentation for our modifications
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications
** Userspace
*** [[binary compatibility]]
*** [[gsmd]] - the GSM daemon managing the GSM Modem
*** [[gpsd]] - the AGPS (Assisted GPS) daemon

=== OpenMoko ===
* [[OpenEmbedded]] - The distribution-building framework
* [[Toolchain]] - The toolchain we use for compilation
* [[OpenMoko]] - The OpenMoko distribution
** [[OpenMoko2007]] - The first intended release of it
** [[OpenMoko2007.2]] - An improved release with more formalized style guidelines.
** [[Userspace root image]]

==== User Interface Related ====
* [[Look & Feel]]
** [[Artwork]]
* [[Applications]]
* [[Widgets]]
** [[Widget Inheritance Graph]]
* [[Application UI Design Recommendations]]

=== Misc. Development Related ===
* [[Freshman todo]]
* [[Templates]]
* [[PIM Storage]]
* [[Coding Guidelines]]
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the OpenMoko SDK]]
* [[Application Development Crash Course]] -A very basic how-to for the new people.
* Alternative distributions for [[Neo1973]] GTA01: [[Angstrom on Neo1973]], [http://pokylinux.org Poky] (instructions needed!)
* [[License]] - How we license our code
* [[Development resources]] - Describes resources for developers (lists, svn, ...)
* [[Neo1973 Phase 0]] - Information for Phase 0 device owners
* [[Wishlist:Neo1973 P0 Review]] - Impressions of the Phase 0 hardware device, also the Phase 0 FAQ
* [[Neo1973 Phase 1]] - Information for Phase 1 device owners
* [[Wishlist:Neo1973 P1 Review]] - Impressions of the Phase 1 hardware device
* [[External Feeds]] - List of feeds from people blogging about OpenMoko

== Administrative / Organizational ==

* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.
* [[Hear Me FIC]] - Information to help FIC know what the community wants.
* [[Listen Up Community]] - Community's To-Do-List
* [[Wiki Issues]] - problems/requests regarding this Wiki

== Miscellaneous ==
* [[WiFi support in OpenMoko]]
* [[Neo1973 and Windows]] - If you want to commit that offence ;) (does not work, help!)
* [[Press Coverage]] - What the press says about the OpenMoko project
* [[mFAQ]] - The OpenMoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the OpenMoko project
* [[Wish List]] - A collection of ideas and ideals we'd like to see implemented some day
* [[Wish List - Hardware]] - A collection of ideas we'd like to see in the next Neo release
* [[Wishlist:BuiltInScriptingLanguage|Wish List - Built-in Scripting Language]] - Discussion on a suitable scripting language to be included
* [[Media Content]] - What types of media on the device can we use (that is non-software)?
* [[Testimonials]] - How did you get to OpenMoko?
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you put money aside for Neo1973? Put your nick here.
* [[iPhone]] - Comparison between Apple iPhone and FIC Neo1973
* [[Translation]] - Translation of OpenMoko
* [[Summer of code]] - Our page with project applications for Google's Summer of Code
* [[SWAG]] - Where to purchase openmoko swag (T-Shirts!)
* [[Trademark Policy]] -- The OpenMoko Trademark Policy



[[Category:Information| ]]
[[Category:Categories| ]]

Manually using GSM

2007-08-02T07:40:06Z

Shadowjack: Fixed link to GSM headset state

'''When men were real men and typed their own AT commands...'''

Thankfully, this may now be partially obsolete.
The [[Dialer|dialer]] now works!

This is a short guide how to manually get GSM going.

== Requirements ==

* GTA01Bv2 or GTA01Bv3 with very recent u-boot bootloader, providing usbtty (serial over USB) support)
* Do not connect any debug board!

== Walk-Through ==

=== Booting the system ===

* Make sure the rootfs you use has 'auto usb0' in /etc/network/interfaces
* Configure the host's usb0 interface to 192.168.0.200 netmask 255.255.255.0
* ssh to root@192.168.0.201

=== Disabling the getty ===

Our default images all have a getty running on /dev/ttySAC0, please edit /etc/inittab and disable the getty on that port

=== Reducing the loglevel ===

{{note|You don't need this in kernel builds with patchset ≥ 1288}}

To keep the kernel from writing to /dev/ttySAC0, you need to use <code>dmesg -n1</code>.

=== Powering up the GSM Modem ===

* verify there is no getty or any other app running on /dev/ttySAC0
root@fic-gta01:~$ lsof | grep ttySAC0
* power-up the GSM Modem
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on

=== Connecting to GSM Modem ===

* change permissions on ttySAC0
root@fic-gta01:~$ chown uucp.uucp /dev/ttySAC0
* setup /usr/spool/uucp
root@fic-gta01:~$ mkdir /usr/spool
root@fic-gta01:~$ mkdir /usr/spool/uucp
root@fic-gta01:~$ chown uucp.uucp /usr/spool/uucp
* enable CTS/RTS flow control
root@fic-gta01:~$ stty -F /dev/ttySAC0 crtscts
* access the GSM Modem UART
root@fic-gta01:~$ cu -l /dev/ttySAC0
Connected.
AT-Command Interpreter Ready
OK

''If it will hang on "Connected" message then probably your device has nonworking GSM modem - check [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=256 Bug #256]''

'''cu seems to have problems with the hardware flow control. The one way I always managed to get GSM working is to start cu first and then on a different console issue the stty command.'''
--[[User:DanielWillmann|DanielWillmann]] 01:15, 20 March 2007 (CET)

=== Using it manually ===
==== Registering with the Network ====

* enter the following [[Hardware:AT_Commands]]:
<pre>
ATE1
OK
AT+CFUN=1
ERROR
AT+CPIN="...."
OK
AT+COPS
OK
</pre>

==== Answering an incoming call ====
<pre>
RING
ATA
OK
</pre>

==== Dialling an outgoing call ====

To actually be able to talk you have to configure your audio accordingly

<pre>
root@fic-gta01:~$ cd /etc/alsa/
root@fic-gta01:/etc/alsa$ wget http://opensource.wolfsonmicro.com/~gg/neo1973/gsmheadset.working.state
root@fic-gta01:/etc/alsa$ alsactl -f /etc/alsa/gsmheadset.working.state restore
</pre>

Up the "Amp right" volume to hear the speaker on both ears, then dial

<pre>
ATD012340234;
</pre>

If you get NO CARRIER, try...

<pre>
ATD+xxyzzzzzzz
</pre>

ie, ATD+<country_code><area_code><phone_number>

==== Hanging up ====
<pre>
ATH
OK
</pre>

=== Using [[gsmd]] ===

You can use the [[gsmd]] and [[libgsmd-util]] programs to have a slightly more high-level interface to the GSM Modem. It's still console based, though.

For further instructions, see [[gsmd]]

=== Using tui ===

Tui (available from www.sf.net/projects/tui) is able to do all this. It is still text-based, but input-rxvt can take data from touchscreen, so you can actually do the calls using your finger. It also plays wav file on incoming call, so it is theoretically usable. It even does caller id.

=== Manually using GPRS ===

See [[Manually using GPRS]]

[[Category:Documentation]]
[[Category:Developer software]]

Translation

2007-08-01T12:02:05Z

Shadowjack: /* Russian */

{{todo|{{PAGENAME}}}}

Let us spread the popularity of OpenMoko/Neo1973 by localization of the software and translation of documentation and wiki.

Just as an overview who is able and willing to translate parts into other languages,
please join and add your Language and name. The source for the translation will
be English. If you have good English skills then you could contribute by correcting
the sources :)

A good point to start would be to continuous translating of
http://en.wikipedia.org/wiki/OpenMoko into more languages on the other language sites of wikipedia.

"...it is easy to join and spend some minutes for translating,
and when someone finds some mistakes in any languages don't
blame the translator - just be productive and fix it yourself!" -[[User:RobertMichel|Robert Michel]]

Please take a look at [[Translation HOWTO]] and improve it if possible.

Languages already offered on our community mailinglist, please add your name yourself and join community mailinglist (until we'll have a proper mailinglist) to discuss about translations:

== Afrikaans ==

== Amharic ==
* [[User:ethiopia|Ethiopia Alemayehu]]

== Armenian ==
* [[User:surenk|Suren Karapetyan]]

== Arabic عربي ==
* Hossam Mahmoud حسام محمود
* [[User:ترجمان05|ترجمان05]]
* [[User:Lixy|Lixy]] 17:54, 21 July 2007 (CEST)

== Bulgarian ==
* [[User:Mr700|Doncho Nicolaev Gunchev]]

== Catalan ==

* [[User:montxovs|Montxo Vicente i Sempere]]

* [[User:Mandarino|Mandarino]]

* [[User:RafaelCarreras|Rafael Carreras]]

== Chinese (Simplified)==
* [[User:JarodWang|JarodWang]]
* xyb

== Czech ==
* [[User:Mikesh|Michal Heczko]]
* [[User:Vatoz|Vaclav Cerny]]

== Danish ==
* [[User:EsbenDamgaard|Esben Damgaard]]
* [[User:UlrikRasmussen|Ulrik Rasmussen]]
* [[User:miki|Mikkel Kirkgaard Nielsen]]

== Dutch ==
* [[User:MarcVerwerft|Marc Verwerft]]
* [[User:Madjo|Marcel De Jong]]
* [[User:OliverH|Oliver Heesakkers]]
* [[User:LuitvD|Luit van Drongelen]]
* [[User:reinouts|Reinout van Schouwen]]

([[User:Madjo|Marcel]] 18/04) Misschien is het handig om alvast te beginnen met vertalen van de Wiki? Of hebben jullie andere ideeen? Ik heb al een start gemaakt van de voorpagina van de wiki, maar ben nog niet veel verder gekomen
([[User:reinouts|Reinout]] 21/04) Valt er verder nog niks te vertalen? De wiki is niet echt boeiend.

== Esperanto ==
* [[User:Antono|Antono Vasiljev]]
* [[User:Alekcxjo|Alekĉjo Rajmondo]]

== Estonian ==
* [[User:Hadara|Sven Petai]]
* [[User:Myoldryn|Jaan Nigul]]

== Finnish ==
* [[User:Jani-Matti_Hätinen|Jani-Matti Hätinen]]
* [[User:TuomoSipola|Tuomo Sipola]]
* [[User:Eyec|Samuli Perttula]]
* [[User:gua|Atte Hinkka]]

== French ==
* [[User:SebastienJolicoeur|Sebastien Jolicoeur]]
* [[User:MarcSert|Marc Sert]]
* [[User:FoucaultdeBonneval|Foucault deBonneval]]
* [[User:Sufflope|Jean-Sébastien Bour]]
* [[User:Ymahe|Yves Mahé]]
* [[User:opampca|Richard Lussier, Canada]]
* [[User:Kheldar|Guillaume Maiano]]
* [[User:Thomas01|Thomas Leclere]]
* [[User:fredlala|Frédéric Lasnier]]
* [[User:alekcxjo|Alexandre Raymond]]

== German ==
* [[User:RobertMichel|Robert Michel]]
* [[User:FabianOff|Fabian Off]]
* [[User:Denis std|Denis]]
* Lars C.
* [[User:AndreasHochsteger|Andreas Hochsteger]]
* [[User:Christophloew|Christoph Löw]]
* [[User:dFence|Daniel Zauner]]
* [[User:Imitation|Thomas Sanladerer]]

== Greek ==
* [[User:Chronix|Polychronis Papadakis]]

== Hebrew ==
* [[User:OlegSverdlov|Oleg Sverdlov]]
* [[User:Any_Key|Any_Key]]
* [[User:Koala|Koala]]

== Indonesian ==
* [[User:Hcblue|Hcblue]]

== Italian ==
* per il momento useremo [http://www.openmokoboard.org/ita/index.php?getforum=24 questo forum] per organizzarci. iscrivetevi e partecipate.
* [[User:SergioTota|Sergio Tota]]
* [[User:Franco|Franco Rimoldi]]
* [[User:Filippo|Filippo]]
* [[User:Massi|Massimiliano]]
* [[User:Markk0|Marco Cattaneo]]
* [[User:Cga|Callea Gaetano Andrea]]
* [[User:Herod2k|Alessandro]]
* [[User:shainer|Lisa Vitolo]]
* [[User:tia1982|Mattia]]
* [[User:azanutta|abe]]
* [[User:Gualti|Gualtiero]]
* [[User:Milo|Milo Casagrande]]
* [[User:White|Marco Celeri]]
* [[User:Aegis|Maurizio Scorianz]]

== Japanese ==
*[[User:WilliamLai|William Lai]]
*[[Momoko Matsuzaki]]

== Norwegian ==
*[[User:Hanscats|Hans Cats]]
*[[User:Vegar|Vegar Storvann]]

== Polish ==
* [[User:KrzysztofKajkowski|Krzysztof Kajkowski]]
* Tomasz Zieliński
* [[User:MaciejLigenza|Maciej Ligenza]]
* [[User:PiotrDuda|Piotr Duda]]
* [[User:Zbraniecki|Zbigniew Braniecki]]

== Portuguese ==
*[[User:Skull Death|James Côrtes]]
* Sergio Bessa
* Mario Costa
* Tiago Saraiva

== Punjabi ==
* [[User:aalam|A S Alam]]

== Romanian ==

* [[User:alexxed|Alexandru Szasz]]
* [[User:sin|Lucian]]

== Russian ==
* [[User:OlegSverdlov|Oleg Sverdlov]]
* [[User:DenisBY|Denis Kot]]
* [[User:MikhailGusarov|Mikhail Gusarov]]
* [[User:x-demon|Alexander Sokolow]]
* [[User:Any_Key|Any_Key]]
* [[User:Dmitri|Dmitri]]
* [[User:Buffet|Denis Kaledin]]
* [[User:Nes|Mike Drapolyuk]]
* [[User:vase|Vasiliy Tolstov]]
* [[User:Shadowjack|Shadowjack]]
Можем начинать переводить wiki :)
К любой странице добавляете /ru и переводите. В конце оригинальной страницы и переведенной добавляете ссылку на шаблон
<nowiki>{{Languages|Имя_страницы_оригинала}}</nowiki>

== Slovak ==
* [[User:Cezz|Cezz]]
* [[User:PipBoy2000|PipBoy2000]]

== Spanish ==
* [[User:RosangelaCaninoKoning|Rosangela CaninoKoning]]
* [[User:kresp0|Santiago Crespo (kresp0)]]
* [[User:José_Suárez|José Suárez]]
* [[User:Rafa_Couto|Rafa Couto (caligari)]]
* [[User:NeoMorfeo|Guillermo Santos (NeoMorfeo)]]
* [[User:Mandarino|Mandarino]]
* [[User:pptudela|Pepe Tudela]]
* [[User:avathar|Fernando González (Avathar)]]
* [[User:Rbruzz|Rbruzz]]

== Swedish ==
* [[User:yeager|Daniel Nylander]]

== Turkish ==
* [[User:EnginErenturk|Engin Erenturk]]
* [[User:Supernova|İsmail AŞCI]]

== Welsh ==
* [[User:Rhoslyn_Prys|Rhoslyn Prys]]

And feel free to join and add an new language to this list above.

{{Languages|Translation}}

GSM

2007-07-30T18:56:26Z

Shadowjack: Added languages block

'''GSM''', ([http://en.wikipedia.com/wiki/GSM Global System for Mobile communications]) is the phone standard and network type supported by the [[Neo1973]]. Future phones may support other standards.

GSM covers making phone calls, sending '''SMS''' text messages, and access to Internet via '''GPRS'''. A '''SIM''' ([http://en.wikipedia.org/wiki/Subscriber_Identity_Module Subscriber Identity Module]) card is given along the contract with an operator, and the customer inserts the card in the phone to authorize it. The card is plastic (approximately 15mm*23mm*1mm) with several gold contacts on, and it determines the mobile phone 'number' and what network the phone is on.

The Neo1973 phone can be used with any operator that has a GSM network; it is quad-band and thus supports every frequency (850, 900, 1800, and 1900 MHz). Thus it will work in most countries, with the exception of some of the US and some other parts of the world that completely lack GSM coverage.

== Applications ==

Calls can be placed using the graphical [[Dialer]] or the textual gsmd-tool.

Rest needs to be done on the command-line [[manually using GSM]] and [[manually using GPRS]], until [[gsmd]] supports more.

== Programming ==

The GSM features (including dialing, SMS, GPRS, and SIM access) will be programmed via [[gsmd]].

== Standards information ==

You can find a full list of GSM/3GPP standards at [http://webapp.etsi.org/key/key.asp?full_list=y this ETSI site] (attention! more than 2000 entries) or at [http://pda.etsi.org/pda/queryform.asp the light-weight ETSI site].

=== GSM 02.07 - Required features ===

See [[GSM02.07]].

=== GSM 07.07 - Main AT commands ===

07.07 describes the main commands used by the [[Gsmd]] software of the Openmoko system to communicate via a serial interface with the [[GSM]] subsystem of the phone.

* http://www.ctiforum.com/standard/standard/etsi/0707.pdf

For more, see [[Hardware:AT Commands]].

Note that the descendant of this specification is [http://www.3gpp.org/ftp/Specs/html-info/27007.htm 3GPP TS 27.007 - AT command set for User Equipment (UE)]. (Does OpenMoko support any of these newer versions?)

=== GSM 07.05 - Additional AT commands (SMS and CBS) ===

* http://www.ctiforum.com/standard/standard/etsi/0705.pdf

=== GSM 07.10 - Multiplexing ===

* direct link?

{{Languages|SIM}}
[[Category:Applications]]
[[Category:Hardware]]

Devirginator/it

2007-07-30T18:14:33Z

Shadowjack: Added languages block

Il '''devirginator''' un è un programma utilizzato in combinazione con [[dfu-util]], [[OpenOCD]] e [[Debug Board]] per reporogrammare alle impostazioni di fabbrica il telefono from scratch.

== Codice sorgente ==

Il codice sorgente di devirginator è disponibile qui http://svn.openmoko.org/trunk/src/host/devirginator/

== Documentazione ==

{{nota|Questa deriva da http://svn.openmoko.org/trunk/src/host/devirginator/README rev. 1215 e potrebbe essere obsoleta}}

=== Iniziare ===

Per iniziare,
% cp config.example config
e fai le modifiche necessarie. In particulare, devi configurare SNAPSHOT.
Quindi
% make
Questo richiede Netpbm e transfig. Infine assicurati che openocd sia attivo,
accendi il dispositivo, diventa root, ed esegui
# ./devirginate

=== Prerequisiti ===

Il dispositivo deve essere connesso con:

* JTAG, con un'interfaccia supportatata da OpenOCD (necessaria per tutti gli stages)
* USB, connesso alla su cui è in funzione "devirginate" (richiesto solo per lo stage 2 e successivi)

Inoltre, se una serial console è connessa al dispositivo, la progressione
dell'installazione può essere monitorata.

Sono bnecessari i seguenti programmi:

==== dfu-util ====

* dfu-util deve essere accessibile dalla macchina su chui è attivo "devirginate". Se dfu-util non è nel PATH, puoi selezionare un path specifico in "config".

Per fara il build di dfu-util, esegui:
cd $OMDIR/openmoko/trunk/src/host/dfu-util
./autogen.sh
./configure
make

==== OpenOCD ====

OpenOCD SVN revision 130 con libftdi 0.8 funziona. Altre
combinazioni possono anche funzionarec. E' richiesto il seguente patch:

http://svn.openmoko.org/developers/werner/openocd-wait-patiently.patch

Per el istruzioni per il build, vedi http://svn.openmoko.org/developers/werner/notes/openocd

Se stai usando la build di OpenOCD fatta dalla OpenMoko
distribution (SVN revision 1180 o successiva), il patch è già
applicato.

==== telnet ====

Oltre a tutto ciò, "devirginate" necessita di telnet.

==== netpbm, transfig, wget, perl ====

"setup.sh" può essere eseguito da un'altra macchian che ha in share la stessa gerarchia del
file system. Necessita di Netpbm, transfig, wget, e Perl.

=== Setup ===

Innazitutto devirginator necessita di essere configurato. Questo include

* scaricare i binari per u-boot, kernel, etc.
* generare/convertire diversi files usando il processo di setup

Per il momento il setup deve essere fatto nella directory contente tutti i
files riferiti a devirginator. I files generati durante il setup
sono posizionati nella directory tmp/. I files in tmp/ sono inoltre usati
durante l'uso di devirginator.

Per iniziare, copia config.example su "config" e applica le modifiche necessarie.
Quasi tutte le configurazioni necessarie sono di defaults, ma una cosa che potresti
voler fare è configurare SNAPSHOT con il date code dello the snapshot che desideri.

Poi esegui ./setup.sh o semplicemente make .

setup.sh ora scaricherà ogni file perduto ed eseguirà le varie
conversioni. Se apapre qualche errore durante questo processo, ad esempio a causa della
mancanza di strumenti o di un errore di configurazione, setup.sh si fermerà con un errore.
Potrai quindi correggere l'errore e riprovare. I files già scaricati in tmp/ verranno
saltati quando riprovi (setup.sh lo farà lo stessose i files avranno subito dei
cambiamenti).

setup.sh inoltre controlla se gli esguibili sono disponibili durante l'uso di devirgination
e segnalerà se manca qualcosa. In generale, si può eseguire setup.sh su una macchina diversa che "devirginate", in
questo caso questi avvisi saranno ignorati.

=== Files ===

==== Script ====
* crc32.pl -Permette la funzione crc32 che comanda la IEEE CRC-32. Questo script è usato da altri script Perl, con "do".

* envedit.pl
* openocdcmd.pl
* scriptify.pl
* setup.sh

==== Configurazione utente ====

===== File di configiurazione statici =====

I file seguenti contengono script ed altra informazioni di configurazione
"statici" che sono usati nel processo di devirgination. Normalmente basta
editare questi file per cambiare le funzioni del processo di setup.

Ognuno di questi file è convertito in qualche maniera da setup.sh.
Qui sotto dopo la freccia sono indicati i rispettivi file risultanti.

* openocd.in -> tmp/script.ocd

Commands to execute by OpenOCD in phase 0. To perform variable
expansion, each line of this file is processed by the shell with
eval "echo $line". Due to this, shell meta-characters should be
avoided.

If changing any addresses in openocd.in, you also need to update
u-boot.in.

* u-boot.in -> tmp/u-boot.out

Commands to execute in u-boot during stage 0. This file is converted
to an image understood by u-boot, and then executed from memory with
u-boot's "autoscr" command.

* environment.in -> tmp/environment

Environment settings for the regular u-boot environment. Note that
the changes in this file are made on top of the interim environment
produced in stage 0. In particular, the "mtdparts" variable is
retained from that stage.

Long lines can be split in environment.in by simply indenting the
continuation. Note that the newline and the indentation are replaced
with one space. E.g.,
<pre>
foo=some
thing
</pre>
would yield foo=some thing

* smiley.fig -> tmp/smiley.gz
The stage 0 splash screen, a smiling face on a green background.

==== Download cache ====

* tmp/System_boot.png -> tmp/splash.gz
This is a copy of the OpenMoko logo, which then gets converted to a
gzip-ed raw framebuffer image.

* tmp/openmoko-devel-image-*.rootfs.jffs2
* tmp/lowlevel_foo-*.bin
* tmp/u-boot-*.bin
* tmp/uImage-*.bin

* tmp/env.old
* tmp/env.new
* tmp/preboot_override
* tmp/preboot_override.noscrub
* tmp/preboot_override.scrub

==== Script ====

I primi messaggi saranno qualcosa di simile a questo:
<pre>
Open On-Chip Debugger
> script /home/moko/om/trunk/src/host/devirginator/tmp/script.ocd
reset halt
wait_halt
waiting for target halted...
Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
[...]
</pre>
E' importante "pc: 0x00000000". Se il numero è differente, ad esempio
qualcosa del tipo "pc: 0xffffffed", il dispositivo probabilmente non
è acceso. In questo caso puoi provare a farlo ripartire, o se openocd
è bloccato,

* chiudi openocd
* togli e reinserisci il connettore USB nel JTAGkey o nel debug v2 board
* apri openocd

=== Stage ===

The setup process is divided into three stages (plus a special zero
stage, see below). Each stage leaves the device in a stable state.
An installation run can include all or only some stages. Each stage
requires successful completion of all previous ones.

* Stage 1: erases all previous NAND content, installs u-boot, and makes the device ready to receive further updates by DFU.
* Stage 2: installs Linux and the root file system.
* Stage 3: To be defined.

Note that you most likely require privileges for some of the USB
operations "devirginate" performs. Therefore, do all this as "root".

To perform all stages, run
# ./devirginate
from the trunk/src/host/devirginator/ directory.

To run only individual stages, specify the stage numbers, each prefixed
by "-", e.g.,
# ./devirginate -1

==== Stage 0 ====

Se la tabella dei bad block NAND è invalida, può essere cancellata all'inzio
dello stage 1. Questo è chiamato "stage 0".

Non è un'opzione ideale, perchè se l'ultimo blocco NAND è corrotto,
queste informazioni andranno perse.
Di default, lo stage 0 non viene eseguito.

==== Stage 1 ====

Immediately after starting, the screen lights up, showing random junk.
This is an indication that the setup process has started. Note that the
screen content may change ("decay") during all this. This is normal.

After 10-30 seconds, the screen will go dark. This indicates that we
now a have u-boot running on the device.

About 60-90 seconds later, the screen will light up again and show a
smiling face on a green background. This indicates that the first stage
has completed. The smiling face will appear each time you activate the
device.

The device now contains:
* a bad block table (BBT)
* u-boot, with DFU capability
* a basic set of u-boot environment variables
* the interim splash screen

What is still missing:
* the Linux kernel
* the root file system
* the final environment
* the final splash screen

==== Stage 2 ====

To begin phase 2, activate the device. The stage 1 smiley will show.

Phase 2 can take several minutes. Progress of the download procedure
is indicated by hash signs (#) printed on the terminal where
"devirginate" runs.

At the end of phase 2, the device resets, displays a partial OpenMoko
splash screen, then resets again, displays the correct splash screen
and finally boots Linux.

==== Stage 3 ====

TBD.
{{Languages|Devirginator}}

[[Category:Developer software]]
[[Category:Guides]]

Devirginator

2007-07-30T18:11:51Z

Shadowjack: Added languages block

The '''devirginator''' is a program that can be used in combination with [[dfu-util]], [[OpenOCD]] and [[Debug Board]] to completely (factory-re-)program a phone from scratch.

== Source code ==

The source code of devirginator is available at http://svn.openmoko.org/trunk/src/host/devirginator/

== Documentation ==

{{note|This is derived from http://svn.openmoko.org/trunk/src/host/devirginator/README rev. 1215 and might be outdated}}

=== Quick start ===

First,
% cp config.example config
and may changes as needed. In particular, you must set SNAPSHOT.
Then
% make
This requires Netpbm and transfig. Finally, make sure that openocd runs,
power the device up, become root, and run
# ./devirginate

=== Prerequisites ===

The device must be connected to:

* JTAG, with an interface supported by OpenOCD (required for all stages)
* USB, connected to the machine running "devirginate" (only required for stage 2 and beyond)

Furthermore, if a serial console is connected to the device, installation
progress can be monitored.

The following programs are needed:

==== dfu-util ====

* dfu-util must be accessible from the machine running "devirginate". If dfu-util is not in PATH, you can set an explicit path in "config".

To build dfu-util, do this:
cd $OMDIR/openmoko/trunk/src/host/dfu-util
./autogen.sh
./configure
make

==== OpenOCD ====

OpenOCD SVN revision 130 with libftdi 0.8 is known to work. Other
combinations may also work. The following patch is required:

http://svn.openmoko.org/developers/werner/openocd-wait-patiently.patch

For build instructions, see http://svn.openmoko.org/developers/werner/notes/openocd

If you're using the version of OpenOCD built by the OpenMoko
distribution (SVN revision 1180 or later), the patch is already
applied.

==== telnet ====

Furthermore, "devirginate" requires telnet.

==== netpbm, transfig, wget, perl ====

"setup.sh" can be run from a different machine sharing the same file
system hierarchy. It requires Netpbm, transfig, wget, and Perl.

=== Setup ===

The devirginator first needs to be set up. This includes

* downloading binaries for u-boot, kernel, etc.
* generating/converting various files used during the setup process

At the moment, the setup must be done in the directory containing all
files belonging to the devirginator. The files generated during setup
are stored in the directory tmp/. The files in tmp/ are also used
during devirgination.

First, copy config.example to "config" and make the necessary changes.
Almost all settings have reasonable defaults, but the least thing you
will have to do is set SNAPSHOT to the date code of the snapshot you
desire.

Next, run either ./setup.sh or just make .

setup.sh will now download any missing files, and perform the various
conversions. If any error occur during this, e.g., because of missing
tools or a configuration error, setup.sh will stop with an error. You
then have to correct the problem and retry. Files already downloaded
to tmp/ will be skipped in the retry (setup.sh will still probe if
they have changed).

setup.sh also checks if executables used during devirgination are
available and prints a warning if it finds anything missing. In general,
one can run setup.sh on a different machine than "devirginate", in
which case these warnings can be ignored.

=== Files ===

==== Scripts ====
* crc32.pl -Provides the function crc32, which computes the IEEE CRC-32. This script is used by other Perl scripts, with "do".

* envedit.pl
* openocdcmd.pl
* scriptify.pl
* setup.sh

==== User configuration ====

===== Static configuration files =====

The following files contain scripts and other "static" configuration
information that is used in the devirgination process. In general,
it is only necessary to edit these files when changing functionality
of the setup process.

Each of these files is converted in some way by setup.sh. Below, we
indicate the name of the respective resulting file after the arrow.

* openocd.in -> tmp/script.ocd

Commands to execute by OpenOCD in phase 0. To perform variable
expansion, each line of this file is processed by the shell with
eval "echo $line". Due to this, shell meta-characters should be
avoided.

If changing any addresses in openocd.in, you also need to update
u-boot.in.

* u-boot.in -> tmp/u-boot.out

Commands to execute in u-boot during stage 0. This file is converted
to an image understood by u-boot, and then executed from memory with
u-boot's "autoscr" command.

* environment.in -> tmp/environment

Environment settings for the regular u-boot environment. Note that
the changes in this file are made on top of the interim environment
produced in stage 0. In particular, the "mtdparts" variable is
retained from that stage.

Long lines can be split in environment.in by simply indenting the
continuation. Note that the newline and the indentation are replaced
with one space. E.g.,
<pre>
foo=some
thing
</pre>
would yield foo=some thing

* smiley.fig -> tmp/smiley.gz
The stage 0 splash screen, a smiling face on a green background.

==== Download cache ====

* tmp/System_boot.png -> tmp/splash.gz
This is a copy of the OpenMoko logo, which then gets converted to a
gzip-ed raw framebuffer image.

* tmp/openmoko-devel-image-*.rootfs.jffs2
* tmp/lowlevel_foo-*.bin
* tmp/u-boot-*.bin
* tmp/uImage-*.bin

* tmp/env.old
* tmp/env.new
* tmp/preboot_override
* tmp/preboot_override.noscrub
* tmp/preboot_override.scrub

==== Scripts ====

The first few messages should look like this:
<pre>
Open On-Chip Debugger
> script /home/moko/om/trunk/src/host/devirginator/tmp/script.ocd
reset halt
wait_halt
waiting for target halted...
Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
[...]
</pre>

The "pc: 0x00000000" is important. If the number is different, e.g.,
something like "pc: 0xffffffed", the device is probably not turned
on. In this case, you can try to restart, or, if openocd is stuck,

* kill openocd
* pull and then replace the USB plug of the JTAGkey or debug v2 board
* start openocd

=== Stages ===

The setup process is divided into three stages (plus a special zero
stage, see below). Each stage leaves the device in a stable state.
An installation run can include all or only some stages. Each stage
requires successful completion of all previous ones.

* Stage 1: erases all previous NAND content, installs u-boot, and makes the device ready to receive further updates by DFU.
* Stage 2: installs Linux and the root file system.
* Stage 3: To be defined.

Note that you most likely require privileges for some of the USB
operations "devirginate" performs. Therefore, do all this as "root".

To perform all stages, run
# ./devirginate
from the trunk/src/host/devirginator/ directory.

To run only individual stages, specify the stage numbers, each prefixed
by "-", e.g.,
# ./devirginate -1

==== Stage 0 ====

If the NAND bad block table is invalid, it can be erased at the beginning
of stage 1. We call this "stage 0".

In general, this is not a desirable option, because if the last NAND blocks
are defective, this information will be lost, and unreliable operation may
result. By default, stage 0 is not performed.

==== Stage 1 ====

Immediately after starting, the screen lights up, showing random junk.
This is an indication that the setup process has started. Note that the
screen content may change ("decay") during all this. This is normal.

After 10-30 seconds, the screen will go dark. This indicates that we
now a have u-boot running on the device.

About 60-90 seconds later, the screen will light up again and show a
smiling face on a green background. This indicates that the first stage
has completed. The smiling face will appear each time you activate the
device.

The device now contains:
* a bad block table (BBT)
* u-boot, with DFU capability
* a basic set of u-boot environment variables
* the interim splash screen

What is still missing:
* the Linux kernel
* the root file system
* the final environment
* the final splash screen

==== Stage 2 ====

To begin phase 2, activate the device. The stage 1 smiley will show.

Phase 2 can take several minutes. Progress of the download procedure
is indicated by hash signs (#) printed on the terminal where
"devirginate" runs.

At the end of phase 2, the device resets, displays a partial OpenMoko
splash screen, then resets again, displays the correct splash screen
and finally boots Linux.

==== Stage 3 ====

TBD.

{{Languages|Devirginator}}

[[Category:Developer software]]
[[Category:Guides]]

Hardware:Neo1973:Alternate Cases:Camera

2007-07-30T17:59:56Z

Shadowjack: Fixed table formatting

Alternate case for the Neo1973, with rear-mounted camera module.

==Concept==

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==
Camera module 

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick
|-
|1. ||[[User:Bootlessjam|Bootlessjam]]
|-
|2. ||[[User:Diatessaron|Diatessaron]]
|-
|3. ||[[User:Thomas Mathiesen|Thomas Mathiesen]]
|}

[[Category:Neo1973_alternate_cases]]

Hammerhead/Protocol

2007-07-17T11:34:37Z

Shadowjack: /* Global packets */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 02 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:04.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:02 00 10 01 00

Possibly, some kind of bitfield/flag.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout:

SEND: L:03 CH:0 FL:4 TYPE:04 92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency". This packet is identical in cold1.log and cold2.log

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== SEND Packet 13 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:02.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:13 ef cd 21 43

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

==== SEND Packet e5 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:13.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:e5 00 03 00 00

Possibly, some kind of bitfield/flag.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-17T11:19:43Z

Shadowjack: /* Global packets */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 02 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:04.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:02 00 10 01 00

Possibly, some kind of bitfield/flag.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout:

SEND: L:03 CH:0 FL:4 TYPE:04 92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency". This packet is identical in cold1.log and cold2.log

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== SEND Packet 13 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:02.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:13 ef cd 21 43

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-17T11:15:56Z

Shadowjack: /* SEND Packet 02 */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 02 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:04.

Usual layout:

SEND: L:00 CH:0 FL:4 TYPE:02 00 10 01 00

Possibly, some kind of bitfield/flag.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout:

SEND: L:03 CH:0 FL:4 TYPE:04 92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency". This packet is identical in cold1.log and cold2.log

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-17T11:15:11Z

Shadowjack: /* SEND Packet 04 */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 02 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:04.

Usual layout
SEND: L:00 CH:0 FL:4 TYPE:02 00 10 01 00

Possibly, some kind of bitfield/flag.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout:

SEND: L:03 CH:0 FL:4 TYPE:04 92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency". This packet is identical in cold1.log and cold2.log

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-17T11:13:18Z

Shadowjack: /* Global packets */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 02 ====

Flags = 4

Seen only once per session at the start, during init.
This packet is identical in cold1.log and cold2.log
Comes right after SEND TYPE:04.

Usual layout
SEND: L:00 CH:0 FL:4 TYPE:02 00 10 01 00

Possibly, some kind of bitfield/flag.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout
SEND: L:03 CH:0 FL:4 TYPE:04 92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency". This packet is identical in cold1.log and cold2.log

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Advertising

2007-07-16T18:33:55Z

Shadowjack: /* General Ideas */

== Text ==
* There could be a description of OpenMoko/Neo1973 features
* There could be a short story about what OpenMoko/the Neo1973 does different:
** e.g.:
After leaving work your Neo's GPS automatically switches your Alarm Profile from
Silent to Loud and guides you to the next gas station. At home, your Neo automatically
deploys its WiFi functionality, retrieves your email (free of charge) and activates
voice over ip capabilities (free of charge).
And so on...
** e.g.:
Neo: Hi, I'm an Neo.
iPhone: And I'm an iPhone.
* iPhone looks on a big map and tries to orientate himself
Neo: What are you doing?
iPhone: I try to locate myself by using Google Maps.
Neo: Oh, that doesn't seem to be very exciting. I use GPS for that kind of stuff.
Works automatically.
iPhone: GPS, yeah?
Neo: Yes. Oh, wait, I'm entering the cinema. I think, it's better for me, to
switch to stand-by now. See you after the movie.
iPhone: Oh, bye.
* Neo leaves, iPhone looks on the map again.
iPhone: Oh, here we are! Finally...
[http://lists.openmoko.org/pipermail/community/2007-July/006141.html]
** e.g.:
Scene: Completely blank white background.
Two people enter the frame.
Moko: Hi, I'm an OpenMoko
iPhone: And I'm an iPhone
* OpenMoko looks like he's enjoying himself
iPhone: What are you doing?
Moko: Oh, I just downloaded this great new game I came across. Want to try it?
iPhone: I, er, I can't play new games. I've got this great game of solitaire, though!
Moko: That's a shame. Nothing at all?
iPhone: Well, I can play games off the web. Some of them. Want a game of bejeweled?
Moko: ...thanks, no. I'm fine.
[http://lists.openmoko.org/pipermail/community/2007-July/006110.html]
* There ''should'' be some pre-composed basic information that can be copy'n'pasted into one's Myspace/Facebook/whatever/-profile.
* There ''should'' be some pre-composed advanced information for press/blogs/mobile service providers

=== Printed Advertisement ===
...

== Video ==

Adam Krikstone did some nice OpenMoko video ads: (youtube)

[http://www.youtube.com/view_play_list?p=472DE700A3CC70A4 Playlist]

[http://www.youtube.com/watch?v=DCQ7dmGuAU8]

[http://www.youtube.com/watch?v=tQPjfUqp-dk]

[http://www.youtube.com/watch?v=4qP-K1HOMHk]

[http://www.youtube.com/watch?v=S--2HeQqjq4]

[http://www.youtube.com/watch?v=dpwxzEopg60]

[http://www.youtube.com/watch?v=EuG2hYiO9AU]

[http://www.youtube.com/watch?v=lGjY7tigdkA]

[http://www.youtube.com/watch?v=YR4ezMgRlWo]

[http://www.youtube.com/watch?v=OZC3mjRW5Tg]

[http://www.youtube.com/watch?v=GxsVFG7jHI8]

[http://www.youtube.com/watch?v=62kLhNngE20]

[http://www.youtube.com/watch?v=kR-4VhlsiV8]

== Sound empathy / Jingle ==
* There should be some kind of jingle for OpenMoko, just like this "Hello Moto" thing from Motorola
** [http://tetraden.te.funpic.de/openmoko/OpenMoko_free_your_phone02.ogg Number one] (suggestions/whishes? franzkautz@yahoo.de Topic: sth. with OpenMoko)
** [http://tetraden.te.funpic.de/openmoko/OpenMoko_free_your_phone04.ogg Number two] (franzkautz@yahoo.de)

== Thoughts, Notions ==
=== General Ideas ===
* '''What is advertised?'''
* If we advertise a phone by claiming it can do everything maybe no one will buy it.
* '''Question''': Who is supposed to buy this phone?
# '''Average Phone User''' probably only wants a phone to make calls. Why would he buy an opensource linux phone with additional command line? We ''need'' reasons for ''him'' to buy a phone running OpenMoko:
#* Easy to use (not implemented though ;-)
#* Rich and powerfull text input methods
#* MS Outlook/whatever Sync
#* (please add)
# '''Advanced Phone User''': won't be hard to persuade him. As we likely are all advanced phone users it will be easy to find reasons/features for him to buy this phone:
#* GPS-based profiles
#* Seamless GPS-based GSM/WiFi/VoIP-switching
#* (please add)
# '''Technophobe Phone User''' really needs some reasons for this phone:
#* Really easy to use (really not implemented ;-)
#* Flashy UI look
#* (please add)

=== Further Ideas ===
Something that came to me passing some mobile service provider's outlet today. This should be done when GTA_02 is available and software running.

''A guy walks into a mobile service provider's outlet or approached by the outlet's staff. The guy asks the clerk about their phones and ends up showing him his Neo. He explains him the Neo's features that stand unrivaled to any of the mobile service provider's offered phones and eventually leaves him completly flabbergasted and pondering about the meaning of life and mobile connectivity/whatever''

--[[User:Minime|Minime]] 16:58, 7 July 2007 (CEST)

=== Controversial Issues ===
* We need to be careful about using copyrighted material (e.g. youtube)
** Other legal issues...?
** Be aware of what we are advertising: What functions does OpenMoko currently feature, what is planned and what not? Are functions advertised protected by patents?
* What is the community's goal in advertising?
** Are we advertising OpenMoko?
** Are we advertising the Neo1973? And if so, is this our job? The Neo1973 is after all, a commerical product.

[[Category:Community]]
[[Category:Information]]

Advertising

2007-07-16T18:33:14Z

Shadowjack: /* Thoughts, Notions */

== Text ==
* There could be a description of OpenMoko/Neo1973 features
* There could be a short story about what OpenMoko/the Neo1973 does different:
** e.g.:
After leaving work your Neo's GPS automatically switches your Alarm Profile from
Silent to Loud and guides you to the next gas station. At home, your Neo automatically
deploys its WiFi functionality, retrieves your email (free of charge) and activates
voice over ip capabilities (free of charge).
And so on...
** e.g.:
Neo: Hi, I'm an Neo.
iPhone: And I'm an iPhone.
* iPhone looks on a big map and tries to orientate himself
Neo: What are you doing?
iPhone: I try to locate myself by using Google Maps.
Neo: Oh, that doesn't seem to be very exciting. I use GPS for that kind of stuff.
Works automatically.
iPhone: GPS, yeah?
Neo: Yes. Oh, wait, I'm entering the cinema. I think, it's better for me, to
switch to stand-by now. See you after the movie.
iPhone: Oh, bye.
* Neo leaves, iPhone looks on the map again.
iPhone: Oh, here we are! Finally...
[http://lists.openmoko.org/pipermail/community/2007-July/006141.html]
** e.g.:
Scene: Completely blank white background.
Two people enter the frame.
Moko: Hi, I'm an OpenMoko
iPhone: And I'm an iPhone
* OpenMoko looks like he's enjoying himself
iPhone: What are you doing?
Moko: Oh, I just downloaded this great new game I came across. Want to try it?
iPhone: I, er, I can't play new games. I've got this great game of solitaire, though!
Moko: That's a shame. Nothing at all?
iPhone: Well, I can play games off the web. Some of them. Want a game of bejeweled?
Moko: ...thanks, no. I'm fine.
[http://lists.openmoko.org/pipermail/community/2007-July/006110.html]
* There ''should'' be some pre-composed basic information that can be copy'n'pasted into one's Myspace/Facebook/whatever/-profile.
* There ''should'' be some pre-composed advanced information for press/blogs/mobile service providers

=== Printed Advertisement ===
...

== Video ==

Adam Krikstone did some nice OpenMoko video ads: (youtube)

[http://www.youtube.com/view_play_list?p=472DE700A3CC70A4 Playlist]

[http://www.youtube.com/watch?v=DCQ7dmGuAU8]

[http://www.youtube.com/watch?v=tQPjfUqp-dk]

[http://www.youtube.com/watch?v=4qP-K1HOMHk]

[http://www.youtube.com/watch?v=S--2HeQqjq4]

[http://www.youtube.com/watch?v=dpwxzEopg60]

[http://www.youtube.com/watch?v=EuG2hYiO9AU]

[http://www.youtube.com/watch?v=lGjY7tigdkA]

[http://www.youtube.com/watch?v=YR4ezMgRlWo]

[http://www.youtube.com/watch?v=OZC3mjRW5Tg]

[http://www.youtube.com/watch?v=GxsVFG7jHI8]

[http://www.youtube.com/watch?v=62kLhNngE20]

[http://www.youtube.com/watch?v=kR-4VhlsiV8]

== Sound empathy / Jingle ==
* There should be some kind of jingle for OpenMoko, just like this "Hello Moto" thing from Motorola
** [http://tetraden.te.funpic.de/openmoko/OpenMoko_free_your_phone02.ogg Number one] (suggestions/whishes? franzkautz@yahoo.de Topic: sth. with OpenMoko)
** [http://tetraden.te.funpic.de/openmoko/OpenMoko_free_your_phone04.ogg Number two] (franzkautz@yahoo.de)

== Thoughts, Notions ==
=== General Ideas ===
* '''What is advertised?'''
* If we advertise a phone by claiming it can do everything maybe no one will buy it.
* '''Question''': Who is supposed to buy this phone?
# '''Average Phone User''' probably only wants a phone to make calls. Why would he buy an opensource linux phone with additional command line? We ''need'' reasons for ''him'' to buy a phone running OpenMoko:
#* Easy to use (not implemented though ;-)
#* Rich and powerfull text input methods
#* MS Outlook/whatever Sync
#* (please add)
# '''Advanced Phone User''': won't be hard to persuade him. As we likely are all advanced phone users it will be easy to find reasons/features for him to buy this phone:
#* GPS-based profiles
#* Seamless GPS-based GSM/WiFi/VoIP-switching
#* (please add)
# '''Technophobe Phone User''' really needs some reasons for this phone:
#* Really easy to use (really not implemented ;-)
#* (please add)

=== Further Ideas ===
Something that came to me passing some mobile service provider's outlet today. This should be done when GTA_02 is available and software running.

''A guy walks into a mobile service provider's outlet or approached by the outlet's staff. The guy asks the clerk about their phones and ends up showing him his Neo. He explains him the Neo's features that stand unrivaled to any of the mobile service provider's offered phones and eventually leaves him completly flabbergasted and pondering about the meaning of life and mobile connectivity/whatever''

--[[User:Minime|Minime]] 16:58, 7 July 2007 (CEST)

=== Controversial Issues ===
* We need to be careful about using copyrighted material (e.g. youtube)
** Other legal issues...?
** Be aware of what we are advertising: What functions does OpenMoko currently feature, what is planned and what not? Are functions advertised protected by patents?
* What is the community's goal in advertising?
** Are we advertising OpenMoko?
** Are we advertising the Neo1973? And if so, is this our job? The Neo1973 is after all, a commerical product.

[[Category:Community]]
[[Category:Information]]

Hammerhead/Protocol

2007-07-16T17:18:17Z

Shadowjack: /* RECEIVED Packet 16 */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout
92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency".

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock. 1ms is also period of C/A PRN code.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Gpsd

2007-07-16T16:53:10Z

Shadowjack: /* Q: Can gpsd support Differential GPS. */

== What is GPS ==

The Global Positioning System (GPS) is a worldwide radio-navigation system formed from a constellation of 24 satellites and their ground stations.

GPS uses these "man-made stars" as reference points to calculate positions accurate to a matter of meters. In fact, with advanced forms of GPS you can make measurements to better than a centimeter!

In a sense it's like giving every square meter on the planet a unique address.

GPS receivers have been miniaturized to just a few integrated circuits and so are becoming very economical. And that makes the technology accessible to virtually everyone.

These days GPS is finding its way into cars, boats, planes, construction equipment, movie making gear, farm machinery, even laptop computers.

Soon GPS will become almost as basic as the telephone. Indeed, at Trimble, we think it just may become a universal utility.

(from the [http://www.trimble.com/gps/index.shtml GPS Tutorial])

(Another helpful overview [http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html Global Positioning System Overview])

== [[Hardware:AGPS|AGPS]] ==
is described on a [[Hardware:AGPS|page of its own]].

== PMB 2520 Hammerhead ==
The PMB 2520 Hammerhead is a one-chip solution for GPS that is produced by Infineon Technologies in cooperation with Global Locate. It allows the usage of assistance data by supporting A-GPS standards.

(all infomation is coming from the datasheet of PMB 2520)
[http://www.infineon.com/upload/Document/cmc_upload/documents/011/4061/pmb2520-pb-200505.pdf short datasheet]
=== Modules of the Hammerhead===

The Hammerhead consists of the following modules:
*RF front-end with on-chip, high gain and low noise, LNA, I/Q mixers, on-chip polyphase complex IF filter, digitally controlled AGC, and 3-bits ADC for the I and Q paths.
*Sigma-Delta RF PLL with on-chip PCO and on-chip loop filter.
*Embedded PLL and NCO for baseband clock generation.
*Multiple channels digital mixers and parallel correlator engines to enable real time correlation of the PRN code for up to 14 satellites.
*Post processor including peak detection logic
*SRAM for storing correlation results

=== Host Interface ===

The Hammerhead integrates 3 serial interfaces:
*UART
*I2C
*SPI

The UART in the Hammerhead is a full-duplex UART interface. It is fixed in 8N1(8 data bits, no parity, 1 stop bit) mode. On the GTA01, the host processor connect with the Hammerhead through the UART.

=== Host software Architecture ===

The Hammerhead driver software is delivered as a plugin for [http://gpsd.davisnetworks.com/bin/view/Main/GpsdHome gpsd].
It provides both high level positioning information in a number of formats, and an interface to feed in the AGPS data.

The gpsd libraries provide the following infomation to the high level software:
*Position data
*Library status
*Time-out and Packet Available

The high level software sends the following messages to the plugin:
*Assistance data
*Positioning Commands
*Configuration Commands

Gpsd communicates with the system at the following part:
*Communications Drivers
*System Timer
*NV storage
*Log buffer

== GPS on GTA01 ==

At the GTA01, the host processor is a S3C2410.

=== Hammerhead on the GTA01 ===

On the GTA01, the Hammerhead are configured that connected with the host processor through the UART. The UART of data output/input is connected to the UART 1 of the SC2410. The UART of the hardware flow control is connected to the UART 2 of the SC2410.

== Q & A ==

====Q: Can gpsd support Differential GPS.====
*While the neo does not have any means of receiving [http://en.wikipedia.org/wiki/Differential_GPS DGPS signals] directly, it can be streamed from the internet server. Peer-peer from stationary (charging?) neos that have GPS signal and cheap internet connections will now work, because we need precise coordinates of base station. However, we can use wide-area corrections (WAAS, SDCM), if someone will stream them. We even can setup own wide-area correction system.
*This can generate positions accurate to well under a metre, compared to (probably) 2-3m without.
*The gpsd plugin is the place that these corrections would need to be done, as they need to be performed on a per-satellite basis, before generating the position.
*This is separate from AGPS - AGPS gives information on current satellite position. DGPS is a local minute by minute 'ionospheric weather' for your region.

====Q: Can someone upload somewhere an strace of the interaction between gpsd, and the hammerhead chip?====
*Ideally this would be requesting a GPS position every second, starting from 'cold', with no AGPS data, for at least half an hour, in an area where the reciever can see the sky.
*To aid in reverse engineering efforts.
*A reverse-engineering page has been created: [[Hammerhead/Protocol]]

====Q: Can I get NMEA data from the GPS?====

A: Not directly. However, the gpsd program 'gpspipe', with the -r switch will output NMEA data with the current position information. The right way to do it is to use libgpsd in your program if possible.

[[Category:GPS]]

Hammerhead/Protocol

2007-07-16T13:25:38Z

Shadowjack: /* Analysis of FF packets */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{| border="1"
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 06 || 02 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 1 || 0c || 04 || <nowiki>c=8|4</nowiki> || CH:0 (global)
|-
| 6 || 0e || 05 || <nowiki>c=8|4</nowiki> || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout
92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency".

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-16T13:20:07Z

Shadowjack: /* Packet statistics */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
====Packet types====

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

====Analysis of FF packets====
found in [http://linuxtogo.org/~ph5/tmp/gllin/cold1.log.gz cold1.log.gz] (gz archive seems to be incomplete).
"Reply packet length" (RPL) reported as raw value seen in packet.
Total packets: 61.
Unique packets: 10.
{|
! Frequency !! Type !! RPL !! Flags !! Channels
|-
| 1 || 00 || 0c || c=8|4 || CH:0 (global)
|-
| 1 || 06 || 02 || c=8|4 || CH:0 (global)
|-
| 1 || 0c || 04 || c=8|4 || CH:0 (global)
|-
| 6 || 0e || 05 || c=8|4 || CH:2, (CH:4)*4, CH:5
|-
| 3 || 16 || 00 || 8 || CH:0 (global)
|-
| 49 || 23 || 07 || 8 || (CH:2)*12, (CH:4)*17, (CH:5)*20
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout
92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency".

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hammerhead/Protocol

2007-07-15T17:54:19Z

Shadowjack: /* Possible lock scheme that it may use */

We have set up a SCM repository for experimental code and documentation at http://projects.linuxtogo.org/projects/sphyrna.

Christian did some stracing on TomTom device, and result is great logs at http://www.maintech.de/download/hammerhead-strace.log . 'pH5' on IRC has put up some traces at http://linuxtogo.org/~ph5/tmp/gllin (a cold start, a hot start and a somewhat longer trace). He even has a software that can init and send command to phase-1 openmoko device in http://linuxtogo.org/~ph5/tmp/hhtest.c . (Please use strace -s9999 -x to produce traces).

[http://en.wikipedia.org/wiki/GPS_signals GPS signals at wikipedia] seems to be required reading for very basics, along with [http://www.colorado.edu/geography/gcraft/notes/gps/gps.html this page from University of Colorado] for more in depth stuff.

http://home.earthlink.net/~cwkelley/ has sources for open-source GPS receiver, and
http://home.earthlink.net/~cwkelley/documentation.htm is its documentation.

GP2021 is "dumb" GPS receiver, similar to hammerhead. (But I think it communicates over ISA bus, not over serial). However, its data sheets are freely available. Well, hammerhead marketing tells us that their GPS chip is something special, http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053 . It seems to differ from "dumb" receivers by doing code phase search in hardware, directly.

== Possible lock scheme that it may use ==

From reading the published brief information sheets on global locates products, not the patents.
The global locate chip has massively parallel correlators, and configurable integrators to integrate over a given time.
I would expect it to do something like - in this case.
*Load orbit data from file (or download from net).
*Look at time.
*Get apriori position.
*Compute positions of satellites. Using apriori position, compute satellite visibility and relative speeds.
*Init the GPS.
*Set the hardware to expect to receive from the set of visible satellites (the hardware is unlikely to be designed to receive them all at once, as you'll never see more than around 16 of the nominal 32).
*Set the integration time at 10ms-20ms or so - around, or a bit under a data bit.
*Now, read back the outputs of the integrators, to see if we've got possible data (carrier lock?).
*If we do have data, spend a bit of time working out the exact relative phase of the PRN with regard to the carrier - each 'chip' of the PRN is around a thousand cycles of the carrier - you need to work this out exactly to get psuedoranges with a resolution of under a meter.
**it's possible this is done in hardware
*Now that we've got all the satellites locked in the hardware, simply interrogate the hardware regularly, so that we can read out the 50bps datastream from each satellite.
**It seems this step takes 19s or so. From the first timestamp in the file, to the first GPGSV line - satellites in view, and their actual signal strengths.
*Read the navigation messages from each satellite, which cycles every 6 seconds.
*Compute a position.
*Output it to NMEA
** It seems this takes 22 seconds.

== Enhancements ==

To keep to the datasheet of 1s position times, it cannot read the whole navigation message, but significantly under 50 bits of it.
It must:
*Use 'AGPS' data to initialise the hardware to a condition where it can get a rapid lock - perhaps telling it the Doppler - then compute what the navigation message from each satellite may be, based on the internal clock.
*Work out at what point in this navigation message the 20-30 bits that it's received come.
*Compute the time that was in the navigation message, though it may not have picked it up (from the internal clock) and add it to the information on where the bit edges are from the hardware.
**If the uncertainty in relative time - due to local clock drift and movement of the GPS device - is under 10ms, then you know immediately as you detect the satellite signal the current satellite time - you simply snap the time to the nearest bit-edge, letting you immediately compute a position, without waiting for more data.
***With typical crystal accuracy, this implies you need to take a position every 3 minutes or so in order to keep the clock set correctly enough for this to work.
**This gives you a psuedorange to the satellite to within several meters.
*Compute a position.

== Analysis ==

Looks like there were 8 satellites overhead at the time that log was made.

The protocol appears to be oriented around 32-bit words (the single-byte markers notwithstanding.) LSB-first, as can be seen on negative numbers.

The first stream of 0x80's to the GPS is simply to synch up the UART in the GPS to the correct baudrate.

=== Packet format ===
Packet format (same format in both directions):
* The start of a packet is marked by FF or FE.
** FF in packets that do not carry data, but rather explicitly request a response. (This isn't used very often. More often we receive data without explicitly requesting it.) The response will be an FE-packet with the same length and type as the FF-packet. The GPS does not send any FF packets, only gltt does.
** FE in packets that carry data sections.
* The first word (32 bits) following the start-of-packet marker is the header.
** The first byte (if it's indeed little-endian, the least significant byte) gives the data length, measured as ''the number of data words minus 1.'' For FE-packets, this is the length of the data section of this packet. For FF-packets, it's the length of the data section in the expected response.
** The second byte of the header is always FD.
** MS nibble of the third byte might be flags for the packet.
*** 0x4 set: The words are for increasing register numbers
*** 0x4 not set: The words are for/from the same register. The register is probably something like a FIFO
** LS nibble of the third byte is an identifying number of the channel (1-8), 0 in case this is not channel-specific
** The fourth byte is the packet type. It seems to be more like a register (start) number.
* In FE-packets only, the data section (''n'' 32-bit words) follows.
* Finally, FC is sent to mark the end of the packet.
* After the FC in an FF-packet, gltt sends a bunch of zeros. In some cases it sends a number of zeros equal to the number of bytes in the response packet; in some cases it sends more. I would guess that these have no effect.

For example:
ff 04fdc00c fc
(possibly followed by zeros), is a request for a packet of type 0C, with length 20d ((4 + 1) * 4), and flags C0.

fe 04fdc00c 0025102a 45dbdd4e 36030000 4b260000 16010000 fc
would be an appropriate response.

=== Packet statistics ===
Packet types:

(Ugh, I do not understand this. Is it SEND or RECEIVED packets? [[User:Pavel|Pavel]] 22:26, 6 May 2007 (CEST))

{|
| Frequency || Type || Max length || Min length
|-
| 9 || 16 || 73 || 11
|-
| 86 || 08 || 19 || 11
|-
| 8 || e2 || 15 || 15
|-
| 7 || 23 || 133 || 101
|-
| 63 || 0a || 15 || 15
|-
| 6 || 24 || 71 || 39
|-
| 52 || 0b || 11 || 11
|-
| 4 || 01 || 11 || 11
|-
| 263 || 05 || 19 || 15
|-
| 24 || 9d || 315 || 19
|-
| 2 || 06 || 25 || 19
|-
| 16 || e0 || 11 || 11
|-
| 13 || 20 || 15 || 15
|-
| 13 || 10 || 577 || 59
|-
| 128 || 18 || 11 || 11
|-
| 12 || 9e || 303 || 15
|-
| 117 || 00 || 65 || 39
|-
| 11 || 0c || 33 || 11
|-
| 10 || 9f || 477 || 61
|-
| 10 || 0e || 541 || 31
|-
| 1 || e5 || 11 || 11
|-
| 1 || 80 || 17 || 17
|-
| 1 || 13 || 11 || 11
|-
| 1 || 04 || 23 || 23
|-
| 1 || 02 || 11 || 11
|-
|}

=== Global packets ===

All packets in this category have the "channel" (or "ID") field set to 0.

==== SEND Packet 04 ====

Flags = 4

In cold2.log this packet comes only once at the start.
Part of this packet seems to setup the timestamp clock (see packet 16).

Usual layout
92 24 11 02 7b 39 8e 23 00 00 00 00 7b 39 8e 23

Word 2 and 4 (both are 0x238e397b = 596523387) seem to control the timestamp clock. Multipliying this value by say 0.99 makes the timestamp clock run at 0.99 its normal speed. So this value is some sort of "frequency".

==== SEND Register/Packet 08 ====

One 32 bit word bitmask

* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.
* 0x40: Unknown
* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4000 triggers a measurement on channels, that have been setup. This needs an edge, so you have to unset and then set this bit.

==== RECEIVED Packet 0c ====

Flags = 0

Is global -- not about particular sattelite, probably fixed length and rare.

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock.

It seems, that the clock can be widely tuned (probably using divider or so): At least I saw 1000 ticks and 2000 ticks per second.

CMD-04 and CMd-08 seem to be needed to init and start it.

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

Packet type 00 (with the exception of the very first FE-packet in the log) appears to specify a particular satellite to track. It also seems that this specifies the "ID" field (LS nibble of the third header byte) that will be used for future packets concerning this satellite. (Non-satellite-specific packets have ID=0.)

Bits 3-7 of the 11th byte of the packet -- third byte of the third data word -- are the satellite PRN number. In this log only 8 satellites appear to be tracked (2, 4, 8, 10, 13, 23, 27, 29). If I'm reading the GPGSV messages correctly, 24 should also be visible, but it doesn't appear gltt even attempts to track it.

As for the rest of the packet... There's a lot that gets repeated, information common to all the satellites, at least initially. When a batch of 8 of these packets gets sent, usually only the PRN and two other words differ among the 8. So those two words contain whatever satellite-specific info is needed, it seems. They both appear to be little-endian integers, one around -10^8 and one around 10^8.

(Info needed to search for sattelite... doppler frequency range and phase range is useful).

==== RECEIVED Packet 10 ====

Last four bytes are the little endian timestamp, in miliseconds. (Ok, it may actually be number of frames or something on that particular channel).

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

It carries variable-length array of 16-bit integers... 6 to 32 entries were seen.

==== RECEIVED Packet 06, 08 ====

short packets, 06 has varying length, and both are rare.

==== RECEIVED Packet 9d ====

Okay, so packets 10, 23 and 9d come in groups, for each sattelite, and they seem to contain enough info to compute position. (9d seems to come later than the other two, perhaps only after sending a packet 08?)

Packet 9d seems to contain 2 32-bit integers (second one is signed), then 3, 0, 0 and flags (?) -- so the packet length is constant.

==== RECEIVED Packet 0e ====

Always appears to be 24 bytes. Satellite-specific.

==== RECEIVED Packet 9e ====

Always appears to be 8 bytes. Satellite-specific. First 4 bytes are a signed 32-bit integer.

==== RECEIVED Packet 9f ====

Comes in variants of differing lengths: 20, 36, and 84-byte packets were seen. Satellite-specific.

== NMEA ==

It is possible to translate NMEA messages into something readable using script from http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hhdecode , and using c decoder http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/hh.c .

NMEA description is available at http://www.gpsinformation.org/dale/nmea.htm .

At this point:

256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(GPS, "\xfe\x00\xfd\x40\x08\x40\x60\x00\x00\xfc", 10) = 10
256 write(NMEA, "\x24\x47\x50\x47\x47\x41\x2c\x31\x35\x34\x31\x30\x34\x2e\x39\x35\x2c\x34\x39\x34\x38\x2e\x39\x35\x30\x33\x33\x39\x2c\x4e\x2c\x30\x30\x39\x35\x37\x2e\x39\x35\x35\x39\x37\x39\x2c\x45\x2c\x31\x2c\x30\x36\x2c\x35\x2e\x30\x2c\x32\x32\x30\x2e\x30\x2c\x4d\x2c\x2d\x30\x2e\x35\x38\x31\x30\x31\x34\x2c\x4d\x2c\x2d\x30\x2e\x31\x39\x30\x30\x31\x39\x30\x2c\x2a\x34\x30\x0d\x0a", 91) = 91
256 write(NMEA, "$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
", 91) = 91

...6 satelitte GPS fix was obtained. (And yes, there's big read few lines before that in the log).

GSA sentence looks interesting, too. It tells us satellites #02, #04, #08, #10, #13 and #27 were used at this point.

256 write(NMEA, "\x24\x47\x50\x47\x53\x41\x2c\x41\x2c\x33\x2c\x30\x32\x2c\x30\x34\x2c\x30\x38\x2c\x31\x30\x2c\x31\x33\x2c\x32\x37\x2c\x2c\x2c\x2c\x2c\x2c\x2c\x36\x2e\x37\x2c\x33\x2e\x30\x2c\x36\x2e\x30\x2a\x33\x45\x0d\x0a", 51) = 51
256 write(NMEA, "$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E

The whole log is
<pre>
$GPGGA,154035.21,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6A
$GPRMC,154035.24,V,,,,,,,240407,,*1A
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154035.61,,,,,00,00,5.0,,M,-0.586099,M,-0.1700199,*6E
$GPRMC,154035.63,V,,,,,,,240407,,*19
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,154038.24,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4B
$GPRMC,154038.29,V,,,,,,,240407,,*1A
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154038.54,,,,,00,04,300.0,,M,-0.586099,M,0.0000199,*4C
$GPRMC,154038.56,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154042.72,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*46
$GPRMC,154042.74,V,,,,,,,240407,,*1F
$GPGSV,3,1,09,27,77,114,24,08,59,192,33,10,46,302,33,02,33,244,34*7E
$GPGSV,3,2,09,04,18,206,33,13,42,076,25,29,11,271,29,24,243,352,*49
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154043.67,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*43
$GPRMC,154043.69,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,27,,,,,,,,669.0,300.0,600.0*36
$GPGGA,154046.89,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*47
$GPRMC,154046.93,V,,,,,,,240407,,*12
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154047.14,,,,,00,06,300.0,,M,-0.587100,M,0.0000199,*42
$GPRMC,154047.19,V,,,,,,,240407,,*11
$GPGSA,A,1,02,04,08,10,,,,,,,,,669.0,300.0,600.0*33
$GPGGA,154050.07,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*47
$GPRMC,154050.10,V,,,,,,,240407,,*1E
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154050.45,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*41
$GPRMC,154050.47,V,,,,,,,240407,,*1C
$GPGSV,3,1,09,27,77,114,24,08,59,192,26,10,46,302,25,13,42,076,16*78
$GPGSV,3,2,09,02,33,244,26,04,18,206,25,29,11,271,25,24,243,352,*44
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154053.35,,,,,00,06,300.0,,M,-0.586100,M,0.0000199,*45
$GPRMC,154053.37,V,,,,,,,240407,,*18
$GPGSA,A,1,27,,,,,,,,,,,,669.0,300.0,600.0*39
$GPGGA,154058.70,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*49
$GPRMC,154058.72,V,,,,,,,240407,,*12
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154058.97,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*40
$GPRMC,154058.98,V,,,,,,,240407,,*16
$GPGSA,A,1,02,,,,,,,,,,,,669.0,300.0,600.0*3E
$GPGGA,154059.38,,,,,00,03,300.0,,M,-0.581014,M,0.0000199,*44
$GPRMC,154059.40,V,,,,,,,240407,,*12
$GPGSA,A,1,02,13,,,,,,,,,,,669.0,300.0,600.0*3C
$GPGGA,154104.95,4948.950339,N,00957.955979,E,1,06,5.0,220.0,M,-0.581014,M,-0.1900190,*40
$GPRMC,154104.95,A,4948.950339,N,00957.955979,E,000.0,000.0,240407,,*3E
$GPGSV,3,1,09,08,59,192,42,10,46,302,42,04,18,206,41,27,77,114,16*74
$GPGSV,3,2,09,13,42,076,18,02,33,244,18,29,11,271,40,24,243,352,*48
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,04,08,10,,,,,,,,,,11.2,5.0,10.0*39
$GPGGA,154106.52,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.581025,M,-0.1900190,*4A
$GPRMC,154111.60,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154122.94,,,,,00,06,3.0,,M,-0.581010,M,-0.1900190,*62
$GPRMC,154122.96,V,,,,,,,240407,,*14
$GPGSA,A,1,13,,,,,,,,,,,,6.7,3.0,6.0*36
$GPGGA,154119.10,4948.936977,N,00957.930742,E,1,05,3.0,245.0,M,-0.576004,M,-0.1870190,*4D
$GPRMC,154119.10,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3A
$GPGSA,A,3,04,08,10,27,,,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154128.15,4948.936977,N,00957.930742,E,1,06,5.0,245.0,M,-0.587003,M,-0.1860190,*47
$GPRMC,154128.15,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3D
$GPGSV,3,1,09,27,77,114,22,08,59,192,39,10,46,302,39,02,33,244,40*7B
$GPGSV,3,2,09,04,18,206,38,13,42,076,11,24,243,352,,23,14,085,*48
$GPGSV,3,3,09,29,11,271,*4F
$GPGSA,A,3,02,04,08,10,27,,,,,,,,11.2,5.0,10.0*3E
$GPGGA,154131.86,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578004,M,-0.1860190,*44
$GPRMC,154131.86,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*3F
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154138.55,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.578000,M,-0.1860190,*47
$GPRMC,154138.55,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*38
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154141.69,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.583002,M,-0.1840190,*42
$GPRMC,154141.69,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*39
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154146.16,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.595000,M,-0.1830190,*4F
$GPRMC,154146.16,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*36
$GPGSA,A,3,02,04,08,10,27,,,,,,,,6.7,3.0,6.0*3C
$GPGGA,154151.34,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*4D
$GPRMC,154151.34,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*30
$GPGSV,3,1,09,27,77,114,26,08,59,192,42,10,46,302,41,13,42,076,25*7A
$GPGSV,3,2,09,02,33,244,42,04,18,206,37,29,11,271,37,24,243,352,*46
$GPGSV,3,3,09,23,14,085,*49
$GPGSA,A,3,02,04,08,10,13,27,,,,,,,6.7,3.0,6.0*3E
$GPGGA,154200.05,4948.936977,N,00957.930742,E,1,06,3.0,245.0,M,-0.587002,M,-0.1860190,*48
$GPRMC,154200.05,A,4948.936977,N,00957.930742,E,000.0,000.0,240407,,*35
$GPGSA,A,3,,,,,,,,,,,,,6.7,3.0,6.0*36

</pre>

[[Category:GPS]]

Hardware:Neo1973:Alternate Cases:General-purpose buttons (side-mounted)

2007-07-15T12:16:23Z

Shadowjack: /* Interest */

Alternate case for the Neo1973, with side-mounted dual-state buttons.

==Concept==
Two hardware buttons for simple tasks such as volume up/down, zoom in/out.

==Sub-variants==
Buttons on right-hand side 
Buttons on left-hand side

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==
Buttons

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick
|-
| 1. || [[User:Shadowjack|Shadowjack]]
|-
| 2. ||
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:Stylus mount

2007-07-14T17:19:08Z

Shadowjack: /* Interest */

Alternate case for the Neo1973, with a secure method for storing the stylus when not in use.

==Design options==
1. The stylus is pushed end-on into a round hole slightly larger than the stylus and retained by a spring-loaded clip at the end. 
2. The stylus is stored by pushing laterally into a C-section clip.

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick
|-
|1. || [[User:Tetraden|Tetraden]]
|-
|2. || [[User:Shadowjack|Shadowjack]]
|-
|3. ||
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:Removal of free space

2007-07-14T17:16:38Z

Shadowjack: /* Interest */

=Concept==
There is unnecessary free space within the case - this variant would remove that, possibly with some re-arrangement of components, to make the phone slightly smaller.

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick
|-
|1. || [[User:Chooseopen|Chooseopen]]
|-
|2. ||
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:General-purpose buttons (side-mounted)

2007-07-14T17:15:27Z

Shadowjack: /* Interest */

Alternate case for the Neo1973, with side-mounted dual-state buttons.

==Concept==
Two hardware buttons for simple tasks such as volume up/down, zoom in/out.

==Sub-variants==
Buttons on right-hand side 
Buttons on left-hand side

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==
Buttons

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick
|-
| 1. || Shadowjack
|-
| 2. ||
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:General-purpose buttons (side-mounted)

2007-07-14T17:06:06Z

Shadowjack: /* Interest */

Alternate case for the Neo1973, with side-mounted dual-state buttons.

==Concept==
Two hardware buttons for simple tasks such as volume up/down, zoom in/out.

==Sub-variants==
Buttons on right-hand side 
Buttons on left-hand side

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==
Buttons

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick !!
|-
|1. Shadowjack
|-
|}

[[Category:Neo1973_alternate_cases]]

Talk:Hardware:Neo1973:Alternate Cases:Extra battery

2007-07-14T17:05:03Z

Shadowjack:

Should not nick list be numbered list instead of table?