Openmoko - User contributions [en]

PulseAudio

2008-04-12T13:38:54Z

PH5: how to make pulseaudio available on the network

'''PulseAudio''' ([http://www.pulseaudio.org/ homepage]) is the sound server used by OpenMoko to mix output from several applications as needed.

[[neod]] uses PulseAudio to play the samples "startup" and "touchscreen".

The samples are loaded from files and can be changed or disabled at the configuration file /etc/pulse/session.

== Turning the Neo1973 into a USB sound card ==

The sound server can easily be made available (and discoverable, thanks to [http://www.avahi.org Avahi]) in the local network, effectively turning the Neo1973 into an overqualified USB sound card (see also: http://www.pulseaudio.org/wiki/PerfectSetup):

ipkg install pulseaudio-module-zeroconf-publish pulseaudio-module-native-protocol-tcp
echo "load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16" >> /etc/pulse/session
echo "load-module module-zeroconf-publish" >> /etc/pulse/session
/etc/init.d/pulseaudio restart

Now on a Desktop with PulseAudio properly set up, the padevchooser applet lists the Neo's hostname as audio sink as soon as it is connected via USB.

[[Category:Software ]]
[[Category:Application Developer]]

Openmoko Local Groups: Berlin

2007-09-09T10:39:19Z

PH5: pH5->neo++

See [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]

=== Possible Participants ===
{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
!Has Device
!Has Debug Board
|-
|[[User:Minime|tim]]
|mostly web related
|No GTA01Bv4, waiting for GTA02.
|berlin.nord
|willing to organize stuff i.e. meeting location/whatever. [http://wiki.openmoko.org/index.php?title=User_talk:Minime&action=edit&section=new talk to me], or e-mail: OM DOT 5 DOT minime@xoxy.net
|
|
|-
|[[User:spag|spag]]
|too lazy
|patiently waiting for GTA02 with WLAN
|Marzahn
|I'm interested in VoIP applications on OpenMoko.
|
|
|-
|[[User:PH5|pH5]]
|Coding, RE, Uni
|OpenMoko, gsmd, GTA01, Magician
|Zehlendorf
|[http://projects.linuxtogo.org/projects/sphyrna Sphyrna]
|[[Image:Moko.jpg|center]]
|
|-
|[[User:Barmeier|barmeier]]
|Coding in C and Java
|GTA01, Magician
|Steglitz
|I'am interested in Sync, application integration and usability improvements
|
|
|-
|[[User:Kriss|kriss]]
|Coding
|
|Wedding
|
|[[Image:Moko.jpg|center]]
|[[Image:MokoBox.jpg|center]]
|-
|[[User:Roh|roh]]
|developer support
|just working here ;)
|mitte
|
|[[Image:Moko.jpg|center]]
|[[Image:MokoBox.jpg|center]]
|-
|...
|
|
|
|
|
|
|}

=== Meetings, Events ===
Meeting language is German ;-)
{|border=1
!Date
!Location
!Topic
!Who
|-
|8.-12. August 2007
|Flugplatz Finowfurt
|[https://events.ccc.de/camp/2007/Intro/ Chaos Communication Camp 2007] und [http://events.ccc.de/camp/2007/GSM_Village GSM Village]
|?
|-
|23.08.2007 / 18:00
|[https://berlin.ccc.de/wiki/CCC_Berlin CCCB] / [https://berlin.ccc.de/wiki/Club_Discordia Club Diskordia]
|First meeting. bring your hardware
|Roh, pH5, [[User:Minime|tim]](+ 2?), ? (please add yourself)
|-
|no definite date yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|no location yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|First GTA01Bv4 impressions for P1 owners and those who have no Neo yet. Giving each other a helping hand getting started.
|[[User:Minime|tim]], ...
|}
[[Category:OpenMoko_Local_Groups:_Berlin]]

Openmoko Local Groups: Berlin

2007-08-20T17:26:04Z

PH5: /* Meetings, Events */

See [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]

=== Possible Participants ===
{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:Minime|tim]]
|mostly web related
|No GTA01Bv4, waiting for GTA02.
|berlin.nord
|willing to organize stuff i.e. meeting location/whatever. [http://wiki.openmoko.org/index.php?title=User_talk:Minime&action=edit&section=new talk to me], or e-mail: OM DOT 5 DOT minime@xoxy.net
|-
|[[User:spag|spag]]
|too lazy
|patiently waiting for GTA02 with WLAN
|Marzahn
|I'm interested in VoIP applications on OpenMoko.
|-
|[[User:PH5|pH5]]
|Coding, RE, Uni
|OpenMoko, gsmd, GTA01, Magician
|Zehlendorf
|[http://projects.linuxtogo.org/projects/sphyrna Sphyrna]
|-
|[[User:Barmeier|barmeier]]
|Coding in C and Java
|GTA01, Magician
|Steglitz
|I'am interested in Sync, application integration and usability improvements
|-
|...
|
|
|
|
|}

=== Meetings, Events ===
Meeting language is German ;-)
{|border=1
!Date
!Location
!Topic
!Who
|-
|8.-12. August 2007
|Flugplatz Finowfurt
|[https://events.ccc.de/camp/2007/Intro/ Chaos Communication Camp 2007] und [http://events.ccc.de/camp/2007/GSM_Village GSM Village]
|?
|-
|23.08.2007 / 18:00
|[https://berlin.ccc.de/wiki/CCC_Berlin CCCB] / [https://berlin.ccc.de/wiki/Club_Discordia Club Diskordia]
|First meeting. bring your hardware
|Roh, pH5, ? (please add yourself)
|-
|no definite date yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|no location yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|First GTA01Bv4 impressions for P1 owners and those who have no Neo yet. Giving each other a helping hand getting started.
|[[User:Minime|tim]], ...
|}
[[Category:OpenMoko_Local_Groups:_Berlin]]

Openmoko Local Groups: Berlin

2007-08-16T22:26:42Z

PH5: /* Possible Participants */

See [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]

=== Possible Participants ===
{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:Minime|tim]]
|mostly web related
|No GTA01Bv4, waiting for GTA02.
|berlin.nord
|willing to organize stuff i.e. meeting location/whatever. [http://wiki.openmoko.org/index.php?title=User_talk:Minime&action=edit&section=new talk to me], or e-mail: OM DOT 5 DOT minime@xoxy.net
|-
|[[User:spag|spag]]
|too lazy
|patiently waiting for GTA02 with WLAN
|Marzahn
|I'm interested in VoIP applications on OpenMoko.
|-
|[[User:PH5|pH5]]
|Coding, RE, Uni
|OpenMoko, gsmd, GTA01, Magician
|Zehlendorf
|[http://projects.linuxtogo.org/projects/sphyrna Sphyrna]
|-
|...
|
|
|
|
|}

=== Meetings, Events ===
Meeting language is German ;-)
{|border=1
!Date
!Location
!Topic
!Who
|-
|8.-12. August 2007
|Flugplatz Finowfurt
|[https://events.ccc.de/camp/2007/Intro/ Chaos Communication Camp 2007] und [http://events.ccc.de/camp/2007/GSM_Village GSM Village]
|?
|-
|no definite date yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|no location yet - please use [[Talk:OpenMoko_Local_Groups:_Berlin|discussion]]
|First GTA01Bv4 impressions for P1 owners and those who have no Neo yet. Giving each other a helping hand getting started.
|[[User:Minime|tim]], ...
|}
[[Category:OpenMoko_Local_Groups:_Berlin]]

Booting the Neo FreeRunner from SD via U-Boot

2007-08-13T18:44:04Z

PH5: suggest ext2 file system on SD cards

Here are the steps described to boot your system from an SD card.

=== Step 1: Build your kernel ===

Kernel building is supposed to be done through OpenEmbedded. If you use the MokoMakefile open up $OMDIR/openmoko/trunk/oe/packages/linux/linux-gta01/defconfig-2.6.21.6-fic-gta01. If you are building OM-2007.2 open $OEDIR/packages/linux/linux-gta01/defconfig-2.6.21.5-fic-gta01. (''Note that the kernel version may change in future versions.'')

Now find the line saying:

CONFIG_MMC_S3C=m

and change it to:

CONFIG_MMC_S3C=y

If you want to use an ext2 file system on the SD, also find the line saying:

CONFIG_EXT2_FS=m

and change it to:

CONFIG_EXT2_FS=y

Thats it. Now rebuild the kernel.

=== Step 2: Populate SD card ===

Format partition 1 as ext3 (or better ext2 if enabled, see above). Mount your SD card somewhere and put your image on it:

mount /dev/sda1 /mnt/moko
tar -C /mnt/moko/ -xvzf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

Now we also want the kernel on there

cp uImage /mnt/moko/boot/

If you are building OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After building a new image by issuing ''bitbake openmoko-devel-image'' there will be a ''OpenMoko-....tar'' in the deploy directory. Copy it on the SD card by doing

mount /dev/sda1 /mnt/moko
tar -C /mnt/moko/ -xvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar

In OM-2007.2 the last built kernel gets a special soft-link. Therefore you can copy it by doing:
cp uImage-fic-gta01-latest.bin /mnt/moko/boot/uImage

=== Step 3: Add uboot boot entry ===

On my Phase-1 Neo the boot menu entry existed already. If yours is missing it follow those instructions: Start uboot in bootmenu mode (= hold AUX while powering on) and add the following entry via serial console: (See [[Bootloader]] section on how to access an bootloader).

GTA01Bv4 # setenv menu_4 Boot from SD: setenv bootargs root=/dev/mmcblk0p1 rootdelay=5 console=ttySAC0,115200 console=tty0 loglevel=8 \${mtdparts}\; mmcinit\; ext2load mmc 0 0x32000000 /boot/\${sd_image_name}\; bootm 0x32000000
GTA01Bv4 # setenv sd_image_name uImage
GTA01Bv4 # saveenv

You can now easily boot a different kernel by changing the variable sd_image_name to the new name.

=== Step 4: Boot into the new system ===

Power off your device, insert the SD card and boot into the boot menu. You should have an entry called "Boot from SD" which does exactly that. :-)

[[Category:Software]]
[[Category:Guides]]

Booting the Neo FreeRunner from SD via U-Boot

2007-08-13T18:42:31Z

PH5: add instructions to compile in ext2 fs

Here are the steps described to boot your system from an SD card.

=== Step 1: Build your kernel ===

Kernel building is supposed to be done through OpenEmbedded. If you use the MokoMakefile open up $OMDIR/openmoko/trunk/oe/packages/linux/linux-gta01/defconfig-2.6.21.6-fic-gta01. If you are building OM-2007.2 open $OEDIR/packages/linux/linux-gta01/defconfig-2.6.21.5-fic-gta01. (''Note that the kernel version may change in future versions.'')

Now find the line saying:

CONFIG_MMC_S3C=m

and change it to:

CONFIG_MMC_S3C=y

If you want to use an ext2 file system on the SD, also find the line saying:

CONFIG_EXT2_FS=m

and change it to:

CONFIG_EXT2_FS=y

Thats it. Now rebuild the kernel.

=== Step 2: Populate SD card ===

Format partition 1 as ext3 (ext2 will not boot). Mount your SD card somewhere and put your image on it:

mount /dev/sda1 /mnt/moko
tar -C /mnt/moko/ -xvzf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

Now we also want the kernel on there

cp uImage /mnt/moko/boot/

If you are building OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After building a new image by issuing ''bitbake openmoko-devel-image'' there will be a ''OpenMoko-....tar'' in the deploy directory. Copy it on the SD card by doing

mount /dev/sda1 /mnt/moko
tar -C /mnt/moko/ -xvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar

In OM-2007.2 the last built kernel gets a special soft-link. Therefore you can copy it by doing:
cp uImage-fic-gta01-latest.bin /mnt/moko/boot/uImage

=== Step 3: Add uboot boot entry ===

On my Phase-1 Neo the boot menu entry existed already. If yours is missing it follow those instructions: Start uboot in bootmenu mode (= hold AUX while powering on) and add the following entry via serial console: (See [[Bootloader]] section on how to access an bootloader).

GTA01Bv4 # setenv menu_4 Boot from SD: setenv bootargs root=/dev/mmcblk0p1 rootdelay=5 console=ttySAC0,115200 console=tty0 loglevel=8 \${mtdparts}\; mmcinit\; ext2load mmc 0 0x32000000 /boot/\${sd_image_name}\; bootm 0x32000000
GTA01Bv4 # setenv sd_image_name uImage
GTA01Bv4 # saveenv

You can now easily boot a different kernel by changing the variable sd_image_name to the new name.

=== Step 4: Boot into the new system ===

Power off your device, insert the SD card and boot into the boot menu. You should have an entry called "Boot from SD" which does exactly that. :-)

[[Category:Software]]
[[Category:Guides]]

Talk:Hammerhead/Protocol

2007-06-22T19:01:08Z

PH5:

Um... Pavel, maybe I'm missing something here, but I think what you're calling "received packet 00" is what I'm calling packet 10. Are you saying that the high nibble of the packet type doesn't matter? Because I can't see any particular connection between these packets and the type 00 packets that gltt sends. Likewise what you're calling packet 03 has a type byte of 23, and 0D has a type byte of 9D. (I'm pretty sure that the high nibble is important. For another example, look at packet type 0E versus 9E.) [[User:FloppusMaximus|FM]] 23:24, 6 May 2007 (CEST)

Since you never answered, I fixed the headings. I don't have much time to work on this at the moment, so that's basically all I did. Also I'm not sure what you're talking about w.r.t packet 06 (/16?) so I left that alone. If you disagree with my analysis, that's fine, and please say so. [[User:FloppusMaximus|FM]] 13:32, 17 May 2007 (CEST)

I also think the high nibble of the packet type is important. 0E seems to be an answer to the 00 packet when a satellite is locked, whereas 9E is one of the possible answers (9D,9E,9F) to the 05 packet. I have started to analyze the cold start trace at [http://linuxtogo.org/~ph5/tmp/gllin/cold2.log.gz], there are some statistics about the 00 packet at [http://linuxtogo.org/~ph5/tmp/gllin/cold2-cmd00-stat.txt] and a closer look on the sequence of events on a single channel (ch 1) [http://linuxtogo.org/~ph5/tmp/gllin/cold2-ch01.txt]. I used a shell script [http://linuxtogo.org/~ph5/tmp/gllin/decode.sh] to filter the serial communication out of the strace output. [[User:PH5|PH5]] 16:19, 17 May 2007 (CEST)

Except for the flags, the packet format is now mostly understood [http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/doc/?root=sphyrna]. The 'packet type' is really an initial register offset, every channel has its own set of registers, and the 0x2 flag seems to switch to a completely different register bank. [[User:PH5|PH5]] 20:58, 22 June 2007 (CEST)

Hammerhead/Protocol

2007-06-22T18:57:23Z

PH5: add link to sphyrna

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

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

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

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

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

== Possible lock scheme that it may use ==

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

== Enhancements ==

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

== Analysis ==

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

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

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

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

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

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

=== Packet statistics ===
Packet types:

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

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

=== Global packets ===

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

==== SEND Packet 04 ====

Flags = 4

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

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

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

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

One 32 bit word bitmask

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

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

Flags = 0

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

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock.

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

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

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

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

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

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

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

==== RECEIVED Packet 10 ====

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

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

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

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

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

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

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

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

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

Always appears to be 24 bytes. Satellite-specific.

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

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

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

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

== NMEA ==

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

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

At this point:

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

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

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

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

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

</pre>

Hammerhead/Protocol

2007-06-21T13:30:37Z

PH5: /* SEND Register/Packet 08 */

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 . (Plesae use strace -s9999 -x to produce traces).

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

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

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

== Possible lock scheme that it may use ==

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

== Enhancements ==

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

== Analysis ==

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

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

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

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

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

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

=== Packet statistics ===
Packet types:

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

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

=== Global packets ===

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

==== SEND Packet 04 ====

Flags = 4

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

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

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

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

One 32 bit word bitmask

* 0x2000 lets the timstamp clock (See 16) run. One can start and stop it using this bit.
* 0x4 resets the timestamp clock to 0. (putting a 0x4 will reset the clock. The bit is self-resetting to 0. This only works, if 0x2000 is set at the same time.

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

Flags = 0

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

==== RECEIVED Packet 16 ====

Flags = 8;
Comes only after request for it.

The chip seems to have an internal 1ms clock. This returns the counter for this clock.

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

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

=== Satelite / channel specific packets ===

==== SEND Packet 00 ====

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

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

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

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

==== RECEIVED Packet 10 ====

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

Packet length is constant (always 16 bytes.)

==== RECEIVED Packet 23 ====

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

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

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

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

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

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

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

Always appears to be 24 bytes. Satellite-specific.

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

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

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

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

== NMEA ==

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

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

At this point:

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

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

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

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

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

</pre>

Talk:Hammerhead/Protocol

2007-05-17T14:19:36Z

PH5:

UI Improvements

2007-04-02T13:21:04Z

PH5: multitouch on resistive touchscreen

==Introduction==

Obviously the tools are in the wild to build interfaces that could rival
(or better IMO) anything Apple comes up with. We just need to organize
this stuff. This would need hardware that can support dynamic
interfaces. I can help here, too.
sean@openmoko.com

==Finding inspiration ...==

===Seen Live===

*[http://www.youtube.com/watch?v=89sz8ExZndc Multi-Touchscreen experiments video @youtube]
*[http://www.youtube.com/watch?v=nPqqfVLQ_qY iPhone UI features demo @youtube]

===Ergonomy - Human/Machine papers ===

===Our weapons===

====The touchscreen====

Question:

What exactly does the touchscreen see when you touch the screen with 2 fingers at the same time,
when you move them, when you move only one of the 2, etc. I'm also interested in knowing how precise
the touchscreen is (ex: refresh rate, possible pressure indication, ...)?

Answer:

* The output is the center of the bounding box of the touched area
* The touch point skips instantly on double touch
* Pressure has almost no effect on a single touch, but not so on a double touch. The relative pressures will cause a significant skewing effect towards the harder touch. You can easily move the pointer along the line between your two fingers by changing the relative pressure.

Conclusions:
* we can detect double touch as jumps, and that's all
* no pressure

Question:

What does one see when sliding two fingers in parallel up(L,R)->down(L,R)?

Answer:

* In theory you see a slide along the center line between your two fingers. In practice, you can't keep the pressure equal, so you will see some kind of zig-zag line somewhere between the two pressure points in the direction of your slide.

Question:

What does one see when narrowing two fingers in slide (=zoom effect on iphone)?

Answer:

* In theory you see the pointer stay at the center of the zoom movement. In practice, you can't keep the pressure equal for both fingers, so the pointer will move towards one of the two pressure points.

====Graphics and computational capabilities====

It would be good to report what performance the current hardware allows.

==Areas of improvement==

* OpenGL for fuild zooming interfaces (2D: the infinite sphere model, 1D: the infinite wheel of fortune/ribbon model, exposé)
* HandGestures
* Physics-model based improvements: inertia and friction
* multi touch screen for natural handgestures

===Physics-inspired animation===

If we want to add eye candy & useability to the UI (such as smooth realistic list scrolling, as seen in apple's
iphone demo on contacts lists), we'll need a physics engine, so that moves & animations aren't all linear.

The most used technique for calculating trajectories and systems of related geometrical objects seems to be [http://en.wikipedia.org/wiki/Verlet_integration verlet integration] implementation; it is an alternative to Euler's integration method, using fast approximation.

We may have no need for such a mathematical method at first, but perhaps there are other use cases. For instance, it may be useful to gesture recognition (i'm not aware if existing gesture recognition engines measure speed, acceleration...).

====Libakamaru====

The [http://people.freedesktop.org/~krh/akamaru.git/ akamaru library] is the code behind [http://www.youtube.com/watch?v=VekgyKQoTeM kiba dock]'s fun and dynamic behaviour. It's dependencies are light (needs just GLib). It takes elasticity, friction, gravity into account.

If you want to take a quick look at the code:
svn co http://svn.kiba-dock.org/akamaru/ akamaru

The only (AFAIK) application using this library is kiba-dock, a *fun* app launcher, but we may find another use to it in the future.

As suggested on the mailing list, it is mostly overkill for the uses we intend to have, but this library may be optimized already, the API can spare some time for too. Furthermore, ''Qui peut le plus, peut le moins''.

====Verlet integration implementation from e17====

There's an undergoing verlet integration implementation into the e17 project (by rephorm) see http://rephorm.com/news/tag/physics , so we may see some UI physics integration into e17 someday.

===OpenGL compositing===

Compositing seems to give zooming interfaces reality (at last!).

Well, considering recent changes in destkop applications, opengl has a
definite future. For instance, the expose (be it apple's or beryl's)
is a very interesting and usable feature. Using compositing allows the
physics metaphore: the human brain doesn't like "gaps"/jumps (for
instance while scrolling a text), it needs continuity. When you look
at apple's iphone prototype, it's not just eye candy, it's maybe the
most natural/human way of navigating, because it's sufficiently
realistic for the brain to forget the non-physical nature of what's
inside.

So, opengl hardware will be needed in a more or less distant hardware,
for 100% fluid operation.

And, if we really want deep changes, multi touch screen if essential
too :( (example: zooming with fingers)...

====Clutter Toolkit====

Clutter, an openedhand project, is an open source software library for creating fast, visually rich graphical user interfaces. The most obvious example of potential usage is in media center type applications. We hope however it can be used for a lot more.

http://clutter-project.org/

Clutter uses OpenGL (and soon optionally '''OpenGL ES''') for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.

From the [http://en.wikipedia.org/wiki/OpenGL_ES wikipedia article], OpenGL ES (OpenGL for Embedded Systems) is a subset of the OpenGL 3D graphics API designed for embedded devices such as mobile phones, PDAs, and video game consoles.

==Improvement ideas==

Please add here any idea that seems of relevance.

===1D Scrolling: [http://en.wikipedia.org/wiki/Uniform_prism n-sided uniform prism]===

====Description====

Take an item list (ex: adress book), print it on a ribbon of paper, and glue it on a wheel (on the tire). You're looking in the front of it, so when you want to go from the A to Z, you touch the wheel and drag it up. When you let the wheel go, it goes furter, taken by it's inertia. Stop the wheel when you got your contact. Got the idea? That's why we may speak of an "infinite wheel", so that the surface is flat. For our case here, we always want to display square content, so the [http://en.wikipedia.org/wiki/Uniform_prism n-sided uniform prism] analogy is mathematically more exact.

Why this wheel model? Because if the modelisation is coherent:
- '''weight''': the more heavy, the fastest it goes = the biggest the item list, the faster it scrolls; that way, you don't have to wait too long for big lists, and you don't miss your item on shorter lists
- '''friction''': there is friction where the wheel is fixed, so that the wheel doesn't turn infinitely
- the initial speed and acceleration vector you give it determines it's futher rotation
- it's "round"/cyclic, so you can browse the list in two directions

We can add "parallel wheels", symbolizing different sorting methods. Slide long to the left / right to look at a different wheel = items organization.

====Controls====

* Sliding up/down = Single click + maintained for a minimal distance
Effect: scroll in an inverted/negated fashion (slide down = scroll up,
slide up = scroll down)

When finger is released (i.e. touchscreen doesn't detect any press):
if (last_speed_seen > value ) then keep this speed and
acceleration, with friction (so that it slows down)
else stop scrolling

Scrolling here is seen as unidimensional, but can apply to
bidimensional situations (ex: zoomed image) too

* Action = quick double tap

* Details/select = short single tap

* Right click = long tap

* Sliding left/right: switch sorting method

====Parts to "hack"====

''Having a scroll that isn't a 1:1 map to the user's action isn't hard. It's just an extra calculation in the scroll code.''

<---- Where is the scroll code? :)

* libmokoui
* gtk

I'm wondering what layer of openmoko has to be hacked, i.e. if working at openmoko layer allows enough possibilities for this; if i'm not mistaken, this is part of libmokoui, but i'm pretty afraid that patching gtk itself woud be needed. Working on the lower level would
apply changes to every application, not only openmoko's.

TODO:
* remove the scrolling slider on finger mode
* make the entire list a "scrolling zone", i.e. an overlay transparent scrolling slider
* define controls

===1D Scrolling: inertia friction integration into openmoko's finger wheel===

The same, but for the wheel. It can be very short to do: you don't have 1:1 anymore, but, for example, 1/4 wheel turn = 1 item. It's demultiplicated, but has inertia.

===2D Scrolling: the infinite sphere model / non-infinite polyhedron===

The same model as the infinite wheel can apply to 2D navigation, except that your wheel becomes an infinite "floating sphere" for image/webpage navigation.

Usages are:
* zoomed image
* zoomed internet webpage
* browsing maps

===n-D navigation: the polyhedra inspiration===

When we want to navigate files, mp3s in an mp3 player, etc... Every control that the application needs is a button. What about looking at the polyhedrons ?

http://en.wikipedia.org/wiki/Polyhedra
http://en.wikipedia.org/wiki/List_of_uniform_polyhedra

===Advanced/Natural handgesture recognition===

TODO

Gestures can be interesting, especially for "jumps" (when the cursor jumps from upper left corner to down right). Jump is different of sliding, and appears only with touchpads and touchscreeds; it can be detected as different from a button press if done fast enough (so you don't have to "aim" precisely).

The interesting jumps are:

* left <-> right
* middle up <-> middle down
* top left <-> down right
* down left <-> top right

==Open questions==

* will the neo/openmoko graphics system be powerful enough for such uses? I suspect apple to do opengl acceleration on this device,
which is waaaaay impossible for us for now
* how does the touchscreen behave? We need a detailed touchscreen wiki information page, with visual traces. How hardware-specific is it?
* without multitouch, is there really room for improvement?

User talk:Parag0n

2007-03-18T08:29:04Z

PH5:

Parag0n, [http://www.flickr.com/photos/ph5/424014896/ this] is for you ;)

Wishlist/Games

2007-03-18T08:25:37Z

PH5: /* Candidates for porting/cross compiling */

{{Wishlist}}

=== Games on OpenMoko ===

This is the page to centralize the suggestions for creating games on the OpenMoko device.

===== Existing game concepts that could be realized =====
* Simple Flash games like [http://www.albinoblacksheep.com/flash/squares2.php Squares2] are often very addicting and good for short playing sessions. Other examples: Bejewelled, Zoo Keeper, [http://novelconcepts.co.uk/FlashElementTD/ Flash Element TD ], ...
* A classic shooter can work well with continous fire and touchscreen controls. An example is Kenta Cho's Java version of [http://www.asahi-net.or.jp/~cs8k-cyu/java/noiz2_e.html Noiz2]
* Same is true for a 3D shooter with no/seldom used additional controls. For example a combat flying game like Hunt for the [http://www.smallrockets.com/pc/baron/ Red Baron]. You can control the speed with a slider, shoot rockets and drop bombs with special buttons but those are things you only need from time to time. Most of the time you are shooting continously and aiming which can be done in the corner of the touchscreen (so it doesn't obstruct your view).
* Osu! Tatakae! Ouendan/Elite Beat Agents - Rhythm-based touching of circles and paths on the screen is a great concept and shouldn't be that difficult to pull off if you leave out some of the great presentation.
* Pac Pix - The necessary shape-recognition would probably be difficult to manage with a small budget but the general idea is quite cool.
* Kirby Canvas Curse - Again, not easy to do with a small budget.

===== Candidates for porting/cross compiling =====
* [http://www.openttd.com Transport Tycoon Deluxe]. Very possible, in fact the author of the Palm & GP2X ports of the game is already interested in OpenMoko.
* [http://www.aeonflame.com/ Gloop Zero] - A little like physics-based Lemmings. Get the liquid from one part of the level to another with tools like path-drawing, bombs, anti-gravity...
* [http://www.clickgamer.com/moreinfo.htm?pid=4188&section=PALM Plazmoids!] - A space game with screen-size levels. Move your ship around by touching where it should go. Collect the plazmoids (asteroids) by catching them in your elastic tractor beam (lots of simple physics again), shoot enemies with a button or double tap.
* [http://redshift.hu/ Legacy] (and successor The Quest) - Classic first person turn based RPG. Movement and menus can completely be controlled with the touchscreen.
* [http://www.warfareincorporated.com/ Warfare Inc.] - A full real time strategy game is no problem with a touchscreen. In fact, it's a lot of fun!
* [http://en.wikipedia.org/wiki/Heroes_of_Might_and_Magic Heroes of Might and Magic] maybe can be port this [http://www.pocketheroes.net/ Pocket Heroes] for PocketPC
* Command & Conquer and Red Alert - [http://sourceforge.net/projects/freera/ FreeRA] or [http://freecnc.org/ FreeCNC]
* [http://www.fade-team.com/acedior.htm Acedior] - A classic graphic adventure game.
* Frozen Bubble
* GJeweled
* [http://www.bridgebuilder-game.com Bridge Builder]
* Pipe Dreams
* ScummVM
* [http://www.tucows.com/preview/9259 Gem Drop]
* that addictive Photo game where you have to spot the 5 differences in x seconds
* Checkers, Chess, Minesweeper (interesting touchscreen variation: [http://toyspring.com/3dm/ 3D Mines] by Toyspring, Solitaire, Mahjong, Connect Four, Tic-tac-toe, Black Jack
* Creating a Nethack port could be done. Tony said on the list: "I'm not entirely sure yet. I imagine I'll first do a text port with a "portal" view (in which you only see a part of the screen at a time), and a user-selected font size. Then I'd try a tiles-based port. It all depends on how readable the text is on the small screen."
* [http://www.mame.net/ MAME] - Multiple Arcade Machine Emulator. This versatile emulator turns a given platform into a powerful gaming system. It has been ported to WinCE and many UNIX flavors as well. It would be wonderul to have this on the OpenMoko.
* [http://gnome-sudoku.sourceforge.net/ Gnome Sudoku]
* [http://web.mit.edu/xiphmont/Public/gPlanarity.html gPlanarity] would be a nice stylus game.
* [http://www.chiark.greenend.org.uk/~sgtatham/puzzles/ Simon Tatham's Portable Puzzle Collection] is GTK based and includes, among others, both Sudoku and Planarity style games called Solo and Untangle.

===== General ideas about games on OpenMoko =====
* A easy network library for Bluetooth and/or GPRS connectivity.
* Every turn-based game should be possible with on screen buttons.
* Action games should need only one main control action most of the time such as moving somewhere on a 2D plane, aiming in 3D, drawing a path. Special items and actions are possible but should only be needed from time to time. There is no solution for first person shooter type games where you move and aim independently.
* The finger getting into the way of seeing what's going on is a problem. Most games would probably need a stylus. Games with first person aiming can be controlled with a thumb in one corner of the screen, however you'd probably need one of them thumbstraps they make for the DS so that your thumb glides over the screen with ease.
* GPS can be used for location based games. An example is [http://codeninja.de/tron/ Tron]. Links to location-based/Alternate Reality games in these [http://del.icio.us/tallpaul/games+street del.icio.us pages]
* Bluetooth controllers should be supported. I am especially thinking about the Nintendo Wii remote.
* If version 2 of the hardware has an accelerometer a [http://www.rubylane.com/shops/molotov/item/SUN1769 tilt maze ball game] is possible.

What is not possible without magic tricks / an external controller:
* Classic first person shooters, action adventures, jump 'n' runs
* Emulators for classic systems
* Network lip for easy Bluetooth and/or GPRS connections.
* Bluetooth controllers should be supported. I am especially thinking about the Nintendo Wii remote.
* If version 2 of the hardware has an accelerometer a [http://www.rubylane.com/shops/molotov/item/SUN1769 tilt maze ball game] is possible.

[[Category:Ideas]]