{{Languages|OpenEmbedded}}

Openmoko, our distribution, is built using OpenEmbedded. OpenEmbedded will:

* Generate (cross-compile) software packages for multiple embedded targets.
* Handle different hardware architectures, and support multiple releases across those architectures.

For more information please see the [http://www.openembedded.org/ Open Embedded] website.

== Building the Openmoko Distribution with OpenEmbedded ==

'''Note:''' If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt [[Toolchain]]. For more complex applications with many library dependencies, download a prebuilt [[OpenEmbedded Torrent]].

Building Openmoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your Openmoko distribution.

=== Simplified Instructions: MokoMakefile ===

For beginners who wish to customize their Openmoko distribution, the facility called [[MokoMakefile]] simplifies building OpenEmbedded.

=== Quick Start: OpenEmbedded Torrent ===

If you are a system developer and would like to get up-to-speed as quickly as possible, then download an [[OpenEmbedded Torrent]].

== From Scratch: OpenEmbedded ==

Beginner Openmoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.

=== Preparations ===

Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The [http://wiki.openembedded.net/index.php OpenEmbedded Wiki] provides [http://wiki.openembedded.net/index.php/OEandYourDistro setup instructions] for FreeBSD, Mac OS X, and most major Linux distributions, of course.

For OpenEmbedded installation instructions please refer to [http://wiki.openembedded.net/index.php/OEandYourDistro OEandYourDistro].

=== ${OE_HOME} ===

Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.

For Bash users:
export OE_HOME=${HOME}/oe

For Tcsh users:
setenv OE_HOME ${HOME}/oe

Next, run 'mkdir -p ${OE_HOME}' to create the directory.

=== Synchronizing OpenEmbedded With Git ===

Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable .

To syncronize the OpenEmbedded tree, run
<pre>
git clone git://git.openembedded.net/openembedded ${OE_HOME}/org.openembedded.dev
</pre>

Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the [http://wiki.openembedded.net/index.php/GitPhraseBook OE GitPhraseBook] for more info on checking out different branches.

To update the tree, run
<pre>
cd ${OE_HOME}/org.openembedded.dev
git pull
</pre>

For further information on Git, see [http://git-scm.com The Git Homepage].

Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'.
<pre>
org.openembedded.dev
|-- classes
| |-- rootfs_ipk.bbclass
| `-- xorg-module.bbclass
|-- conf
| `-- local.conf.sample
| |-- distro
| | `-- angstrom-2008.1.conf
| |-- machine
| | |-- om-gta01.conf
| | `-- om-gta02.conf
`-- packages
|-- tangogps
| |-- tangogps.inc
| `-- tangogps_0.9.3.bb
`-- images
|-- console-image.bb
|-- fso-console-image.bb
|-- fso-image.bb
|-- openmoko-image.bb
|-- opie-image.bb
`-- x11-image.bb
</pre>

=== local.conf ===

If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory.

'''Note:''' Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} .

Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages.
<pre>
OE_HOME ?= "${HOME}/oe"

MACHINE = "om-gta02"
DISTRO = "openmoko"

DL_DIR = "${OE_HOME}/downloads"

BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"

BBMASK = ""

TMPDIR = "${OE_HOME}/build-${MACHINE}/tmp"
CACHE = "${TMPDIR}/cache"

IMAGE_FSTYPES = "jffs2 tar.gz"

ENABLE_BINARY_LOCALE_GENERATION = "0"
</pre>

The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.

=== setup-env ===

For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script.

setup-env for Bash users:
<pre>
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02
export BBPATH=${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev
</pre>
setup-env for Tcsh users:
<pre>
[[ -z ${OE_HOME} ]] && setenv OE_HOME ${HOME}/oe
[[ -z ${MACHINE} ]] && setenv MACHINE om-gta02
setenv BBPATH ${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev
</pre>
To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.

See the section entitled [http://wiki.openmoko.org/wiki/OpenEmbedded#BitBake_Overlays BitBake Overlays] for an example of a more complicated setup-env script.

=== Testing the OE Build Environment ===

That's it! Now you should be prepared to bake your first BitBake recipe.

bitbake helloworld

=== Building an Image ===

There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images

A good place to start is with

bitbake fso-image

That concludes this introduction to BitBake and OpenEmbedded. Good luck!

=== Other References ===

Please feel free to refer to other online sources of information for [http://bitbake.berlios.de BitBake], [http://www.openembedded.org OpenEmbedded], and the [http://www.angstrom-distribution.org Angstrom Distribution] to name a few.

== Broken Builds and Bug Reporting ==

Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.

Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.

Below are a few useful steps to follow when a build does not successfully complete:

* Identify the package that failed to build
** Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'
* If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead
** bitbake -c clean somepackage && bitbake -b ${OE_HOME}/org.openembedded.dev/packages/somepackage/somepackage_0.1.bb
** add PREFERRED_VERSION_somepackage = "0.1" to local.conf
* Read the BitBake log, as well as config.log if it exists
** Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc.
* Try to identify the root cause of the error
** In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error
** Most packages that build with autotools will also have a config.log file that contains the exact cause of the error
* If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.
* Otherwise, check the [http://bugs.openembedded.net OpenEmbedded Bugzilla] to see if the error is known.
* If a solution is already available, then try it out. If you can fix the error, then do so. If your solution is correct, please post all relevent patches to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]

=== Where to Report Bugs ===

Authentic bugs should be reported to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]

== Tips & Tricks ==

=== Setting the PREFERRED_VERSION for a package ===

If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages.

For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".

=== Screen is Your Friend ===

If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well.

In order to ensure that a build continues in the presence of communication failures, it is advisable to use the [http://www.gnu.org/software/screen GNU Screen] utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.

Screen installation varies with your OS and distribution.

=== BitBake Overlays ===

Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately.

Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.
<pre>
oe
|-- build-beagleboard
| |-- conf
| | `-- local.conf
| `-- tmp
|-- build-om-gta02
| |-- conf
| | `-- local.conf
| `-- tmp
|-- build-ts72xx
| |-- conf
| | `-- local.conf
| `-- tmp
|-- com.somecompany.dev
| |-- conf
| | `-- machine
| `-- packages
| |-- images
| | `-- console-image.bb
| `-- rxtx
| |-- files
| |-- rxtx-fixes-from-debian.patch
| `-- rxtx_2.1-7r2.bb
|-- org.openembedded.dev
| |-- conf
| | `-- machine
| `-- packages
| `-- images
|-- org.openmoko.dev
| |-- conf
| | `-- machine
| `-- packages
| `-- tangogps
| |-- tangogps.inc
| `-- tangogps_0.9.3.bb
`-- setup-env
</pre>

An example of the setup-env script with multiple overlays and multiple build targets is below.

<pre>
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02

unset BBPATH

case "${MACHINE}" in
"beagleboard" | "ts72xx" )
BBPATH="${OE_HOME}/com.somecompany.dev"
;;
"om-gta02")
BBPATH="${OE_HOME}/org.openmoko.dev"
;;
*)
echo -e "error: unsupported machine"
exit -1
;;
esac

export BBPATH=${BBPATH}:${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev
</pre>

Note that the overlay-specific BBPATH entry ''precedes'' the default BBPATH entries.

Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).

<pre>
...
BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"
BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"

BBFILE_COLLECTIONS = "upstream moko"
BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"
BBFILE_PRIORITY_upstream = "0"
BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"
BBFILE_PRIORITY_moko = "1"
...
</pre>

In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.

=== Useful BitBake Commands ===

<pre>
# list all of the tasks defined for a given package_name
bitbake -c listtasks <package_name>

# clean the work directory for a specific package
bitbake -c clean <package_name>

# build a specific recipe
bitbake -b <path/to/some/recipe.bb>

# if files or variables not found debug with
bitbake -D -D -D
</pre>

[[Category:Application Developer]]
[[Category:System Developers]]

Om 2009

2009-04-14T15:42:00Z

Nytowl: /* Bug List and Known Issues */

Om 2009

2009-04-13T14:25:25Z

Nytowl: /* Bug List and Known Issues */

2008-11-10T20:18:39Z

Nytowl: /* Bluetooth GPS relay */

{{Neo FreeRunner Menu}}

== Basic Setup ==

For basic setup instructions, check the [[Getting_Started_with_your_Neo_FreeRunner#Use the GPS|GPS getting started instructions]].

Note that there is a known issue between the GPS and SD card slot which is discussed [[GPS_Problems|here]].

== Testing ==

* [[Howto_Test_Your_GPS_with_agpsui| How to test your GPS with agpsui]]

* Shell test script for raw data dump:

<pre>
echo 0 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron &&
sleep 1s && echo 1 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron && stty -F /dev/ttySAC1 -echo && cat -u /dev/ttySAC1 | grep -v ^$
</pre>

== Low level access ==

This section is for debugging and daemon development only. Applications should use a higher level interface (see next section).

There is no userland driver required for the GTA02; the driver is built into the kernel.

To turn on the GPS, echo 1 to the sys file:

echo 1 > /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron

To read from the GPS, simply read /dev/ttySAC1. Enter the gpspipe command as follows:

gpspipe -r 127.0.0.1 2947

You will find gpspipe in the package gps-utils. You can also just "cat /dev/ttySAC1", but it produces the unknown msg*58. This doesn't happen with gpspipe.

Before getting a fix, the GPS spits out lots of "$GPTXT,01,01,01,NMEA unknown msg*58", though these stop once a fix is obtained.

A position without a fix looks like this:
$GPGGA,235946.99,,,,,00,00,5.0,,M,0.0001999,M,0.0020199,*57

A position with a fix looks as follows:
$GPGGA,065852.00,5613.022527,N,00306.725890,W,1,05,0.5,158.0,M,0.277000,M,-0.010 0515,*7A

(The [http://openstreetmap.org/?lat=56.13&lon=-3.067&zoom=9&layers=B000TFF given position] is in central Scotland.)

--[[User:Speedevil|Speedevil]] 11:52, 7 April 2008 (CEST)

If you are having GPS problems with your FreeRunner, please document them on the page [[GPS Problems]]. [[FreeRunner GPS antenna repair SOP]] documents a possible solution.

In Openmoko projects, there is a GPS test program called '''agpsui''' that provides a graphical and text dump of GPS information. See [[Howto Test Your GPS with agpsui]]. The project is called [http://svn.projects.openmoko.org/svnroot/openmoko-agpsui Openmoko AGPS UI project].

== Using GPS ==

Aside from accessing the GPS data in applications programs running directly on the smartphone,
you can also access the GPS data stream from another device such as a laptop.

Here are a couple ways to do that. You can use a network connection to pull data from the gpsd daemon, or you can make the smartphone appear to be a generic Bluetooth-connected GPS receiver.

Using gpsd requires a program that understands its protocol, such as GPSdrive.
Using Bluetooth would allow using just about any program that understands the NMEA protocol.

=== GPS Daemons ===

The GPS uses a single serial connection for communication, and this cannot be shared directly by applications. To provide simultaneous access to GPS data for multiple applications, and to provide a consistent interface for the applications, we use a daemon as an intermediary. There are two daemons you are likely to meet on the Openmoko phones:

==== gpsd ====
This is used on Om 2008.x and FDOM. It implements the widely used gpsd protocol and can share gps data over a network.
==== ogpsd/fso-gpsd ====
Ogpsd is used on FSO and SHR, and implements the Gypsy dbus protocol. For compatibility with applications needing the gpsd protocol there is a helper daemon, fso-gpsd, which translates ogpsd output to the gpsd protocol.

{{Warning|Do not run more than one gps daemon at a time. They will both try to talk to the gps serial port, and neither will work properly.}}

=== Using gpsd with a network connection ===

This procedure depends upon being able to set up a network connection between your Neo and your laptop. The connection can be over either WiFi or USB cable.

First be sure you have gpsd installed. Some Neo FreeRunner images don't have gpsd, they use a different GPS stack called gypsy.

# On host type: '''nc -vvn -l -p 5000 > /tmp/nmeaNP''' (Host starts listening on port 5000 for GPS-signals and sends them to /tmp/nmeaNP)
# On the Neo type: '''nc 192.168.0.200 5000 < /dev/ttySAC1''' (Signals from device will be send to port 5000 on host.) If your host is connected to the neo via wifi, change the IP address in the command to the one of the host.
# On the host PC install GPSD, your GPS is attached as /tmp/nmeaNP
# start gpsd on host with: '''gpsd -p /tmp/nmeaNP'''
# run your application! I used gpsdrive and it works better than my stand-alone GPS.

Tested with RoadNav. Works great!

Another way is to forward gpsd on the neo. If '192.168.0.202' is your neo, then run "ssh -L 2947:localhost:2947 root@192.168.0.202" on the host.

Tested and works with roadnav, gpsdrive, and tangogps on the host computer. [[User:Sargas|Sargas]] 21:52, 16 August 2008 (UTC)

If you have an unlimited [[GPRS]] data package you could make your gpsd service accessible over the Internet. This opens up many possibilities. For example, you could implemented AVL ([http://en.wikipedia.org/wiki/Automatic_Vehicle_Location Automatic Vehicle Location]) by having a web server somewhere query your gpsd server for your position and write it to a KML file which would then display your location on a Google map.

=== Bluetooth GPS relay ===

Here is how to make your smartphone appear to be a Bluetooth GPS.

#Power up the bluetooth radio
#Ensure [http://wiki.openmoko.org/wiki/Gpsd#GPS_on_GTA02 gpsd] is running and the gps-utils package is installed
#Run '''sdptool add SP'''
#Run '''rfcomm -r watch 0 1 sh -c "gpspipe -r >/dev/rfcomm0" &'''

There are some scripts [http://handheldshell.com/software/bluetooth.php here] to simplify the process

== GTA02 GPS Hardware Assist Feature ==

GTA02 is using the [[u-blox ANTARIS 4 ATR0635]] hardware and could use [http://www.u-blox.com/services/assistnow_online.html u-blox AssistNow Online] GPS (A-GPS) servces. GTA02 hardware design does not comply with official Assist Offline service requirement.

=== Assist Online/Offline comparsion ===

The "A"GPS support could cut TTFF time from 40 secs to 10-20 seconds. And the valid time of assist now download is about 4 hours. You could also check the following address:

http://embedded-system.net/assistnow-gps-services-boost-up-gps-receiver-performance-u-blox.html

Due to the [[u-blox ANTARIS 4 ATR0635]] need to have extra flash to storage up to 14 days of offline data (90 KBytes).

=== Assist Online ===

Each download package could have up to 4 hours vaild data to assist TTFF. For u-blox Assist Online, you have to provide approximate longitude/latitude and time to get the corresponds "almanac" and "ephemeris" package. This might be base on application design for how to provide the longitude/latitude. User could select the location area from list menu or world map, or better implementation using the GSM/wi-fi location technique/service.

==== u-blox Assist Online implementation ====

For GTA02 default shipment image, there is no A-GPS/GPS supported software inside. You could find the u-blox A-GPS online implementation document here:

* Documentation: http://people.openmoko.org/matt_hsu/ImplementationAssistNowServerAndClient(GPS.G4-SW-05017-C).pdf

And implementation code in following address.

* Source code: http://svn.openmoko.org/developers/matt_hsu/agps-online/

Here is a brief script to run this application:

#!/bin/sh

echo 1 >/sys/bus/platform/drivers/neo1973-pm-gps/neo1973-pm-gps.0/pwron

./agps-onlinec -c full -u youraccount -k yourpasswd -la 25.073270 -lo
121.574805 -p 999999.00

cat /dev/ttySAC1

-la 25.073270 -lo 121.574805 is reference latitude/longtitude

Here is a simple perl skript doing the same:

<pre>
#!/usr/bin/perl -wT
#
# ublox AssistNow Online almanach downloader for Neo FreeRunner
#
# v0.1
#
# Wilfried Klaebe <wk-openmoko@chaos.in-kiel.de>
#
# Usage:
#
# agps-alm.pl > /dev/ttySAC1
#

use strict;
use IO::Socket::INET;
use vars qw(%h);

my $user = 'user@somewhere.invalid';
my $pass = 'pass-from-ublox';

my $s = new IO::Socket::INET(PeerAddr => 'agps.u-blox.com', Proto => 'tcp', PeerPort => 46434);

$s->print('user='.$user.';pwd='.$pass.';cmd=alm;lat=0;lon=0;pacc=40000000;', "\n");

print STDERR $s->getline;

while(my $l = $s->getline) {
print STDERR $l;

$l =~ s/(\r\n|\n)+\Z//g;

if ($l eq "") {
if ($h{'content-length'} > 0 && $h{'content-type'} eq 'application/ubx') {
$s->read($l,$h{'content-length'});
print $l;
}
exit(0);
}

if ($l =~ m/\A(.+): (.+)\Z/) {
$h{lc($1)} = lc($2);
}
}
</pre>

This also works with <tt>cmd=full</tt> and meaningful lat/lon/pacc values.

Same in python:

<pre>
#!/usr/bin/python
#
# ublox AssistNow Online almanach downloader for Neo FreeRunner
#
# v0.1
#
# Wilfried Klaebe <wk-openmoko@chaos.in-kiel.de>
#
# Usage:
#
# agps-alm.py > /dev/ttySAC1
#

import sys
import socket
import re

user='your@mail.address'
pwd='pwdfromublox'

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('agps.u-blox.com',46434))

s.send('user='+user+';pwd='+pwd+';cmd=alm;lat=0;lon=0;pacc=40000000;\n')

buf = s.recv(4096)
while 1:
b = s.recv(4096)
if not b:
break
buf += b

h = {}

while 1:
(l,s,buf) = buf.partition('\n')
l = l.rstrip('\r\n')
#
sys.stderr.write(l+'\n')
#
if (l == ""):
if h.has_key('content-length') and h['content-length'].isdigit() and h.has_key('content-type') and h['content-type'] == 'application/ubx':
sys.stdout.write(buf[0:int(h['content-length'])])
sys.exit(0)
#
m = re.search('\\A(.+): (.+)\\Z',l)
if m:
h[m.group(1).lower()] = m.group(2).lower();
</pre>

==== u-blox Assist Now account application ====

To apply for a free u-blox Assist Now account, please send an e-mail to:
agps-account@u-blox.com

Leave body and subject of the message empty. And not all mail account are accepted/could get reply. since the protocol is pretty straight forward, implement an extra proxy to scale up user should be easy.

=== Assist Offline ===

u-blox Assist Offline service could provide up to 14 days of valid assist GPS data in single download package. But Assist Offline service need an extra flash to storage Almanac data, and [[u-blox ANTARIS 4 ATR0635]] will automatically use these data while system start up. GTA02 don't support Assist Offline.

==== u-blox Assist Offline implementation ====

Due to the u-blox 4 need to have extra flash to storage up to 14 days of offline data (90 KBytes), GTA02 don't have it. I would very interested if there is another way to twist it around, but not likely, so far. Offline sample data you could find in the following addesss:

http://alp.u-blox.com/

And u-blox did provided source code of Assist offline server implementation and ubx header, you could find it here:

http://people.openmoko.org/tony_tu/src/u-blox

==== Possible implementation mechanism ====

We can use the same protocol as the online assist to provide the time, last location, almanac and ephemeris data that would be held in the extra flash storage when we power up the GPS. Time is available from the local clock, and we can save location, almanac and ephemeris when the GPS is shut down. We may be able to have a better guess at startup location based on GSM cell ID, WiFi access points, or by the user selecting an area on a map.

Some Ruby tools already exist for downloading and uploading Almanac and Ephemeris. See http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox

==== UBX protocol ====
Protocol specification (html-help format): http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm

Sample header could be found here: [http://people.openmoko.org/tony_tu/src/u-blox/AssistNowOfflineServerSampleImplementation/ubx.h ubx.h]

Conversion between lat/ln and ECEF xyz coordinates:
http://www.u-blox.com/customersupport/docs/GPS.G1-X-00006.pdf

Packet generator:

<pre>
#!/usr/bin/python
#
# ubx packet generator
#
# v0.1
#
# Wilfried Klaebe <wk-openmoko@chaos.in-kiel.de>
#
# Usage:
#
# ubxgen.py 06 13 04 00 01 00 00 00 > packet.ubx
#
# prepends 0xb5 0x62 header,
# appends checksum,
# outputs binary packet to stdout
#
# you can send the packet to GPS chip like this:
#
# cat packet.ubx > /dev/ttySAC1

import sys
import binascii

cs0=0
cs1=0

sys.stdout.write("\xb5\x62")

for d in sys.argv[1:]:
c = binascii.unhexlify(d)
sys.stdout.write(c)
cs0 += ord(c)
cs0 &= 255
cs1 += cs0
cs1 &= 255

sys.stdout.write(chr(cs0)+chr(cs1))
</pre>

----

== Configuration for a higher sampling rate ==

The GPS chip can be flexibly configured for more than one sample per second. Sometimes I need a good GPS log for experimental projects, and I configure my Neo Freerunner's GPS to take '''4 samples per second''' (the maximum it can do) and to send me nothing more than '''GPRMC (Date+Time+Lat+Lon+Speed+Direction) and GPGGA (...+Altitude+Sats+HDOP) messages''' - I disable the other ones because they are redundant.

These configurations have to be done via the u-blox binary protocol. So I just build the messages using the above "ubxgen.py" script like this:
<pre>

# disable unnecessary messages:
ubxgen.py 06 01 03 00 f0 01 00 > CFG-MSG-GPGLL-OFF.ubx
ubxgen.py 06 01 03 00 f0 02 00 > CFG-MSG-GPGSA-OFF.ubx
ubxgen.py 06 01 03 00 f0 03 00 > CFG-MSG-GPGSV-OFF.ubx
ubxgen.py 06 01 03 00 f0 05 00 > CFG-MSG-GPVTG-OFF.ubx
ubxgen.py 06 01 03 00 f0 08 00 > CFG-MSG-GPZDA-OFF.ubx
cat CFG-MSG-GP*-OFF.ubx > /dev/ttySAC1

# reduce measurement time and message cycle to 250ms (4Hz):
ubxgen.py 06 08 06 00 fa 00 01 00 00 00 > CFG-RATE-4HZ.ubx
cat CFG-RATE-4HZ.ubx > /dev/ttySAC1

# alternatively:
# reduce measurement time and message cycle to 500ms (2Hz):
ubxgen.py 06 08 06 00 f4 01 01 00 00 00 > CFG-RATE-2HZ.ubx
cat CFG-RATE-2HZ.ubx > /dev/ttySAC1

</pre>

Using this setup, the output of "gpspipe -r" will dump around 600 bytes per second (4 GPRMC + 4 GPGGA messages).

To recover the default values, just turn off the GPS or let the FR suspend.

----

== GPS applications ==
{{main|GPS applications}}

[[Category:GPS]]
[[Category:Neo FreeRunner Hardware]]