Openmoko - User contributions [en]

Neo 1973 and Windows

2009-01-22T00:41:55Z

Brian H Wilson: /* Further references */

''Note -- The guidelines on this page work for the Neo FreeRunner too -- at least they do if you have a recent kernel installed. (See notes below on bluescreen of death before proceeding.)''

This page tries to collect some information on how to use your Neo1973 together with a computer running a Microsoft(R) Windows(TM) series operating system.

Please note that this is not really supported, and that the Openmoko developers themselves only use Linux for testing.

Also note that Windows appears to not recognize and communicate with the neo as a USB device unless you install the .inf file below, and hence you will always have to [[forcing fast charge mode|force fast charge]] to recharge using a usb connection to a Windows machine unless you install that .inf.

== Connecting to the phone ==

=== Bluetooth connection ===

How to connect to Windows XP via Bluetooth is described here: [[Manually_using_Bluetooth#Bluetooth_networking_with_a_Windows_XP_system]]

=== USB Ethernet emulation ===

{{note|With some recent versions of FSO or SHR with kernel 2.6.28 and Windows XP, you might get a Blue Screen Of Death (BSOD) as soon as you connect your Freerunner. ( https://docs.openmoko.org/trac/ticket/2211 )}}

{{note|For Windows XP USB RNDIS networking ''finally works'' as of Kernel 2.6.22.5-moko11 using the procedure described below.}}

{{note|For Vista this procedure works with the 2.6.24 kernel that ships with the Neo FreeRunner. The initial SSH connection seems a little slow however.}}

# Download http://privat.wmo.de/~c_schweers/NeoRndis.inf ([[NeoRndis.inf|Listing of NeoRndis.inf]]) to somewhere convenient on your Windows machine. If the file is not reachable, you can download another working inf file here: http://users.informatik.uni-halle.de/~rabe/neo/Neo1973.inf ([[Neo1973.inf|Listing of Neo1973.inf]]). If you have Windows Vista x64 try this one: [http://openmoko.kamillo.pl/neo_vista_x64.inf http://openmoko.kamillo.pl/neo_vista_x64.inf]. If you have Windows 2000 download this: [http://minucci.net/file/FreeRndis.zip http://minucci.net/file/FreeRndis.zip]
# Power up your Neo1973, let it boot into Openmoko, and then connect its USB port to the Windows machine, using a standard USB-A to USB-mini-B cable. Note that if you connect the cable ''before'' powering the phone on, Windows will detect a device presented by the [[Boot lader|boot loader]]. This probably isn't what you want. Let the phone power up first.
# Assuming the new drivers are downloaded and accessible as above, Windows should detect the Neo1973 and prompt you for a driver for a "RNDIS/Ethernet Gadget". Select to specify your own driver, and then choose the NeoRndis.inf file you downloaded earlier. This file tells Windows XP to use its own built-in RNDIS driver for the device.
# Windows may complain of "reduced network connectivity". This is because it expects to be able to get an address automatically from the Neo1973 and it doesn't provide one in the default setup. To fix this, see the next step.
# Go into the Windows network configuration for the new USB networking adapter and set the IP address of the interface to 192.168.0.200.

If you have trouble using the Windows tools to set the IP address (on XP it would not allow me to type in the full ip address!), use a command line.
List all available interfaces to get the adapter name to use:

$ '''netsh interface ip show config'''
''...lots of stuff here not shown, at the bottom I see my USB interface...''
Configuration for interface "Local Area Connection 11"
DHCP enabled: Yes
InterfaceMetric: 0
DNS servers configured through DHCP: None
WINS servers configured through DHCP: None
Register with which suffix: Primary only

Now that you know the name of the ethernet adapter, use the command to configure it.

$ '''netsh interface ip set address name="Local Area Connection 11" static 192.168.0.200 255.255.255.0'''
Ok.

You should now be able to connect to your smart phone on 192.168.0.202 via ssh (e.g. putty). The distribution you have might not have an ssh server running on it but if you still have a command line window open, you can ping the phone to make sure it's connected.

$ '''ping 192.168.0.202'''

Pinging 192.168.0.202 with 32 bytes of data:

Reply from 192.168.0.202: bytes=32 time=3ms TTL=64
etc... good news!

'''Getting a Blue Screen of Death (BSOD) in windows XP?''' Some extra drivers are automatically installed with new devices (e.g. "SecureRemoteMiniPort"). Try disabling them in the device manager while the Neo is not connected. You need to select "Show hidden devices" in the view menu to see them. Then reconnect the Neo.

== Connection to the Internet ==

If you want to connect to the internet from your Neo via Windows XP, e.g. for doing ipkg update/upgrade, you need to set up IP forwarding and routing properly.

==== Option 1, using Windows ICS ====

An easy way to do this is to use Windows Internet Connection Sharing.

To do this, you need to create a network bridge which contains the usb connection to the Neo.

Then you tell Windows to share the WAN connection (i.e. the network interface which connects your Windows system to the internet) with the new bridge.

Then you manually set the IP address of the bridge to 192.168.0.200

After you have done all this, the Neo will be able to route through the Windows machine out to the internet. DNS queries will also be proxied by the Windows machine. Of course, /etc/resolv.conf on the Neo needs to be set to your local DNS or a free DNS.

'''New''' When you have LAN with network address 192.168.0.0 you have to do some hacking.
1. Edit /etc/network/interfaces and set for usb0
'' address 192.168.2.202
netmask 255.255.255.0
network 192.168.2.0
gateway 192.168.2.1
''
On Windows go to Network settings, ''pull out LAN cable'' (so there's no connection with local DHCP server which conflicts with IP 192.168.0.1), enable connection sharing for Neo-USB cable. Then edit Neo-usb interface settings and change it's IP address to 192.168.2.1 and set gateway for yours 192.168.0.x (other which you have). Apply changes with OK. Put in net cable. Enjoy net on NEO.

'''Example: Setup for wifi only internet connection (windows xp and Neo FreeRunner)'''
# Once the Network Connections window shows both "Wireless Network Connection Status:Connected" and "openmoko Status:Connected" Right click on Wireless Network Connection and goto Properties. Select Advanced tab, and turn on Internet Connection sharing. Choose the openmoko network.
# If you get the error: the ip address is already in use. Change your wireless router address away from 192.168.0.2, to something like 192.168.1.2
# Windows will change the ip address of openmoko network to 192.168.0.1 and the Network Connections window will show "Wireless Internet Connection Status: connected,shared"
# Right click on openmoko network and goto Properties. Change the ip address of openmoko network to 192.168.0.200
# Login to openmoko using Putty (ssh client for windows) 192.168.0.202

=== Option 1.5, using a Network Bridge ===

Just bridge the USB and Ethernet networks together (Win XP).

To do this, you need to create a network bridge which contains the usb connection to the Neo and your normal Ethernet (or WiFi) connection (the one you use to go on the internets).

Then you set up the bridge like your Ethernet was (DHCP or static IP, e.g. 10.10.0.foo) and the Neo to be in the same subnet as the bridge (10.10.0.bar)

After you have done all this, the Neo will be able to route through the Windows machine out to the internet. DNS queries will also be proxied by the Windows machine. Of course, /etc/resolv.conf on the Neo needs to be set to your local DNS or a free DNS.

=== Option 2, using AnalogX ===

AnalogX is a lightweight, free network proxy for Windows. It can proxy HTTP, FTP, SMTP and other protocols. It's very easy to set up and works with any software on the phone that supports proxies (eg. opkg).

* Download and install AnalogX onto your Windows PC (http://www.analogx.com) (http://www.analogx.com/files/proxyi.exe) This is the actual program used.
* Run AnalogX. The default configuration should be ok: open mode, all protocols on.
* Connect your phone using the USB cable as normal.
* Configure opkg to use the proxy by editing /etc/opkg.conf. There's 2 lines to uncomment and change.
** option http_proxy http://192.168.0.200:6588
** option ftp_proxy http://192.168.0.200:21
* opkg should now work via the proxy.

Other apps like [[Minimo]] can also be configured to use a proxy. Use the HTTP proxy URL as above.

=== Option 3, using IP Forwarding and extra routing ===

An alternative way is to do it manually:

In the Windows registry, go to:
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
and set
REG_DWORD: "IPEnableRouter" to "1"
Be aware that IP Forwarding can be a security risk.

Then, if there is a router between your Windows XP system and the internet, you also need to tell the router how to get back to your Neo, so you need to set a route on it for 192.168.0.0/255.255.255.0 to your Windows XP LAN interface IP address. Windows will then forward the packets to the Neo.

=== Option 4, using HTTP proxy at work with Putty SSH tunneling ===

If your PC is running Windows and Internet connection goes through proxy, you can simply use [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY: A Free Telnet/SSH Client]. In Connection->SSH->Tunnels you can add tunnel to your proxy server. For example, if proxy address is "10.0.0.1:8080":
Source port: 8080
Destination: 10.0.0.1
Radio button: "Remote"
Then you will only need to set http_proxy address at your 1973/Freerunner:

# export http_proxy=http://localhost:8080

And have Internet.

== Further references ==

* http://www.microsoft.com/whdc/device/network/NDIS/rndis.mspx
* http://maemo.org/maemowiki/USBnetworkingWinXP
* http://docwiki.gumstix.org/Setting_up_USBnet
* http://handhelds.org/moin/moin.cgi/WindowsXpUsbNetworkHowTo
* [http://www.petri.co.il/configure_tcp_ip_from_cmd.htm Configuring TCP/IP settings from command line]

[[Category:Networking]]
[[Category:Host OSes]]

Neo 1973 and Windows

2009-01-22T00:40:09Z

Brian H Wilson:

Bricked

2008-09-21T04:36:25Z

Brian H Wilson: /* What is/is not a 'bricked' Neo? */

== What is/is not a 'bricked' Neo? ==

"Bricked", by analogy with "as useful as a brick", means that the phone's state (as stored in flash memory) has gotten sufficiently messed up that you cannot get it operational via normal means, no matter how clever. The usual (but not the only) cause, as in the story below, is errors in re-flashing the device. The normal way to "un-brick" a phone requires use of a [[Debug_Board]].

Note that being "bricked" must be distinguished from having a deeply-discharged battery. If you phone was working fine last Friday and won't boot up at all this Monday morning, it is more likely suffering the "really-dead-battery"; recovery from this is described on the [[Neo FreeRunner Hardware Issues#Can't boot with discharged or missing battery|Neo FreeRunner Hardware Issues]].

== Notes on a 'bricked' Neo ==

I've just spent a very long time, with the help of a few people on irc (who I now owe drinks to), trying to recover my Neo. This page is the result and is supposed to act as a collection of information to help owners with bricked or semi-bricked devices.

== The Problem defined ==

A typing error in the splashimage environment variable resulted in the splash image being read into the memory starting at 0x200000 rather than 0x32000000. The change was written, with the error being unnoticed, using saveenv. As a result it was not possible to connect the device to usb until it had booted fully. Any attempt to either start with usb plugged in or plugging it in at the u-boot prompt resulted in a locked up device. Looking at dmesg on the host the following errors were reported

usb 3-1: new full speed USB device using uhci_hcd and address 21
usb 3-1: device not accepting address 21, error -110

(the address number will change).

So the problem was that although the device could now boot there was no way to flash it with dfu.

=== The Solution ===

The solution was to try and prevent the splashimage environment variable from being looked at, thus preventing the write to the wrong area of memory.

==== Attempt 1 ====

The idea was to dump mtdblock1 to a file, scp the file to a PC, hex edit it scp the file back to the phone and then dd the result into the mtdblock.

On the Neo

dd if=/dev/mtdblock1 of=mtdblock1.bin

Rebooting was required because of the i/o errors. The i/o error problem has been reported as bug [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=567 567]

Once the Neo had rebooted the file was copied to a PC using scp. The first attempt to hex edit was made, the idea was to change 1 byte of the word '''splashimage''' so that it would, hopefully, be ignored by the bootloader. The resulting file was scp'd back to the Neo and written to flash

dd if=new_mtdblock1 of=/dev/mtdblock1

again once this was done a 'reboot' was performed.

==== Result 1 ====

When the device booted there was a small tux image in the top left hand corner of the screen and a u-boot version string displayed over some of it. The device would not continue to boot.

Powered off the Neo, powered on with AUX+POWER go give a reduced boot menu.

Boot
Factory reset

Selecting Boot resulted in a familiar 'bad magic number' error. However, selecting Factory reset resulted in the device booting. This time DFU was operational, but /dev/ttyACM0 was not available so there was no way to change the environment variable for splashimage.

'''[[User:CesarB|Cesar Barros]] points out that'''

''The reason editing the environment by hand does not work well is not the missing variable, but that the CRC doesn't match anymore, which makes it ignore the whole environment''

which makes perfect sense.

==== Attempt 2 ====

This idea involved taking the mtdblock1 from a working Neo and dd'ing it to the failed Neo's flash. '''WARNING!!! Never flash an u-boot-env (mtdblock1) that does not come from your own Neo. It contains a partition table and bad block table that's unique for each Neo.'''

==== Result 2 ====

The process was similar to attempt one, although no hex edit took place. The result was that the Neo booted perfectly, although without a splash screen. As the next stage for this the mtdblock3 was dumped from the working Neo and dd'd into mtdblock3 of the Neo with no splash screen.

The final result was a perfectly fine Neo with a splash screen, working boot menu and dfu capabilities.

== Discoveries ==

1. You can use dd to extract and overwrite your mtd partitions. This works particularly well for u-boot-env and splash providing the source device has a similar partition layout. Doing this on the u-boot partition was '''not''' tested. However, after you have used dd on the mtdblock devices as either the if= or of= you get i/o errors with even basic commands. The only way to get round this is to 'reboot' by removing the battery.

2. Hex editing the extracted mtd partition (u-boot-env) and trying to dd that works but the results are not what is expected. It appears that if one of the boot env parameters is missing, in this case splashimage, the u-boot-env parameters are all treated as if they were blank and the device uses default settings. This is because the CRC no longer matches.

3. QEMU is very useful for testing out your theories before actually doing them on a real device. Most of the things we tried were tried on qemu first. Sadly QEMU's sd card emulation appears to be broken.

== Useful information ==

On your Neo:

cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00004000 "u-boot"
mtd1: 00004000 00004000 "u-boot_env"
mtd2: 00200000 00004000 "kernel"
mtd3: 000a0000 00004000 "splash"
mtd4: 03d1c000 00004000 "rootfs

[[Category:Hardware]]

Neo FreeRunner Battery

2008-09-02T17:57:18Z

Brian H Wilson: /* What to do if your battery has become completely discharged */

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

== Make sure your battery never discharges completely. ==

This is an issue because the internal charging circuitry can not be turned on until the FreeRunner has booted, and booting through USB power alone does not work.

=== What to do if your battery has become completely discharged ===

Should the battery become completely discharged, your options are:
* Try booting with Wallwart USB-power supply (hold AUX button while inserting USB-plug)
* Recharge the dead battery with an external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with either a spare GTA01/GTA02 battery or a compatible battery, then plug in USB power and swap the dead battery into the FreeRunner while it's booted up and running.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that. (Not recommended)

The first option is probably the easiest and most sensible.

== Compatible Replacement Batteries ==

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1070
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Neo FreeRunner Battery

2008-09-02T17:55:40Z

Brian H Wilson: /* What to do if your battery has become completely discharged */

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

== Make sure your battery never discharges completely. ==

This is an issue because the internal charging circuitry can not be turned on until the FreeRunner has booted, and booting through USB power alone does not work.

=== What to do if your battery has become completely discharged ===

Should the battery become completely discharged, your options are:
* Try booting with Wallwart USB-power supply (hold AUX button while inserting USB-plug)
* Recharge the dead battery with an external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with either a spare GTA01 or GTA02 battery or a compatible battery, then plug in USB power and swap the dead battery into the FreeRunner while it's booted up and running.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

The first option is probably the easiest and most sensible.

== Compatible Replacement Batteries ==

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1070
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Neo FreeRunner Battery

2008-09-02T17:52:04Z

Brian H Wilson: /* Compatible Replacement Batteries */

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

== Make sure your battery never discharges completely. ==

This is an issue because the internal charging circuitry can not be turned on until the FreeRunner has booted, and booting through USB power alone does not work.

=== What to do if your battery has become completely discharged ===

Should the battery become completely discharged, your options are:
* Try booting with Wallwart USB-power supply (hold AUX button while inserting USB-plug)
* Use external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

== Compatible Replacement Batteries ==

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1070
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Neo FreeRunner Battery

2008-09-02T17:43:05Z

Brian H Wilson: /* Notes about expected battery life */

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

== Make sure your battery never discharges completely. ==

This is an issue because the internal charging circuitry can not be turned on until the FreeRunner has booted, and booting through USB power alone does not work.

=== What to do if your battery has become completely discharged ===

Should the battery become completely discharged, your options are:
* Try booting with Wallwart USB-power supply (hold AUX button while inserting USB-plug)
* Use external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

=== Compatible Replacement Batteries ===

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1070
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Host-based development with Xoo and Xephyr

2008-09-02T15:29:17Z

Brian H Wilson:

This page introduces you to the most efficient way to create new software for the Openmoko platform. Note that there is a VMware image where this environment has been prebuilt for you.
''Does anyone know where to find this VMWare image??''

==Host-based development==

This term means you develop most of your application in your standard desktop environment until it's almost finished. Then you can use a [[Toolchain]] to cross-compile your application for the Neo1973. Host-based development is incredibly more efficient since you can use your (typically) fast computer, large monitor, ... Compiling for your host also means that your edit-run-debug turnaround cycles are much faster, because you can skip the uploading-to-neo step.

==Xoo and Xephyr==
[http://projects.o-hand.com/xoo/ Xoo] is a GTK2 based graphical wrapper around a ‘Windowed’ X Server. The X server is typically '''Xnest''', the nested X server, or [http://projects.o-hand.com/xephyr Xephyr]. It is intended for embedded developers that want to simulate a target device (with an '''accurate''' display size, working hardware buttons, etc) on a desktop machine.

Note that Xoo is not required to simulate Openmoko hardware - it just improves the presentation.

==Prerequisites==

===Part I (precompiled software)===

You need to install some software that is usually not present on a desktop system, but used on the Neo1973. Some of this software has already been precompiled by your friendly distribution packager, so you don't need to compile it yourself. Most likely you can install the following packages from your distribution repository:

* gtk-doc-tools
* libstartup-notification0-dev
* libapm-dev
* libgpgme11-dev
* libgtk2.0-dev
* libebook1.2-dev
* libecal1.2-dev
* libnotify-dev
* libpulse-dev
* libcurl4-openssl-dev (or libcurl4-gnutls-dev)
* matchbox-window-manager
* matchbox-keyboard
* pulseaudio
* xephyr ( package is called xserver-xephyr on ubuntu and debian )
* xoo

Ubuntu-Specific Packages
* gnome-common (does this belong above?)
* ubuntu-mobile-dev (this depends on many other development packages; some are necessary, others optional)

Other Useful Packages
* libasound2-dev (needed to compile openmoko-dialer2 ([[User:Tomjoad]]))

Gentoo users run just
# emerge <package>

''note'': To get the Xephyr package installed Gentoo users have to rebuild the x11-base/xorg-server package with the "kdrive" use flag enabled ([http://gentoo-wiki.com/Scratchbox#Xephyr_support link])

Debian/Ubuntu
$ sudo apt-get install <package>
For Fedora, you can use
# yum install <package>
For Mandriva, you may try
# urpmi <package>

for any other find a way how to do it in your distro.

===Part II (building from source)===

You also need some software that is typically not found in your distribution repository, either because it's too new, too specific, or unheard of.

Most likely you will need to compile the following packages for your distribution:

* matchbox-panel-2
* libjana
* libipkg

To compile and install matchbox-panel-2:

mkdir -f /local/pkg/ohand
cd /local/pkg/ohand
svn co http://svn.o-hand.com/repos/matchbox/trunk matchbox
cd matchbox/matchbox-panel-2
./autogen.sh
make install

To compile and install libjana:

mkdir -f /local/pkg/ohand
cd /local/pkg/ohand
svn co http://svn.o-hand.com/repos/jana/trunk jana
cd jana
./autogen.sh
make install

To compile and install libipkg:

mkdir -f /local/pkg/handhelds.org
cd /local/pkg/handhelds.org
wget http://downloads.openmoko.org/sources/ipkg-0.99.163.tar.gz
tar xzf ipkg-0.99.163.tar.gz
cd ipkg-0.99.163
./configure
make install

==Building the Openmoko core==

First we download the Openmoko subversion repository:

mkdir -f /local/pkg/openmoko
cd /local/pkg/openmoko
svn co http://svn.openmoko.org/trunk/src src

Then you compile the software contained there, e.g. you will definitely want to compile at least:

In directory src/target/:
* [http://svnweb.openmoko.org/trunk/src/target/gsm/ gsmd]
* [http://svnweb.openmoko.org/trunk/src/target/opkg/ opkg]

In directory src/target/OM-2007.2/artwork:
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/artwork/icons/ icons]

In directory src/target/OM-2007.2/libraries/:
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokoui2/ libmokoui2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokopanelui2/ libmokopanelui2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokojournal2/ libmokojournal2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokogsmd2/ libmokogsmd2]

In directory src/target/OM-2007.2/daemons/:
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/daemons/neod/ neod]

In directory src/target/OM-2007.2/panel-plugins/:
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/panel-plugins/openmoko-panel-gsm/ openmoko-panel-gsm]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/panel-plugins/openmoko-panel-usb/ openmoko-panel-usb]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/panel-plugins/openmoko-panel-battery/ openmoko-panel-battery]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/panel-plugins/openmoko-panel-gps/ openmoko-panel-gps]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/panel-plugins/openmoko-panel-bt/ openmoko-panel-bt]

In directory src/target/OM-2007.2/applications:
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-today2/ openmoko-today2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-dialer2/ openmoko-dialer2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-calculator2/ openmoko-calculator2]
* [http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-appmanager2/ openmoko-appmanager2]

Each of these packages can be compiled with the well-known-triple of:

./configure (or ./autogen.sh, if it's the first time)
make
make install

==Data files==

Some of the data files are not yet installed. We will create links so that Openmoko finds the data files and uses them directly from the svn directories that you have checked out. To create the links:

cd /usr/local/share/matchbox
ln -s /local/pkg/openmoko/src/target/OM-2007.2/misc/openmoko-today2-folders vfolders

cd /usr/share/themes
ln -s /local/pkg/openmoko/src/target/OM-2007.2/artwork/themes/openmoko-standard-2

==Starting the nested Openmoko==

We have prepared a script for you that starts Xoo and all the necessary X clients in one run. The script is online at
* [http://svnweb.openmoko.org/trunk/src/host/xoo/om-launch om-launch]

==Creating a new application==

{{todo|...}}

==Using a Neo1973 as external GSM modem==

{{todo|...}}

==Using an external GPS device==

{{todo|...}}

{{Languages|Host-based development with Xoo and Xephyr}}
[[Category:Technical]]
[[Category:Documentation]]
[[Category:Emulation]]

Neo FreeRunner Battery

2008-08-28T15:09:57Z

Brian H Wilson: /* Compatible Replacement Batteries */ Corrected BL-6C mah

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

Make sure that the battery never discharges completely. This is an issue because
the internal charging circuitry can not be turned on until the FreeRunner has
booted, and booting through USB power alone does not work.
(If you have the newest kernel images, you should be safe due to a software fix.)

Actually this isn't true for all FreeRunner devices, I got flawless boot on GTA02 DateCode 20080626, when holding AUX while insering USB-plug of Wallwart powersupply. Also I don't see how new kernel image could help on this issue, other than if it stopped DIScharging of battery in time 
Should the battery become completely discharged, your options are:
* Try booting with Wallwart USB-powersupply (maybe hold AUX during inserting USB-plug)
* Use external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

=== Compatible Replacement Batteries ===

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1070
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Neo FreeRunner Battery

2008-08-28T15:06:15Z

Brian H Wilson: /* USB charger */

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

Make sure that the battery never discharges completely. This is an issue because
the internal charging circuitry can not be turned on until the FreeRunner has
booted, and booting through USB power alone does not work.
(If you have the newest kernel images, you should be safe due to a software fix.)
Should the battery become completely discharged, your options are:
* Use external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

=== Compatible Replacement Batteries ===

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1200
|no
|
|}

== USB charger ==

For information about USB battery chargers that can be used with the Neo FreeRunner see
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

Neo FreeRunner Battery

2008-08-28T14:52:00Z

Brian H Wilson: /* USB charger */ Added category battery

{{Neo FreeRunner Menu}}
=== GTA02 1200 mAh Smart Battery ===

*Using SANYO 1200mAh cell
*Battery Technical information: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf Detailed Battery Information]

* 1200mAh Smart Battery with Coulomb-counter and protection circuit
* The Smart Battery keeps track of maximum and current capacity for precise prediction of remaining battery power and time until shutdown, based on actual power dissipation.

For more information, see the GTA01 battery info at [[Neo1973 Battery]]

=== Notes about expected battery life ===
Battery life is a work in progress. The power saving software is in a very rudimentary state. At the moment 12h is about the most (note though a [http://lists.openmoko.org/pipermail/community/2008-July/020339.html recent result of at least 21h], mostly in suspend, with multiple short wakeups, on the predecessor device GTA01). A week standby and 6 hours talk, 20 hours mp3 might be attainable when power saving software is complete.

Make sure that the battery never discharges completely. This is an issue because
the internal charging circuitry can not be turned on until the FreeRunner has
booted, and booting through USB power alone does not work.
(If you have the newest kernel images, you should be safe due to a software fix.)
Should the battery become completely discharged, your options are:
* Use external stand-alone charger (compatible with the Nokia BL-5C battery)
* Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
* Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
* Charge the battery directly, [http://wiki.openmoko.org/wiki/Charging_battery_directly see here], how I did that.

=== Compatible Replacement Batteries ===

Other known FreeRunner-compatible batteries include the BL-series (BL-4X, BL-5X) from Nokia, and their third-party equivalents.
These may not work to revive a device and may not report charge information.
It is probably a good idea to check that your battery is not greater than the stock battery's voltage of 3.7V (the above suggests that 4.5VDC should be fine) unless you know what you are doing.

{| border="1" cellpadding="4" cellspacing="0"
!Battery Model
!Capacity (mAh)
!Charge info reported
!Notes
|-
|NOKIA BL-4
|
|no
|
|-
|NOKIA BL-4C
|750
|
|
|-
|NOKIA BL-5B
|760/890
|
|
|-
|NOKIA BL-5C
|950
|no
|
|-
|NOKIA BL-6C
|1200
|no
|
|}

== USB charger ==
{{main|USB charger}}

[[Category:Battery]]
[[Category:Neo FreeRunner Hardware]]

GPS Data Logger

2008-08-25T05:26:08Z

Brian H Wilson: /* More features */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the u-blox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== Native u-blox format ===

One suggestion is to simply store and process the data in the u-blox binary format.
This might be a starting point but leaves out the possibility of the software interoperating
with other receivers or even running on the Neo 1973.

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes u-blox Antaris 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

=== Audio clips ===

It would be useful to be able to capture short audio comments, especially when collecting data for Openstreetmap. This can be easily done by starting recording when AUX is pressed and stopping it when it is released.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

u-blox Antaris product page http://www.u-blox.com/products/a4products.html

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-24T15:49:55Z

Brian H Wilson: /* External links */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the u-blox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== Native u-blox format ===

One suggestion is to simply store and process the data in the u-blox binary format.
This might be a starting point but leaves out the possibility of the software interoperating
with other receivers or even running on the Neo 1973.

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes u-blox Antaris 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

u-blox Antaris product page http://www.u-blox.com/products/a4products.html

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-24T15:48:58Z

Brian H Wilson: /* Data format and exchange */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the u-blox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== Native u-blox format ===

One suggestion is to simply store and process the data in the u-blox binary format.
This might be a starting point but leaves out the possibility of the software interoperating
with other receivers or even running on the Neo 1973.

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes u-blox Antaris 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-24T15:46:25Z

Brian H Wilson: /* RINEX */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the u-blox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes u-blox Antaris 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-24T15:38:47Z

Brian H Wilson: /* Support for postprocessing? */ spelling fix

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the u-blox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

Talk:Flashing the Neo FreeRunner

2008-08-23T15:16:03Z

Brian H Wilson: Talk:Flashing the Neo FreeRunner moved to Talk:Flashing the Neo Freerunner: Standardized the name.

There is another page like this [[Flashing Openmoko]] They should be merged [[User:Thewtex|thewtex]] 05:44, 21 July 2008 (UTC)

That page is now about flashing the Neo 1973 [[User:Brian H Wilson|Brian H Wilson]] 04:12, 12 August 2008 (UTC)

So, where are the u-boot images? --[[User:Gero|Gero]] 21:35, 27 July 2008 (UTC)

The u-boot images are found with the daily builds. See Freerunner/ASU daily builds in [[Latest Images]]. '''Note''' the file names are ''wrong''. If you look through the dates, they all seem to have the same file names indicating version and git commit hash. However, use the latest build, and you can check the true version by booting into u-boot, connecting to u-boot, and issuing the 'version' command. [[User:Thewtex|thewtex]] 04:40, 28 July 2008 (UTC)

== Erasing rootfs ==

Is it still necessary to erase the rootfs partition before flashing a new one, if the new one is smaller? If so then we should add this as one of the steps.

Also instructions on setting the boot menu timeout to something sensible would be a good thing to have in here, as hitting AUX every 20 seconds to keep the phone shutting down while flashing a rootfs is tedious.

At least in my experience, it won't shut down when an image is being transferred.

Flashing the Neo FreeRunner

2008-08-23T15:16:03Z

Brian H Wilson: Flashing the Neo FreeRunner moved to Flashing the Neo Freerunner: Standardized the name.

Openmoko regularly releases updated versions of the Openmoko root filesystem, the [[kernel]], and the [[Bootloader| U-Boot]] as binary images. These may be programmed into the Flash memory (NAND) of Neo FreeRunner. For that, you can use the USB cable and another computer which will run an Openmoko provided tool to flash the Neo FreeRunner "through" USB.

== Overview ==
All the components of the software in the FreeRunner are bundled together into binary images.

On a desktop computer when you want to replace the operating system (OS), you would boot it from a CD-ROM drive, then copy OS files from the CD to the internal hard drive. The FreeRunner does not have a CD-ROM drive and files must typically be re-written/flashed directly into internal storage (NAND flash). It is also possible to load all the OS files to and boot from a microSD.

The FreeRunner has two kinds of internal program storage: NOR flash and NAND flash. The NOR flash is small and stores only a special boot program used when you need to re-write the contents of the NAND flash. NAND flash acts more like a hard drive.

The NAND Flash is divided into 3 partitions for the bootloader, kernel, and root filesystem - so each of these components can be flashed separately. For example if you are trying to install a modified kernel, you only have to follow the steps to flash the kernel image.

* '''bootloader''': a small program that runs first and starts everything else when the FreeRunner is powered on or reset (depending on [[Booting the Neo FreeRunner|how you reset it]], the version from NOR or NAND is booted).
* '''kernel''': the central component in the Linux operating system.
* '''root filesystem''': contains all the files that make up the commands and applications that you can run.

'''Before you start: Erasing the root filesystem or flashing the uboot are radical measures. Take the time to ponder the necessity. Sometimes problems can be fixed by updating only the kernel.'''

== Alternative : running from microSD card ==

You may install this distribution on the microSD card, in order to [[Booting from SD | boot from microSD card]]. That allows you to keep another distribution installed in NAND (for instance to test 2008.08 while still having 2007.2 for default boot).

== Collect the things you need ==

=== Download the DFU-util program ===

You will download that program on your desktop computer. It will allow you to connect to the FreeRunner through the USB cable and control its bootloader. That connection uses a special protocol which addresses the bootloader's interface, and differs from USB networking. There is a separate page to describe it in more detail: [[dfu-util]].

'''MacOS X:''' [[MacOS_X#Graphical_Flashing_with_Openmoko_Flasher]]

'''Linux:''' http://buildhost.openmoko.org/releases/Freerunner/dfu-util

Make sure it is executable by setting the permissions with this command: chmod a+x dfu-util

'''Note:''' dfu-util seems to consistently fail with a "-62" error on 64-bit Linux. If you have access to a 32-bit machine, use it instead!
There are some ubuntu64 interpid packages which work just fine for me in hardy too. So you might try at your own risk: [http://packages.ubuntu.com/de/intrepid/dfu-util]

'''Windows:''' http://projects.openmoko.org/frs/?group_id=166&release_id=162

See additional driver installation instructions for Windows at [[Dfu-util-windows]]

=== Download the image files that you will need ===

Exactly what files you need depends on what you are trying to install. In most cases you will need to install a Kernel (uImage) and a Root Filesystem (rootfs). In rare cases, when there is a bug you need fixed, you will also install a new bootloader.

Please read [[Distributions]] for choosing the distribution which fits your needs, and then see [[Download]] for downloading.

== Boot the FreeRunner from NOR Flash ==

[[Image:menu15.jpg|thumb|Booting from NOR Flash]]

# Read the other sections of this page first, because you will have 30 seconds to enter the flashing commands, come back here when ready.
# Do not connect the USB cable from the PC to your Neo FreeRunner yet (disconnect it).
# Boot your Neo Freerunner into the NOR uBoot menu for flashing.
## Press and hold AUX button
## Press the Power button until the boot menu comes up
## This menu is labelled '''*** BOOT MENU (NOR) ***'''
## See also [[Booting the Neo FreeRunner]]
# Stay in NOR uBoot menu, do not to select or enter any item in menu. Now you will be able to flash, make backups of your Freerunner or query the Freerunner with dfu-util.
# The FreeRunner only stays at the NOR boot prompt for about 30 seconds and then shuts off unless you do something.
# Connect your Neo to the GNU/Linux or Windows host via a USB cable.
# Now you can enter the dfu-util commands on your PC as described below.
# If the Neo FreeRunner turns off before you press start flashing ('''screen goes black'''), go back to step 2. If you start flashing in time, the phone will not turn off meanwhile.



Note that the dfu-util connection does '''not''' use Ethernet over USB - that is, you should not attempt to set up a usb0 network interface on your GNU/Linux host desktop (on Windows, you need a DFU class driver, or you can use the LibUSB-Win32 driver described on the [[Dfu-util-windows]] page). The dfu-util utility sets up its own connection to the FreeRunner. In fact, you will not be able to make an Ethernet-over-USB connection to the FreeRunner when it is at the uBoot menu; this type of connection is only available when the FreeRunner has booted fully.

After connecting the FreeRunner to your host via USB cable, you can test whether dfu-util "sees" the FreeRunner by executing:

dfu-util -l
If you get error messages from the dfu-util command then try again. Often it works on the second try.

== Do a backup ==

If you have a working image that you're happy with but want to try something different, you should probably do a [[Pre-Flash Backup]].

== Using dfu-util ==

dfu-util can be used to read flash memory, write memory, and get information from the device.

This is the general command format to write an image file to a (predefined) "partition name" (referred to as ''altsetting'' in dfu-util help/manual) :

dfu-util -a ''altsetting'' -R -D ''file_name''

where: 
-a ''altsetting'' : Specify the altsetting of the DFU interface by name or by number 
-R : Issue USB Reset signalling once we're finished 
-D ''file_name'' : Write firmware from ''file_name'' into device

On Linux, you run dfu-util from a command shell prompt. If you have not put it somewhere on your command path you probably need to prefix it with a "./" like this '''./dfu-util'''.
On some systems you need to be root before this will work and on Ubuntu you must preface the command with "sudo" or you will get the following error: "Cannot claim interface: could not claim interface 2: Operation not permitted"

On Windows, you need to open a command window and run from a command line. Use Start-Run Program and type "cmd" to open a Window.

More detailed manual for gfu-util is available here : [[Dfu-util]]

== Flashing the Kernel ==

Note: The phone needs to be in the U-boot bootup menu for this to work. Get there by holding down the aux button while powering up the device.

The command format is

dfu-util -a kernel -R -D ''/path/to/uImage''

When flashing succeeds the following will be shown:

status(0) = No error condition is present
Done!

Flashing may fail with an error -110. This indicates that the kernel is too big for the default kernel partition. uboot can be used to change the size of the default partitions on the device. It may also mean that you are trying to put the wrong thing in the kernel space.

== Flashing the Root Filesystem ==

The root filesystem has to be an image in jffs2 format. If the file you downloaded is zipped or compressed (has a .gz, bz2, .zip, tar, tar.gz or .tgz extension) you have to uncompress it first.

The command format is

dfu-util -a rootfs -R -D ''rootfs_filename.jffs2''

where ''rootfs_filename.jffs2'' is the name of the file containing the root filesystem.

When flashing succeeds the following will be shown:

status(0) = No error condition is present
Done!

== Flashing the boot loader to the NAND==

The boot loader (U-boot) file should have a .bin extension. As with the root filesystem, if the file you downloaded is zipped or compressed (has a .gz or .zip extension) you have to uncompress it first.

The command format is

dfu-util -a u-boot -R -D ''uboot.bin''

where ''uboot.bin'' is the name of the boot loader binary image file.

''Reminder'': You should have [[Flashing_the_Neo_FreeRunner#Boot_the_FreeRunner_from_NOR_Flash|boot from NOR first]], in order to flash the boot-loader in NAND. After flashing succesfully, make sure you reboot from NAND's newly flashed boot loader, to benefit from the updates.


(Optional) After an upgrade, you may wish to check that the u-boot version matches the one you have just flashed. You can use 'grep Bootloader /dev/mtdblock1' from a shell on the FreeRunner (and possibly the 1973 as well) to get the '''NAND''' u-boot version, like this:
root@om-gta02:~# grep Bootloader /dev/mtdblock1
Neo1973 Bootloader U-Boot 1.3.2+gitr18+64eb10cab8055084ae25ea4e73b66dd03cc1a0cb

You can grep for the same string in /dev/mtdblock0 to retrieve the '''NOR''' u-boot version:
root@om-gta02:~# grep Bootloader /dev/mtdblock0
Neo1973 Bootloader U-Boot 1.3.2-moko12



== Reboot the FreeRunner from NAND ==

You should now be able to boot into the new images.

Pay attention '''to booting from the NAND flash this time''', in particular if you upgraded the boot-loader (in short: 1. press and hold ''power button'' down, and then 2. press ''aux button'')

The boot menu should be labelled '''*** BOOT MENU (NAND) ***''' this time (see [[Booting#Log_into_U-Boot_in_the_NAND_Flash|booting from NAND]] for more detailed instructions).

[[Category:Flashing Openmoko| ]]

U-Boot

2008-08-23T15:15:20Z

Brian H Wilson: /* Related pages */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader used on the smartphones is called '''U-Boot'''. It takes care of device functionality until Openmoko is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Booting into U-boot ==

* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Hold in the AUX button on power-up to access the boot menu.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

All versions of the OM smartphone use the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/daily/ in the subdirectory [device]/200808/[date]/.

All versions of the GTA02 (Neo Freerunner) that have been sold to the public are version 5 hardware so look for a file with "gta02" and "v5" in the name, for example
uboot-gta02v5-latest.bin

The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 Openmoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]]. For neo 1973 you may see [[Flashing_Openmoko#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

== Related pages ==

See [[Flashing the Neo 1973]] and [[Flashing the Neo Freerunner]] for instructions on using dfu-util to install a new bootloader in your phone.

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

U-Boot

2008-08-23T15:14:32Z

Brian H Wilson: /* USB connectivity problems */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader used on the smartphones is called '''U-Boot'''. It takes care of device functionality until Openmoko is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Booting into U-boot ==

* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Hold in the AUX button on power-up to access the boot menu.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

All versions of the OM smartphone use the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/daily/ in the subdirectory [device]/200808/[date]/.

All versions of the GTA02 (Neo Freerunner) that have been sold to the public are version 5 hardware so look for a file with "gta02" and "v5" in the name, for example
uboot-gta02v5-latest.bin

The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 Openmoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]]. For neo 1973 you may see [[Flashing_Openmoko#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

== Related pages ==

See [[Flashing Neo 1973]] and [[Flashing Freerunner]] for instructions on using dfu-util to install a new bootloader in your phone.

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

GTA02 revisions

2008-08-22T19:44:14Z

Brian H Wilson:

This page will give you an overview of all the revisions of the GTA02 hardware, both pre-release and planned future revisions. The internal codename of the [[Neo FreeRunner]] was GTA02.

All Neo Freerunners that have been released to the public at this time are [[#GTA02v5|revision 5]]. (August 2008)

== GTA02 specification ==

The GTA02 will be a [[GTA01]] but with a major revision of everything. These components were added:
* Wifi: Atheros 802.11 b/g
* CPU: Samsung S3C2442 B54 SoC @ 400Mhz
* SMedia Glamo3362 Graphics Accelerator
* 2x ST 3D Accelerometers
* 256MB Flash
* 128MB SDRAM
* 2MB NOR Flash
* 1200mAh Battery
* 2 LEDs illuminating the two buttons.
* GPS: u-blox/Atmel ATR0635
* Bluetooth
* GSM/GPRS: 850/1800/1900 Mhz or 900/1800/1900 Mhz
* USB Host function with power
And it lost:
* One speaker, becoming mono.

== Estimated time line ==
{{Todo|It should be nice if their are some dates next to the milestones}}
* GTA02v3 design finalized - DONE
* GTA02v3 power supply flaw found, GTA02v4 needed - DONE
* GTA02v4 design finalized - DONE
* GTA02v4 small number produced for Openmoko internal developer evaluation - DONE
* GTA02v4 thorough evaluation by Openmoko internal developers - In progress
* GTA02v4 flaw found, GTA02v5 needed - On hold while further development on drivers is done to ensure no further hardware bugs. - In progress
* GTA02v5 design finalized - DONE
* GTA02v5 small number produced for Openmoko internal developer evaluation - Done (around 20)
* GTA02v5 thorough evaluation by Openmoko internal developers - Done
* GTA02v5 produced in moderate volume - Done
* GTA02v5 goes on sale to community via web store - Done

== GTA02v1 ==
First generation of prototypes that was given to internal Openmoko software developers. Total 30 pcs fabricated.

*It is working just fine, but still based on 2440, with external NAND/SDRAM and no NOR flash
*Using the PCF50633 05 N3 due to 04 N3 not available, re-work power for basic schematics verification
*Using GTA01 SIM socket
*Add external debug port
*Still using Global locate A-GPS
* ATAG_REVISION: 0310

== GTA02v2 ==
Second generation of prototypes, Total 50 pcs run at Taipei SMT factory MOUNT

*Ideal is have 256 MB NAND on Samsung package, Due to chip availability Start using S3C2442 B43
*Using correct PMU PCF50633 04 N3
*Change new SIM socket
*Change to u-blox A-GPS
*Change LCM power from 3.3v to 1.8v
*USB power switch layout/pin assignment mistake, could not verify USB host supply 5v function
*GPS function verified ok with good sensitivity
* ATAG_REVISION: 0320

== GTA02v3 ==
Production verification version, 2007/10/11 28 pcs fabricate at FIC SuZhou

*Still using S3C2442 B43 for hardware verification
*Using control pilot run to verify S3C2442 B54 chips 
* ATAG_REVISION: 0330

== GTA02v4 ==
Mass production release candidate version 1

2 weeks after v3 gerber out, release the v4 gerber, and 2007/10/20 20 pcs fabricate at FIC SuZhou

*Change LCM power from 1.8v to 3.3v for display stability issue
*fabricate another 200 pcs for yield rate/production verification
*fabricate 50 pcs with S3C2442 B43 (128 MB NAND) for quality comparsion
*USB host power chip have some output voltage stability issues with Vb/Vcc comes from different power source, need layout change to fix the issue
*Battery Coulomb design not working on A4
* ATAG_REVISION: 0340

== GTA02v5 ==
Mass production candidate version 2/Mass production version

* First batch fabricate 2008/1/14 at FIC SuZhou
* Mass production A5 trial run start from 2008 March, including some resistor/capacitor change compare with inital 100 pcs prototypes A5, and prototypes for GTA02 developers was tracked in the [[Prototypes| Prototypes Page]]
* Coulomb counter issue fixed
* USB host power switch fixed
* Need add capacitor for PMU Vbat input for stability issue, this could be done by direct SMT or hand rework
* Need rework (still using SMT in production) add capacitor for PMU Vbat input for PMU stability issue.
* Need manual rework GSM IR UART path a 100k pull down for better GSM deep sleep
* ATAG_REVISION: 0350

===GTA02 mass Production version change list===
*PMU's LED power error: PMU potential damage issue
*NOR FLASH enable WP: User can write data into NOR FLASH.
*CE CS/RS fine tune: Audio's background noise too high
*I2C pull high resistor: The resistor is too high and signal is distorted
*GSM leakage current: TX_MODEM has a pull high resistor on IO_3V3
*Power consumption: Disable keep active function
*SDIO clock and esd protect resistor
*Refer to Datasheet: R1526 to 33K
*GSM modem on pin: The R1018 is too small and has some leakage current
*LED driving transistor: When GPIO is on, the transistor will be draw more current on LED. This is component change fix, do not need change PCB or re-work.

== GTA02v6 ==
Mass production candidate version 3/Mass production version 

A6 will be fine tune version of A5, only minor schematic change for better product quality and version control. Capacitor and resistor change A6 also on mass production A5 

*First 100 pcs start from 2008 mid April, and factory make component placement mistake on GSM, second 100 pcs PCB arrive time TBD.
*Add capacitor space for Vbat, reduce the SMT effort
*Add GSM IR resistor for better GSM deep sleep
*Reserve 3 GPIO for hardware version control
*Fixed LEDs power usage (from about 150mW of v5 to about 25mW)
* ATAG_REVISION: 0360

=== GTA02 A5 to A6 changes ===
*Power Glitch on VB_SYS: Add capacitor on layout, Mass production A5 also apply this change.
*G-sensor separate these interrupt pins: At A5, each accelerometer INT1/INT2 connected to same line, at A6 only INT1 was connected.
*GSM_modem power source Reduce power's ripple when the phone is talking
*Keep active Disable keep active function, just fine tune
*GPIO for version control
*GSM RX_IR has some noise Add resistor and reduce GSM RX_IR noise and gsm can't enter suspend mode easily, apply on mass production A5.
*LED driving transistor apply on mass production A5.
*LCM's VDDIO We can totally power off LCM's power, save about extra 1mA.

GTA02 revisions

2008-08-22T19:43:29Z

Brian H Wilson: Added statement that v5 is current revision

This page will give you an overview of all the revisions of the GTA02 hardware, both pre-release and planned future revisions. The internal codename of the [[Neo FreeRunner]] was GTA02.

All Neo Freerunners that have been released to the public at this time are [[#GTA02V5|revision 5]]. (August 2008)

== GTA02 specification ==

The GTA02 will be a [[GTA01]] but with a major revision of everything. These components were added:
* Wifi: Atheros 802.11 b/g
* CPU: Samsung S3C2442 B54 SoC @ 400Mhz
* SMedia Glamo3362 Graphics Accelerator
* 2x ST 3D Accelerometers
* 256MB Flash
* 128MB SDRAM
* 2MB NOR Flash
* 1200mAh Battery
* 2 LEDs illuminating the two buttons.
* GPS: u-blox/Atmel ATR0635
* Bluetooth
* GSM/GPRS: 850/1800/1900 Mhz or 900/1800/1900 Mhz
* USB Host function with power
And it lost:
* One speaker, becoming mono.

== Estimated time line ==
{{Todo|It should be nice if their are some dates next to the milestones}}
* GTA02v3 design finalized - DONE
* GTA02v3 power supply flaw found, GTA02v4 needed - DONE
* GTA02v4 design finalized - DONE
* GTA02v4 small number produced for Openmoko internal developer evaluation - DONE
* GTA02v4 thorough evaluation by Openmoko internal developers - In progress
* GTA02v4 flaw found, GTA02v5 needed - On hold while further development on drivers is done to ensure no further hardware bugs. - In progress
* GTA02v5 design finalized - DONE
* GTA02v5 small number produced for Openmoko internal developer evaluation - Done (around 20)
* GTA02v5 thorough evaluation by Openmoko internal developers - Done
* GTA02v5 produced in moderate volume - Done
* GTA02v5 goes on sale to community via web store - Done

== GTA02v1 ==
First generation of prototypes that was given to internal Openmoko software developers. Total 30 pcs fabricated.

*It is working just fine, but still based on 2440, with external NAND/SDRAM and no NOR flash
*Using the PCF50633 05 N3 due to 04 N3 not available, re-work power for basic schematics verification
*Using GTA01 SIM socket
*Add external debug port
*Still using Global locate A-GPS
* ATAG_REVISION: 0310

== GTA02v2 ==
Second generation of prototypes, Total 50 pcs run at Taipei SMT factory MOUNT

*Ideal is have 256 MB NAND on Samsung package, Due to chip availability Start using S3C2442 B43
*Using correct PMU PCF50633 04 N3
*Change new SIM socket
*Change to u-blox A-GPS
*Change LCM power from 3.3v to 1.8v
*USB power switch layout/pin assignment mistake, could not verify USB host supply 5v function
*GPS function verified ok with good sensitivity
* ATAG_REVISION: 0320

== GTA02v3 ==
Production verification version, 2007/10/11 28 pcs fabricate at FIC SuZhou

*Still using S3C2442 B43 for hardware verification
*Using control pilot run to verify S3C2442 B54 chips 
* ATAG_REVISION: 0330

== GTA02v4 ==
Mass production release candidate version 1

2 weeks after v3 gerber out, release the v4 gerber, and 2007/10/20 20 pcs fabricate at FIC SuZhou

*Change LCM power from 1.8v to 3.3v for display stability issue
*fabricate another 200 pcs for yield rate/production verification
*fabricate 50 pcs with S3C2442 B43 (128 MB NAND) for quality comparsion
*USB host power chip have some output voltage stability issues with Vb/Vcc comes from different power source, need layout change to fix the issue
*Battery Coulomb design not working on A4
* ATAG_REVISION: 0340

== GTA02v5 ==
Mass production candidate version 2/Mass production version

* First batch fabricate 2008/1/14 at FIC SuZhou
* Mass production A5 trial run start from 2008 March, including some resistor/capacitor change compare with inital 100 pcs prototypes A5, and prototypes for GTA02 developers was tracked in the [[Prototypes| Prototypes Page]]
* Coulomb counter issue fixed
* USB host power switch fixed
* Need add capacitor for PMU Vbat input for stability issue, this could be done by direct SMT or hand rework
* Need rework (still using SMT in production) add capacitor for PMU Vbat input for PMU stability issue.
* Need manual rework GSM IR UART path a 100k pull down for better GSM deep sleep
* ATAG_REVISION: 0350

===GTA02 mass Production version change list===
*PMU's LED power error: PMU potential damage issue
*NOR FLASH enable WP: User can write data into NOR FLASH.
*CE CS/RS fine tune: Audio's background noise too high
*I2C pull high resistor: The resistor is too high and signal is distorted
*GSM leakage current: TX_MODEM has a pull high resistor on IO_3V3
*Power consumption: Disable keep active function
*SDIO clock and esd protect resistor
*Refer to Datasheet: R1526 to 33K
*GSM modem on pin: The R1018 is too small and has some leakage current
*LED driving transistor: When GPIO is on, the transistor will be draw more current on LED. This is component change fix, do not need change PCB or re-work.

== GTA02v6 ==
Mass production candidate version 3/Mass production version 

A6 will be fine tune version of A5, only minor schematic change for better product quality and version control. Capacitor and resistor change A6 also on mass production A5 

*First 100 pcs start from 2008 mid April, and factory make component placement mistake on GSM, second 100 pcs PCB arrive time TBD.
*Add capacitor space for Vbat, reduce the SMT effort
*Add GSM IR resistor for better GSM deep sleep
*Reserve 3 GPIO for hardware version control
*Fixed LEDs power usage (from about 150mW of v5 to about 25mW)
* ATAG_REVISION: 0360

=== GTA02 A5 to A6 changes ===
*Power Glitch on VB_SYS: Add capacitor on layout, Mass production A5 also apply this change.
*G-sensor separate these interrupt pins: At A5, each accelerometer INT1/INT2 connected to same line, at A6 only INT1 was connected.
*GSM_modem power source Reduce power's ripple when the phone is talking
*Keep active Disable keep active function, just fine tune
*GPIO for version control
*GSM RX_IR has some noise Add resistor and reduce GSM RX_IR noise and gsm can't enter suspend mode easily, apply on mass production A5.
*LED driving transistor apply on mass production A5.
*LCM's VDDIO We can totally power off LCM's power, save about extra 1mA.

U-Boot

2008-08-22T19:36:33Z

Brian H Wilson:

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader used on the smartphones is called '''U-Boot'''. It takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Booting into U-boot ==

* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Hold in the AUX button on power-up to access the boot menu.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

All versions of the OM smartphone use the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/daily/ in the subdirectory [device]/200808/[date]/.

All versions of the GTA02 (Neo Freerunner) that have been sold to the public are version 5 hardware so look for a file with "gta02" and "v5" in the name, for example
uboot-gta02v5-latest.bin

The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]]. For neo 1973 you may see [[Flashing_Openmoko#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

See [[Flashing Openmoko]]

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

U-Boot

2008-08-22T19:12:25Z

Brian H Wilson:

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Booting into U-boot ==

* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Hold in the AUX button on power-up to access the boot menu.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

All versions of the OM smartphone use the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/daily/ in the subdirectory [device]/200808/[date]/.

All versions of the GTA02 (Neo Freerunner) that have been sold to the public are version 5 hardware so look for a file with "gta02" and "v5" in the name, for example
uboot-gta02v5-latest.bin

The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]]. For neo 1973 you may see [[Flashing_Openmoko#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

See [[Flashing Openmoko]]

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

U-Boot

2008-08-22T16:56:26Z

Brian H Wilson: /* General */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

All versions of the OM smartphone use the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/daily/ in the subdirectory [device]/200808/[date]/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]]. For neo 1973 you may see [[Flashing_Openmoko#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

See [[Flashing Openmoko]]

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

GPS Data Logger

2008-08-19T21:23:09Z

Brian H Wilson: /* GPS multiplexer */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy and either use one of them or use them for inspiration.
See the Gypsy author's take on GPSd here: http://folks.o-hand.com/iain/gypsy/why-not-gpsd.html

So far Gypsy looks pretty good to me.

Maybe the control program should be separated out from the multiplexer.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T21:08:37Z

Brian H Wilson: /* External links */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

gypsy http://folks.o-hand.com/iain/gypsy/ GPS data multiplexer

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T21:07:13Z

Brian H Wilson: /* External links */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

=== Commercial software ===

ESRI ArcPad http://www.tdsway.com/products/solo_field

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T18:04:43Z

Brian H Wilson: /* RINEX */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== More features ==

All I can think of at the moment is rangefinders. I am sure there are others.

=== Laser rangefinder ===

There is another common situtaion where people use a laser rangefinder in conjunction with GPS, to get the location of an object that is not reachable (for example a boat) or a tree trunk (under heavy canopy).

== External links ==

ESRI ArcPad http://www.tdsway.com/products/solo_field

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T04:11:37Z

Brian H Wilson: /* External links */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== External links ==

ESRI ArcPad http://www.tdsway.com/products/solo_field

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

TDS Solo Field http://www.tdsway.com/products/solo_field

Trimble Terrasync http://www.trimble.com/terrasync.shtml

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T04:06:31Z

Brian H Wilson: /* People working on this project */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

== People working on this project ==

[[User:Brian H Wilson]] is blabbing a lot here and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T04:06:06Z

Brian H Wilson: /* RINEX */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accommodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. It might be possible to used tokenized GPX to make it more compact.

== External links ==

GPSd http://gpsd.berlios.de/

GPX http://www.topografix.com/gpx.asp http://en.wikipedia.org/wiki/GPX_(data_transfer)

RINEX specs ftp://ftp.unibe.ch/aiub/rinex/

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-19T00:06:36Z

Brian H Wilson: /* RINEX */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage? No.
It's an exchange format but it's intended to include data required to perform post-processing.
It stores direct satellite observations, not things needed for navigation like calculated position.

Specs are here: ftp://ftp.unibe.ch/aiub/rinex/

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

GPX would accomodate everything we need but it's ASCII XML and that means 1/2 the file is just XML formatting. We'd probably be better off recording raw NMEA streams.

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-18T22:42:03Z

Brian H Wilson: /* GPS multiplexer */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as bearing, PDOP and satellites in use. (Not just time and position).

Angle / inclination -- it might be possible to use the accelerometers in the smartphone to determine current inclination and calculate percent grade. You'd have to be able to calibrate this: mount the smartphone in a bracket and then read the acceleratometers to set it to 0 when on level ground.

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

Bearing - some GPS receivers include an electronic compass that provides azimuth even when not moving. The multiplexer should know if bearing values are valid or not and indicate this. The value should indicate whether it is set for magnetic or true north.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage?
It's an exchange format but it's intended to include data required to perform post-processing.
It might be overkill for applications that don't require post-processing.

Specs are here: ftp://ftp.unibe.ch/aiub/rinex/

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-18T22:37:55Z

Brian H Wilson: /* Data Logger */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as PDOP and satellites in use. (Not just time and position)

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

==== Speedometer, Pedomater -- Usage of logger by itself ====

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts such as hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

Speedometer functions would include tracking minimums, maximums, averages for speed, distance, and elevation (stopped, moving, combined). Bicyclists (and runners? I am not a runner...) want to know total climb.

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage?
It's an exchange format but it's intended to include data required to perform post-processing.
It might be overkill for applications that don't require post-processing.

Specs are here: ftp://ftp.unibe.ch/aiub/rinex/

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-18T22:34:34Z

Brian H Wilson: /* RINEX */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as PDOP and satellites in use. (Not just time and position)

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts like hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate general format for internal storage?
It's an exchange format but it's intended to include data required to perform post-processing.
It might be overkill for applications that don't require post-processing.

Specs are here: ftp://ftp.unibe.ch/aiub/rinex/

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-18T22:32:43Z

Brian H Wilson: /* Data format and exchange */

This page was created to address the use cases mentioned in [[GTA02 GPS]], including

* I want to log GPS data for later analysis.
* I want to collect GPS data for scientific field work (forestry, biology, etc)

The page was started on 17 August 2008 mostly as a thought exercise.
Please jump in and add to it.

== Overview ==

The typical commercial approach to managing GPS data is to create one big application that does everything well. Unfortunately everyone has a different idea of what "doing everything well" means. One person might want to use GPS to log and analyze bicycle rides while another does weed mapping and another might be doing asset management. One application cannot do all this well.

A better approach is to break it up into a set of components. Each component can be a standalone application. This relies on some kind of multiplexer such as gpsd (does gypsy support multiplexing?) so that each app has access to the GPS data stream.

Initially the main functions could be broken out these components.

# A '''GPS multiplexer''' that talks to the GPS receiver and feeds data to many applications.
# A '''GPS Controller''' to that can talk to the mulitplexer (and hence the GPS receiver) to display status and adjust settings.
# A '''Data Logger''' that can run all the time and record GPS data.
# A '''Field Collection Tool''' that allows doing specific operations such as averaging GPS data while waiting at a point for increased accuracy and entering attributes for a point.

'''Mapping''' We should consider how to support mapping as a part of the field collection tool; it is not strictly necessary but it can be very nice to have it incorporated. Likewise if you are logging a breadcrumb trail it can be very nice to be able to see it on the map. A mapping component will need to be able to update its display with data collected from the logger and the field collection tool.

== Main components ==

=== GPS multiplexer ===

Look at gpsd and gypsy (and the related religious wars) and either use one of them or use them for inspiration.

Partial list of requirements for the multiplexer
* Control internal GPS receiver
* Control external GPS connected via serial port (USB or bluetooth)
* Feed data from the selected GPS receiver to multiple applications.
* Handle a RTCM stream to allow realtime DGPS postprocessing.
* Supply all attributes to applications, including such things as PDOP and satellites in use. (Not just time and position)

==== External GPS ====

There is no reason we are limited to using the built-in GPS receiver. For applications requiring more accuracy (for example sub-meter), the GPS multiplexer should be able to accept data via USB or bluetooth and feed it to our applications. The controller program should be able to handle this situation.

=== Support for postprocessing? ===

Real-time DGPS correction possibilities include receiving an RTCM stream from an external device, receiving RTCM over an IP connection, and WAAS. Does the Ublox receiver support RTCM? Most receivers that support it just accept a stream of data from a serial line. You don't have to reverse engineer it, you just accept data from some source such as a DGPS Beacon Receiver and feed the output to the GPS receiver and you get something approaching 1 meter accuracy.

Postprocessed DGPS correction requires recording pseudorange data and running an application later. In the open source world this means [http://en.wikipedia.org/wiki/RINEX RINEX]. Anyone with more knowledge of RINEX should jump in and edit this section.

=== GPS controller ===

''I think OM gps test program (what's it called) does much of this.''

Some GPS receivers include a feature to stop logging or to issue warnings if data quality goes too low for any reason. Where should this be handled? In the multiplexer or in the applications? Maybe the settings should be applied to the multiplexer and it should issue warnings to the applications which would then decide what to do.

=== Data Logger ===

The basic concept of the logger is to create a bread crumb trail as you move about.
It has its own preference settings to determine if points are plotted based on change in position or on a time basis or both.

It should also be possible to set what is logged. Possibilities include time, position, bearing, velocity, elevation, pseudo-range data, HDOP, PDOP, satellites used, type of GPS, type of antenna, DGPS on/off, type of DGPS.

The data logger would be one crucial component in an application of GPS for bicyclists (and outdoor enthusiasts like hikers and runners.) Other requirements would be a good display (to substitute for a speedometer) and a good mapping program.

Should we expand on that on this page? It would be neat to have something that interoperates with the GPS multiplexer and the data logger so maybe we should?

''I ride a bicycle and I use GPS as a speedometer and to do field work and I want to be able to do both with my Freerunner.'' [[User:Brian H Wilson|Brian H Wilson]] 19:38, 18 August 2008 (UTC)

=== Field Collection Tool ===

'''Attributes''' Mission planning should include setting up a file to be used for data collection, and that file should define attributes to be included. The data collector should be configurable to facilitate easy entry of the attribute data. For example, if you define a field to have a finite list of values, the values could be available as a drop down list.

'''Point averaging''' Stand in one place and collect points until you are happy. The display should show current PDOP/HDOP and expected accuracy and number of readings used to create tehe point. Preferences should include storing all data used to create the averaged point.

'''Points, lines and polygons.''' You should be able to collect all three. A typical use for polygons is to walk around a space while collecting GPS points to create a polygon showing the location of some physical object such as a wetland.

==== Other related tools ====

Other specialized field collection tools could be used for

* Asset management, example: urban forestry, agriculture, public works
* Map making, for example to collect data for the Open Street Map project
* Geocaching
* ??? Add yours here ???

== Data format and exchange ==

The data should be stored internally in a compact form that is open or at least well documented (for example ESRI Shapefiles). Storing in XML based formats is bulky and should probably be avoided.

There should be a desktop tool to manage transferring the data that has been collected from the smartphone to more portable exchange formats such as GPX and GML and KML. "GPS Office"

=== RINEX ===

Would RINEX be an appropriate format for internal storage?
It's an exchange format.

Specs are here: ftp://ftp.unibe.ch/aiub/rinex/

This guy wrote a program that takes Ublox Antares 4 data and writes it as RINEX data.
http://home.comcast.net/~dmilbert/softs/ant2rin.htm

== People working on this project ==

[[User:Brian H Wilson]] blabbing a lot and wishing he had more time to work on this.

[[Category: GPS]]

GPS Data Logger

2008-08-18T19:51:02Z

Brian H Wilson: /* Field Collection Tool */

GPS Data Logger

2008-08-18T19:46:21Z

Brian H Wilson: /* Data format and exchange */

GPS Data Logger

2008-08-18T19:45:21Z

Brian H Wilson: /* Overview */

GPS Data Logger

2008-08-18T19:43:44Z

Brian H Wilson: /* Field Collection Tool */

GPS Data Logger

2008-08-18T19:38:47Z

Brian H Wilson: /* Data Logger */

GPS Data Logger

2008-08-18T19:36:23Z

Brian H Wilson: /* Overview */

GPS Data Logger

2008-08-18T19:34:53Z

Brian H Wilson:

GPS Data Logger

2008-08-18T18:39:07Z

Brian H Wilson: New page: This page addresses the use cases mentioned in GTA02 GPS, including Category: GPS

This page addresses the use cases mentioned in [[GTA02 GPS]], including

[[Category: GPS]]

GPS applications

2008-08-18T18:37:34Z

Brian H Wilson: /* Use cases */ Removed link to email that was not really relevant. Added link to new data logger page.

== Possible GPS applications ==

As people develop more sophisticated GPS applications, please note them here.

=== Use cases ===

* I want to look at maps.
* I want to be able to prepare data and load my own maps.
* I want to load map data in a WKB (well known binary) format such as shapefiles.
* I want to go somewhere; please tell me how to get there. Routing.
* I want to help with the [[Openstreetmap]] project by collecting data.
* I want to use [[Openstreetmap]] data in a map viewer.
* I want to use the smartphone GPS to go [[Geocaching]]
* I want the GPS to update profile settings based on my location. Example, mute the phone ringer when I am at work.
* I want to log GPS data for later analysis. [[GPS Data Logger]]
* I want to collect GPS data for scientific field work (forestry, biology, etc)

=== Applications software ===

'''Please note if a program works or if it's vapourware.'''

* Cairo-based mapping (I wonder what this is?)
* [http://www.kflog.org/cumulus/ Cumulus] GPS software for glider pilots (and pilots in general), has a port for Qtopia and pulls (world) maps from the KFLog flight planner project. I think someone has put a project like this on the projects website * [http://wiki.openstreetmap.org/index.php/Pyroute Pyroute] is a routing program written in Python by Ojw, and a mobile phone GUI for maps, GPS, and routing.
:* [http://wiki.openstreetmap.org/index.php/Rana Raná] is the new version of pyroute
* [http://wiki.openstreetmap.org/index.php/Gosmore Gosmore] is a routing and viewer of OSM XML data such as the planet.osm.
* [[GPS Sight]], a popular Openmoko project under LGPL.
* [[GPS-Trail]] a simple trail logger.
* [[GPS_Navigation#roadmap|roadmap]] mapping system using freely available maps (US census TIGER, DGLib, shapefiles).
* [[Navit]] a car navigation system with routing engine.
* [http://svn.projects.openmoko.org/svnroot/openmoko-agpsui Openmoko AGPS UI project].* [[Orrery]], an unpopular Openmoko project for displaying the night sky.
* [[qpegps]] qtopia (arm PDA) based map viewer with gps features
* [[QMapControl]] Qtopia based mapping widget. Displays maps and custom data, also other widgets can be bound to coordinates. GPS parser for the gllin output included.
[http://projects.openmoko.org/projects/openvario/ here].
* [http://www.tangogps.org TangoGPS] mapping program. Downloads maps on demand and caches them, very efficient. '''Works very well.'''

Manually using GPS

2008-08-15T20:34:33Z

Brian H Wilson: Manually using GPS moved to GPS on the Neo 1973: THe page name did not make any sense and info is only for the Neo 1973

#REDIRECT [[GPS on the Neo 1973]]

GPS on the Neo 1973

2008-08-15T20:34:33Z

Brian H Wilson: Manually using GPS moved to GPS on the Neo 1973: THe page name did not make any sense and info is only for the Neo 1973

The Neo1973 device contains an integrated GPS. The particular device
is marketed as an AGPS, and there is some [[Hardware:AGPS |
discussion]] available as to what significance that "A" might have.

All purchased phones do not include the GPS binary driver. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html]
But finally, as described in [[November_29%2C_2007_Community_Update]], the binary driver is available to the community now.

There is an ongoing effort to write a Free Software
program that could be used instead of this binary-only program. See
[[Hammerhead/Protocol]] for details and the latest status.

== Quick test (driver output to console) on Neo1973 Phase 1 ==
''Main article: [[Getting GPS console output with gllin]]''

To get the output of this driver, read the file /tmp/nmeaNP (it is actually a pipe, not a file). The simplest way is to open another ssh connection to the phone and use cat:
cat /tmp/nmeaNP

This way it is possible to see the first results very easily.

== The "GPS Sight" program with graphic interface ==
''Main article: [[GPS Sight]]''

There is also a working open source GPS preview program to get the gllin output to the graphical environment. It can immediately show the location, altitude, speed and curved distance from selected point. This program can also draw the covered path (no background map).

== The old program in /home/root/DM2/gps ==
''Main article - [[Phase 1 GPS driver]]''

In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included
in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device). It was compiled to OABI format which now is obsolete as OM2007.2 builds are in EABI format, but developers suggested tricks to run it with ''chroot''. These approaches seem now obsolete and the old binary seems even no longer easily available.

== Bluetooth GPS ==

He also [http://pavelmachek.livejournal.com/39659.html succeeded]
at getting the Neo1973 to act like a bluetooth GPS with the following
script: (Note that this script has bad problems if you run it more than once. You can get a "time traveling GPS" effect, with the GPS showing you your past position).

#!/bin/sh
killall rfcomm tail
mknod /dev/rfcomm0 c 216 0
echo 1 > /sys/devices/platform/s3c2410-i2c/i2c-0/0-0008/gta01-pm-bt.0/power_on
sleep 1
hciconfig hci0 up name linuxgps
sleep 1
sdpd
sleep 1
sdptool add SP
(
while true; do
rfcomm listen /dev/rfcomm0 1
sleep 1
done
) &
(
while true; do
tail -f /tmp/gps.nmea > /dev/rfcomm0
echo 1 > /sys/class/leds/gta01\:vibrator/brightness
sleep 1
echo 0 > /sys/class/leds/gta01\:vibrator/brightness
done
) &

== Using UDP ==

gllin sends a udp packet per nmea sentence on port 6000. this is a much cleaner aproach because using files will fill up memory or rootfs (the latter will result in the need for reflashing).

i switch off writing to /tmp/nmeaNP and logging to log/... with

-np
-nmea

the help says that -nmea is the default, fact is that gllin logs nmea sentences into ./log/<date> wich will fill up mem or rootfs for long running tests. the following python script reads the nmea sentences (you need to have python-io installed to get the socket module):

#!/usr/bin/python
import sys
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('127.0.0.1', 6000))
while True:
line = s.recv(1024)
sys.stdout.write(line)
sys.stdout.flush()

the program just prints those to stdout but other methods are possible (i feed them into a NMEA parser).

benefits are that both programs can be started and stopped at will. none needs the other. gllin will not terminate if /tmp/nmeaNP is not there or not read from. the `cat /tmp/nmeaNP | gzip > gps.gz` is a useless idea anyway because the files in log/ (current directory) contains the NMEA data already.

== NMEA ==
The ouput from the binary driver seems to follow the NMEA standard.

Some information about it is available at [http://gpsinformation.org/dale/nmea.htm gpsinformation.org] and on [http://en.wikipedia.org/wiki/NMEA Wikipedia].

[[Category:GPS]]

Getting GPS console output with gllin

2008-08-15T20:31:48Z

Brian H Wilson: Added intro comment

[[gllin]] is the driver used to access GPS data in the Neo 1973. If you have a Freerunner you don't need to look at this page.

== How to see gllin output ==

This page describes the "quick start" procedure allowing to see the first output and actually use the GPS device in the command line mode, using the [[gllin]] driver.

After you download and install the gllin_1.0+r350-r0_fic-gta01.ipk (or similar), it creates the folder 'gllin' in the root home. This folder contains the executable with the same name which starts the driver.

To get the output of this driver, read the file /tmp/nmeaNP (it is actually a pipe, not a file). The simplest way is to open another ssh connection to the phone and use cat:
cat /tmp/nmeaNP
Type cat ''after'' you start the gllin, not before. The output from the GPS driver looks like
$GPRMC,235946.99,V,,,,,,,120180,,,N*78
$GPGSA,A,1,,,,,,,,,,,,,11.2,5.0,10.0*36
$GPGGA,235946.99,,,,,00,00,5.0,,M,0.0001999,M,0.0020199,*57
(and so on).

The data are presented in [http://gpsinformation.org/dale/nmea.htm NMEA format] which gives a lot of data. The coordinates themselves are reported with the two messages (GPRMC and GPGGA) that are described below. Both messages occur in the normal output (also in conditions when the the device does not see any satellites and cannot give actually report the coordinates). They consist of multiple comma separated fields. Even numeric fields like coordinates under some circumstances are empty. Empty fields are easy to recognize because commas are included anyway.

Below we discuss both messages, giving the real examples that were taken in surroundings of Zurich (official coordinates 47°22′N, 8°33′E with approximate elevation about 408 m) early morning (about 6:44 UTC), in the 8th of January 2008.

== GPRMC message ==
GPRMC tels the latitude, longitude, speed, time and date. Hence the proper signal could also be used to set up the clock. If the device can see the satellites, the message looks like

GPRMC,064459.00,A,4723.078551,N,00831.004788,E,000.0,000.0,080108,,,A*50

Where:
*'''064459.00''' Fix taken at 6:44:59.00 UTC (early morning)
*'''A''' '''A''' for the normal (active) message or '''V''' for the void message. Void messages are described below.
*'''4723.078551,N''' Latitude 47 degrees 23.078551 minutes North.
*'''00831.004788,E''' Longitude 8 degrees 31.004788 minutes East
*'''000.0''' Ground speed in knots (we are just standing in place). Multiply by 1.852 to get kilometers per hour.
*'''000.0''' Track angle in degrees
*'''080108''' Date - 8th of January 2008 (year goes last, 240307 is 24th of March 2007)
*'''(empty)''' Would be magnetic variation
*'''<nowiki>*</nowiki>50''' The checksum, begins with *

If the device cannot see the satellites properly (it usually does not work indoors unless very close to the window), it puts 'V' (void) at the output. In this case the GPRMC messages look like

GPRMC,114031.52,V,,,,,,,120108,,,N*76

In this case it is necessary to go to the more open place. It may take several minutes before device reports the correct location.

== GPGGA message ==
This message does not tell the speed but it tells the number of satellites, estimates the quality and gives the altitude. The message looks like

GPGGA,064458.00,4723.078480,N,00831.004426,E,1,06,1.0,464.0,M,0.271000,M,0.0100505,*42

Here
*'''064458.00''' Current time is 06:44:54 UTC (the test was done early morning)
*'''4723.078480,N''' Latitude 47 degrees 23.078480 seconds North
*'''00831.004426''' Longitude 8 deg 31.004426 seconds East
*'''1''' Fix quality: 0 = invalid, 1 = GPS fix (SPS), 2 = DGPS fix, 3 = PPS fix, 4 = Real Time Kinematic, 5 = Float RTK, 6 = estimated, 7 = manual input, 8 = simulation mode
*'''06''' Number of satellites being tracked (six are seen)
*'''1.0''' Horizontal dilution of position
*'''464.0,M''' Altitude (in meters) above mean sea level.
*'''0.271000, M''' Height of geoid (mean sea level) above WGS84 ellipsoid
*'''0.0100505''' time in seconds since last DGPS update
* Following the spec, next should go the DGPS station ID number but seems missing.
* '''<nowiki>*</nowiki>42''' the checksum, always begins with *

If the device cannot see the satellites properly it reports the zero quality. The number of satellites can also be checked. For instance, the device indoors may report:

GPGGA,120213.58,,,,,00,00,1.0,,M,0.0001999,M,0.0020599,*56

Which means that the UTM time is 12:02:13.58 (correct), the quality is 0 and no any satellites can be seen. This explains why the coordinate fields are empty.

== Using grep ==
The trivial way to concentrate on one type of the GPS messages is to use grep which is installed in the phone:
cat /tmp/nmeaNP | grep GPRMC

From other interesting messages, device emits GPGSV (detailed information about satellites and where they are in the sky). See [http://gpsinformation.org/dale/nmea.htm NMEA documenation] for details.

== Using awk ==
The awk tool provides some more elegant parsing capabilities. For example, find your current location with
awk -F, '/\$GPGGA/ {print (substr($3,0,2) + (substr($3,3) / 60.0)) $4, (substr($5,0,3) + (substr($5,4) / 60.0)) $6}' /tmp/nmeaNP

[[Category:GPS]]
[[Category:Application Developer]]

Hammerhead/Protocol

2008-08-15T20:28:18Z

Brian H Wilson: Added intro

Hammerhead is the GPS receiver chip used in the Neo 1973. The only way currently to use it is via a closed-source binary program. This page describes efforts to write an open source driver. (Mostly abandoned since the release of the Neo Freerunner which uses a different chipsset)

== Repository ==

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

[[User:mmontour]] has created a quick and dirty gtk program called 'satscan' which performs the first steps of a cold-start acquisition. It scans through the satellite numbers 8 at a time in several different frequency bands, and displays a symbol on the screen indicating the strength of each signal. The program (which includes portions of 'hhtest.c') is available here: [http://members.shaw.ca/mmontour/satscan/]. Description/screenshots are

[http://openmoko.togaware.com/survivor/SatScan.html]

== Background resources ==

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://folks.o-hand.com/andrew/strace-schwartz-oabi is a log of all library calls (i.e. a superset of system calls) made by gllin during a hot start and acquiring the time (but no fix), except acos() because printing all acos() calls would fill gigabytes per second.

A file giving doppler information on the above longtrace NMEA is on [http://www.mauve.plus.com/gps].

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

https://okeefesrv.geomatics.ucalgary.ca/essentials/index.html provides a library of useful GPS-related algorithms under a 3-clause BSD license.

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.

There is an interesting paper on increasing accuracy of commercial GPSs that may be applicable. [http://www.ion.org/search/view_abstract.cfm?jp=j&idno=2439].
Other interesting papers. [http://gauss.gge.unb.ca/papers.pdf/iongpsgnss2003.beran.pdf] [http://topo.epfl.ch/documents/EuroSDR/beran05.pdf]

=== Packet format & comm protocol ===

See sphyrna project for up-to-date decoding info.

[[Category:GPS]]

Neo 1973 hardware

2008-08-15T20:26:07Z

Brian H Wilson: /* AGPS */ Fixed link

{{Box}}

[[Openmoko]] is a software distribution stack that sits on top of a [[hardware]] platform. The [[Neo1973]] phone is the first hardware platform to take advantage of Openmoko. You can find specifics of the [[:Category:Neo1973 Hardware | Neo1973 Hardware]] by reviewing this introduction page and the pages in the category as shown at the bottom of this page.

'''Note that this page is about the first Openmoko phone which is now discontinued. See details on the second Openmoko phone at this page - [[Neo FreeRunner GTA02 Hardware]].'''

[[Image:Gta01b v3 top.jpg|thumb|400px|display (top) side]]
[[Image:Gta01b v3 bottom.jpg|thumb|400px|component (back) side]]

==User experiences of Phase 0 hardware==
[[Wishlist:Neo1973_P0_Review]]

==User reports of robustness==
User experiences - drops onto concrete - ... [[Neo1973 Robustness]]

== Physical Dimensions ==
* 120.7 x 62 x 18.5 mm (4.75 x 2.44 x 0.728 inch)
* 184 +/- 5 g (6.5 ounces)
* For the purposes of acquiring/cutting a properly sized screen protector, the display hole of the case is about 45 x 59 mm, while the top cover internal frame can house up to a 53 x 74 mm protector; sizes much larger than the display hole would obviously necessitate removing the front cover for installation.
* A Useful size comparison between the Neo1973, iPhone, Motorola A1200 and the SEM600i can be seen at [http://www.sizeasy.com/page/size_comparison/5512-Neo1973-vs-Apple-iPhone-vs-M600i-2-vs-A-1200 sizeasy]

== Main components ==
=== Processor ===
The main Processor (CPU) of the Neo1973 is a Samsung S3C2410AL-26 (Capable of running up to 266 MHz)

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410 S3C2410.htm]
* User Manual: [http://www.samsung.com/global/business/semiconductor/productRightMenuDown.do?doc_file=26537 2410UserManual.pdf]
* Core: ARM920T
* Instruction Set: ARMv4
* BSDL File: [http://www.samsung.com/global/business/semiconductor/productRightMenuDown.do?doc_file=26554 S3C2410_BGA_BSDLJTAGFILE.bsd]
* GPIO Assignments: https://svn.openmoko.org/trunk/doc/hardware/GTA01Bv4/gpio.txt

=== Flash ===
64MB Samsung NAND flash (K9F1208U0B) attached to S3C2410 NAND controller.

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=158&partnum=K9F1208U0B]
* Data Sheet: [http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NANDFlash/SLC_SmallBlock/512Mbit/K9F1208U0B/ds_k9f1208x0b_rev03.pdf]
* Connected to: S3C2410 NAND controller

This is the only flash memory in the device. The S3C2410 boots directly from nand, using the [[S3C2410 Steppingstone]].

We only use free software, no proprietary flash file systems. For a full description of how it is used, see [[NAND bad blocks]]

=== RAM ===
128MB SDRAM (2x Samsung K4M511633C) attached to S3C2410 SDRAM controller
* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=136&partnum=K4M511633C]
* Data Sheet: [http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/MobileSDRAM/MobileSDRSDRAM/512Mbit/K4M511633C/ds_k4m511633c.pdf]
* Connected to: S3C2410

=== GSM/GPRS ===
The [[GSM]] (including GPRS) modem is Texas Instruments Calypso based.

* Connected to: S3C2410 UART1 (full-uart, RxD, TxD, CTS, RTS), /dev/ttySAC0 in userspace
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch
* Accessible GSM/GPRS antenna jack (if battery cover is removed)

==== CALYPSO digital baseband ====
Unfortunately we cannot provide many details on the GSM chipset due to very tight NDAs. However, this is not neccessarily required, since it interfaces using a standard UART serial line with the S3C2410. On that interface, [http://www.3gpp.org/ftp/Specs/archive/07_series/07.05/ GSM 07.05], [http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/ GSM 07.10] and other standardized protocols are used.

==== TWL3014 analog baseband ====
Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12295&contentId=4703 TWL3014]

==== TRF6151 RF Transceiver ====
Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12296&contentId=4701 TRF6151] 
GPRS Class12/CS4 

=== [[Hardware:AGPS|AGPS]] ===
Hammerhead PMB 2520 AGPS from Global Locate.

* Product Homepage: [http://www.globalocate.com/SEMICONDUCTORS/SEMI_HAMMER_Frameset.htm Hammerhead]
* Connected to: S3C2410 UART2 (full-uart, RxD, TxD, CTS, RTS) /dev/ttySAC1 in userspace
* Driver: Implemented as a binary with NMEA output suitable for the gpsd daemon ([[gpsd]])
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch
* Externally-accessible GPS antenna connector of type MMCX

A binary (closed source) driver is available - see [[gllin]].
Efforts to reverse engineer the protocol are partially detailed in [[Hammerhead/Protocol]], these have stalled since the announcement that the Neo FreeRunner will use a different GPS.

=== microSD-Card ===
The Neo1973 has one microSD aka Transflash slot.
It supports SDHC. MicroSD slot is [[Disassembling_Neo1973#Opening_back_cover|under battery]].
* Connected to: S3C2410 MMC/SD controller
* Mounted to: /media/card
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c_mci.patch
* [[Supported microSD cards]]
* Specifications: [http://www.sdcard.org/confirm/confirm_memorycard.aspx SD Simplified Specification], [http://www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf MMC (partial)], [http://www.sandisk.com/Assets/File/OEM/Manuals/manual-rs-mmcv1.0.pdf MMC (product manual)]

=== LCD Module (LCM) ===
This is a 2.8" diagonal (1.7" x 2.27" - 43mm x 58mm) 480x640 toppoly (tpo) TD028TTEC1 module (283 DPI), using a Toshiba JBT6K74 TFT LCD Driver Chipset.
* Homepage: [http://www.tpo.biz/ENG/business-eng/Activer-Matrix-VGA.htm Activer-Matrix-VGA.htm]
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-jbt6k74.patch
* Backlight Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-backlight.patch
* Connected to: S3C2410 Display Controller and S3C2410 SPI Interface channel 1
* Backlight controllable via /sys/class/backlight/gta01-bl

==== Touch Screen ====
* Connected to: S3C2410 TS controller
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_touchscreen.patch

==== Stylus ====

Seemingly identical to [http://cgi.ebay.com/4in1-PDA-Stylus-LED-Light-Torch-Laser-Pointer-Pen-h7_W0QQitemZ280089656134QQihZ018QQcategoryZ48677QQrdZ1QQcmdZViewItem this one on ebay]

=== Bluetooth ===
Delta DFBM-CS320 Class2 Module, using CSR BlueCore4 (V2.0+EDR).

* Data Sheet: [http://www.delta.com.tw/product/cp/vco/BT/download/pdf/CS/2.DFBM-CS320.pdf 2.DFBM-CS320.pdf]
* CSR Data Sheet: [http://www.csrsupport.com/download/2302/CS-101564-DSP10%20BlueCore4-ROM%20Product%20Data%20Sheet.pdf CS-101564-DSP10 BlueCore4-ROM Product Data Sheet.pdf]
* Driver: Stock Linux Kernel BlueZ
* Connected to: S3C2410 USB Host controller (OHCI)
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch

=== Vibrator ===
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-vibrator.patch
* Connected to: S3C2410 GPIO
* Controllable via /sys/class/leds/gta01:vibrator

=== USB Host ===
The USB Host controller is inside the S3C2410
* Driver: Stock Linux kernel ohci_hcd

=== USB Device ===
The USB Device controller is inside the S3C2410
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_udc.patch
* Please see [[USB Product IDs]] on information about which Vendor/Product IDs we use
* 1200mAh lithium battery charges when connected to powered host.
* Mini-B connector [http://www.cypressindustries.com/enlarge.asp?Img=products/images/ccmusbb-32005-601.gif this one].
* This can be used as a USB host: [[Neo1973_USB_host]]

=== I2C Devices ===
The I2C is a simple communication standard intended to move small amounts of data a few inches between chips.
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973.

=== Audio ===
See also: [[Neo1973 Audio Subsystem]]

==== Wolfson Codec ====

''Main article: [[WM8753]]''

There's a [[WM8753]] Wolfson Microelectronics ''codec'' (This is not a "smart" codec that can interpret MP3/... it is a simple dumb "sound card".

==== Stereo Amplifier ====
There's a National Semiconductor [[LM4857]] Stereo Amplifier at the analog audio output of the WM8753

* Product Homepage: [http://www.national.com/pf/LM/LM4857.html LM4857.html]
* Data Sheet: [http://www.national.com/ds.cgi/LM/LM4857.pdf LM4857.pdf]
* Connects to: S3C2410 I2C (Control)

==== Analog wired Headset ====
There's a four-ring 2.5mm stereo jack which provides connectivity to old-fashioned wired headsets.

The headsets used by Motorola smartphones (A780,A1200, ...) and the V-360 have a compatible configuration.

Pinout: [http://lists.openmoko.org/pipermail/community/2008-March/013791.html]

<pre><nowiki>
base = ground
speaker left (internal impedance 33R) to ground. (+jackinsert detection)
speaker right (internal impedance 33R) to ground.
tip = mic electret condenser type, to ground.
bias (power for mic) 2K2 from +3.3v(wolfson codec)
(+HoldButton shortcircuit to ground)
</nowiki></pre>

==== Bluetooth Headset ====
This one is wired via PCM bus from the CSR Bluetooth chip to the Wolfson codec.

=== Power Management ===
A Philips PCF50606 is used for [[Neo1973_Power_Management|power management]].

* Data Sheet: [http://www.nxp.com/acrobat/literature/9397/75009763.pdf PCF50606/605]
* User Manual: [http://www.rockbox.org/twiki/pub/Main/DataSheets/pcf50606.pdf pcf50606.pdf]
* Connected to: S3C2410 via I2C, client address is 0x08.
* Driver Source: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-pcf50606.patch

=== Battery ===
The [[Neo1973 Battery]] is compatible with a Nokia BL5C battery.
According to [http://lists.openmoko.org/pipermail/community/2007-February/003758.html this] post on the mailinglist.
[http://wiki.openmoko.org/index.php?title=Image:Neo1973-with-BL5C-battery.png Photo] of the battery inside the Neo1973.

=== Buttons ===
The Neo1973 features two buttons:
# [[Neo1973 Power Button|The Power Button]]
# [[Neo1973 AUX Button|The "Aux" button]]

=== Alternate cases ===
A number of alternate case designs have been suggested and requested.

[[Neo1973 case schematics]]

[[Alternate Neo1973 case designs]]

== History ==
=== GTA01 ===
This is the most simple, non-bluetooth version of the prototype.

==== GTA01v3 ====
First generation of prototypes that was given to internal OpenMoko software developers.

Unfortunately not useful at all due to non-working touchscreen.

* ATAG_REVISION: 0x0000130

==== GTA01v4 ====
Second generation of prototypes that was given to [[User:HaraldWelte|Harald]] +[[User:Mickey|Mickey]].

Unfortunately still not useful due to half-working touchscreen.

* ATAG_REVISION: 0x00000140

=== GTA01B ===
This is the bluetooth-enabled fork of GTA01

==== GTA01Bv2 ====
This is the first produced version of the bluetooth-enabled version.

* ATAG_REVISION: 0x00000220

==== GTA01Bv3 ====
This is the second produced version of the bluetooth-enabled version. It contains mainly GPS-related fixes.

* ATAG_REVISION: 0x00000230

This is the version that is shipped in [[Neo1973#Phase_0_.28GTA01Bv3.29|Phase 0]].

===== GTA01Bv3 Errata =====
====== PMU unable to resume from suspend ======
Due to use of wrong GPIO/EINT pin, the PMU cannot wake-up the phone after suspend. This means, specifically, '''the following events can not bring the phone back from suspend-to-ram''':
* PMU RTC Alarm
* Power button press
* Charger events (charger insertion/removal/error)
* Low battery

====== Stand-by time extremely low ======
This is due to a design bug resulting in at least 30mA additional standby current, since we cannot properly switch off the power supply to the S3C2410 PLL's. There is nothing we can do to change this with post-production fixes. GTA01Bv4 will address this issue.

====== GSM doesn't resume phone from suspend ======
The GSM modem currently doesn't signalize a wakeup interrupt to the S3C2410 in case there's some noteworthy event, such as incoming call, loss of network, incoming SMS or the like.

This is a serious issue, but can be fixed with a GSM Modem Firmware update.

====== GSM Sidetone too loud ======
The local feedback sidetone (see [http://en.wikipedia.org/wiki/Sidetone]) is too loud. This will be addressed in a GSM firmware update

====== Bad block ======
Due to an error in the production process, the factory-programmed NAND bad block information has been lost. This means that some blocks in the flash will wear out rapidly, which might become as bad as rendering the device unusable.

==== GTA01Bv4 ====
This is the version that is being shipped in [[Neo1973#Phase_1_.28GTA01Bv4.29|Phase 1]]

===== Looks =====
This is what the GTA01Bv4 PCB looks like without the shielding cans, which will be fitted later.
[[Image:Gta01b_v4_front.jpg|thumb|400px|Component side]]
[[Image:Gta01b_v4_back.jpg|thumb|400px|Display side]]

===== Errata =====

There were two versions of GTA01Bv4: some were given away (red mainboard), and some were sold (green mainboard). The given-away have [[one transistor too many]].

===== Changes from GTA01Bv3 =====
# Fix all Errata items from GTA01Bv3
# Add I2C, SPI and one irq and wakeup capable GPIO pin to debug port plus have test pads for all these signals (for soldering wires directly on the pcb)
# Fix a number of production related details and minor hardware details that are not user-visible

===GTA02===
The [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]] is now called the Neo FreeRunner and shipped within the "Mass Market launch" (see [http://wiki.openmoko.org/wiki/Neo1973#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|timeline]).
It is a new main release with [[Neo1973:_GTA01Bv4_versus_GTA02_comparison|features added]]

===Debug Connector===
This is the connector used to connect the [[Debug Board]] and possibly other hardware.

Connections are:
* 39 - GND
* 38 - STDI
* 37 - _RESET
* 36 - STMS
* 35 - STCK
* 34 - STDO
* 33 - GSM_EN
* 29 - _STRST
* 19 - X_I2C_SCL (H-TP4703)
* 18 - X_I2C_SDA (H-TP4704)
* 17 - SPI_CLK0
* 16 - SPI_MOSI0
* 15 - SPI-MISO0
* 14 - SS0
* 13 - EINT3 (H-TP4705)
* 3 - MODEM_TXD (H-TP4701)
* 2 - MODEM_RXD (H-TP4702)

Information from [http://people.openmoko.org/roh/Debugport_GTA01bv4.png].

===Test points===

* GSM RTS - H-TP1531
* GSM CTS - H-TP1530
* GSM Modem on - R10818 - ungrounded end
* GSM_EN - R1501 (not present) - ungrounded end

== Distinguishing hardware revisions ==
=== Inside the [[Bootloader]] ===
Every hardware revision has its own u-boot image type. Thus, the bootloader has the revision hard-coded.
The hardware revision is passed on to the kernel via the ATAG mechanism (ATAG_REVISION)

=== Inside the [[Kernel]] ===
The kernel receives the ATAG_REVISION during bootup, and saves its contents in the "system_rev" global variable.

=== From Userspace ===
The kernel exports the system_rev variable in /proc/cpuinfo as "Revision :" line.

??? So does GTA01Bv4 equal the cat /proc/cpuinfo output of
Hardware : GTA01
Revision : 0240

== Approval ==
*CE compliance is needed before a product can be sold in the EU. The CE mark indicates that a product complies to the relevant legislation, defined in the [http://ec.europa.eu/enterprise/newapproach/standardization/harmstds/reflist.html harmonised standards]. This refers also to the most relevant, for the Neo1973, [http://ec.europa.eu/enterprise/newapproach/standardization/harmstds/reflist/emc.html Directive 89/336/EEC on electromagnetic compatibility] (EMC is the art of assuring [http://en.wikipedia.org/wiki/Electromagnetic_compatibility electromagnetic compatibility] between products). The standards are defined by [http://www.cenelec.org CENELEC] (European Committee for Electrotechnical Standardization), but not verified by any authority. It is the responsibilty of the manufacturer to convince himself that a product is in compliance, and is obligated to be able to prove this (with relevant technical documentation) for a specific product to the authorities on request. Whether the current Phase 1 devices are actually tested against the directives are unknown, no documentation has been disclosed, other than the fact that the devices bear the CE mark.

*[http://www.fcc.gov/ FCC]

===GTA01 FCC test report===

[http://people.openmoko.org/tony_tu/GTA01/certificate/FCC/ FCC test report]

===GTA01 CE test report===

[http://people.openmoko.org/tony_tu/GTA01/certificate/CE/ CE test report]

===GTA01 NCC test report===

For Taiwan Import usage:

[http://people.openmoko.org/tony_tu/GTA01/certificate/NCC/ NCC test report]

[[Category:Neo1973 Hardware]]