Openmoko - User contributions [en]

Neo Freerunner audio subsystem

2010-03-18T22:51:27Z

Neiljerram: /* Empirical Data for Mic Settings */

The Neo Freerunner (GTA02) inherited the audio subsystem from its older brother the Neo 1973 (GTA01). However, there are a few small differences.
This page tries to show and explain the differences and points you to the [[Neo_1973_audio_subsystem | Neo 1973]] page whenever it touches the common points (but there may be overlaps for the sake of usability). As wiki pages are, errors and omissions are likely, and your help is welcomed.

==Differences from Neo 1973==
* There is only 1 (mono) built-in loud speaker (connected to LOUT1) instead of 2 (stereo).
* The Wolfson Codec driver presents 94 separate controls {switches, multiplexers, and volumes} to the alsa system (in both Neos). Unfortunately they are not mapped exactly the same for the GTA01 as for the GTA02.

==Possible sound connections through the Wolfson Codec==
* "Yes" = Confirmed, alsa state file exists.
* "No" = Not possible / not desirable.
* "Should" = Should be possible, not confirmed yet.
* "?" = Have no idea.

{| cellspacing="0" cellpadding="5" border="1"

|- align="center"
! - !! CPU !! GSM !! Bluetooth

|- align="center"
! GSM
| Yes

|- align="center"
! Bluetooth
| via BT-USB || Yes

|- align="center"
! Wired Speaker
| Yes || Yes || via CPU

|- align="center"
! Wired Mic
| Yes || Yes || via CPU

|- align="center"
! Body Earpiece
| Should || Yes || should (via CPU)

|- align="center"
! Body Speaker
| Yes || Yes || should (via CPU)

|- align="center"
! Body Mic
| Yes || Yes || should (via CPU)

|}

==Alsamixer channel controls==
The ALSA state files are installed by default, and belong to package ''"openmoko-alsa-scenarios"''.
To see where the files reside, do ''"opkg files openmoko-alsa-scenarios"''.
Currently ([[SHR]]), they are in ''"/etc/freesmartphone/alsa/default/gsmhandset"''; in other systems, they might be found in ''"/usr/share/openmoko/scenarios/"''.
Recommended statefile for phone usage is http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new

# State: '''''GSM <-> Built-in Handset''''' (file gsmhandset.state)
## Mic volume:
##* Control 48: "Mic2 Capture Volume" (alsamixer name: "Mic2". Suggested value: max [3] - see below)
##* Control 12: "Mono Sidetone Playback Volume" (alsamixer name: "Mono sidetone" Suggested value: 5 [=0dB])
##* Control 5: "Mono Playback Volume" (alsamixer name: "Mono" Value: as needed [80..110]) This is the "user control" for mic
##* Control 63: 'Mic Sidetone Mux' MANDATORY VALUE "Mic 2"!!!
##* General rule is to keep control.12, and ajust control.48 so you have a resonable setting for user control.5 (i.e. NOT <70 or >110)
## Earpiece volume:
##* Control 6: "Bypass Playback Volume"
##* Control 4: "Speaker Playback Volume" This is the user control for earpiece volume

According to the [http://www.mail-archive.com/community@lists.openmoko.org/msg56045.html conclusion] of a [http://www.mail-archive.com/community@lists.openmoko.org/msg56037.html thread] from Dec 09, you might want to set Control 12 to value 5 if people you call complain about background noise, static, etc with the above settings.

For mic settings please refer also to http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem#AT.25Nxxxx

user should set volume according to own preferences:
for mic the (full, true) procedure is as follows:
reduce #5 by some 15..30 steps
do testcall:
you get very low volume at far end. but tone should be clear, no clipping (sharp agressive noise)
if there is clipping: reduce #48 by one step (i.e. to "2")
then adjust #5 to your preferences and taste
(do `alsactrl store -f gsmhandset.state` to save the changes if you used a mixer to adjust the levels)

for earpiece(-speaker):
level up modem to full volume (AT+CLVL cmd used by framework),
level up #6 to full volume,
adjust by #4
if you get clipping when #4 is at moderate level (same as above): reduce #6 (or even AT+CLVL) until clipping vanishes
(very unlikely to occur for earpiece playback)

# State: '''''GSM <-> Built-in Handsfree''''' (file gsmspeakerout.state)
## Mic volume:
##* Control ?:
## Speaker volume:
##* Control ?:
# State: '''''GSM <-> Wired Headset''''' (file gsmheadset.state)
## Mic volume:
##* Control 49: "Mic1 Capture Volume"
##* Control 12: "Mono Sidetone Playback Volume"
##* Control 5: "Mono Playback Volume"
## Speaker volume:
##* Control 6: "Bypass Playback Volume"
##* Control 3: "Headphone Playback Volume"
# State: '''''GSM <-> Bluetooth Headset''''' (file ???)
## Alternative working state files: [http://handheldshell.com/gsm_headset.txt]
## Mic volume:
##* Control 13: "Mono Voice Playback Volume"
##* Control 5: "Mono Playback Volume"
# State: '''''CPU <-> Built-in Handset''''' (file voip-handset.state)
## Mic volume:
##* Control ?:
## Speaker volume:
##* Control ?:
# State: '''''CPU <-> Wired Headset''''' (file headset.state)
## Stereo sound:
##* Control ?:
## Headset output:
##* Control 94: "Amp Spk Switch" <- false
# State: '''''CPU <-> Buildin Speaker''''' (file stereoout.state)
## Mono sound:
##* Control ?:
## Headset output:
##* Control 94: "Amp Spk Switch" <- true
# State: '''''CPU -> GSM''''' (file gsmhandset.state)
## Mono sound:
##* Control 74: Mono Mixer Left Playback Switch to true
##* Control 75: Mono Mixer Right Playback Switch to true
##* Control 1: PCM Volume suggested value 135

--[[User:Femto|Femto]] 12:39, 24 September 2008 (UTC) I've updated above values. Must be checked.

-- I created another state file (voip-handsfree.state) for CPU Handsfree, mixed and matched voip-handset and stereoout. You can find it [http://wiki.openmoko.org/wiki/User:Savimonty here]. Feel free to make a change to it if there are errors. I don't see any, though.

=== Volume Control ===

Angus Ainslie has written a simple [http://n2.nabble.com/Sound-quality-in-calls.-tp1087522p1096155.html python volume control] (which is getting more and more sophisticated) using some of these settings.

Installing the GUI mixer

<pre>
wget http://handheldshell.com/pymixer.py
wget http://handheldshell.com/volume.desktop
cp pymixer.py /usr/bin
chmod u+x /usr/bin/pymixer.py
cp volume.desktop /usr/share/applications
opkg install python-pygtk
opkg install http://handheldshell.com/python-pyalsaaudio_0.3-ml0_armv4t.ipk
</pre>

If the python script aborts unexpectedly then look [http://lists.openmoko.org/nabble.html#nabble-td1128064 here] for a fix

You could also try [http://www.mazikeen.demon.co.uk/openmoko/fso-simplemixer.py fso-simplemixer.py], a simplified mixer based on the one above.

== Empirical Data for Mic Settings ==

'''"Experiment 1"''' in the table means:
# Set your controls as follows: control.12 (Mono Sidetone Playback Volume): 5 control.48 (Mic2 Capture): 3 control.63 (Mic Sidetone Mux): Mic 2 
# Call another phone from your Neo FreeRunner, mute it's microphone and listen to your voice coming from Neo FreeRunner's microphone. Connect to FreeRunner, run alsamixer and experiment then with control.5 (Mono Playback Volume) by lowering it so that buzzing noise is gone or at an acceptable level. After the noise is reduced, observe the actual volume/clarity of your voice when you speak.
# Write result in the table: "''Positive''" if you don't normally use such settings, but you achieved at least similar level of quality while using these settings, quality meaning lack of noise and clarity/volume of voice. "''Already in use''", if you already normally use settings that have control.12/48/63 like above. Write in notes if you experimented with other settings but found out these were superior, or similar. "''Negative''" if you don't normally use such settings, you experimented, but you failed to achieve similar level of quality with the settings above and experimenting with control.5. Please write in the notes how it failed - most typically did you not hear anymore your voice as well after reducing control.5 enough to get rid of the noise, or how did the experiment turn out negative? "''Not done''", if you didn't complete this experiment.

{| cellspacing="0" cellpadding="5" border="1"
| User || FR Revision + buzzfix? || Microphone Settings in Use (before) || Result of Experiment 1 || Notes
|- align="center"
| [[User:TimoJyrinki]] || A7 || control.5: 97 control.12: 5 control.48: 3 control.63: Mic 2 || Already in use || Able to reach acceptable level of quality with other settings as well, but somewhat less volume can be had with control.63 set to Right PGA before noise starts to be heard (when increasing control.5 and/or control.12 to compensate).
|- align="center"
| [[User:TimoJyrinki]] || A5 + buzzfix || control.5: 105 control.12: 7 control.48: 3 control.63: Mic 2 || Not done || Only checked from a backup, not sure anymore how the audio quality was like. Buzzfix now failing on the device so cannot test. I have used these kind of settings and also earlier control.63 set to Right PGA while increasing control.5.
|- align="center"
| [[User:Pini]] || A5 + buzzfix || control.5: 127 control.12:: 1 control.48: 1 control.63: Mic 2 || In use || Setting successfully tested in a rather noisy environment (train platform)
|- align="center"
| [[User:Neiljerram]] || A6 + buzzfix || control.5: 110 control.12: 7 control.48: 3 control.63: Right PGA || Not done || I've had no complaints at all about audio quality since accidentally discovering the Right PGA setting. It may be voodoo, but it works for me.
|- align="center"
| [[User:YourName]] || A1 + buzzfix || control.5: NN control.12:: N control.48: N control.63: NNNN || Not done || -
|}

Remark by jOERG: Please try to understand when you are using a different setting than control.63: Mic 2, you are using a whole bunch of function blocks from PGA and digital section and you are not considering how the settings of those function blocks impact on your results. The whole test report is void / useless if using left/right_PGA. Also, as elaborated here and in Talk, there's no benefit from using PGA routing (beyond voodoo).

[[Category:Neo FreeRunner Hardware]]
[[Category:Audio]]

User:Neiljerram

2009-12-16T00:32:28Z

Neiljerram: /* Working and Not Working */

I use Debian on my Freerunner. Following is a description of my setup, and of how well (or not) things are working with that setup.

=== Main points ===

Debian installed (again) on 10th December (2009, following major filesystem corruption of my previous Debian install).

matchbox window manager and keyboard. I'm kind of missing the E17 keyboard, but not as much as I expected to. The matchbox keyboard seems more usable than you'd think, given its size.

trayer, openmoko-panel-plugin and auxlaunch. Here's my .xsession:

#!/bin/sh
trayer --edge top --height 60 &
openmoko-panel-plugin &
zhone &
rm -f .auxlaunchpid
auxlaunch -dms &
exec matchbox-window-manager -use_titlebar no -use_cursor no

Some screenshots to show how it looks... I think the plainness of the top panel goes well with the sharp angles of Gtk+ apps.

<gallery>
Image:2009-12-15-221523_480x640_scrot.png|zhone
Image:2009-12-15-222642_480x640_scrot.png|auxlaunch
Image:2009-12-15-222742_480x640_scrot.png|Simon Tatham's cube puzzle
Image:2009-12-15-223038_480x640_scrot.png|aptitude-gtk
</gallery>

cellwriter is fun to have around. Once it has been started for the first time (which you can do from auxlaunch), it adds an icon to the top panel, and then you can click that to make cellwriter appear and disappear. So there is no need to decide whether to replace matchbox-keyboard with cellwriter in the openmoko-panel-plugin config; it's easy to have both. I made the following changes to the default config.

* Grid: 10 by 4 calls. Otherwise, when training, you can't get to some of the characters.

* Keyboard: 480 pixels wide. Obviously.

* Enable extended input events. Otherwise just doesn't work as an input method.

* Window docking: Bottom. Otherwise completely covers the app that you're trying to type into!

=== Working and Not Working ===

SMS mostly OK.

* Sometimes fails to send an outbound message, and then the message sits forever (until deleted) in zhone as "unsent".

* zhone's design of immediately showing you a received message doesn't completely work in practice, because it makes it easy to miss when there are other new messages.

Phone calls mostly OK.

* I haven't touched the GSM ALSA state file, and I haven't had any complaints.

* Ring tone is too quiet; I never hear it.

Wifi seems OK. I'm using the basic Debian approach with configuration in /etc/network/interfaces:

iface eth0 inet manual
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
...
iface default inet dhcp

and in /etc/wpa_supplicant/wpa_supplicant_conf:

network={
ssid="xxxxxx"
psk="xxxxxxxxxxxxxxxxxxxxxx"
}

Then when I need wifi, I

* use openmoko-panel-plugin's Wifi icon to power up the radio

* do "ifup eth0" and "dhclient eth0" in a terminal.

That all works, but

* it would be nicer if the "ifup eth0" could be made to happen automatically when the Wifi radio is powered up

* I'm sure I shouldn't have to do the "dhclient eth0" step explicitly; so something must be wrong in my configuration there

* I don't understand why the Freerunner apparently wants "wpa-conf" in /etc/network/interfaces, whereas my other Debian systems have "wpa-roam".

(I previously tried wicd and wifi-radar, but they both seem to be very good at hanging the system and/or eating loads of CPU; and I don't see any great need for them.)

GPRS seems unreliable, and this appears to be a regression from my previous Debian installation - perhaps something to do with the new GSM muxer? In my previous installation, I used the "PDP toggle" function in John Sullivan's fso.el, and GPRS stayed up for several hours after that. In this installation I use openmoko-panel-plugin's GSM icon to enable GPRS, and it only stayed up for a few minutes. I'm sure the dbus activation calls are the same, so I would guess that this is something to do with the GSM infrastructure, and possibly a bad interaction with the #1024 recamping problem (which my phone definitely suffers from).

=== Queries/Ideas/Plans ===

auxlaunch should also support killing an existing window - for apps like TangoGPS which don't have a quit button anywhere. I wonder if anyone already has a patch for that?

Why doesn't the current app resize itself when cellwriter pops up, in the same way they all do when matchbox-keyboard pops up?

Why does [http://wiki.debian.org/DebianOnFreeRunner#ChoosingKernel http://wiki.debian.org/DebianOnFreeRunner#ChoosingKernel] say that the default kernel is 2.6.29, when I apparently have 2.6.28 (and didn't do anything special to get this):

debian-gta02:~# uname -a
Linux debian-gta02 2.6.28-20090105.git69b2aa26 #1 PREEMPT Tue Mar 3 20:22:28 UTC 2009 armv4tl GNU/Linux

Why does [http://docs.openmoko.org/trac/ticket/2277 http://docs.openmoko.org/trac/ticket/2277] say that using a 2.6.28 kernel "makes the rest of the phone broken"? (Most things seem to be working for me with a 2.6.28 kernel.)

User:Neiljerram

2009-12-16T00:21:15Z

2009-12-15T23:55:34Z

Neiljerram: /* Main points */

I use Debian on my Freerunner. Following is a description of my setup, and of how well (or not) things are working with that setup.

=== Main points ===

* Debian installed (again) on 10th December (2009, following major filesystem corruption of my previous Debian install).

* matchbox window manager and keyboard. I'm kind of missing the E17 keyboard, but not as much as I expected to. The matchbox keyboard seems more usable than you'd think, given its size.

* trayer, openmoko-panel-plugin and auxlaunch. Here's my .xsession:

#!/bin/sh
trayer --edge top --height 60 &
openmoko-panel-plugin &
zhone &
rm -f .auxlaunchpid
auxlaunch -dms &
exec matchbox-window-manager -use_titlebar no -use_cursor no

* Some screenshots to show how it looks... I think the plainness of the top panel goes well with the sharp angles of Gtk+ apps.

<gallery>
Image:2009-12-15-221523_480x640_scrot.png|zhone
Image:2009-12-15-222642_480x640_scrot.png|auxlaunch
Image:2009-12-15-222742_480x640_scrot.png|Simon Tatham's cube puzzle
Image:2009-12-15-223038_480x640_scrot.png|aptitude-gtk
</gallery>

* cellwriter is fun to have around. Once it has been started for the first time (which you can do from auxlaunch), it adds an icon to the top panel, and then you can click that to make cellwriter appear and disappear. So there is no need to decide whether to replace matchbox-keyboard with cellwriter in the openmoko-panel-plugin config; it's easy to have both. I made the following changes to the default config.

** Grid: 10 by 4 calls. Otherwise, when training, you can't get to some of the characters.

** Keyboard: 480 pixels wide. Obviously.

** Enable extended input events. Otherwise just doesn't work as an input method.

** Window docking: Bottom. Otherwise completely covers the app that you're trying to type into!

=== Queries/Ideas/Plans ===

* auxlaunch should also support killing an existing window - for apps like TangoGPS which don't have a quit button anywhere. I wonder if anyone already has a patch for that?

* Why doesn't the current app resize itself when cellwriter pops up, in the same way they all do when matchbox-keyboard pops up?

* Why does [http://wiki.debian.org/DebianOnFreeRunner#ChoosingKernel http://wiki.debian.org/DebianOnFreeRunner#ChoosingKernel] say that the default kernel is 2.6.29, when I apparently have 2.6.28:

debian-gta02:~# uname -a
Linux debian-gta02 2.6.28-20090105.git69b2aa26 #1 PREEMPT Tue Mar 3 20:22:28 UTC 2009 armv4tl GNU/Linux

User:Neiljerram

I use Debian on my Freerunner. Following is a description of my setup, and the status of how things are working with that setup.

Accelerometer data retrieval

2009-10-30T21:34:45Z

Neiljerram: Guile Scheme implementation of accelerometer reading and autorotation

==Scope==

This document describes a way to access the data provided by the
accelerometers. Furthermore the format of the acquired datastream is explained
in detail. This document does not cover the physical basics of acceleration or
the mathematical details on this subject.

==Axis orientation==

To understand the values provided by the accelerometers it is crucial to
understand how the sensors are oriented. In the following I will refer to the
sensors as first and second sensor. The way to access the data sources of
these two will be described later on in this document.

The Z axis is pointing from the display downwards to to the back of the
openmoko. This applies to both of the sensors.
(Also see [http://wiki.openmoko.org/wiki/Talk:Technical:Accelerometer_Fundamentals Definition of gmeter readings as force rather than acceleration])

===Orientation of the first sensor===

To explain the axis orientation I have created some images for easier
understanding. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the first sensor is ''/dev/input/event2''.

[[Image:Accelerometer_orientation1.png|Axis orientation of the first accelerometer]]

===Orientation of the second sensor===

In contrast to the first sensor the second one is turned 45 degrees around the
Z axis. See the attached image to get a clue about its orientation. Note that X and Y are in the same plane as the screen, while the Z arrow is pointing "into the screen", i.e. behind the Neo. The device for the second sensor is ''/dev/input/event3''.

[[Image:Accelerometer_orientation2.png|Axis orientation of the second accelerometer]]

==Data acquisition==

The information from both of the accelerometers is exported through two
different input event based file mappings. These device nodes can be found at
''/dev/input/event2'' and ''/dev/input/event3''.

The sensor I am refering to as the first one is ''event2''. Therefore the second
one is accessible through the ''event3'' device.

Hint: Adding /etc/udev/rules.d/55-freerunner-accelerometer.rules with
SUBSYSTEM=="input", ATTRS{modalias}=="input:b0018v0000p0000e0000-e0,3,kra0,1,2,mlsfw", SYMLINK+="accelerometer-top"
SUBSYSTEM=="input", ATTRS{modalias}=="input:b0018v0000p0000e0000-e0,3,kra0,1,2,mlsfw", SYMLINK+="accelerometer-bottom"
will give you bit more meaningful device names. [[User:Lindi|Lindi]] 08:16, 15 July 2009 (UTC)

These device nodes can be opened by the default filesystems calls for reading
files. The data can be read from the stream as soon as the sensor measures it. Note that since the data is exported as normal files you can easily e.g. use netcat to stream the accelerometer data over bluetooth to your laptop to a control a game running on your laptop.

==Data structure==

To be able to use the measured data it is important to understand the format
in which the data is provided.
The structure of the given data is based on the kernel input event message
system which exports the following data structure:

<pre>
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
</pre>

The data is written to the stream message by message. Therefore the minimal
used blocksize is 128 bit (16 byte).

Lets have a look at an example readout of the accelerometer data, divided into
the used sections.

<pre>
|----- time ------| |type| |code| |-value-|
8c66 4819 721c 0006 0002 0002 03a8 0000
8c66 4819 7222 0006 0000 0000 0000 0000
8c66 4819 99e6 0006 0002 0000 0048 0000
8c66 4819 9a36 0006 0002 0001 0024 0000
8c66 4819 9a50 0006 0002 0002 0396 0000
8c66 4819 9a57 0006 0000 0000 0000 0000
</pre>

Using recent kernels (>=2.6.29), you might see this instead, because accelerometers are now reporting
absolute values instead of relative ones (more on that later) :

<pre>
|----- time ------| |type| |code| |-value-|
8163 49da 6d62 000d 0000 0000 0000 0000
8163 49da 91d8 000d 0003 0000 0048 0000
8163 49da 9231 000d 0003 0001 0012 0000
8163 49da 9251 000d 0003 0002 03ba 0000
8163 49da 9270 000d 0000 0000 0000 0000
8163 49da b6cf 000d 0003 0000 0036 0000
</pre>

I think the time structure does not need further explanation. A lot more
interesting is the type, code and value part of every message. Lets take a
closer look at these parts.

===Event types===

The types categorize the incoming messages. All possible types can be found in
the kernel sources or include files in ''INCLUDEDIR/linux/input.h''
During the tests with the accelerometers I observed the fact that only two
different message types are used.

;0x00:
:According to ''linux/input.h'' this event is called ''EV_SYN''. It signals the wish to ''syncronize''. Normally this event is used in combination with code 0x00 to mark the send data complete and therefore applyable.

;0x02:
:This event is called ''EV_REL'' and signals ''relative movement''. It is used to transmit the acceleration the sensors encounter.

The definition should not be taken too seriously in this context, because the
data values provided by the accelerometer always represent the absolute
acceleration measured at the given time. So, in newer kernels, the proper
''absolute movement'' notification is used instead :

;0x03:
:This event is called ''EV_ABS'' and signals ''absolute movement''. It replaces the ''EV_REL'' notifications in newer kernels, but
the information (the event codes) is the same.

===Event codes===

Both types of event may supply different codes. These codes can be understood
as some kind of further specification about the specified data values

====Synchronization event codes====

The synchronization event may use quite a lot of codes, as ''linux/input.h''
shows. However the only used one seems to be the 0x00 code.

;0x00:
:This code is referred to as SYN_REPORT. It means that the last dataset was completely transmitted. Therefore the before transmitted set of data values can be considered complete. This means if this message is received you may process the given data further.

===Relative movement event codes===

The amount of possible codes for this event type is quite big. The only used
ones are the following ones.

;0x00:
:REL_X - Acceleration in x direction

;0x01:
:REL_Y - Acceleration in y direction

;0x02:
:REL_Z - Acceleration in z direction

The X, Y and Z axis are to be understand as defined in the chapter about [[#Axis_orientation|Axis orientation]].

====A typical message block====

A typical message block consists of 3 messages containing the acceleration
data for every of the three axis followed by a syncronization message to
signal the end of the block.

The following example is such a message block with detailed explanation of its
different messages and data sections.

<pre>
8c66 4819 99e6 0006 0002 0000 0048 0000
|------Time-------| EV_REL REL_X |-Value-|
(Measured acceleration in x axis direction of 72)

8c66 4819 9a36 0006 0002 0001 0024 0000
|------Time-------| EV_REL REL_Y |-Value-|
(Measured acceleration in y axis direction of 36)

8c66 4819 9a50 0006 0002 0002 0396 0000
|------Time-------| EV_REL REL_Z |-Value-|
(Measured acceleration in z axis direction of 918)

8c66 4819 9a57 0006 0000 0000 0000 0000
|------Time-------| EV_SYN SYN_REPORT |-Value-|
(The transmitted data block is complete you may process the given data)
</pre>

===Absolute movement event codes===

More information about this change may be available here :

http://git.openmoko.org/?p=kernel.git;a=commit;=b2ae84d8bd469fe81fa0a967fde9008416a78365

Although the information is the same as before, the absolute interface differs from the relative one by the fact that
only changed values are reported. So if the phone was completely idle, experiencing exactly the same acceleration from
one sample to the next, you will read only synchronization events (this will not happen due to noise, though).

So when you miss the value for an axis between two synchronization events, just assume the previous value still holds.

==Test application==

A simple test application written in ruby:
<pre>
#!/usr/bin/env ruby
x = 0
y = 0
z = 0
File.open("/dev/input/event3") do |f|
while true
event = f.read(16).unpack("llSSl")
time = event[0] + event[1] / 1000000.0
type = event[2]
code = event[3]
value = event[4]
if type == 2 || type == 3
x = value if code == 0
y = value if code == 1
z = value if code == 2
end
if type == 0 && code == 0
sum = Math::sqrt(x*x + y*y + z*z).to_i
printf("%5d %5d %5d %5d\n", x, y, z, sum)
end
end
end

</pre>

Equivalent version in python:

<pre>
#!/usr/bin/python
import struct
from math import sqrt

x = 0
y = 0
z = 0
secondsensorfile = "/dev/input/event3"
#int, int, short, short, int
fmt = 'iihhi'
#open file in binary mode
in_file = open(secondsensorfile,"rb")
event = in_file.read(16)
while event:
(time1,time2, type, code, value) = \
struct.unpack(fmt,event)
time = time2 / 1000.0

if type == 2 or type == 3:
if code == 0:
x = value
if code == 1:
y = value
if code == 2:
z = value
if type == 0 and code == 0:
sum = int(sqrt(x*x + y*y + z*z))
print time, x, y, z, sum
event = in_file.read(16)
in_file.close()

</pre>

Equivalent in Perl

<pre>
#!/usr/bin/perl

$x = 0;
$y = 0;
$z = 0;

$secondsensorfile = "/dev/input/event3";
#open file in binary mode
open FILE, $secondsensorfile;
binmode FILE;

while (read FILE, $buf,16) {
($t1,$t2,$type,$code,$value)=unpack "iissi",$buf;
if ($type==2) {
if ($code==0) {$x=$value};
if ($code==1) {$y=$value};
if ($code==2) {$z=$value};
}
if (($type==0) && (code==0)) {
printf "%f %05d %05d %05d\n",$t1+$t2/1000000,$x,$y,$z;
}
}

</pre>

Also, for the new absolute interface (Perl) :

<pre>
#!/usr/bin/perl

$x = 0;
$y = 0;
$z = 0;

$secondsensorfile = "/dev/input/event3";
#open file in binary mode
open FILE, $secondsensorfile;
binmode FILE;

while (read FILE, $buf,16) {
($t1,$t2,$type,$code,$value)=unpack "iissi",$buf;
if ($type==3) {
if ($code==0) {$x=$value};
if ($code==1) {$y=$value};
if ($code==2) {$z=$value};
}
if (($type==0) && ($code==0)) {
printf "%f %05d %05d %05d\n",$t1+$t2/1000000,$x,$y,$z;
}
}
</pre>

Read the data in C (FIXME: We're not printing times here).

<pre>
#include <stdio.h>
#include <time.h>
#include <sys/times.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <assert.h>

struct input_event {
struct timeval time;
uint16_t type;
uint16_t code;
int32_t value;
};

int read_all(int fd, char *buf, int count)
{
int n_read = 0;
while (n_read != count) {
int result = read(fd, buf + n_read, count - n_read);
if (result < 0)
return result;
else if (result == 0)
return n_read;
n_read += result;
}
return n_read;
}

int main(int argc, char *argv[])
{
int fd;
struct input_event ev;

assert(16 == sizeof(struct input_event));

if (argc != 2) {
fprintf(stderr, "missing /dev/input/XXX\n");
return 1;
}

while (1) {
if ((fd = open(argv[1], O_RDONLY)) == -1) {
perror("open");
return 1;
}
int ret = read_all(fd, (char *) &ev, sizeof(struct input_event));
if (ret != sizeof(struct input_event)) {
fprintf(stderr, "ret == %d\n", ret);
perror("read");
return 1;
}
close(fd);
printf("type:%u code:%u value:%d\n", ev.type, ev.code, ev.value);
usleep(500000); /* 2 reads per second, you might want to read more */
}

return 0;
}
</pre>

And in Guile Scheme. (This one is a complete autorotation program.)

<pre>
;; Open device file for the second accelerometer (whose axes are
;; aligned with the screen). Must make Guile's internal buffer small
;; (16), otherwise it reads too far ahead and this program gets mostly
;; out of date data.
(define e (open-file "/dev/input/event3"
"r0"))
(setvbuf e _IOFBF 16)

;; Uniform vector for reading data from device file. Must match
;; sizeof(struct input_event), otherwise the read can get an 'invalid
;; argument' error.
(define v (make-u16vector 8))

(define (current-acceleration)
(let loop ((x #f) (y #f) (z #f))
(uniform-vector-read! v e)
(let ((code (u16vector-ref v 4))
(axis (u16vector-ref v 5))
(meas (+ (u16vector-ref v 6)
(* 65536 (u16vector-ref v 7)))))
(if (>= meas (expt 2 31))
(set! meas (- meas (expt 2 32))))
(case code
((2 3)
(case axis
((0) (loop meas y z))
((1) (loop x meas z))
((2) (loop x y meas))
(else (loop x y z))))
(else
(if (and x y z)
(list x y z)
(loop x y z)))))))

(define (orientation x y z)
(cond ((and (< y -200)
(> (- y) x y))
0)
((and (> x 200)
(< (- x) y x))
1)
((and (> y 200)
(< (- y) x y))
2)
((and (< x -200)
(> (- x) y x))
3)
(else #f)))

(define (main)
(let loop ((ori #f))
(let ((new-ori
(apply orientation
(current-acceleration))))
(and ori
new-ori
(not (= ori new-ori))
(system* "xrandr"
"-o"
(number->string new-ori)))
(sleep 1)
(loop (or new-ori ori)))))

(main)
</pre>

== The /sys interface ==

To get the sampling rate of the first accelerometer ''lis302dl.1'' :

# cat /sys/devices/platform/lis302dl.1/sample_rate
100

To set the sampling rate :

# echo 400 > /sys/devices/platform/lis302dl.1/sample_rate
# cat /sys/devices/platform/lis302dl.1/sample_rate
400

OM2008.12 has too big threshold for some games and applications (value=18).
You can use sysfs to change it. Use command like this one:

# echo 10 > /sys/devices/platform/lis302dl.1/threshold

The other one is ''lis302dl.2''. See [[GTA02 sysfs#Accelerometers]] for the other options.

==See also==
* [[Accelerometer_Fundamentals]]
* [[Gestures]], [http://code.google.com/p/accelges/source/browse/trunk/accelneo/src/accelneo.c code sample]

==External Links==
* [http://projects.openmoko.org/projects/gestures/ Openmoko Motion Gestures]
* [http://en.wikipedia.org/wiki/Accelerometer Wikipedia - Accelerometer]
* [http://dev.borza.ro/demo/Motion-based%20Gesture%20Recognition%20with%20an%20Accelerometer/Paper.pdf Motion-based Gesture Recognition with an Accelerometer - Paper]
* [http://www.youtube.com/watch?v=s5QMW8k5nis YouTube video: Playing with Accelerometers]
* [http://westhoffswelt.de/blog/my_first_openmoko_application.html Magic Eightball Application using the Accelerometers]

[[Category:Accelerometer]]

Community Updates/2008-09-17

2008-09-15T20:57:27Z

Neiljerram: Mention Qtopia 4.3.3

Everybody loves Community Updates, but that's a huge endeavour for one person to tackle. So let us try a little social experiment here: ''community written community update''. I posted an outlined list of bullet points, and left it to everybody else to elaborate along the following editorial guidelines:
* Include everything that was hot on a mailing lists at some point since launch.
* Limit each point to three sentences and one link.
[[User:MinhHaDuong|MinhHaDuong]] 14:20, 15 September 2008 (UTC)

== Software and distributions ==
* Dale's DFU script started
* FDOM started
* Gentoo started
* Several classic games ported: Duke Nukem 3D, Battle for Wesnoth, DOOM (Coming Soon)
* Debian fso-pkg team is getting full steam ahead
* Qtopia 4.3.2 and 4.3.3 (including echo fix) released
* Google SoC projects released: gestures (includes autorotates the screen !), ReMoKo

== Cool mod ==

* [[Openmokast]]

== News from the git ==
* The html access to downloads.openmoko.org that provided 2007.2 has been discontinued.
* 2008.8 + daily updates is getting better and better, working its way towards a bug fix release (milestone tagged 2008.9 in the trac)
* Om shuffling git branches around is about done, .asu.dev is dead wood now.
* New "head" development branch is only basesystem+installer (no phone stack preloaded, even less applications)
* FSO Milestone 3 released
* Planned architecture for next release is Tichy + Paroli + framework .

== Documentation team ==
* Redesigned wiki Main page in time for the Digg day
* Deleting lots of old/unused wiki pages
* Introduced wiki navigation boxes, working on categories
* Learning to use Widimedia. Postponed CSS revision, wondering how to deal with multilinguism better
* More blog added to the planet

== Notable fixes ==
* GPS TTFF bug was fixed soon after launch (what happens to the first batch units then, is there a way / necessity to do the hardware fix ?)
* Keyboard choices in 2008.2 explained
* Workaround found for suspend corrupts SD card partition table (??? Slow the GLAmo clock ???)
* Echo cancelation turned on in TI chip (is that undocumented function in ?)

== Hot bugs ==
* Touch Screen Coordinates not re-calculating correctly on screen Rotation (Every mode except randr -o 0) Patch is available, no package update.
* Using Bluetooth headset is still impossible/hard to do
* Sound is still awfully complicated (alsa.state remains black magic)
* Power management: progress but still far from goal of autonomy in days (full discharge vs. forced load issue, LEDs and buttons use model still in flux, charging while off, fine-grained subsystems sleep...)
* Repeated messages on the mailing lists
* The trac is getting crowded, bug reports numbers are exploding

== Classifieds ==
* community-repository is slow to take off: orrery, diversity-wifi, mofi, moko-sudoku, comic-reader, only omview has been added in September.
* A classified section has been started to sell/buy on the wiki
* There was a job offer for an X dev
* The Paris meeting was a big success with ~80 attendees.
* FreeRunners still seem to sell like hotcakes, they are frequently out of stock.

Om 2008 keyboard

2008-09-15T20:48:14Z

Neiljerram: Improve description of keyboard's basic operation

{{Om 2008.8}}
== Keyboard guide ==

[[Image:asu_keyboard_lower.png|250px|right|ASU Keyboard]]
[[Image:asu_keyboard_word.png|250px|right|ASU Keyboard with hello]]
[[Image:asu_keyboard_numeric.png|250px|right|ASU Keyboard with numeric keys]]

* Fuzzy typing: you only have to touch near each letter that you want, not exactly on it.
* Sliding your finger left is backspace.
* Sliding your finger right is space.
* Sliding your finger up/down changes between lowercase/uppercase/numbers/special characters.
* Hovering over a letter for more than 2 seconds activates zoom mode, allowing you to type specific letters without prediction.

=== Writing something ===

If the keyboard pops up, just write someting. Each time you touch the screen, with your finger or with the stylus, the keyboard remembers all of the letters that are near where you touched. Then, after each touch, it matches all of the possible letter combinations against words in the dictionary, and shows the matching words above the keyboard, with the most common match in the middle. If you click on this word (or slide the finger over the keyboard to the right), it will be transfered to the cursor position in the input field that is currently selected. If you want one of the matches other than the most common one, use your finger (or stylus) to scroll the matches bar to the left or right, then click when the match that you want is in the middle.

If there are no words in the dictionary that match the touches so far, the keyboard shows a word (regardless of whether it actually makes sense) that is just the sequence of letters closest to each touch.

Note that although this keyboard is often referred to as "predictive", it is not predictive in the sense of guessing further letters, to complete a word, beyond the ones that you have already typed.

===Deleting text ===
To delete the word you have typed before you transferred it to the input box, you can erase it by simply sliding your finger left on the keyboard (this writes a backspace, see below)

=== Changing keyboard layout ===

The keyboard only displays a subset of the available keys at any one time. To change the keyboard layout to access additional keys slide your finger up or down directly on the keyboard. You have to do this fast that the zoom will not be activated.

The default layout when the keyboard is displayed is the lowercase alphabet but this may be overwritten by the application bringing up the keyboard.

=== Where is the Backspase or Space character? ===
You can input a space or backspace by simply sliding with your finger left or right. Sliding left on the keyboard gives you an backspace, sliding right writes a space.
Note that to delete a character inside the input box, the word guessing box needs to be empty. If it is not empty, the backspace will first delete the box and you need to slide your finger left again. If something is inside the guessing box, a right-slide will transfer the typed stuff to the input box currently selected (this is the same as clicking onto the typed word).

=== Keyboard Zoom ===

[[Image:asu_keyboard_zoom.png|200px|center|ASU Keyboard with zoom]]

If you hover your finger (or stylus) over a letter for more than 2 seconds a magnifiying glass, or zoom mode is displayed that allows you to see the letter you are selecting. This also overrides the prediction feature for this letter, so you can type specific letters with this method.

= Customizations =

As it behaves in the shipped 2008.8 state, this keyboard doesn't suit all users.

== Debate ==

Some people don't like this keyboard, because it lacks a full Qwerty keyboard. Another issue people have, is they can't switch the keyboard prediction off.

For a description of alternative solutions and potential workarounds, see [[Keyboard Debate]].

{{main|Keyboard_Debate}}

Also, bellow are some (more ?) customizations/tweaks/hacks proposed by some users :

== Reactivating The Keyboard Toggle ==
Most applications should bring up the keyboard automatically when keyboard input is required. However, one can have a small 'qwerty' button which can manually toggle the keyboard on and off. See the [[Keyboard_Toggle|keyboard toggle tutorial]] for more information.

== Using the Full Qwerty keyboard ==

See [http://wiki.openmoko.org/wiki/Keyboard_Debate#How_to_install_the_illume_.28Raster.27s.29_keyboard_.3F here]

[[Category:Om 2008.8]]
[[Category:Basic End User]]