Openmoko - User contributions [en]

GTA04 Group Tour Donations Hub

2012-03-09T09:32:17Z

Hns: reformatted

= Background =
There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price from currently 666 EUR to 479/499 EUR.
Unfortunately this is still too high for some members of the community, while others are willing to donate some money to make the group tour a success, but don't need two or more units.

= Idea =
To bring both parties together, please add yourself to this list if you are seeking a subsidy from a helpful donator. Ir if you search someone to do substantial work and want to subsidize it.

= How to use this list =
Since you should also give something to the community, please formulate a project what you would like to work out.
Donators should scan this list and directly contact the project owner. If you agree, arrange for a single order in the online shop.

= Project Proposals: I am seeking for a donation =
-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Date added: 6 mar 2012
* Your contact data: <email address in a robot-unfriendly format>
-----

* Project: test the GTA04, and report bugs/behaviour as wished for by software or hardware developers. I run linux since 2002 and have the freerunner since 2008 as my daily phone, so I think the best I can offer is user experience and debugging and putting this info on a wiki or where else whished for.
* How much you could afford yourself: 250 EUR (unfortunately two kids and eat up quite a bit of money and a science career in Germany hasn't proven to be as a constant source for money.)
* Date added: 9 mar 2012
* Your contact data: spielraum @ web . de
-----

= Wish list: I search someone to solve an issue and would donate =
== general ideas ==
* camera driver ported to Linux 3.2 and made working
* improved suspend
* FM transceiver
* BlueTooth pairing w/ automobile or headset for hands-free communication. Needs: Audio, contact list, direct DTMF dialing (via keys in vehicle)
* <please add>

== template - please append projects ==

* Project: <please describe what you would like to get done>
* How much you would donate: <e.g. 500 EUR>
* Date added: 8 mar 2012
* Your contact data: <me @ example . anywhere>
----

* I would like to see any improvement in the kernel and user land for GTA04
* I have 2 GTA04 boards paid for as a donation
* Date added: 8 mar 2012
* Contact me for details: cvwillegen@gmail.com
----

* I would donate 500 EUR or another GTA04 to someone who's doing kernel/driver/phone stack development
* Date added: 8 mar 2012
* Contact: gta04@edv-buero-lehner.de
----

[[Category:Community]]

GTA04 Group Tour Donations Hub

2012-03-09T09:31:03Z

Hns: Reduced proposal to required information

= Background =
There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price from currently 666 EUR to 479/499 EUR.
Unfortunately this is still too high for some members of the community, while others are willing to donate some money to make the group tour a success, but don't need two or more units.

= Idea =
To bring both parties together, please add yourself to this list if you are seeking a subsidy from a helpful donator. Ir if you search someone to do substantial work and want to subsidize it.

= How to use this list =
Since you should also give something to the community, please formulate a project what you would like to work out.
Donators should scan this list and directly contact the project owner. If you agree, arrange for a single order in the online shop.

= Project Proposals: I am seeking for a donation =
-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Date added: 6 mar 2012
* Your contact data: <email address in a robot-unfriendly format>
-----

* Project: test the GTA04, and report bugs/behaviour as wished for by software or hardware developers. I run linux since 2002 and have the freerunner since 2008 as my daily phone, so I think the best I can offer is user experience and debugging and putting this info on a wiki or where else whished for.
* How much you could afford yourself: 250 EUR (unfortunately two kids and eat up quite a bit of money and a science career in Germany hasn't proven to be as a constant source for money.)
* Date added: 9 mar 2012
* Your contact data: spielraum @ web . de
-----

= Wish list: I search someone to solve an issue and would donate =
== general ideas ==
* camera driver ported to Linux 3.2 and made working
* improved suspend
* FM transceiver
* BlueTooth pairing w/ automobile or headset for hands-free communication. Needs: Audio, contact list, direct DTMF dialing (via keys in vehicle)
* <please add>

== template - please append projects ==

* Project: I want to see Kernel/API improvement
* How much you would donate: 500 EUR
* Date added: 8 mar 2012
* Your contact data: me@example.anywhere
----

* I would like to see any improvement in the kernel and user land for GTA04
* I have 2 GTA04 boards paid for as a donation
* Date added: 8 mar 2012
* Contact me for details: cvwillegen@gmail.com
----

* I would donate 500 EUR or another GTA04 to someone who's doing kernel/driver/phone stack development
* Date added: 8 mar 2012
* Contact: gta04@edv-buero-lehner.de
----

[[Category:Community]]

GTA04 Group Tour Donations Hub

2012-03-08T18:22:32Z

Hns: /* Wish list: I search someone to solve an issue and would donate */

= Background =
There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price from currently 666 EUR to 479/499 EUR.
Unfortunately this is still too high for some members of the community, while others are willing to donate some money to make the group tour a success, but don't need two or more units.

= Idea =
To bring both parties together, please add yourself to this list if you are seeking a subsidy from a helpful donator. Ir if you search someone to do substantial work and want to subsidize it.

= How to use this list =
Since you should also give something to the community, please formulate a project what you would like to work out.
Donators should scan this list and directly contact the project owner. If you agree, arrange for a single order in the online shop.

= Project Proposals: I am seeking for a donation =
-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Date added: 6 mar 2012
* Your contact data: <email address>
-----

* Project: I want to improve the example driver of the 3.2 kernel and bring it upstream
* How much you could afford yourself: 200 EUR
* Date added: 6 mar 2012
* Your contact data: me@example.anywhere
-----

= Wish list: I search someone to solve an issue and would donate =
== general ideas ==
* camera driver ported to Linux 3.2 and made working
* improved suspend
* FM transceiver
* BlueTooth pairing w/ automobile or headset for hands-free communication. Needs: Audio, contact list, direct DTMF dialing (via keys in vehicle)
* <please add>

== template - please append projects ==

* Project: I want to see Kernel/API improvement
* How much you would donate: 500 EUR
* Date added: 8 mar 2012
* Your contact data: me@example.anywhere
----

* I would like to see any improvement in the kernel and user land for GTA04
* I have 2 GTA04 boards paid for as a donation
* Date added: 8 mar 2012
* Contact me for details: cvwillegen@gmail.com
----

[[Category:Community]]

GTA04 Group Tour Donations Hub

2012-03-08T16:51:18Z

Hns: /* Wish list: I search someone to solve an issue and would donate */

GTA04 Group Tour Donations Hub

2012-03-08T16:51:06Z

Hns:

GTA04 Group Tour Donations Hub

2012-03-06T10:08:13Z

Hns: /* Wish list - what potential donators would like to see */

GTA04 Group Tour Donations Hub

2012-03-06T10:05:51Z

Hns:

GTA04 Group Tour Donations Hub

2012-03-06T07:33:51Z

Hns:

GTA04 Group Tour Donations Hub

2012-03-06T07:26:37Z

Hns:

GTA04 Group Tour Donations Hub

2012-03-06T05:54:53Z

Hns:

GTA04 Group Tour Donations Hub

2012-03-05T21:59:33Z

Hns:

There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price from currently 666 EUR to 479/499 EUR.
Unfortunately this is still too high for some members of the community, while others are willing to donate some money to make the group tour a success, but don't need two or more units.
To bring both parties together, please add yourself to this list if you are seeking a subsidy from a helpful donator.
Since you should also give something to the community, please formulate a project what you would like to work out.
Donators should scan this list and directly contact the project owner. If you agree, arrange for a single order in the online shop.

-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Your contact data: <email address>
-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Your contact data: <email address>
-----

GTA04 Group Tour Donations Hub

2012-03-05T21:58:29Z

Hns: New page: There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price. Unfortunately it is still too high for some members ...

There is a GTA04 Group Tour (http://www.handheld-linux.com/wiki.php?page=GTA04%20Group%20Tour) to get enough units to reduce the price. Unfortunately it is still too high for some members of the community while others are willing to donate some money to make the group tour a success. To bring both parties together, please add yourself to this list if you are seeking a subsidy from a helpful donator. Since you should also give something to the community, please formulate a project what you would like to work out.
Donators should scan this list and directly contact the project owner. If you agree, arrange for a single order in the online shop.

-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Your contact data: <email address>
-----

* Project: <please describe briefly what you want to contribute to the community if you had a GTA04>
* How much you could afford yourself: <e.g. 200 EUR>
* Your contact data: <email address>
-----

Community Updates/2011-09-01

2011-06-09T15:09:54Z

Hns: /* Hardware */

Freerunner RFID Board

2011-05-19T09:35:05Z

Hns: fixed link to U-Boot source file

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This page is work in progress and quite incomplete. If you want to improve, please volunteer.

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

The tag is compatible to readers that support:
* ISO 15693
* ISO 18000-3 mode 1

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

The Reader chip supports these standards:
* ISO 14443A (Mifare)
* ISO 14443B
* ISO 15693
* ISO 18000-3

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]

=== RFID Tag ===

The locations where to connect the I2C wires in a Freerunner are shown on the photo on the right side

* '''ANT1''', '''ANT2''' (TP27, TP28): solder two wires to connect the antenna
* '''VCC''' (TP8): +1.8V - +3.3V, available at the AUX-Switch
* '''SCL''', '''SDA''' (TP18, TP9): Serial clock and data, get it from testpoints at the debug connector
* '''GND''' (TP19): Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''EN0''', '''EN1''' (TP24, TP23): select address; usually connect to GND (I2C address 0x50)

=== RFID Reader ===

==== mandatory ====
* '''ANT''', '''VSS''' (TP26, TP25): solder two wires to connect the antenna
* '''VIN''' (TP22): +2.7 - +5.5V, main power available at the AUX-Switch
* '''VIO''' (TP21): +1.8 V - VIN, IO power available at the AUX-Switch
* '''SCLK''' (TP14): SPI clock input (mandatory)
* '''SOMI''' (TP16): SPI data from reader to CPU (mandatory)
* '''SIMO''' (TP17): SPI data from CPU to reader (mandatory)
* '''IRQ''' (TP7): positive interrupt impulse (should be connected to a GPIO)
====optional====
* '''SS''' (TP14): SPI chip select (only used in SPI with SS mode)
* '''EN''' (TP15): chip enable (optional to power down chip)
* '''EN2''' (TP4): second chip enable (optional to power down chip)
====extended====
* '''CLK''' (TP3): optional 60kHz / 13 MHz clock output to drive an external MCU
* '''MOD''' (TP1): external TX modulation input
* '''ASK''' (TP2): external RX demodulator output

====interface mode selection====
NOTE: R4, R5, R7, R8 choose the interface mode:
* R4, R5, R8 soldered: SPI without SS mode (default)
* R4, R7, R8 soldered: SPI with SS mode - also connect TP14, TP16, TP17
* none soldered: parallel mode - also connect TP10, TP11, TP12, TP13, TP14, TP15, TP16, TP17

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/gta04-uboot/source/tree/gta04e/board/goldelico/beagle-expander/trf7960.c

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the [[Talk:Freerunner_RFID_Board|discussion page]].

[[Category:Neo FreeRunner reworks and mods]]

Community Updates/2011-05-01

2011-04-27T08:32:39Z

Hns: /* Hardware */

{{Improve}}
{{Note|
*Take a moment and look at [[Talk:Community_Updates/Draft|this page]] to get a clue on how to contribute to Community Updates while following OM wiki editing guidelines please.
*I you are planning longer edition, please use <nowiki>{{Editing|your_username_here|date_here|editing_summary_here}}tag. Remember to remove/comment out it right after you save your work.</nowiki>
*Please fill in everything you think the community should know.
*On 2011-05-01 this content should be _moved_ to http://wiki.openmoko.org/wiki/Community_Updates/YYYY-MM-DD, feel free to do it.
*Post the CU release also on the community mailing list, since some people prefer to read news directly there. Regarding this, it helps copy-pasting from browser page to mailing list post if relevant URLs are included as is in addition to having linked parts of text (if in hurry you can also just post a note that CU is readable on web page).
}}



====='''Period 2011-03-01 to 2011-04-30'''=====

== Hardware ==

* [[Freerunner RFID Board]] - new hardware mod announced
* [[Freerunner Navigation Board v3]] - new version ready
* [[GTA04]] - engineering hardware (A2 revision) boots to Linux/Debian/LXDE - YouTube Video: [http://www.youtube.com/watch?v=3KnJc7eImQ4&feature=channel_video_title]

== Distributions ==

Distributions lists releases and other significant updates in distributions that have some support for the Openmoko devices.

{{DistributionBox|
Name=Android Cupcake [Stable, January 2011]|
Description=The AoF community has uploaded an update of the stable Cupcake release of AoF. This release contains:
* All fixes from Android Cupcake (Google via scarhill)
* Separate NAND or SD based installations (ran)
* Improved GPS timestamps (Michael)
* Updated APN list from Cyanogenmod (scarhill)
* WMIConfig for boosting WiFi power (Niels)
* Improved backup script (Teodor, ran)
|
Screenshot=Android-on-Freerunner-Splash.png|
Codename='Android Cupcake on Freerunner'|
Homepage=http://code.google.com/p/android-on-freerunner/|
Image=[http://code.google.com/p/android-on-freerunner/wiki/GetIt How to install]|
Works={{works on Android}}
}}

{{DistributionBox|
Name=Android Froyo [Experimental, April 2011]|
Description=The AoF community has uploaded an update of the experimental Froyo release of AoF. This release contains:
* All fixes from Android Froyo (Google via scarhill)
* Separate NAND or SD based installations (ran)
* Improved GPS timestamps (Michael)
* Updated APN list from Cyanogenmod (scarhill)
* WMIConfig for boosting WiFi power (Niels)
* Improved backup script (Teodor, ran)
* GPRS fix (scarhill)
* Bluetooth, sound an performance improvements (ran)
* Freeze fixes (ran)
* Improved battery status indication (ran)
* CMUX fix (panicking)|
Screenshot=Android-on-Freerunner-Splash.png|
Codename='Android Froyo on Freerunner'|
Homepage=http://code.google.com/p/android-on-freerunner/|
Image=[http://code.google.com/p/android-on-freerunner/wiki/GetIt How to install]|
Works={{works on Android}}
}}

{{DistributionBox|
Name=QtMoko [Stable, March and April 2011]|
Description=New experimental (v34) and then stable (v35) QtMoko release:
* QX installs Xglamo as debian package
* WLAN with wpa-psk can now connect more then once (Alfa21)
* QNetWalk package has been fixed
* accelerometers in QtMaze now work
* NeronGPS moved back to old nice version
* disabled disk cache in Arora
* qtmoko bookmarks in Arora
* usb mass storage has now param removable=y for happy winxp (Alfa21)
* faenqo theme - added golden debian background (Tiago Bortoletto Vaz)
* themes now use jpg for backgrounds to save space (Tiago Bortoletto Vaz)
* docked keyboard - fix ctl and alt keys always pressed (Gennady Kupava)
* disabled login on tty1..tty6 to save memory
* qterminal - dont display unused back icon (Gennady Kupava)
* fix back icon in help browser (Gennady Kupava)
* new beautiful theme faenqomod (Joif)
* correct package dependencies in eyepiece
* qtmoko internal package manager has been disabled
* building kernel as debian package
* Fix missing icon for qtmoko apps web
* Build with translations
* Fix Xglamo install in QX
* Dont build qx_helper, it's not needed anymore
* Fixed package description for gta02-gsm-bt-fix|

Screenshot=Qtmokomain.png|
Codename='QtMoko v35'|
Homepage=http://qtmoko.org|
Image=[http://sourceforge.net/projects/qtmoko/files/]|
Works={{Works_on_QtMoko}}
}}

{{DistributionBox|
Name=Distro Name [version]|
Description=Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.|
Screenshot=System_boot.png|
Codename='codename'|
Homepage=http://www.homepage.org|
Image=[http://www.homepage.org/path/to/ images]|
Works={{Works}}
}}

==Applications==

===New Applications===

{{ApplicationBox|
Name=QtMoko-Chess|
Description=GNUChess frontend for QtMoko|
Screenshot=qtmoko-chess.png|
Homepage=http://qtmoko.sourceforge.net/apps/qtmoko-chess.html|
TestedOn=QtMoko v35|
PackageName=[http://qtmoko.sourceforge.net/apps/qtmoko-chess_35-1_armel.deb QtMoko-Chess]
}}

===Application Updates===

{{ApplicationBox|
Name=Exampleapp 0.0.1|
Description=Exampleapp 0.0.1 is an application to do some stuff...
* new example feature 1
* new example feature 2|
Screenshot=System_boot.png|
Homepage=http://wiki.openmoko.org/|
TestedOn=SHR-Unstable,Om2009T5|
PackageName=[http:// www.some.srv/path_to/Exampleapp.ipk Exampleapp]
}}

==General News==

Most important and change making mails on the mailing lists, blogs etc.. Coolest hacks, screenshots, themes etc..

==Event News==

* '''2011-05-11-14''' [http://www.linuxtag.org/2011/en/exhibitors/exhibitors-partners.html Linux Tag] | Openmoko GTA04 on LinuxTag, Hall 7.2a, Booth 115, Berlin, Germany

[[Category:Community Update]]

Community Updates/2011-05-01

2011-04-18T07:59:44Z

Hns: /* Event News */

{{Improve}}
{{Note|
*Take a moment and look at [[Talk:Community_Updates/Draft|this page]] to get a clue on how to contribute to Community Updates while following OM wiki editing guidelines please.
*I you are planning longer edition, please use <nowiki>{{Editing|your_username_here|date_here|editing_summary_here}}tag. Remember to remove/comment out it right after you save your work.</nowiki>
*Please fill in everything you think the community should know.
*On 2011-05-01 this content should be _moved_ to http://wiki.openmoko.org/wiki/Community_Updates/YYYY-MM-DD, feel free to do it.
*Post the CU release also on the community mailing list, since some people prefer to read news directly there. Regarding this, it helps copy-pasting from browser page to mailing list post if relevant URLs are included as is in addition to having linked parts of text (if in hurry you can also just post a note that CU is readable on web page).
}}



====='''Period 2011-03-01 to 2011-04-30'''=====

== Hardware ==

* [[Freerunner RFID Board]] - new hardware mod announced
* [[Freerunner Navigation Board v3]] - new version ready

== Distributions ==

Distributions lists releases and other significant updates in distributions that have some support for the Openmoko devices.

{{DistributionBox|
Name=Android Cupcake [Stable, January 2011]|
Description=The AoF community has uploaded an update of the stable Cupcake release of AoF. This release contains:
* All fixes from Android Cupcake (Google via scarhill)
* Separate NAND or SD based installations (ran)
* Improved GPS timestamps (michael)
* Updated APN list from Cyanogenmod (scarhill)
* WMIConfig for boosting WiFi power (niels)
|
Screenshot=Android-on-Freerunner-Splash.png|
Codename='Android Cupcake on Freerunner'|
Homepage=http://code.google.com/p/android-on-freerunner/|
Image=[http://code.google.com/p/android-on-freerunner/wiki/GetIt How to install]|
Works={{works on Android}}
}}

{{DistributionBox|
Name=Android Froyo [Experimental, April 2011]|
Description=The AoF community has uploaded an update of the experimental Froyo release of AoF. This release contains:
* All fixes from Android Froyo (Google via scarhill)
* Separate NAND or SD based installations (ran)
* Improved GPS timestamps (michael)
* Updated APN list from Cyanogenmod (scarhill)
* WMIConfig for boosting WiFi power (niels)
* GPRS fix (scarhill)
* Bluetooth, sound an performance improvements (ran)
* Freeze fixes (ran)
* Improved battery status indication (ran)
* CMUX fix (panicking)|
Screenshot=Android-on-Freerunner-Splash.png|
Codename='Android Froyo on Freerunner'|
Homepage=http://code.google.com/p/android-on-freerunner/|
Image=[http://code.google.com/p/android-on-freerunner/wiki/GetIt How to install]|
Works={{works on Android}}
}}

{{DistributionBox|
Name=QtMoko [Stable, March and April 2011]|
Description=New experimental (v34) and then stable (v35) QtMoko release:
* QX installs Xglamo as debian package
* WLAN with wpa-psk can now connect more then once (Alfa21)
* QNetWalk package has been fixed
* accelerometers in QtMaze now work
* NeronGPS moved back to old nice version
* disabled disk cache in Arora
* qtmoko bookmarks in Arora
* usb mass storage has now param removable=y for happy winxp (Alfa21)
* faenqo theme - added golden debian background (Tiago Bortoletto Vaz)
* themes now use jpg for backgrounds to save space (Tiago Bortoletto Vaz)
* docked keyboard - fix ctl and alt keys always pressed (Gennady Kupava)
* disabled login on tty1..tty6 to save memory
* qterminal - dont display unused back icon (Gennady Kupava)
* fix back icon in help browser (Gennady Kupava)
* new beautiful theme faenqomod (Joif)
* correct package dependencies in eyepiece
* qtmoko internal package manager has been disabled
* building kernel as debian package
* Fix missing icon for qtmoko apps web
* Build with translations
* Fix Xglamo install in QX
* Dont build qx_helper, it's not needed anymore
* Fixed package description for gta02-gsm-bt-fix|

Screenshot=Qtmokomain.png|
Codename='QtMoko v35'|
Homepage=http://qtmoko.org|
Image=[http://sourceforge.net/projects/qtmoko/files/]|
Works={{Works_on_QtMoko}}
}}

{{DistributionBox|
Name=Distro Name [version]|
Description=Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.|
Screenshot=System_boot.png|
Codename='codename'|
Homepage=http://www.homepage.org|
Image=[http://www.homepage.org/path/to/ images]|
Works={{Works}}
}}

==Applications==

===New Applications===

{{ApplicationBox|
Name=Exampleapp 0.0.1|
Description=Exampleapp 0.0.1 is an application to do some stuff..|
Screenshot=System_boot.png|
Homepage=http://wiki.openmoko.org/|
TestedOn=SHR-Unstable,Om2009T5|
PackageName=[http:// www.some.srv/path_to/Exampleapp.ipk Exampleapp]
}}

===Application Updates===

{{ApplicationBox|
Name=Exampleapp 0.0.1|
Description=Exampleapp 0.0.1 is an application to do some stuff...
* new example feature 1
* new example feature 2|
Screenshot=System_boot.png|
Homepage=http://wiki.openmoko.org/|
TestedOn=SHR-Unstable,Om2009T5|
PackageName=[http:// www.some.srv/path_to/Exampleapp.ipk Exampleapp]
}}

==General News==

Most important and change making mails on the mailing lists, blogs etc.. Coolest hacks, screenshots, themes etc..

==Event News==

* '''2011-05-11-14''' [http://www.linuxtag.org/2011/en/exhibitors/exhibitors-partners.html Linux Tag] | Openmoko GTA04 on LinuxTag, Hall 7.2a, Booth 115, Berlin, Germany

[[Category:Community Update]]

Community Updates/2011-05-01

2011-04-12T10:21:17Z

Hns: New page: {{Improve}} {{Note| *Take a moment and look at this page to get a clue on how to contribute to Community Updates while following OM wiki editing guidelines...

Freerunner RFID Board

2011-04-11T14:09:26Z

Hns: /* Features */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

The tag is compatible to readers that support:
* ISO 15693
* ISO 18000-3 mode 1

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

The Reader chip supports these standards:
* ISO 14443A (Mifare)
* ISO 14443B
* ISO 15693
* ISO 18000-3

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]

=== RFID Tag ===

The locations where to connect the I2C wires in a Freerunner are shown on the photo on the right side

* '''ANT1''', '''ANT2''' (TP27, TP28): solder two wires to connect the antenna
* '''VCC''' (TP8): +1.8V - +3.3V, available at the AUX-Switch
* '''SCL''', '''SDA''' (TP18, TP9): Serial clock and data, get it from testpoints at the debug connector
* '''GND''' (TP19): Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''EN0''', '''EN1''' (TP24, TP23): select address; usually connect to GND (I2C address 0x50)

=== RFID Reader ===

==== mandatory ====
* '''ANT''', '''VSS''' (TP26, TP25): solder two wires to connect the antenna
* '''VIN''' (TP22): +2.7 - +5.5V, main power available at the AUX-Switch
* '''VIO''' (TP21): +1.8 V - VIN, IO power available at the AUX-Switch
* '''SCLK''' (TP14): SPI clock input (mandatory)
* '''SOMI''' (TP16): SPI data from reader to CPU (mandatory)
* '''SIMO''' (TP17): SPI data from CPU to reader (mandatory)
* '''IRQ''' (TP7): positive interrupt impulse (should be connected to a GPIO)
====optional====
* '''SS''' (TP14): SPI chip select (only used in SPI with SS mode)
* '''EN''' (TP15): chip enable (optional to power down chip)
* '''EN2''' (TP4): second chip enable (optional to power down chip)
====extended====
* '''CLK''' (TP3): optional 60kHz / 13 MHz clock output to drive an external MCU
* '''MOD''' (TP1): external TX modulation input
* '''ASK''' (TP2): external RX demodulator output

====interface mode selection====
NOTE: R4, R5, R7, R8 choose the interface mode:
* R4, R5, R8 soldered: SPI without SS mode (default)
* R4, R7, R8 soldered: SPI with SS mode - also connect TP14, TP16, TP17
* none soldered: parallel mode - also connect TP10, TP11, TP12, TP13, TP14, TP15, TP16, TP17

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the [[Talk:Freerunner_RFID_Board|discussion page]].

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-10T08:50:51Z

Hns: /* User Reports */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]

=== RFID Tag ===

The locations where to connect the I2C wires in a Freerunner are shown on the photo on the right side

* '''ANT1''', '''ANT2''' (TP27, TP28): solder two wires to connect the antenna
* '''VCC''' (TP8): +1.8V - +3.3V, available at the AUX-Switch
* '''SCL''', '''SDA''' (TP18, TP9): Serial clock and data, get it from testpoints at the debug connector
* '''GND''' (TP19): Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''EN0''', '''EN1''' (TP24, TP23): select address; usually connect to GND (I2C address 0x50)

=== RFID Reader ===

==== mandatory ====
* '''ANT''', '''VSS''' (TP26, TP25): solder two wires to connect the antenna
* '''VIN''' (TP22): +2.7 - +5.5V, main power available at the AUX-Switch
* '''VIO''' (TP21): +1.8 V - VIN, IO power available at the AUX-Switch
* '''SCLK''' (TP14): SPI clock input (mandatory)
* '''SOMI''' (TP16): SPI data from reader to CPU (mandatory)
* '''SIMO''' (TP17): SPI data from CPU to reader (mandatory)
* '''IRQ''' (TP7): positive interrupt impulse (should be connected to a GPIO)
====optional====
* '''SS''' (TP14): SPI chip select (only used in SPI with SS mode)
* '''EN''' (TP15): chip enable (optional to power down chip)
* '''EN2''' (TP4): second chip enable (optional to power down chip)
====extended====
* '''CLK''' (TP3): optional 60kHz / 13 MHz clock output to drive an external MCU
* '''MOD''' (TP1): external TX modulation input
* '''ASK''' (TP2): external RX demodulator output

====interface mode selection====
NOTE: R4, R5, R7, R8 choose the interface mode:
* R4, R5, R8 soldered: SPI without SS mode (default)
* R4, R7, R8 soldered: SPI with SS mode - also connect TP14, TP16, TP17
* none soldered: parallel mode - also connect TP10, TP11, TP12, TP13, TP14, TP15, TP16, TP17

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the [[Talk:Freerunner_RFID_Board|discussion page]].

[[Category:Neo FreeRunner reworks and mods]]

Freerunner Navigation Board v3

2011-04-08T06:57:06Z

Hns: fixed typo in one link

The third version of the Freerunner Navigation Board was necessary because the compass chip used on the [[Freerunner Navigation Board]] and the [[Freerunner Navigation Board v2]] has been discontinued.

=Features=

Due to the new, smaller compass chip, the FRNBv3 offers a complete 10-DoF navigation solution. In addition to the 3D-Gyroscope, 3D-Kompass and the barometer which are already known from the FRNBv2, the v3 adds an high resolution accelerometer. It should be more accurate for navigation purposes than the integrated LIS302 accelerometers.

===Top Side===
* 3D Gyroscope ITG-3200
* 3D Magnetometer HMC5883L
* Air pressure/temperature sensor BMP085
* Accelerometer BMA180

==Bottom side==
The Bottom side of the PCB contains optional chips which might be used for different purposes. The FRNBv3 includes:
* TCA6705 7 channel LED controller
* MPR121 touch sensor controller
* M26LR64 I²C EEPROM accessible through RFID (antenna still needed)
* TXS0102 I²C level shifter (to connect additional sensors
* MIC1557 based 38KHz oscillator (for IR-remote control applications)

==Additional features==
The board operates with 3V or 3.3V which is needed for the sensors to work correctly. To be able to connect the board to other devices (for example GTA04, OpenPandora, Always Innovating devices), the I/O voltage can be anything between 1.8V and VCC.
To use the board with the Freerunner, just short the VCC and VCCIO solder.

All sensors feature a "conversion complete" output which can trigger an interrupt. These signals are now available at small solder points.

=Documentation=
Schematic and board layout files are available from https://gitorious.org/frnbv3/frnbv3-hardware (CadSoft EAGLE 5.x format)

==Pinout==
Will be added soon.

==Installation==
See [[Freerunner Navigation Board v2]]

==Issues==
'''Known HW or SW Issues'''
Nothing known yet.

==Software==

=Availability=
The [http://handheld-linux.com handheld-linux.com] team already takes preorders. You can find it [http://www.handheld-linux.com/wiki.php?page=Navigation%20Board here].

Two assembly options are available:
* Complete: Contains all chips as described above.
* Standard: Top-Side only, contains all sensors relevant for navigation purposes. The compass chip should be a little bit more accurate since a few capacitors on the bottom side are missing. They could distord the magnetic field.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T18:40:24Z

Hns: /* Pinout */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]

=== RFID Tag ===

The locations where to connect the I2C wires in a Freerunner are shown on the photo on the right side

* '''ANT1''', '''ANT2''' (TP27, TP28): solder two wires to connect the antenna
* '''VCC''' (TP8): +1.8V - +3.3V, available at the AUX-Switch
* '''SCL''', '''SDA''' (TP18, TP9): Serial clock and data, get it from testpoints at the debug connector
* '''GND''' (TP19): Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''EN0''', '''EN1''' (TP24, TP23): select address; usually connect to GND (I2C address 0x50)

=== RFID Reader ===

==== mandatory ====
* '''ANT''', '''VSS''' (TP26, TP25): solder two wires to connect the antenna
* '''VIN''' (TP22): +2.7 - +5.5V, main power available at the AUX-Switch
* '''VIO''' (TP21): +1.8 V - VIN, IO power available at the AUX-Switch
* '''SCLK''' (TP14): SPI clock input (mandatory)
* '''SOMI''' (TP16): SPI data from reader to CPU (mandatory)
* '''SIMO''' (TP17): SPI data from CPU to reader (mandatory)
* '''IRQ''' (TP7): positive interrupt impulse (should be connected to a GPIO)
====optional====
* '''SS''' (TP14): SPI chip select (only used in SPI with SS mode)
* '''EN''' (TP15): chip enable (optional to power down chip)
* '''EN2''' (TP4): second chip enable (optional to power down chip)
====extended====
* '''CLK''' (TP3): optional 60kHz / 13 MHz clock output to drive an external MCU
* '''MOD''' (TP1): external TX modulation input
* '''ASK''' (TP2): external RX demodulator output

====interface mode selection====
NOTE: R4, R5, R7, R8 choose the interface mode:
* R4, R5, R8 soldered: SPI without SS mode (default)
* R4, R7, R8 soldered: SPI with SS mode - also connect TP14, TP16, TP17
* none soldered: parallel mode - also connect TP10, TP11, TP12, TP13, TP14, TP15, TP16, TP17

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T18:38:36Z

Hns: /* Pinout */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
*** FIXME ***

[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]

=== RFID Tag ===

* '''ANT1''', '''ANT2''' (TP27, TP28): solder two wires to connect the antenna
* '''VCC''' (TP8): +1.8V - +3.3V, available at the AUX-Switch
* '''SCL''', '''SDA''' (TP18, TP9): Serial clock and data, get it from testpoints at the debug connector
* '''GND''' (TP19): Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''EN0''', '''EN1''' (TP24, TP23): select address; usually connect to GND (I2C address 0x50)

=== RFID Reader ===

==== mandatory ====
* '''ANT''', '''VSS''' (TP26, TP25): solder two wires to connect the antenna
* '''VIN''' (TP22): +2.7 - +5.5V, main power available at the AUX-Switch
* '''VIO''' (TP21): +1.8 V - VIN, IO power available at the AUX-Switch
* '''SCLK''' (TP14): SPI clock input (mandatory)
* '''SOMI''' (TP16): SPI data from reader to CPU (mandatory)
* '''SIMO''' (TP17): SPI data from CPU to reader (mandatory)
* '''IRQ''' (TP7): positive interrupt impulse (should be connected to a GPIO)
====optional====
* '''SS''' (TP14): SPI chip select (only used in SPI with SS mode)
* '''EN''' (TP15): chip enable (optional to power down chip)
* '''EN2''' (TP4): second chip enable (optional to power down chip)
====extended====
* '''CLK''' (TP3): optional 60kHz / 13 MHz clock output to drive an external MCU
* '''MOD''' (TP1): external TX modulation input
* '''ASK''' (TP2): external RX demodulator output

====interface mode selection====
NOTE: R4, R5, R7, R8 choose the interface mode:
* R4, R5, R8 soldered: SPI without SS mode (default)
* R4, R7, R8 soldered: SPI with SS mode - also connect TP14, TP16, TP17
* none soldered: parallel mode - also connect TP10, TP11, TP12, TP13, TP14, TP15, TP16, TP17

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T17:14:56Z

Hns:

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
*** FIXME ***

[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]
* '''VCC''': +3.3V, available at the AUX-Switch
* '''VIO''': +1.8 V - +3.3V, available at the AUX-Switch
* '''GND''': Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''SCL''', '''SDA''': Serial clock and data, get it from testpoints at the debug connector
* '''OE''': Output enable from the frequency generator. Pull this pin high to enable the CLK output
* '''CLK''': Clock output from the frequency generator.
* '''LED controller 0-3''': LED current sinks. Connect LEDs in series with current limiting resistors from VCC to these pads.
* '''12-Bit A/D 0-3''': Analog to digital converter inputs. They can operate single ended or differencial. The reference voltage is VCC.
* '''Touch electrodes 0-6''': Connect these pads to a larger conducting area to use it as touch sensor. The inputs 0-3 can also be used to drive LEDs. Refer to the datasheet for more information.

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers). It is tested
on a BeagleBoard and supports "SPI without SS" by using GPIO mode.

Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

Here is a very raw Idea for an interface from user space:

Set power mode
echo "5" >/sys/.../rfid/power

Set protocol
echo "2" >/sys/.../rfid/protocol

Trigger scanning for tags
echo >/sys/.../rfid/scan

Get list of found tags
ls -l /sys/.../rfid/tags/

Get signal strenght of specific tag
cat /sys/.../rfid/tags/uid/rssi

Read data from tag EEPROM
cat /sys/.../rfid/tags/uid/data

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T17:09:15Z

Hns: /* Pinout */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
*** FIXME ***

[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]
* '''VCC''': +3.3V, available at the AUX-Switch
* '''VIO''': +1.8 V - +3.3V, available at the AUX-Switch
* '''GND''': Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''SCL''', '''SDA''': Serial clock and data, get it from testpoints at the debug connector
* '''OE''': Output enable from the frequency generator. Pull this pin high to enable the CLK output
* '''CLK''': Clock output from the frequency generator.
* '''LED controller 0-3''': LED current sinks. Connect LEDs in series with current limiting resistors from VCC to these pads.
* '''12-Bit A/D 0-3''': Analog to digital converter inputs. They can operate single ended or differencial. The reference voltage is VCC.
* '''Touch electrodes 0-6''': Connect these pads to a larger conducting area to use it as touch sensor. The inputs 0-3 can also be used to drive LEDs. Refer to the datasheet for more information.

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Issues==
'''Known HW or SW Issues'''

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers).
Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T17:08:51Z

Hns: /* Features */

[[Image:FRIDBTopBottom.JPG|Freerunner RFID Board|thumb]]

NOTE: This is work in progress and quite incomplete

=Features=

The FRIDB realizes an experimental platform for RFID (13.56 MHz). It consists of an Antenna, a ST Micro M24LR64 RFID-Tag Chip with 64kbit EEPROM and I2C port and a Texas Instruments TRF7960 RFID reader chip with SPI interface.

So you can make the Freerunner either a RFID tag (e.g. to open doors) or a RFID reader (to read/write standard tags e.g. in credit card format).

The FRIDB can also connected to other Microcontrollers and SoC (e.g BeagleBoard) since it has splitted I/O and power supply.

The board comes with three parts that can/must be separated:

== Antenna ==
The antenna is a printed loop designed for a typical center frequency of 13 MHz with a capacitor of 56pF.

It can be fixed by tape instead of the battery cover or mounted externaly.

== RFID-Tag ==
By connecting the I2C EEPROM (ST Micro M24LR64) to the antenna and to the main CPU by I2C, the unit can be used as a dual-port RFID Tag. I.e. the tag can either be read or written through RFID (even if the main device has no power) or through the CPU. A typical scenario could be to personalize the device or to receive online-purchased tickets and store them in the tag so that they can be read out through RFID - even if the battery of the device is down.

The Tag module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== RFID-Reader ==
By connecting the Reader through the SPI interface (TI TRF7960) it is possible to use the Freerunner as a RFID reader.

The Reader module fits into the area above the SIM/SD card reader of the Openmoko Freerunner.
It is up to you to wire the board to the Freerunner main board in a way that you can still swap SD cards and/or SIM cards.

== both ==
Note: you can't use reader and tag in parallel. At least we have not tried. The protocols should be able to handle this case since there is a collision detection mechanism to separate multiple tags. What is not known is how to connect both devices to a single antenna. Maybe through a high-ohm resistor (to attenuate the TX signal from the RFID reader and two capacitors (to separate the DC components).

=Documentation=
The project home is http://projects.goldelico.com/p/fridb/. There, you can find background information, instructions, software etc.

Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://projects.goldelico.com/p/fridb/downloads/.

==Pinout==
[[Image:FRIDB-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]
* '''VCC''': +3.3V, available at the AUX-Switch
* '''VIO''': +1.8 V - +3.3V, available at the AUX-Switch
* '''GND''': Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''SCL''', '''SDA''': Serial clock and data, get it from testpoints at the debug connector
* '''OE''': Output enable from the frequency generator. Pull this pin high to enable the CLK output
* '''CLK''': Clock output from the frequency generator.
* '''LED controller 0-3''': LED current sinks. Connect LEDs in series with current limiting resistors from VCC to these pads.
* '''12-Bit A/D 0-3''': Analog to digital converter inputs. They can operate single ended or differencial. The reference voltage is VCC.
* '''Touch electrodes 0-6''': Connect these pads to a larger conducting area to use it as touch sensor. The inputs 0-3 can also be used to drive LEDs. Refer to the datasheet for more information.

[[Image:FRIDB-top.JPG|Top side with the M24LR64 and the TRF7960|thumb]]
[[Image:FRIDB-bottom.JPG|Bottom side |thumb]]
[[Image:FRIDB-install.JPG|Installation location |thumb]]

[[Image:FRIDB-antenna.JPG|potential Antenna position |thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRIDB to your Freerunner is to solder four wires to...

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===

==Issues==
'''Known HW or SW Issues'''

==Data Sheets==
* TRF7960: http://focus.ti.com/lit/ds/slou186f/slou186f.pdf
* M24LR64: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00217247.pdf

==Software==
===U-Boot driver===
some C-code for a U-Boot API is available to do some preliminary SPI communication (e.g. read/write registers).
Link: http://projects.goldelico.com/p/fridb/source/tree/master/u-boot

===Kernel drivers===
Upcoming.

===Userspace software===

n/a yet. Volunteers welcome!

What we most likely need is a Card scanner application (i.e. one that lists when tags come to vicinity).
And it would be nice to read/write content (which is unfortunately not quite standardized).

And we should have a keyboard driver that pressing the AUX button "types" the
ID of the current card plus a Newline. This would allow to use the card scanner like a
barcode scanner.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRIDB. You can find it [http://www.handheld-linux.com/wiki.php?page=RFID%20Board here].

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Freerunner RFID Board

2011-04-07T17:02:44Z

Hns: /* Expansion pads */

File:FRIDB-antenna.JPG

2011-04-07T17:02:18Z

Hns: Proposed mounting the antenna in the battery cover

Proposed mounting the antenna in the battery cover

File:FRIDB-install.JPG

2011-04-07T17:01:33Z

Hns: Location where the FRIDB fits into a Freerunner case

Location where the FRIDB fits into a Freerunner case

Freerunner RFID Board

2011-04-07T17:00:55Z

Hns: /* Pinout */

File:FRIDBTopBottom.JPG

2011-04-07T16:59:39Z

Hns: FRIDBoard (three parts not separated)

FRIDBoard (three parts not separated)

Freerunner RFID Board

2011-04-06T13:58:55Z

Hns: /* Software */

Wish List - Hardware

2011-04-06T13:52:00Z

Hns: /* NFC chip */

This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].

Related pages are:
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices.
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any Openmoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.
*[[CAD models]] - information about the open case models and how to manipulated them yourself in order create custom casings.

This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.
==Battery==
{{Main|Wishlist/LiFePO4 Battery}}

Make the battery independent from SD card and SIM card, so that battery does not have to be taken out when we only want to change either of the cards.

==Processor==
===A FPGA===
A FPGA is a general purpose reconfigurable logic device.
See [[Wish List - Hardware:FPGA]] for more details.

===Samsung S3C2443===
*[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2443&&ppmi=1427 Samsung S3C2443] Up to 533 MHz, can act as a USB 2.0 device.

==Internal Memory==
===RAM===
128MB Dedicated for open files, running software etc., not for storage, or 256MB at all would be really nice and enough for any future software. Using RAM as a swap in unix would significantly speed up the booting process. Approx. 10MB of ram is needed only. The rest, installed software, etc. can be used from ROM sources.

===ROM===
Enough to Hold O/S and a fair number of applications and their settings. Persistent Storage with XIP capability. About 128 MB.

===Storage===
An internal Micro SDHC should be used for users' files and additional software. Furthermore, user should be allowed to connect to an external USB memory and use it for either a storage or OS purposes.

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex. In South Korea, 2.3Ghz is available for WiMAX, known as WiBro. WiMAX Forum sets heart on 2.5 GHz for global use.
----
Two campuses of the University of California have just completed a deal with a WiMAX service provider to lease UC's ITFS/EBS spectrum to provide WiMAX in the SF Bay Area. Bidding was aggressive between Nextwave, Sprint-Nextel, and Clearwire. Other UC campuses have awarded other contracts throughout California to various of the three contenders. The point here is: these three companies are competing aggressively for spectrum in the 2.5-2.7 GHz range, and it's not limited to CA. At a National ITFS Association meeting in 2005, representatives from Intel said they would be ready to release a WiMAX chipset compatible with these frequencies in 2007, for inclusion in laptops. I assume the folks at [[FIC]] know much more about it that I do! Based on these and other clues, I think WiMAX is coming in the 2.5-2.7 GHz band in the near future... I'll be surprised if I do not see some offerings by early 2009.

-[[User:Tzf|Tzf]] 21:54, 24 November 2007 (CET)

===LTE support===
[http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution Long Term Evolution (LTE)] is a high-speed data service, similar to WiMax, but designed to be more compatible with existing GSM systems. While Sprint & Clearwire are currently testing WiMax deployment in the US, AT&T and Verizon appear to be in preference of LTE.

While the project is ongoing and general in scope, it has set itself some specific goals, many of which are oriented around upgrading UMTS to a so-called fourth generation mobile communications technology, essentially a wireless broadband Internet system with voice and other services built on top.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, business card reading, healthcare, servicing, biometric identification, and more.
** Unlike stand-alone cameras, an Openmoko camera could integrate EXIF information from GPS, compass, and internet, making it far more valuable.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful or leave the camera chip in place and have a removable lens assembly and replacement backcover.
** Ability to a) cover the lens when not in use (to protect it and make it more obvious when you are NOT taking photos), and b) possible "lock" on camera use if a business is providing the phone to its employees. This way the phones are identical in hardware, making it cheaper to produce.
*See [[Hardware:Neo1973:Alternate_Cases:Camera | Alternate Cases:Camera]] for phone casing suggestions.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

*Use examples: [http://www.youtube.com/watch?v=UcKqyn-gUbY&mode=related&search= Multi-touch interface (from Adobe TED)], [http://www.youtube.com/watch?v=1ftJhDBZqss&mode=related&search= Multi Touch (new touchscreen technology)]

===Bigger and better screen===
2.8" widescreen (like in [http://etencorp.com E-ten] PDA/smartphones), or 3.5" widescreen (like in [http://www.expansys.ie/d.aspx?i=134944 Fujitsu Siemens LOOX N560]).

262k or 16.7M colurs for displaying images and especially videos.

OLED for better contrast, more rich colours, and less energy consumption.

Maybe the [http://www.sharpsme.com/Page.aspx/europe/en/part/LS037V7DW01/ LS037V7DW01] by Sharp could be a solution. It has nearly the same specs as the currently used, but 3,7" -- [[User:Wedge | Wedge]]

I'd recommend the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD035SHED1%20Product%20Specification%20Ver%200.0-112906.pdf TD035SHED1 (Chineese spec paper)] since it has the very same pinout as the current one. Eventually I'm going to create a new case, and will use that display. Alternately the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD043MGEB1_v0.4.pdf TD043MGEB1] would be a nice option. However it has 8 bits per channel, and not 6 like the current one, so we would need some adaptor board to connect it: Pull down resistors on the 2 lowermost bits of each channel, and connect the current signal lines to the uppermost bits. Or somehow get 8 bits per channel from the controller.
--[[User:Datenwolf|Datenwolf]] 12:06, 28 July 2008 (UTC)

===="Slightly" Larger Screen====
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mm instead of the 3:4 aspect ratio would be even cooler (if one could be found).

====Higher resolution screen====
The current Openmoko hardware has a screen of size 2.8" and resolution 640 x 480 (VGA).

See this LCD panel: http://www.engadget.com/2006/12/27/hitachi-does-800-x-480-display-for-phones/

At 2.9" it is almost exactly the same size as the current screen but has a wider 800 x 480 resolution (WVGA). This is the same resolution as in the Nokia N800 web browsing devices (but those devices have a bigger, lower DPI screen).

A display panel like this would enhance the phones's usability as a small computer, particularly for activities like web browsing, with an almost negligible affect on the size of the device. It would cause slightly increased battery drain though.

===Distance sensing touchscreen===
{{Main|Hardware:NearlyTouchScreen}}
TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen", can sense fingers at a small distance, so you do not get your display greasy, and can unlike some touchscreens, be operated with gloves.

===<s>Video acceleration</s>===
Hardware acceleration for video playback and 2D/3D accelleration will be present in [[GTA02]].

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption.

Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

===Second Display===
A 32x32 OLED display possibly on the back for camera framing or on an edge so it can be viewed like a pager.
This could be used to display any number of alerts (from any installed software) the alerts could have a dynamic prioritisation which means during the work day a message from the boss has high priority but lower at home (could be GPS/Time controlled?) multiple alerts shrink the icons to a 3x3 grid higher priority messages get more space.

===Pico Projector===
[http://www.engadget.com/media/2006/02/digismartphone2.jpg Like the one shown here] or [http://www.youtube.com/watch?v=sT1mhSRichk (video example here)] new cellphones are now coming out with a small, low power projector. This can be used to show movies from your cell phone with 0.5m high image on a while wall for example...

Sample Video: http://www.youtube.com/watch?v=sT1mhSRichk

Sample Vendor/Product Info: http://www.dlp.com/tech/what.aspx

==Input devices==

===Tablet PC like pen input (Wacom Technology)===
The Wacom tablet protocol is openly documented, OSS drivers exist. Connection via UART or USB.
[http://www.wacom-components.com/english/technology/emr.html Wacom mobile technology]
[http://www.wacom-components.com/english/product/sensorboard.html Sensorboards]

Add a pen holder to the case, suitable for a pen [http://www.wacom-components.com/english/product/pen.html like the "Super Slim Pen" on this page]

===Regular phone keypad===
I really like the idea of this phone BUT it misses one
crucial feature - a simple keypad(like most other phones have).
I'd be basicaly happy with a mobile device with a 3-4" screen with a slide out keypad(in a similar way as the n95).

===No Dependence on Stylus===
The Neo's basic functionality should be completely usable without a stylus, Like the iPhone but with stylus use for precision work.

===QWERTY keyboard===
There should be a model that provides a Palm Treo type keyboard for messaging and internet interface. This would be best implemented in a phone casing with clamshell form factor which would give plenty of room for both button keys and screen area. Lets not just copy the iPhones onscreen data entry and make a phone that is a serious data interface device.

===A laser projection keyboard===
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
 
[[Image:Neogame90.jpg]]
 
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
 
:''Note'' : The [http://en.wikipedia.org/wiki/Tapwave_Zodiac Tapwave Zodiac] Palm PDA / Game console hybrid had a similar setup - with an analog stick on the left (also used for quick selection using a radial main menu when working as a PDA), 4 buttons on the right (also configurable for shortcuts when using the device as PDA), and 2 shoulder buttons. Also it had and still has an enthusiastic scene of homebrew development (almost any console emulator for PalmOS can also take advantage of the additional buttons and graphic power of the device). If we also take into account the success encountered by the [http://en.wikipedia.org/wiki/GP32 GP32] in the past and the [http://en.wikipedia.org/wiki/GP2X GP2X] currently on the homebrew scene, it's not unreasonable to plan a future Openmoko device with both a SmartPhone/PDA functionnality ''and'' hand-held console targeting homebrew development.

===Touch bigger than display===
If the sensing area of the touch covered the whole front of the phone, buttons could be emulated. Palm used this to have an input area next to the screen.

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Analogue Controllers===

====Trackball====
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.

====Analog Joystick====
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?

====Dual analogues====
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is widely available in the world, though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.
A good start would be an FM tuner, since it's one of the most widely used formats of radio broadcasting in the world.

Here's a selection of chips, though it's not clear if the drivers are open source. http://www.sigmatel.com/products/portable/wireless/fmtuner.aspx#fragment-14
http://www.st.com/stonline/products/families/automotive/am_fm_tuners.htm

===<s>Accelerometer</s>===
'''Avaliable in GTA02'''

This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed. A [[#Digital compass]] can even be of more use since it gives absolute rotation so slow rotations could also be measured. A 3D compass would be nicest, but a simple 2D compass already is a helpful addition to the accelerometers.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*<s>Attempt to use to stabilise any future camera.</s> While possible in theory the time required to process the accelerometer signals would cause to much latency, as that it could effectively be used for image stabilisation. You'd have to connect the acceleromters directly to the camera circuits.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size.
*With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.
*With a few OLED screens beneath the strip it could be used as dynamic configurable buttons/alerts eg. zoom/flash/shutter with a camera application and SMS/Email/Voicemail alerts in standby

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

Consider using the heart rate monitor from Zephyr tech. This communicates over bluetooth and has an SDK available.
http://www.zephyrtech.co.nz/products/consumer/hrm

===Digital compass===
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low. Also could be used to make the accelerometer data more exact.

A compass is also useful for tagging photographs with the correct direction (in addition to location) of the photo.

Very small [[I2C]] sensors like [http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass] (6.5 x 6.5 x 1.5 mm) are very appropriate for this. Another option is the much smaller [http://www.global.yamaha.com/news/2006/20060726.html Yamaha YAS529 Three-Axis Geomagnetic Sensor IC Chip] (2.0mm x 2.0mm x 1.0mm).

*[[Wishlist/Auto Align Map]]

See [[Wishlist - Hardware: Digital compass]] for more information

See [[I2C Compass]] for an attempt at one

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].
(Could just be cheap and use the thermometer from the battery, thats how they did it in the nokia 5140's). Also is integrated in a barometer/altimeter like the SMD500 mentioned in [[Wish List - Hardware - Atmospheric]].
::But if you carry it in your pocket it is unlikely to show the correct air temperature anyway. [[User:AudriusA|AudriusA]] 17:12, 12 January 2008 (CET)

===Barometer and Variometer (Altimeter)===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

These are also common on high end GPS units. This is a great feature for walkers as you can tell how far you have got on any ascent/decent.

See [[Wish List - Hardware - Atmospheric]] for more information.
::The GPS device [[Manually using GPS|outputs the altitude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)
:::The precision of GPS altitude is very coarse in comparison with a pressure based altimeter, in the order of 10m for GPS vs 25cm for a altimeter [[User:PTT|PTT]] 10:39, 13 October 2008 (UTC)

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

[http://www.fujitsu.com/downloads/MICRO/fma/formpdf/mbf320_fsfin.pdf Fujitsu] has a small strip like reader that has SPI and USB support.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

It can be used to tune brightness of LCD automatically.

Can camera be used like light sensor? (when we have camera)

===A pluggable sensor module===
Give the option of a composite sensor module consisting of pressure, humidity, temperature and light sensors(if camera not present, which is the case), which will be pluggable to the phone and connected to the USB 1.1 port.

===Wheel===
A navigation wheel like on a sony/ericsson 810i would be nice.

The wheel could be mounted beside the headphone jack. In software, it would be appropriate for it to appear as a mouse wheel to applications. The wheel should also accept a press which emulates a middle mouse button click.

Uses for this include:
1. Scrolling lists, with middle button as click/open item.
2. Volume control while talking and in media player.
3. Scrolling pages

===Proximity Sensor===
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.
:Automatically turning the speakerphone on/off sounds good, but to avoid disturbing others, for example in public, turning it on could be delayed so for example short looking at the display or putting it to the other ear doesn’t activate it. Additionally/alternatively the delay could be combined with/replaced by a orientation (or motion) sensor, so that it’s not activated when holding it upright, but only when it’s lying e. g. on a table.

=== Make ''all'' unlocking of phone, password protected===

When my (current non-neophone) phone is in my pocket and I have it locked, it sometimes accidentally unlocks itself since only two keystrokes in the correct order are necessary to unlock it. When it's unlocked and still in my pocket it sometimes calls someone without my knowledge. All phones I've seen today have a press-just-one-button bypass to answer an incoming call even when the phone is locked. I suggest making the locking mechanism let the user configure it so that the user has to enter a password even for answering incoming calls. The likeliness of the phone accidentally runbbing against my car keys, hitting a ten character long password, unlocking the phone without my knowledge and consent is low enough even for us most unlucky users.

==Expansion==
===Positioning of Buttons, Connections and ports===

Ideally any cable ports such as charging, USB, audio, docking should not get in the way of your hand or fingers when holding it in it's normal orientation. For the sake of SDIO cards an external SD slot should be on the top edge. IR for remote control software and ease of inter-device communication should be on the corner so that it is facing away from you for both orientations. Buttons obviously are positioned for finger control. An example of how '''not''' to do this would be the HTC Universal

===Storage===

====MMC/SD/SDIO slot (rather than?) miniSD or microSD====
*Cheaper, more durable cards in a widely accepted format.
*Much much larger storage capacity, [http://blog.scifi.com/tech/archives/2007/08/23/toshiba_unleash_1.html even 32GB]
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].
See more on [http://wiki.openmoko.org/wiki/Wish_List#SD_Card_Slot Wish list - SD Card Slot]

====Two SD slots====
*Micro SDHC for /home partition. Keep like current design underneath SIM card
*Hot swappable externally accessible normal size SDHC/SDIO slot

=== Internal Communication Bus ===
*A standard and/or documented internal communication bus of some sort could simplify adding new hardware modules.
*Serial USB or I2C connector internal to case towards the top
*Several digital I/O pins that operate at TTL levels
*A few analogue I/O pins attached to a A/D converter
*Documentation of Debug board connector could provide some of this functionality.

I2C is used on the Neo with some details of resources already in use documented!
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973.

===Local Communication===

====USB====
* 5V Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host. Provide a maximum current to drive a basic USB keyboard/memory stick/mouse/webcam/astrowebcam. This could be done by adding a small cheap power converter like the [http://www.national.com/pf/LM/LM2753.html LM2753]
* USB 2.0 (USB 1.1 is too slow to transfer data to the card, removing the card everytime from the phone isn't an option too, because it is placed under the battery)
* '''Standard type A socket''' for quick & easy insertion of memory sticks and all kind of devices. This type of connector is more robust to wear and tear compared to the type B socket which is more prone to break down.
* OTG, to be able connect usb keyboard like [http://www.mobile-review.com/pda/review/cherry-kb-en.shtml Cherry G84-4321 SUNRG]
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.
* Protection against incorrectly wired USB ports: some USB ports are wired incorrectly; if the +5V and GND are swapped, the device would get -5V when it's expecting +5V, which could burn some chips. A reverse-biased diode between +5V and GND, D+ and GND, D- and GND, and (if used) ID and GND, with a low enough forward voltage drop (to limite the negative voltages to what the chips can withstand), would protect the device by tripping the port's short circuit protection.
* 2 USB-Ports; one for acting as USB-host and one for acting as USB-device at same time.

====Wireless USB support====
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

====Bluetooth with A2DP====
Is the blue-tooth radio present in the phone A2DP compatible. If not, make it so.

Great for listening to music or watching a movie with full sound.

====SIR/FIR transceiver (Serial Infrared) / IR remote control====
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway.
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros.
**reduces clutter, particularly in the living room.
**inceases the neo's practical status as an 'always-have' device.

Other uses.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

===Other===

====Video Out====
*Through a docking port
**S-Video/Composite Out
**DVI Out
**HDMI Out
**Display Port

==Output devices==

===LED===
*The Neo1973 GTA02 will have LEDs of some sort behind at least one button. [http://lists.openmoko.org/pipermail/community/2007-July/008458.html]
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.
**A Small OLED Screen could be used and display much more information than a LED with minimal power usage.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.
This is really well done in Nokia 5500.

-I second this one. The most used feature in my Nokia 5140 after the calling and sms features is the flashlight. It's just one simple LED, but powerful enough to see with if it's really dark. If it ain't dark, you won't need the light anyway. :)

Also, Who hasn't lost their keys and opened up their cell phone to use as a flashlight?

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

Fix the biggest flaw in the iPod before Apple does!

=== Infrared Transmitter w/ universal remote software ===
Infrared LED on top of device with universal remote software so you can control televisions, DVDs etc.
[http://www.novii.tv/ Here] is an example of universal remote software.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

===HAC Compliance===
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.

==Mobile Communication options==

===Generic Access Network / Unlicensed Mobile Access===
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type Openmoko device.

Note that this features requires more advanced access to the GSM modem.
Special messages needs to be exchanged with the network.

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. An incremental improvement would be a radio with [http://en.wikipedia.org/wiki/EDGE EDGE ] support. EDGE is an evolved GSM standard and, like GPRS, it operates on the same frequency as voice. This means a quad-band EDGE radio will have near-complete worldwide coverage.

[http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe and being deployed in the US, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal. These faster standards operate in different frequencies from GSM/GPRS/EDGE. Which frequency exactly will depend on the carrier and country. For UMTS in the US, AT&T uses 850/1900 MHz but T-Mobile will use 2100/1700 MHz for example.

Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [[Bluetooth_powered_Multi-SIM_support | use another mobile via BT]].
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.
* Dual SIM card support will be especially welcome by the women. They just love to talk on the phone.
* Save the contents from several SIM-cards to memory and simulate them.

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

2 way talk over Sprint/Nextel/Boost networks if possible. At least the walkie talkie feature for sure. It's very annoying being at a lake with no service and can't call your friend in the other boat across the lake.

===[[DECT]]===
* Include a [[DECT]] GAP/CAT-iq transceiver so you can use your home and/or office PSTN line
** Ability to use Alcatel phonebook stuff (like provided by the eventphone.de phone equipment) would be very nice too

===[[SIP phone]]===
Make stripped down (and thus cheaper) version of the Neo1973 phone for use as a SIP phone. Remove GPS, GSM, accelerometers, stylus.

Addition of an centimeters-precise location system [http://en.wikipedia.org/wiki/Real_Time_Location_Systems RTLS] would be nice, as it will allow highly sensible indoor context detection. Imagine putting the phone next to your mirror (where you shave daily) and watch it automatically switch to news radio channel. Or put it next to your bed and see it automatically switch to "sleeping" mode, when only calls from predefined numbers are accepted.

=='''Casing'''==
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.

=== Generic Back Plate Connector ===
If the Neo had a few connectors below the back plate, it would be much easier to develop custom backplates. Connectors needed would be GND, Power-out, Power-in (for charging/expansion battery appliances), some bus (either USB or some other bus, maybe usb wouldn't be the best choice since having a backplate and an upstream connection at the same time might cause problems) and maybe some ID pins to discern battery/charger/generic expansion modules on hardware level
--[[User:DrDeath|DrDeath]] 10:39, 27 September 2008 (UTC)

=== [[Hardware:Neo1973:Alternate_Cases:Expansion_Module_Casing | Expansion Module Casing]] ===
Longer case (150-160mm+) with space in the top to put expansion modules, including test & hobby hardware. Would require use of a standard internal power & communications bus. Could be left empty with blank cover or house cameras, solar panels, a crank powered charger, special transmitters/recievers, or anything else imaginable.

[http://www.likeasecret.com/Neo1973/Neo1973-Exp.mov Neo1973 Expansion Module Quicktime rendering] 
[[Image:Neo1973-Exp.png]]

-mb make a bigger higher resolution screen and the hardware will still be the same size and the free runer bigger a in the free place make z sliding thing wich you would sell in many colour and if sb whants a camera hi can buy it in the sliding thing or he can just buy it blank for his own hard-ware this would be cool this sliding pice could have some cind of shape thet would fit and let you the most posibilities even you could make it covering some front of the phone so you could place a joystick and buttos in it. If you would need leds you would buy a blank cover drill it and it would be fine becous you wouldnt injury the mine case of the phone.

=== Expansion Back Casing ===
Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===[[Hardware:Neo1973:Alternate_Cases:Expansion_Front_Casing|Expansion Front Casing]]===
Replacement fronts with e.g. extra buttons.

===Clamshell Casing===
The clamshell form factor is much preferred by many in that: 1) it provides more area for both screen and keypad 2) its easier for one handed use, the buttons arent crammed in the bottom of the casing 3) clamshell open up to provide longer distance to cover both ear and mouth so you dont have to shout in noisy areas to be heard because the speaker is up on the side of your face 4) clamshells protect the screen from scratches

=== Space efficient Lanyard ===
The hole at the bottom of the phone takes a lot of space. A [http://en.wikipedia.org/wiki/Kensington_Security_Slot Kensington Security Slot] could be used instead.

=== Rugged version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display, maybe aluminium case. The big ugly pseudo military version. What about a casing similar to the OLPC project's in terms of dust and waterproofing? I frequently have to answer the phone with hands dripping sea water and most phone's do not take kindly to that type of treatment. Also the accelerometers can be wired to a protection mechanism which suspends all processing/data activity in case of a (free) fall.

*Seconded. Would get one at once. please IP68 and with rubber coating.
*I support this too. Might make more sense as an accessory which you can snap/peel onto your phone however?
*I'm eager to see a ruggedized version, maybe even floatable.
*+1. No point in having an excellent phone/PDA-device, if you can't take it with you where ever you may go. I think this might work as an optional accessory case design, as a previous contributor mentioned.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

That makes sense to me. I second that idea!
Me, too!
+1 :) i would buy one!

=== Blank ===
Even though the transparent case would work too, I would like to see a blank case of pure black or white so people could have the option of air-brushing,painting or even drawing on the case.

===Integrated solar charger===
Perhaps on one side there could be an integrated photovoltaic. It would be small, but might it be enough to charge the device. It could be integrated in an aesthetically pleasing fashion like [http://i.i.com.com/cnwk.1d/i/bto/20080523/solarboat.jpg this]... except, with a matching color. :)

===Custom look===
Provide a service which offers custom case design like [[Freerunner_Alternative_Case_Designs|this one]], see images below. Just upload two images, reposition them in an interactive website, submit credit card information and the custom case design with application manual will be shipped to you.

<gallery caption="Special casing" heights="100px">
Image:Special-casing-front.jpg|front
Image:Special-casing-back.jpg|back
</gallery>

==Misc==
===Battery Size/Standby Time===

Since the device will be ultimately running a wide selection of software on it the battery needs to be somewhat more robust and have a longer standby time than that of current phone's. At the moment I'm using a Moto (2 days before charging) or a Samsung (3 days before charging) and am not impressed with either phone's standby time, and I'm not using the phone's for anything but calls.

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea, particularly when it's intended to be a mobile-komputing device.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from (or at all) if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry. If 5V is detected on the power line, then the obvious place to get it from is there at any point in time.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

With the dedicated charger it would also be possible to use any standard USB device if
the phone recognized the external power and enabled 5v power when plugged in.

===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

=== GPS antena ===
The current GPS device seems even dependent on weather and may not work in heavy rain or snow. It seems necessary to think how to improve the reliability. The small portable GPS antena may be an option.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.
* Say you have RFID tags on your personal belongings: cellphone, keys... Neo could be programmed to remember the last recorded GPS location before it lost contact with the respective RFIDs. It'd be trivial to check where you left your cellphone, get directions from a map...or beep when the phone gets out of RFID range.

*I agree with this idea, a great idea and you have to do it (Jackcday)
*Or, a python script that use the accelerometers and rfid reader, so when the phone moves it checks for an rfid tag (that would be in the users pocket) and if it doesn't get a response it rings in full volume, or starts a tracking utility :))))
*A RFID reader would need an antenna loop which could probably be used for wireless docking or even charging
*connected RFID UHF Reader to the openmoko via USB Host Mode [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5612279 http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5612279]
* some hardware project is there: [[Freerunner_RFID_Board]]

===NFC chip===
*A Near Field Communication chip, with this chip it will be possible to pay with your phone (like a credit card)in the near future, see [http://www.nokia.com/A4305081 Nokia]for details
*NXP is a chip fabricator which provides NFC chips [http://nxp.com NXP] direct link>> www.nxp.com/#/pip/cb=[type=product,path=/53420/53424]|pip=[pfp=53424][0] their chips also support the above RFID reading
*a technical note: NFC is an extension of RFID where two readers can communicate with each other i.e. both are quite similar

===Less weight===
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary "user" may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common business or multimedia phones.
{|border="1"
| Neo1973 || Fujitsu-Siemens LOOX N560 || E-Ten Glofiish X500+ || Sony Ericsson P990i || iPhone || Nokia E65
|-
| 184 g || 160 g || 146 g || 150 g || 135 g || 115 g
|-
|}

===Make it smaller===
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. A 2.5mm jack is the most common for headsets.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones. Adapters to 2.5mm are of course available and this 3.5mm jack is much more robust.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone. Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Software should know of the jack status===
It should be possible for the OS to see if there is something connected to the audio jacks. That would avoid the embarrasing moments when you accidently pull out the headphones from the cell/laptop and whatever you were listening blares over the place at full volume. If OS can see, that the headphones were unplugged without turning off the audio, then it could pop up a warning that would allow to direct audio to internal speakers or turn it off. If the user would replug the headphones/speakers then the warning would dissapear as well.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

Make it a green one <10mW so it won't be illegal in quite a few countries.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big color display.

=== Inductive Charger ===

It would be nice if it was possible to charge the phone without having to connect a cable. I'd like to have a simple docking station with an inductive charger like the type that's used for electric toothbrushes [http://home.howstuffworks.com/question292.htm ]. The charger itself could get its power from a standard wall-wart power supply, or it could be USB/Firewire powered.

==== Examples of existing commercial systems ====
* http://www.splashpower.com/

*might be combinable with a RFID reader

=== Solar panel/dynamo Charger===

It would be very nice to be able to charge the phone outside of the electric grid (for example on hikes and boating trips). A combined solar panel and muscle empowered (rotational etc.) charger would do the trick nicely.
* It might be possible to include a charger based on a step motor and an excentric weight, similar to automatic wrist watches. Charge by walking/running, if that wouldn't be cool...

'''some mobile Solarpanels'''

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01011&k_id=1400&hot=0 Off-Grid Systems Sunbag L]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01001&k_id=1400&hot=0 Off-Grid Systems Sunbag S]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01011&k_id=1400&hot=0 Silva Solar I]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01012&k_id=1400&hot=0 Silva Solar II]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sol01011&k_id=1400&hot=0 Solarc e-Go Professional] (link broken?)

[http://www.solarc.de/shop/product_info.php?info=p32_e-GO--Professional.html Solarc e-Go Professional] manufacturers page

[http://www.heise.de/mobil/suche/ergebnis?rm=result;q=solar;url=/mobil/artikel/74142/;words=solar Solarc e-Go *]

[http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Solar%20solar;q=solar;url=/newsticker/meldung/91536/ Solar JKT]

- I think a dynamo charger ("share charger", rotational, ...) would be more practical as a peripheral, connected through the USB-interface using the same principle cellphones now charge when connected to an USB-port. You could very easily hack this together. [http://www.metacafe.com/watch/449950/hack_a_flashlight_to_power_your/ flashlight recharge hack] Random thought; Why not create some merchandise toys with a small lithium battery which charge through centrifugal force allowing to recharge the phone with a small "general" connector.

[http://www.heise.de/mobil/artikel/61368/0 Article about aome mobile power-sources]

=== Plastic Solar/Back side on the Neo===

Solar cells from Plastic, on the reverse side of the Neo 1973
modified and introgreated in the battery backcover/flap,
like an energy source when the display is in standby mode.
Thats can be use also as alternate charge method's and also helps in emergency.

http://www.nanosolar.com/

=== Vibration===
Instead of using a counter-weighted motor to provide a vibrate function, a small solenoid could be used.It would provide more of a tap or click feel. It could be used to provide feedback when a on screen button is pressed. Different patterns of taps is a lot easier to recognize compared to different vibration frequencies. For those who know morse code they could have the phone tap out the phone number/name of the person calling/messaging or other alerts.

===As plug-in without screen...===

Along the lines of add-on cards, only looking at it from a different angle, I'd like to see a "faceless" openmoko with a documented hardware interface for both communicating with it and inserting it into other devices. Even the keypad/screen/battery would be attached, openmoko itself would just be faceless sliver of hardware with a documented interface and an API for communicating with the innards.

===Running without battery===
Please make it possible to run the device without a battery inserted (with the charger attached). I have several mobile phones which do not work anymore (even when attached to the charger) because the battery is worn out and new batteries are not available. I want the Openmoko to be usable when the battery is worn out.

* Seconded.

===Make GSM/CDMA/WiFi/WiMax/GPS plugable===
Please make Openmoko mobile as PC GSM/CDMA/... just working like plugable cards, they are cards/adaptor for the DEVICE only. the user may eject GSM module and inject with CDMA module. the DEVICE may provide several slot to allow user choose wifi/wimax/sd/gps/harddisk/...

===Wifi chip that can be used with kismet and other sniffers===
Please change the wifi chip that also can be used for sniffing wifi connection preferably the latest standard, not N. For pen testing. A wifi chips like the [http://www.ralinktech.com/ralink/data/RT2800.pdf RT2800] I think?

===Add a connector for an external Wifi aerial===
PLease can a an external aerial connector be added so better arials can be used useful for sniffing wifi connections for pen testing etc.

==Related Hardware==
See [[Related Hardware]]

[[Category:Hardware ideas| ]]

Wish List - Hardware

2011-04-06T13:50:54Z

Hns: /* RFID tag/RFID Reader */

This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].

Related pages are:
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices.
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any Openmoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.
*[[CAD models]] - information about the open case models and how to manipulated them yourself in order create custom casings.

This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.
==Battery==
{{Main|Wishlist/LiFePO4 Battery}}

Make the battery independent from SD card and SIM card, so that battery does not have to be taken out when we only want to change either of the cards.

==Processor==
===A FPGA===
A FPGA is a general purpose reconfigurable logic device.
See [[Wish List - Hardware:FPGA]] for more details.

===Samsung S3C2443===
*[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2443&&ppmi=1427 Samsung S3C2443] Up to 533 MHz, can act as a USB 2.0 device.

==Internal Memory==
===RAM===
128MB Dedicated for open files, running software etc., not for storage, or 256MB at all would be really nice and enough for any future software. Using RAM as a swap in unix would significantly speed up the booting process. Approx. 10MB of ram is needed only. The rest, installed software, etc. can be used from ROM sources.

===ROM===
Enough to Hold O/S and a fair number of applications and their settings. Persistent Storage with XIP capability. About 128 MB.

===Storage===
An internal Micro SDHC should be used for users' files and additional software. Furthermore, user should be allowed to connect to an external USB memory and use it for either a storage or OS purposes.

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex. In South Korea, 2.3Ghz is available for WiMAX, known as WiBro. WiMAX Forum sets heart on 2.5 GHz for global use.
----
Two campuses of the University of California have just completed a deal with a WiMAX service provider to lease UC's ITFS/EBS spectrum to provide WiMAX in the SF Bay Area. Bidding was aggressive between Nextwave, Sprint-Nextel, and Clearwire. Other UC campuses have awarded other contracts throughout California to various of the three contenders. The point here is: these three companies are competing aggressively for spectrum in the 2.5-2.7 GHz range, and it's not limited to CA. At a National ITFS Association meeting in 2005, representatives from Intel said they would be ready to release a WiMAX chipset compatible with these frequencies in 2007, for inclusion in laptops. I assume the folks at [[FIC]] know much more about it that I do! Based on these and other clues, I think WiMAX is coming in the 2.5-2.7 GHz band in the near future... I'll be surprised if I do not see some offerings by early 2009.

-[[User:Tzf|Tzf]] 21:54, 24 November 2007 (CET)

===LTE support===
[http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution Long Term Evolution (LTE)] is a high-speed data service, similar to WiMax, but designed to be more compatible with existing GSM systems. While Sprint & Clearwire are currently testing WiMax deployment in the US, AT&T and Verizon appear to be in preference of LTE.

While the project is ongoing and general in scope, it has set itself some specific goals, many of which are oriented around upgrading UMTS to a so-called fourth generation mobile communications technology, essentially a wireless broadband Internet system with voice and other services built on top.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, business card reading, healthcare, servicing, biometric identification, and more.
** Unlike stand-alone cameras, an Openmoko camera could integrate EXIF information from GPS, compass, and internet, making it far more valuable.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful or leave the camera chip in place and have a removable lens assembly and replacement backcover.
** Ability to a) cover the lens when not in use (to protect it and make it more obvious when you are NOT taking photos), and b) possible "lock" on camera use if a business is providing the phone to its employees. This way the phones are identical in hardware, making it cheaper to produce.
*See [[Hardware:Neo1973:Alternate_Cases:Camera | Alternate Cases:Camera]] for phone casing suggestions.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

*Use examples: [http://www.youtube.com/watch?v=UcKqyn-gUbY&mode=related&search= Multi-touch interface (from Adobe TED)], [http://www.youtube.com/watch?v=1ftJhDBZqss&mode=related&search= Multi Touch (new touchscreen technology)]

===Bigger and better screen===
2.8" widescreen (like in [http://etencorp.com E-ten] PDA/smartphones), or 3.5" widescreen (like in [http://www.expansys.ie/d.aspx?i=134944 Fujitsu Siemens LOOX N560]).

262k or 16.7M colurs for displaying images and especially videos.

OLED for better contrast, more rich colours, and less energy consumption.

Maybe the [http://www.sharpsme.com/Page.aspx/europe/en/part/LS037V7DW01/ LS037V7DW01] by Sharp could be a solution. It has nearly the same specs as the currently used, but 3,7" -- [[User:Wedge | Wedge]]

I'd recommend the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD035SHED1%20Product%20Specification%20Ver%200.0-112906.pdf TD035SHED1 (Chineese spec paper)] since it has the very same pinout as the current one. Eventually I'm going to create a new case, and will use that display. Alternately the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD043MGEB1_v0.4.pdf TD043MGEB1] would be a nice option. However it has 8 bits per channel, and not 6 like the current one, so we would need some adaptor board to connect it: Pull down resistors on the 2 lowermost bits of each channel, and connect the current signal lines to the uppermost bits. Or somehow get 8 bits per channel from the controller.
--[[User:Datenwolf|Datenwolf]] 12:06, 28 July 2008 (UTC)

===="Slightly" Larger Screen====
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mm instead of the 3:4 aspect ratio would be even cooler (if one could be found).

====Higher resolution screen====
The current Openmoko hardware has a screen of size 2.8" and resolution 640 x 480 (VGA).

See this LCD panel: http://www.engadget.com/2006/12/27/hitachi-does-800-x-480-display-for-phones/

At 2.9" it is almost exactly the same size as the current screen but has a wider 800 x 480 resolution (WVGA). This is the same resolution as in the Nokia N800 web browsing devices (but those devices have a bigger, lower DPI screen).

A display panel like this would enhance the phones's usability as a small computer, particularly for activities like web browsing, with an almost negligible affect on the size of the device. It would cause slightly increased battery drain though.

===Distance sensing touchscreen===
{{Main|Hardware:NearlyTouchScreen}}
TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen", can sense fingers at a small distance, so you do not get your display greasy, and can unlike some touchscreens, be operated with gloves.

===<s>Video acceleration</s>===
Hardware acceleration for video playback and 2D/3D accelleration will be present in [[GTA02]].

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption.

Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

===Second Display===
A 32x32 OLED display possibly on the back for camera framing or on an edge so it can be viewed like a pager.
This could be used to display any number of alerts (from any installed software) the alerts could have a dynamic prioritisation which means during the work day a message from the boss has high priority but lower at home (could be GPS/Time controlled?) multiple alerts shrink the icons to a 3x3 grid higher priority messages get more space.

===Pico Projector===
[http://www.engadget.com/media/2006/02/digismartphone2.jpg Like the one shown here] or [http://www.youtube.com/watch?v=sT1mhSRichk (video example here)] new cellphones are now coming out with a small, low power projector. This can be used to show movies from your cell phone with 0.5m high image on a while wall for example...

Sample Video: http://www.youtube.com/watch?v=sT1mhSRichk

Sample Vendor/Product Info: http://www.dlp.com/tech/what.aspx

==Input devices==

===Tablet PC like pen input (Wacom Technology)===
The Wacom tablet protocol is openly documented, OSS drivers exist. Connection via UART or USB.
[http://www.wacom-components.com/english/technology/emr.html Wacom mobile technology]
[http://www.wacom-components.com/english/product/sensorboard.html Sensorboards]

Add a pen holder to the case, suitable for a pen [http://www.wacom-components.com/english/product/pen.html like the "Super Slim Pen" on this page]

===Regular phone keypad===
I really like the idea of this phone BUT it misses one
crucial feature - a simple keypad(like most other phones have).
I'd be basicaly happy with a mobile device with a 3-4" screen with a slide out keypad(in a similar way as the n95).

===No Dependence on Stylus===
The Neo's basic functionality should be completely usable without a stylus, Like the iPhone but with stylus use for precision work.

===QWERTY keyboard===
There should be a model that provides a Palm Treo type keyboard for messaging and internet interface. This would be best implemented in a phone casing with clamshell form factor which would give plenty of room for both button keys and screen area. Lets not just copy the iPhones onscreen data entry and make a phone that is a serious data interface device.

===A laser projection keyboard===
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
 
[[Image:Neogame90.jpg]]
 
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
 
:''Note'' : The [http://en.wikipedia.org/wiki/Tapwave_Zodiac Tapwave Zodiac] Palm PDA / Game console hybrid had a similar setup - with an analog stick on the left (also used for quick selection using a radial main menu when working as a PDA), 4 buttons on the right (also configurable for shortcuts when using the device as PDA), and 2 shoulder buttons. Also it had and still has an enthusiastic scene of homebrew development (almost any console emulator for PalmOS can also take advantage of the additional buttons and graphic power of the device). If we also take into account the success encountered by the [http://en.wikipedia.org/wiki/GP32 GP32] in the past and the [http://en.wikipedia.org/wiki/GP2X GP2X] currently on the homebrew scene, it's not unreasonable to plan a future Openmoko device with both a SmartPhone/PDA functionnality ''and'' hand-held console targeting homebrew development.

===Touch bigger than display===
If the sensing area of the touch covered the whole front of the phone, buttons could be emulated. Palm used this to have an input area next to the screen.

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Analogue Controllers===

====Trackball====
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.

====Analog Joystick====
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?

====Dual analogues====
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is widely available in the world, though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.
A good start would be an FM tuner, since it's one of the most widely used formats of radio broadcasting in the world.

Here's a selection of chips, though it's not clear if the drivers are open source. http://www.sigmatel.com/products/portable/wireless/fmtuner.aspx#fragment-14
http://www.st.com/stonline/products/families/automotive/am_fm_tuners.htm

===<s>Accelerometer</s>===
'''Avaliable in GTA02'''

This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed. A [[#Digital compass]] can even be of more use since it gives absolute rotation so slow rotations could also be measured. A 3D compass would be nicest, but a simple 2D compass already is a helpful addition to the accelerometers.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*<s>Attempt to use to stabilise any future camera.</s> While possible in theory the time required to process the accelerometer signals would cause to much latency, as that it could effectively be used for image stabilisation. You'd have to connect the acceleromters directly to the camera circuits.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size.
*With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.
*With a few OLED screens beneath the strip it could be used as dynamic configurable buttons/alerts eg. zoom/flash/shutter with a camera application and SMS/Email/Voicemail alerts in standby

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

Consider using the heart rate monitor from Zephyr tech. This communicates over bluetooth and has an SDK available.
http://www.zephyrtech.co.nz/products/consumer/hrm

===Digital compass===
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low. Also could be used to make the accelerometer data more exact.

A compass is also useful for tagging photographs with the correct direction (in addition to location) of the photo.

Very small [[I2C]] sensors like [http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass] (6.5 x 6.5 x 1.5 mm) are very appropriate for this. Another option is the much smaller [http://www.global.yamaha.com/news/2006/20060726.html Yamaha YAS529 Three-Axis Geomagnetic Sensor IC Chip] (2.0mm x 2.0mm x 1.0mm).

*[[Wishlist/Auto Align Map]]

See [[Wishlist - Hardware: Digital compass]] for more information

See [[I2C Compass]] for an attempt at one

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].
(Could just be cheap and use the thermometer from the battery, thats how they did it in the nokia 5140's). Also is integrated in a barometer/altimeter like the SMD500 mentioned in [[Wish List - Hardware - Atmospheric]].
::But if you carry it in your pocket it is unlikely to show the correct air temperature anyway. [[User:AudriusA|AudriusA]] 17:12, 12 January 2008 (CET)

===Barometer and Variometer (Altimeter)===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

These are also common on high end GPS units. This is a great feature for walkers as you can tell how far you have got on any ascent/decent.

See [[Wish List - Hardware - Atmospheric]] for more information.
::The GPS device [[Manually using GPS|outputs the altitude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)
:::The precision of GPS altitude is very coarse in comparison with a pressure based altimeter, in the order of 10m for GPS vs 25cm for a altimeter [[User:PTT|PTT]] 10:39, 13 October 2008 (UTC)

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

[http://www.fujitsu.com/downloads/MICRO/fma/formpdf/mbf320_fsfin.pdf Fujitsu] has a small strip like reader that has SPI and USB support.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

It can be used to tune brightness of LCD automatically.

Can camera be used like light sensor? (when we have camera)

===A pluggable sensor module===
Give the option of a composite sensor module consisting of pressure, humidity, temperature and light sensors(if camera not present, which is the case), which will be pluggable to the phone and connected to the USB 1.1 port.

===Wheel===
A navigation wheel like on a sony/ericsson 810i would be nice.

The wheel could be mounted beside the headphone jack. In software, it would be appropriate for it to appear as a mouse wheel to applications. The wheel should also accept a press which emulates a middle mouse button click.

Uses for this include:
1. Scrolling lists, with middle button as click/open item.
2. Volume control while talking and in media player.
3. Scrolling pages

===Proximity Sensor===
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.
:Automatically turning the speakerphone on/off sounds good, but to avoid disturbing others, for example in public, turning it on could be delayed so for example short looking at the display or putting it to the other ear doesn’t activate it. Additionally/alternatively the delay could be combined with/replaced by a orientation (or motion) sensor, so that it’s not activated when holding it upright, but only when it’s lying e. g. on a table.

=== Make ''all'' unlocking of phone, password protected===

When my (current non-neophone) phone is in my pocket and I have it locked, it sometimes accidentally unlocks itself since only two keystrokes in the correct order are necessary to unlock it. When it's unlocked and still in my pocket it sometimes calls someone without my knowledge. All phones I've seen today have a press-just-one-button bypass to answer an incoming call even when the phone is locked. I suggest making the locking mechanism let the user configure it so that the user has to enter a password even for answering incoming calls. The likeliness of the phone accidentally runbbing against my car keys, hitting a ten character long password, unlocking the phone without my knowledge and consent is low enough even for us most unlucky users.

==Expansion==
===Positioning of Buttons, Connections and ports===

Ideally any cable ports such as charging, USB, audio, docking should not get in the way of your hand or fingers when holding it in it's normal orientation. For the sake of SDIO cards an external SD slot should be on the top edge. IR for remote control software and ease of inter-device communication should be on the corner so that it is facing away from you for both orientations. Buttons obviously are positioned for finger control. An example of how '''not''' to do this would be the HTC Universal

===Storage===

====MMC/SD/SDIO slot (rather than?) miniSD or microSD====
*Cheaper, more durable cards in a widely accepted format.
*Much much larger storage capacity, [http://blog.scifi.com/tech/archives/2007/08/23/toshiba_unleash_1.html even 32GB]
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].
See more on [http://wiki.openmoko.org/wiki/Wish_List#SD_Card_Slot Wish list - SD Card Slot]

====Two SD slots====
*Micro SDHC for /home partition. Keep like current design underneath SIM card
*Hot swappable externally accessible normal size SDHC/SDIO slot

=== Internal Communication Bus ===
*A standard and/or documented internal communication bus of some sort could simplify adding new hardware modules.
*Serial USB or I2C connector internal to case towards the top
*Several digital I/O pins that operate at TTL levels
*A few analogue I/O pins attached to a A/D converter
*Documentation of Debug board connector could provide some of this functionality.

I2C is used on the Neo with some details of resources already in use documented!
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973.

===Local Communication===

====USB====
* 5V Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host. Provide a maximum current to drive a basic USB keyboard/memory stick/mouse/webcam/astrowebcam. This could be done by adding a small cheap power converter like the [http://www.national.com/pf/LM/LM2753.html LM2753]
* USB 2.0 (USB 1.1 is too slow to transfer data to the card, removing the card everytime from the phone isn't an option too, because it is placed under the battery)
* '''Standard type A socket''' for quick & easy insertion of memory sticks and all kind of devices. This type of connector is more robust to wear and tear compared to the type B socket which is more prone to break down.
* OTG, to be able connect usb keyboard like [http://www.mobile-review.com/pda/review/cherry-kb-en.shtml Cherry G84-4321 SUNRG]
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.
* Protection against incorrectly wired USB ports: some USB ports are wired incorrectly; if the +5V and GND are swapped, the device would get -5V when it's expecting +5V, which could burn some chips. A reverse-biased diode between +5V and GND, D+ and GND, D- and GND, and (if used) ID and GND, with a low enough forward voltage drop (to limite the negative voltages to what the chips can withstand), would protect the device by tripping the port's short circuit protection.
* 2 USB-Ports; one for acting as USB-host and one for acting as USB-device at same time.

====Wireless USB support====
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

====Bluetooth with A2DP====
Is the blue-tooth radio present in the phone A2DP compatible. If not, make it so.

Great for listening to music or watching a movie with full sound.

====SIR/FIR transceiver (Serial Infrared) / IR remote control====
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway.
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros.
**reduces clutter, particularly in the living room.
**inceases the neo's practical status as an 'always-have' device.

Other uses.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

===Other===

====Video Out====
*Through a docking port
**S-Video/Composite Out
**DVI Out
**HDMI Out
**Display Port

==Output devices==

===LED===
*The Neo1973 GTA02 will have LEDs of some sort behind at least one button. [http://lists.openmoko.org/pipermail/community/2007-July/008458.html]
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.
**A Small OLED Screen could be used and display much more information than a LED with minimal power usage.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.
This is really well done in Nokia 5500.

-I second this one. The most used feature in my Nokia 5140 after the calling and sms features is the flashlight. It's just one simple LED, but powerful enough to see with if it's really dark. If it ain't dark, you won't need the light anyway. :)

Also, Who hasn't lost their keys and opened up their cell phone to use as a flashlight?

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

Fix the biggest flaw in the iPod before Apple does!

=== Infrared Transmitter w/ universal remote software ===
Infrared LED on top of device with universal remote software so you can control televisions, DVDs etc.
[http://www.novii.tv/ Here] is an example of universal remote software.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

===HAC Compliance===
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.

==Mobile Communication options==

===Generic Access Network / Unlicensed Mobile Access===
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type Openmoko device.

Note that this features requires more advanced access to the GSM modem.
Special messages needs to be exchanged with the network.

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. An incremental improvement would be a radio with [http://en.wikipedia.org/wiki/EDGE EDGE ] support. EDGE is an evolved GSM standard and, like GPRS, it operates on the same frequency as voice. This means a quad-band EDGE radio will have near-complete worldwide coverage.

[http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe and being deployed in the US, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal. These faster standards operate in different frequencies from GSM/GPRS/EDGE. Which frequency exactly will depend on the carrier and country. For UMTS in the US, AT&T uses 850/1900 MHz but T-Mobile will use 2100/1700 MHz for example.

Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [[Bluetooth_powered_Multi-SIM_support | use another mobile via BT]].
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.
* Dual SIM card support will be especially welcome by the women. They just love to talk on the phone.
* Save the contents from several SIM-cards to memory and simulate them.

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

2 way talk over Sprint/Nextel/Boost networks if possible. At least the walkie talkie feature for sure. It's very annoying being at a lake with no service and can't call your friend in the other boat across the lake.

===[[DECT]]===
* Include a [[DECT]] GAP/CAT-iq transceiver so you can use your home and/or office PSTN line
** Ability to use Alcatel phonebook stuff (like provided by the eventphone.de phone equipment) would be very nice too

===[[SIP phone]]===
Make stripped down (and thus cheaper) version of the Neo1973 phone for use as a SIP phone. Remove GPS, GSM, accelerometers, stylus.

Addition of an centimeters-precise location system [http://en.wikipedia.org/wiki/Real_Time_Location_Systems RTLS] would be nice, as it will allow highly sensible indoor context detection. Imagine putting the phone next to your mirror (where you shave daily) and watch it automatically switch to news radio channel. Or put it next to your bed and see it automatically switch to "sleeping" mode, when only calls from predefined numbers are accepted.

=='''Casing'''==
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.

=== Generic Back Plate Connector ===
If the Neo had a few connectors below the back plate, it would be much easier to develop custom backplates. Connectors needed would be GND, Power-out, Power-in (for charging/expansion battery appliances), some bus (either USB or some other bus, maybe usb wouldn't be the best choice since having a backplate and an upstream connection at the same time might cause problems) and maybe some ID pins to discern battery/charger/generic expansion modules on hardware level
--[[User:DrDeath|DrDeath]] 10:39, 27 September 2008 (UTC)

=== [[Hardware:Neo1973:Alternate_Cases:Expansion_Module_Casing | Expansion Module Casing]] ===
Longer case (150-160mm+) with space in the top to put expansion modules, including test & hobby hardware. Would require use of a standard internal power & communications bus. Could be left empty with blank cover or house cameras, solar panels, a crank powered charger, special transmitters/recievers, or anything else imaginable.

[http://www.likeasecret.com/Neo1973/Neo1973-Exp.mov Neo1973 Expansion Module Quicktime rendering] 
[[Image:Neo1973-Exp.png]]

-mb make a bigger higher resolution screen and the hardware will still be the same size and the free runer bigger a in the free place make z sliding thing wich you would sell in many colour and if sb whants a camera hi can buy it in the sliding thing or he can just buy it blank for his own hard-ware this would be cool this sliding pice could have some cind of shape thet would fit and let you the most posibilities even you could make it covering some front of the phone so you could place a joystick and buttos in it. If you would need leds you would buy a blank cover drill it and it would be fine becous you wouldnt injury the mine case of the phone.

=== Expansion Back Casing ===
Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===[[Hardware:Neo1973:Alternate_Cases:Expansion_Front_Casing|Expansion Front Casing]]===
Replacement fronts with e.g. extra buttons.

===Clamshell Casing===
The clamshell form factor is much preferred by many in that: 1) it provides more area for both screen and keypad 2) its easier for one handed use, the buttons arent crammed in the bottom of the casing 3) clamshell open up to provide longer distance to cover both ear and mouth so you dont have to shout in noisy areas to be heard because the speaker is up on the side of your face 4) clamshells protect the screen from scratches

=== Space efficient Lanyard ===
The hole at the bottom of the phone takes a lot of space. A [http://en.wikipedia.org/wiki/Kensington_Security_Slot Kensington Security Slot] could be used instead.

=== Rugged version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display, maybe aluminium case. The big ugly pseudo military version. What about a casing similar to the OLPC project's in terms of dust and waterproofing? I frequently have to answer the phone with hands dripping sea water and most phone's do not take kindly to that type of treatment. Also the accelerometers can be wired to a protection mechanism which suspends all processing/data activity in case of a (free) fall.

*Seconded. Would get one at once. please IP68 and with rubber coating.
*I support this too. Might make more sense as an accessory which you can snap/peel onto your phone however?
*I'm eager to see a ruggedized version, maybe even floatable.
*+1. No point in having an excellent phone/PDA-device, if you can't take it with you where ever you may go. I think this might work as an optional accessory case design, as a previous contributor mentioned.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

That makes sense to me. I second that idea!
Me, too!
+1 :) i would buy one!

=== Blank ===
Even though the transparent case would work too, I would like to see a blank case of pure black or white so people could have the option of air-brushing,painting or even drawing on the case.

===Integrated solar charger===
Perhaps on one side there could be an integrated photovoltaic. It would be small, but might it be enough to charge the device. It could be integrated in an aesthetically pleasing fashion like [http://i.i.com.com/cnwk.1d/i/bto/20080523/solarboat.jpg this]... except, with a matching color. :)

===Custom look===
Provide a service which offers custom case design like [[Freerunner_Alternative_Case_Designs|this one]], see images below. Just upload two images, reposition them in an interactive website, submit credit card information and the custom case design with application manual will be shipped to you.

<gallery caption="Special casing" heights="100px">
Image:Special-casing-front.jpg|front
Image:Special-casing-back.jpg|back
</gallery>

==Misc==
===Battery Size/Standby Time===

Since the device will be ultimately running a wide selection of software on it the battery needs to be somewhat more robust and have a longer standby time than that of current phone's. At the moment I'm using a Moto (2 days before charging) or a Samsung (3 days before charging) and am not impressed with either phone's standby time, and I'm not using the phone's for anything but calls.

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea, particularly when it's intended to be a mobile-komputing device.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from (or at all) if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry. If 5V is detected on the power line, then the obvious place to get it from is there at any point in time.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

With the dedicated charger it would also be possible to use any standard USB device if
the phone recognized the external power and enabled 5v power when plugged in.

===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

=== GPS antena ===
The current GPS device seems even dependent on weather and may not work in heavy rain or snow. It seems necessary to think how to improve the reliability. The small portable GPS antena may be an option.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.
* Say you have RFID tags on your personal belongings: cellphone, keys... Neo could be programmed to remember the last recorded GPS location before it lost contact with the respective RFIDs. It'd be trivial to check where you left your cellphone, get directions from a map...or beep when the phone gets out of RFID range.

*I agree with this idea, a great idea and you have to do it (Jackcday)
*Or, a python script that use the accelerometers and rfid reader, so when the phone moves it checks for an rfid tag (that would be in the users pocket) and if it doesn't get a response it rings in full volume, or starts a tracking utility :))))
*A RFID reader would need an antenna loop which could probably be used for wireless docking or even charging
*connected RFID UHF Reader to the openmoko via USB Host Mode [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5612279 http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5612279]
* some hardware project is there: [[Freerunner_RFID_Board]]

===NFC chip===
*A Near Field Communication chip, with this chip it will be possible to pay with your phone (like a credit card)in the near future, see [http://www.nokia.com/A4305081 Nokia]for details
*NXP is a chip fabricator which provides NFC chips [http://nxp.com NXP] direct link>> www.nxp.com/#/pip/cb=[type=product,path=/53420/53424]|pip=[pfp=53424][0] their chips also support the above RFID reading

===Less weight===
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary "user" may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common business or multimedia phones.
{|border="1"
| Neo1973 || Fujitsu-Siemens LOOX N560 || E-Ten Glofiish X500+ || Sony Ericsson P990i || iPhone || Nokia E65
|-
| 184 g || 160 g || 146 g || 150 g || 135 g || 115 g
|-
|}

===Make it smaller===
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. A 2.5mm jack is the most common for headsets.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones. Adapters to 2.5mm are of course available and this 3.5mm jack is much more robust.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone. Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Software should know of the jack status===
It should be possible for the OS to see if there is something connected to the audio jacks. That would avoid the embarrasing moments when you accidently pull out the headphones from the cell/laptop and whatever you were listening blares over the place at full volume. If OS can see, that the headphones were unplugged without turning off the audio, then it could pop up a warning that would allow to direct audio to internal speakers or turn it off. If the user would replug the headphones/speakers then the warning would dissapear as well.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

Make it a green one <10mW so it won't be illegal in quite a few countries.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big color display.

=== Inductive Charger ===

It would be nice if it was possible to charge the phone without having to connect a cable. I'd like to have a simple docking station with an inductive charger like the type that's used for electric toothbrushes [http://home.howstuffworks.com/question292.htm ]. The charger itself could get its power from a standard wall-wart power supply, or it could be USB/Firewire powered.

==== Examples of existing commercial systems ====
* http://www.splashpower.com/

*might be combinable with a RFID reader

=== Solar panel/dynamo Charger===

It would be very nice to be able to charge the phone outside of the electric grid (for example on hikes and boating trips). A combined solar panel and muscle empowered (rotational etc.) charger would do the trick nicely.
* It might be possible to include a charger based on a step motor and an excentric weight, similar to automatic wrist watches. Charge by walking/running, if that wouldn't be cool...

'''some mobile Solarpanels'''

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01011&k_id=1400&hot=0 Off-Grid Systems Sunbag L]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01001&k_id=1400&hot=0 Off-Grid Systems Sunbag S]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01011&k_id=1400&hot=0 Silva Solar I]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01012&k_id=1400&hot=0 Silva Solar II]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sol01011&k_id=1400&hot=0 Solarc e-Go Professional] (link broken?)

[http://www.solarc.de/shop/product_info.php?info=p32_e-GO--Professional.html Solarc e-Go Professional] manufacturers page

[http://www.heise.de/mobil/suche/ergebnis?rm=result;q=solar;url=/mobil/artikel/74142/;words=solar Solarc e-Go *]

[http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Solar%20solar;q=solar;url=/newsticker/meldung/91536/ Solar JKT]

- I think a dynamo charger ("share charger", rotational, ...) would be more practical as a peripheral, connected through the USB-interface using the same principle cellphones now charge when connected to an USB-port. You could very easily hack this together. [http://www.metacafe.com/watch/449950/hack_a_flashlight_to_power_your/ flashlight recharge hack] Random thought; Why not create some merchandise toys with a small lithium battery which charge through centrifugal force allowing to recharge the phone with a small "general" connector.

[http://www.heise.de/mobil/artikel/61368/0 Article about aome mobile power-sources]

=== Plastic Solar/Back side on the Neo===

Solar cells from Plastic, on the reverse side of the Neo 1973
modified and introgreated in the battery backcover/flap,
like an energy source when the display is in standby mode.
Thats can be use also as alternate charge method's and also helps in emergency.

http://www.nanosolar.com/

=== Vibration===
Instead of using a counter-weighted motor to provide a vibrate function, a small solenoid could be used.It would provide more of a tap or click feel. It could be used to provide feedback when a on screen button is pressed. Different patterns of taps is a lot easier to recognize compared to different vibration frequencies. For those who know morse code they could have the phone tap out the phone number/name of the person calling/messaging or other alerts.

===As plug-in without screen...===

Along the lines of add-on cards, only looking at it from a different angle, I'd like to see a "faceless" openmoko with a documented hardware interface for both communicating with it and inserting it into other devices. Even the keypad/screen/battery would be attached, openmoko itself would just be faceless sliver of hardware with a documented interface and an API for communicating with the innards.

===Running without battery===
Please make it possible to run the device without a battery inserted (with the charger attached). I have several mobile phones which do not work anymore (even when attached to the charger) because the battery is worn out and new batteries are not available. I want the Openmoko to be usable when the battery is worn out.

* Seconded.

===Make GSM/CDMA/WiFi/WiMax/GPS plugable===
Please make Openmoko mobile as PC GSM/CDMA/... just working like plugable cards, they are cards/adaptor for the DEVICE only. the user may eject GSM module and inject with CDMA module. the DEVICE may provide several slot to allow user choose wifi/wimax/sd/gps/harddisk/...

===Wifi chip that can be used with kismet and other sniffers===
Please change the wifi chip that also can be used for sniffing wifi connection preferably the latest standard, not N. For pen testing. A wifi chips like the [http://www.ralinktech.com/ralink/data/RT2800.pdf RT2800] I think?

===Add a connector for an external Wifi aerial===
PLease can a an external aerial connector be added so better arials can be used useful for sniffing wifi connections for pen testing etc.

==Related Hardware==
See [[Related Hardware]]

[[Category:Hardware ideas| ]]

Freerunner RFID Board

2011-04-05T18:19:54Z

Hns: /* Features */

Freerunner RFID Board

2011-04-05T18:18:28Z

Hns: /* Documentation */

Freerunner RFID Board

2011-04-05T18:14:47Z

Hns: New page: thumb NOTE: This is work in progress and quite incomplete =Features= The FRIDB realizes an experimental platform for RFID (13.56 MHz)....

Freerunner Navigation Board v2

2011-04-05T17:59:15Z

Hns: /* Documentation */

The second version of the [[Freerunner Navigation Board]] includes lots of new stuff to play with, while still providing the same feature set as the first version.

[[Image:FRNBv2TopBottom.JPG|Freerunner Navigation Board v2|thumb]]

=Features=

The FRNBv2 realizes all features from the first version on the top side of the PCB. The bottom side is all about further expansion. Most of these chips are not very usable without connecting additional electronics to them. I'll add detailed descriptions of what I did with them to this page.

==Top side==
===3D Gyroscope ITG-3200 ===
The new ITG-3200 digital gyroscope detects rotations and measures their angular velocity. This enables the FR to be used as game controller or to improve navigation capabilities without GPS.

===3D Magnetometer HMC5843===
A magnetometer senses magnetic fields. It can be used as compass for navigation purposes or to sense fields from other magnetic sources.

===Air pressure/temperature sensor: BMP085===
A pressure sensor can be used for weather forecast or to measure the height above sea level if the pressure at sea level is known.
If the height is known from other sources (e.g. GPS), the change in ambient pressure can be used to detect weather changes. This may be useful for gliding.

==Bottom side==
===4ch Programmable LED Controller PCA9632===
This chip can source or sink current for up to four LEDs with a maximum of 25mA per LED. In addition to simple on/off states it can be programmed to blink or dim individual channels or a group of channels. Since the chip does everything on its own, it will continue to work even if the host cpu suspends. This allows the often requested feature <del>to drain the battery even faster</del> to notify users of incoming SMS or missed phone calls by blinking a LED even if the phone is suspended. A blink frequency down to once every 10 seconds and a widely adjustable duty cycle allows for very short flashes to save battery power.

===1kHz – 68MHz Programmable oscillator LTC6904===
This is, well, a programmable oscillator from which one frequency output and the output enable pin are available at testpoints. My intention was to use it as 38kHz oscillator to generate the carrier frequency of common infrared remote controls. The output enable can be connected to a GPIO. After implementing a small driver, this should work as a generic remote control solution using lirc.

===12 bit Analog to Digital Converter ADS1015===
This is similar to the chip which was used on the FRNBv1 to digitize analog gyroscope outputs. It provides only 12 instead of 16 bits of resolution, but this should be enough for most applications. The FRNBv2 does not use it for own purposes, so it is completely under user's control.

===Touch Sensor MPR121===
The MPR121 from Freescale Semiconductor is a multi channel proximity capacitive touch sensor controller. Up to twelve sensor areas could be connected, but due to space restrictions, only seven channels are accessible at solder pads.
It is not guaranteed that the chip will work as intended, but I think it's worth to test it.
The Datasheet can be found [http://www.freescale.com/files/sensors/doc/data_sheet/MPR121.pdf here].

===Expansion pads===
The supply voltage as well as the I2C bus is routed to testpads at the end of the board. These enable easy further expansion with more I2C devices (e.g. a [[I2C_Humidity_Sensor|digital humidity sensor]])

=Documentation=
Schematic and board layout files are available in CadSoft EAGLE 5.x format from http://chonyota.net/freerunner/FRNBv2/

==Pinout==
[[Image:FRNBv2-Pinout.jpg|Pinout: Bottom side, Top side|thumb]]
[[Image:I2C-testpoints.png|I2C testpoints|thumb]]
* '''VCC''': +3.3V, available at the AUX-Switch
* '''GND''': Ground, available from the (big) decoupling capacitor next to the accelerometer
* '''SCL''', '''SDA''': Serial clock and data, get it from testpoints at the debug connector
* '''OE''': Output enable from the frequency generator. Pull this pin high to enable the CLK output
* '''CLK''': Clock output from the frequency generator.
* '''LED controller 0-3''': LED current sinks. Connect LEDs in series with current limiting resistors from VCC to these pads.
* '''12-Bit A/D 0-3''': Analog to digital converter inputs. They can operate single ended or differencial. The reference voltage is VCC.
* '''Touch electrodes 0-6''': Connect these pads to a larger conducting area to use it as touch sensor. The inputs 0-3 can also be used to drive LEDs. Refer to the datasheet for more information.

[[Image:FRNBv2-top.JPG|Top side with the BMP085|thumb]]
[[Image:FRNBv2-bottom.JPG|Bottom side with PCA9632 and LTC6904. The LED controller works :)|thumb]]

==Installation==
===Hardware installation===
The best way to connect the FRNBv2 to your Freerunner is to solder four wires to the VCC, GND, SCL and SDA pads at the top side of the board. SDA and SCL are available at test points next to the debug connector. VCC is accessible at the AUX switch. GND is available from the big decoupling capacitor below the backup battery.

The FRNBv2 can be mounted into the free space below the GPS connector. I would reccomend to apply some adhesive tape to the GPS connector and the metallic cover on the main pcb. It prohibits short circuits which cause damage to the Freerunner or the FRNBv2.

Here is a PDF with an overview of the [http://chonyota.net/freerunner/FRNBv2/FRNBv2-Installation.pdf Installation].

===Software installation===
Boot your OS and run

i2cdetect 0

It should display a table with all I2C adresses for which a device is connected to your Freerunner:
(TODO: example)

You should find all adresses listed below.

==Test Status==
The first PCBs arrived and allows to test single features. The progress will be documented here.

{| border="1"
!Chip !! I²C address !! Test Result !! Notes
|-
|ITG3200 || 0x69 || ok || driver usable but still incomplete
|-
|HMC5843 || 0x1E || ok || driver should to degauss sensor to ensure proper operation
|-
|BMP085 || 0x77 || ok
|-
|PCA9632 || 0x60 || ok
|-
|LTC6904 || 0x17 || ok || works with 15pF cap between SCL and SDA (NOR boot fix)
|-
|ADS1015 || 0x40 || ok || kernel driver incomplete. Userspace driver incomplete
|-
|MPR121 || 0x5A || ok || works, hackish driver available
|}

==Issues==
'''Known HW or SW Issues'''

* LTC6904
: The frequency generator LTC6904 consumes about 0.5mA even if the outputs are turned off. This is not a real bug but it would be nice to turn the chip off while unused. A small modification should make it possible to use one output from the LED controller to control the power.

: The chip works with the NOR-Boot fix described below.
: <del>Reading exactly two bytes from the LTC6904 causes the I2C bus to lock up. The stop condition is not sent correctly and the master does not stop generating a clock. The chip works fine when programmed with a MSP430 microcontroller. Therefore either the Linux driver or the Samsung SoC (or both) are causing the bug. I'll try to resolve this, but I'm quite busy with other stuff. If someone wants to help, please contact me.</del>

* ITG3200
: <del>Use *50V* 2.2nF capacitor for C5.</del> fixed.

* General
: <del>NOR-Boot does not work if the FRNBv2 is connected.</del> If you need the NOR boot only as emergency recovery, hold your finger onto the I2C-SCL pad (pay attention to ESD!) or connect the debug board cable (no need to connect the real board, the cable is enough) to "fix" the issue.

: Of course, this issue can be fixed permanently with an additional capacitor ;-) Solder a 15pF cap between SDA and SCL. A 0402 sized capacitor fits easily onto the test points at the edge of the board.

==Software==
===Kernel drivers===
[http://gitorious.org/freerunner-navigation-board This gitorious page] lists all currently available drivers for the FRNBv2. The kernel drivers for the BMP085 and the HMC5843 are already upstream and will be shipped with kernel 2.6.36. All other drivers need some cleanup and more documentation to be accepted. I will try to get this done. If you're bored and want to help, please do so!

====Bugs====
The compass driver reports wrong values. The latest patch swaps MSB and LSB. Now it returns more meaningful values. There may be more bugs left. For reference you may have a look at another driver which is already upstream: [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/iio/magnetometer/hmc5843.c;h=92f6c6fb90fee13e89a9d23bd109e0e1e152094c;hb=b4e178224cfdc8aae7dda0baab34a4e4110a2e93 hmc5843.c]
bvg

===Userspace software===
====SensMon====
The [[SensMon|sensor-monitor]] is an excellent application to test the different sensors. Alternatively cat and echo can be used to communicate with them. Right now the interfaces to userspace lack some documentation. Either look at the source code or ask me if you are in trouble.

====Barom====
This program provides altitude or weather information on Neo Freerunners with bmp085 pressure sensors installed. The bmp085 is available as part of the Freerunner Navigation Board. Source code and binaries can be found [http://jeepingben.homelinux.net/barom here].

====ValaCompass====
[[ValaCompass]] is a minimalistic 3D compass application written in Vala that displays the North direction considering the pitch and roll orientation of the handheld.

=Availability=
The [http://handheld-linux.com handheld-linux.com] team kindly offered to retail the FRNBv2. You can find it [http://www.handheld-linux.com/wiki.php?page=Navigation%20Board here].

Two assembly options are available:
* Complete: everything you (possibly) want. Contains all chips as described above.
* Standard: contains everything except the frequency generator and the analog to digital converter.

Possible packaging options:
* CAB: Completely assembled board. Just add some wires and you're ready
* DIY: Do it yourself! The PCB and all components needed to get your hands dirty
* PCB: The bare PCB. You are free to buy only what you need.

Right now, only the CAB boards can be ordered online. If you just want the PCB and/or a few parts, contact me or the nice staff at handheld-linux.com.

= User Reports =

Please write to the discussion page.

[[Category:Neo FreeRunner reworks and mods]]

Main Page

2011-02-25T05:50:48Z

Hns:

{{Languages|Main Page}}__NOTOC__
__NOEDITSECTION__[[Image:Neo front 3.gif|right]]
<div style="padding: 2.5ex; text-align: center; font: bold x-large sans">Openmoko™ - Open. Mobile. Free.</div>
'''Openmoko™''' is a project dedicated to delivering mobile phones with an open source software stack. Openmoko was earlier more directly associated with Openmoko Inc, but is nowadays a gathering of people with the shared goal of "Free Your Phone". Distributors are currently selling updated versions of the Openmoko Inc's phone released in 2008, [[Neo FreeRunner]], to advanced users, while the software stack for FreeRunner and future free phones is being developed by the community.

* [[Introduction]]
* [[Why Openmoko|Why Openmoko?]]

[[More Information]]

===Get Involved===
Openmoko is a project driven by a community of passionate and intelligent volunteers. If you have the ability, please contribute to our cause. Openmoko's ambitions far exceed the resources available.

* [[Community Resources]]
* [[Gta02-core|Create a new hardware revision of the gta02 hardware]] with completely free software tools for the hardware creation
* [[GTA04|Follow the ”GTA04” project by Golden Delicious Computers]]
* [[Create User Manuals]] for [[Distributions]] and [[Applications]]
* Enhance the multi-device multi-vendor [[FSO]] middleware.

===How To Purchase===
The Neo FreeRunner is sold by various [[distributors]] around the world.

See [[Getting Openmoko]] for more information.

----

====Latest News====

{{News}}
[[News Archive|more news...]]

----
Problems with this Site or a List? http://admin-trac.openmoko.org/trac
----

[[Category:Community| ]]
[[Category:Categories| ]]

FOSDEM 2011

2011-02-08T15:08:33Z

Hns: /* Pictures */

= FOSDEM 2011 =

Date: Saturday 5 and Sunday 6 February 2011

Unfortunately the request for a dedicated Devroom was declined.
So let's collect interesting talks and attendents. I.e. create sort of a "Visitors Guide".

The official FOSDEM agenda is here: http://www.fosdem.org/2011/

For reference, here is the page from last year: [[Fosdem_2010]]

= Main Talks =
tbd.

= Lightning Talks =
tbd.

= Stands =

Openmoko can share booth space at the http://hackable-devices.org/ booth, which sports open projects like Makerbot, Milkymist, Watts'nzCity, or Shruthi-1. You can find the tables in the H building. Contact wim or john @hackable-devices.org for more.

= Devrooms =

* Embedded: http://lists.fosdem.org/pipermail/fosdem/2010-December/001098.html
* Open Source Telephony: http://lists.fosdem.org/pipermail/fosdem/2010-November/001058.html

= Hardware fixes =
Is there anyone around who can do the buzz (and optionally the other) fixes on my FreeRunner?

:: I probably could help here, if someone brings equipment (solder iron, tweezers, ..) and needed parts.
:: --[[User:Cmair|Cmair]] 17:32, 2 February 2011 (UTC)

= Visitors =
Yes, I will be there

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
! '''Who''' !! '''Saturday''' !! '''Sunday''' !! '''Comment''
|-
| [[User:Hns]] || x || x || Will try to show a running GTA04 at the Hackable Devices stand
|-
| [[aSThRo/ Openmoko-fr.org]] || || x || Meet friends, watch some good confs, fix some phones @ noon on HackableDevice stand...
|-
| [[user:boudewijn]] || x || || Meet OM'ers, enjoy the weekend, helping a hand
|-
| [[user:wvdputte]] || x || x || booth bunny and logistic
|-
| [[user:nightlybuild]] || x || x || booth bunny and logistic
|-
| [[user:cmair]] || x || x || Enjoy the weekend, discuss open phones, watch great talks ...
|-
| [[User:GNUtoo]] || x || x || Will have some devices running SHR(htc dream,nokia N900, openmoko freerunner...)
|-
| [[User:Janvlug|Jan Vlug]] || || x || Hoping to get my Freerunner fixed...
|-
|}

= Pictures =
* http://download.goldelico.com/gta04/images/20110204%20FOSDEM/
* http://chonyota.net/freerunner/FOSDEM11/
* http://www.tuxbrain.com/en/content/bruselas-europes-capital

[[Category:Community]]

FOSDEM 2011

2011-02-07T17:14:22Z

Hns: /* Visitors */

FOSDEM 2011

2011-01-31T20:12:33Z

Hns: /* Visitors */

= FOSDEM 2011 =

Date: Saturday 5 and Sunday 6 February 2011

Unfortunately the request for a dedicated Devroom was declined.
So let's collect interesting talks and attendents. I.e. create sort of a "Visitors Guide".

The official FOSDEM agenda is here: http://www.fosdem.org/2011/

For reference, here is the page from last year: [[Fosdem_2010]]

= Main Talks =
tbd.

= Lightning Talks =
tbd.

= Stands =

Openmoko can share booth space at the http://hackable-devices.org/ booth, which sports open projects like Makerbot, Milkymist, Watts'nzCity, or Shruthi-1. You can find the tables in the H building. Contact wim or john @hackable-devices.org for more.

= Devrooms =

* Embedded: http://lists.fosdem.org/pipermail/fosdem/2010-December/001098.html
* Open Source Telephony: http://lists.fosdem.org/pipermail/fosdem/2010-November/001058.html

= Hardware fixes =
Is there anyone around who can do the buzz (and optionally the other) fixes on my FreeRunner?

= Visitors =
Yes, I will be there

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
! '''Who''' !! '''Saturday''' !! '''Sunday''' !! '''Comment''
|-
| [[User:Hns]] || x || x || Will try to show a running GTA04 at the Hackable Devices stand
|-
| [[aSThRo/ Openmoko-fr.org]] || x || || Meet friends, watch some good confs, fix some phones?...
|-
| [[user:boudewijn]] || x || || Meet OM'ers, enjoy the weekend, helping a hand
|-
| [[user:wvdputte]] || x || x || booth bunny and logistic
|-
| [[user:nightlybuild]] || x || x || booth bunny and logistic
|-
| [[user:cmair]] || x || x || Enjoy the weekend, discuss open phones, watch great talks ...
|-
|}

[[Category:Community]]

GTA04

2011-01-25T17:51:10Z

Hns:

{{Speculations}}
'''News:'''
* There is a new mailing list dedicated to the early adopters of this project: http://lists.goldelico.com/mailman/listinfo/gta04-owner
* general discussions should be continued on the Openmoko Community lists: http://lists.openmoko.org/mailman/listinfo/community

----

The codename '''GTA04''' was picked up in 2010 by Golden Delicious Computers to develop a new motherboard for our open smartphone that follows the original idea and goals.

== GTA04A3 (Early Adopter) ==
Which to expect? A new motherboard, that replaces the one inside your Neo1973/Freerunner. It will reuse the case, the battery and the display. It is known as GTA04A3 (Early Adopter) and its feature might be:

* TI OMAP 3530 DCBB (600/720/; maybe DM3730 with 1GHz) (compatible to [http://www.beagleboard.org])
** integrated graphics - POWERVR SGX Graphics Accelerator of OMAP3530
* Micron DDR/NAND PoP Memory
* Option GTM601W UMTS module
* Wi2Wi WLAN/Bluetooth module + antenna
* GPS module + antenna switch
* LIS302 (accelerometer)
* LSM303 (compass and accelerometer)
* ITG3200 (gyroscope)
* BMP085 (barometric altimeter)
* Si4721 (FM transceiver)

Development samples are scheduled to become available around FOSDEM 2011.

There is a new project page: http://www.gta04.org, which houses the wiki specific to the GTA04 project at Golden Delicious.

An early adopter program is available at: http://www.handheld-linux.com/wiki.php?page=GTA04-Early-Adopter

== History ==

=== Year 2011: Golden Delicious Computers Openmoko Beagle Hybrid GTA04 ===
Golden Delicious Computers has been secretly working on a OMAP3530 based project that apparently has the same target as Openmoko's GTA04 did have. The first result was announced in 2010 [[Openmoko Beagle Hybrid]] aka GTA04A1.

The next GTA04 was the result of integrating that all onto a single PCB aka GTA04A2.

=== Year 2008: Openmoko Inc. GTA04 ===
'''GTA04''' was the codename of a phone that was whose development was canceled (within Openmoko, Inc.). For more information about other phones in development, visit [[Phone Development]]. This phone would have been based on a different system-on-a-chip.

==== GTA04 specifications ====
The GTA04 would have been a [[GTA03]] but with a major hardware revision

New:
* USB 2.0 would be added on the GTA04 at the earliest
* 3G would be added on the GTA04 at the earliest
* Based on a more advanced SoC
* maybe based on the samsung 6400 or 6410
* integrated graphics
* Sean put a hiring on the community and devel list, see [http://lists.openmoko.org/pipermail/community/2008-September/029710.html here] so there will be OpenGL Es and the 6410 eventually
* there had been meetings in April 2008 within Openmoko - see [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002310.html]

[[Category:GTA04| ]]

GTA04

2010-12-22T14:58:39Z

Hns:

{{Speculations}}

The codename '''GTA04''' was apparently picked up in 2010 by Golden Delicious Computers to develop a new open smartphone that follows the original idea and goals.

Although there isn't much information yet, which features can we expect?

* TI OMAP3530 (compatible to [http://www.beagleboard.org])
* 3G (UMTS, HSPA)
* integrated graphics - POWERVR SGX Graphics Accelerator of OMAP3530
* GPS
* WLAN, Bluetooth
* FM Transceiver
* Accelerometer, Compass, Barometer, Gyroscope
* full OTG (High-Speed USB 2.0 with Client & Host mode)
* camera (optional)
* new motherboard that fits into existing Freerunner case

Available: in 2011

There is a new project page: http://www.gta04.org

Early Adopter Program: http://www.handheld-linux.com/wiki.php?page=GTA04-Early-Adopter

== History ==
'''GTA04''' was the codename of a phone that was whose development was canceled (within Openmoko, Inc.). For more information about other phones in development, visit [[Phone Development]]. This phone would have been based on a different system-on-a-chip.

=== GTA04 specifications ===
The GTA04 would have been a [[GTA03]] but with a major hardware revision

New:
* USB 2.0 would be added on the GTA04 at the earliest
* 3G would be added on the GTA04 at the earliest
* Based on a more advanced SoC
* maybe based on the samsung 6400 or 6410
* integrated graphics
* Sean put a hiring on the community and devel list, see [http://lists.openmoko.org/pipermail/community/2008-September/029710.html here] so there will be OpenGL Es and the 6410 eventually
* there had been meetings in April 2008 within Openmoko - see [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002310.html]

[[Category:GTA04]]

=== Openmoko Beagle Hybrid ===
Golden Delicious Computers has been secretly working on a OMAP3530 based project that apparently has the same target as Openmoko's GTA04 did have. The first result was announced in 2010 [[Openmoko Beagle Hybrid]].

The "new" GTA04 is the result of integrating that all onto a single PCB.

GTA04

2010-12-21T14:47:11Z

Hns:

{{Speculations}}

The codename '''GTA04''' was apparently picked up in 2010 by Golden Delicious Computers to develop a new open smartphone that follows the original idea and goals.

Although there isn't much information yet, which features can we expect?

* TI OMAP3530 (compatible to [http://www.beagleboard.org])
* 3G (UMTS, HSPA)
* integrated graphics - POWERVR SGX Graphics Accelerator of OMAP3530
* GPS
* WLAN, Bluetooth
* FM Transceiver
* Accelerometer, Compass, Barometer, Gyroscope
* full OTG (High-Speed USB 2.0 with Client & Host mode)
* camera (optional)
* new motherboard that fits into existing Freerunner case

Available: in 2011

There is a new project page: http://projects.goldelico.com/p/gta04-main/

Early Adopter Program: http://www.handheld-linux.com/wiki.php?page=GTA04-Early-Adopter

== History ==
'''GTA04''' was the codename of a phone that was whose development was canceled (within Openmoko, Inc.). For more information about other phones in development, visit [[Phone Development]]. This phone would have been based on a different system-on-a-chip.

=== GTA04 specifications ===
The GTA04 would have been a [[GTA03]] but with a major hardware revision

New:
* USB 2.0 would be added on the GTA04 at the earliest
* 3G would be added on the GTA04 at the earliest
* Based on a more advanced SoC
* maybe based on the samsung 6400 or 6410
* integrated graphics
* Sean put a hiring on the community and devel list, see [http://lists.openmoko.org/pipermail/community/2008-September/029710.html here] so there will be OpenGL Es and the 6410 eventually
* there had been meetings in April 2008 within Openmoko - see [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002310.html]

[[Category:GTA04]]

=== Openmoko Beagle Hybrid ===
Golden Delicious Computers has been secretly working on a OMAP3530 based project that apparently has the same target as Openmoko's GTA04 did have. The first result was announced in 2010 [[Openmoko Beagle Hybrid]].

The "new" GTA04 is the result of integrating that all onto a single PCB.

Community Updates/2011-02-01

2010-12-14T11:49:50Z

Hns: /* Event News */

{{Improve}}
{{Note|
*Take a moment and look at [[Talk:Community_Updates/Draft|this page]] to get a clue on how to contribute to Community Updates while following OM wiki editing guidelines please.
*I you are planning longer edition, please use <nowiki>{{Editing|your_username_here|date_here|editing_summary_here}}tag. Remember to remove/comment out it right after you save your work.</nowiki>
*Please fill in everything you think the community should know.
*On YYYY-MM-DD this content should be _moved_ to http://wiki.openmoko.org/wiki/Community_Updates/YYYY-MM-DD, feel free to do it.
*Post the CU release also on the community mailing list, since some people prefer to read news directly there. Regarding this, it helps copy-pasting from browser page to mailing list post if relevant URLs are included as is in addition to having linked parts of text (if in hurry you can also just post a note that CU is readable on web page).
}}



====='''Period 2010-12-01 to 2010-12-31'''=====

==Distributions==
=Updated Distributions=
{{DistributionBox|
Name=QtMoko [v30]|
Description= Qtmoko is debian+qtopia based distribution for Freerunner. This is a minor update, the changelog is very short:

* fixed headset jack detection
* Danish translations (Ole Carlsen)
* GPRS fix (Timo Juhani Lindfors)
* battery_platform for dumb batteries as module
* force GPS power up on resume (Gennady Kupava)
Known Problems:
*SD-card corruption due to some problems with KMS-patches in v30 kernel|
Screenshot=Qtmokomain.png|
Codename='v30'|
Homepage=http://www.qtmoko.org|
Image=[http://sourceforge.net/projects/qtmoko/files/Experimental/ images]|
Works={{Works_on_QtMoko}}
}}

{{DistributionBox|
Name=SHR-testing RC1|
Description= The image is based on the 2010.12 release of OpenEmbedded and has latest
versions of E, SHR and FSO apps.

Since last testing a lot has changed:
* Switch to illume2 as illume(1) isn't maintained anymore
* Switch from ogsmd to much faster fsogsmd
* Switch to 2.6.34 kernel (without KMS because this causes some problems with SD-cards for some SHR-u users)
* Everything faster ;)
* And much more i don't remember

Known Bugs:
* There is a problem with the autostart of applications in E, because of that the shr_elm_softkey is not always started.
* The wizard is only working if you wait until FSO is fully started (When FSO is started the display started dimming). If you don't want to wait that long you can exit the wizard with the "Exit" button and do the configurations in shr-settings afterwards.

Untested:
* All feed packages not in the full image.
* All day usage (so GPRS/GPS after several suspends)

Read the full announcement here: http://lists.openmoko.org/pipermail/community/2010-December/063895.html
|
Screenshot=SHR-Logo.png|
Codename='RC1'|
Homepage=http://wiki.shr-project.org|
Image=[http://build.shr-project.org/tests/shr-testing/images/om-gta02/ download]|
Works={{Works_on_SHR}}
}}

=New Distributions =
{{DistributionBox|
Name=Distro Name [version]|
Description=Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.Here comes some additional text to show you guys, how Template:DistributionBox will behave under heavy load of text. It is copied several times on purpose. This way you can see how layout would looke like if description of distribution is very complex or expanded.|
Screenshot=System_boot.png|
Codename='codename'|
Homepage=http://www.homepage.org|
Image=[http://www.homepage.org/path/to/ images]|
Works={{Works}}
}}

==Applications==

===New Applications===

{{ApplicationBox|
Name=Exampleapp 0.0.1|
Description=Exampleapp 0.0.1 is an application to do some stuff..|
Screenshot=System_boot.png|
Homepage=http://wiki.openmoko.org/|
TestedOn=SHR-Unstable,Om2009T5|
PackageName=[http:// www.some.srv/path_to/Exampleapp.ipk Exampleapp]
}}

===Application Updates===

{{ApplicationBox|
Name=Exampleapp 0.0.1|
Description=Exampleapp 0.0.1 is an application to do some stuff...
* new example feature 1
* new example feature 2|
Screenshot=System_boot.png|
Homepage=http://wiki.openmoko.org/|
TestedOn=SHR-Unstable,Om2009T5|
PackageName=[http:// www.some.srv/path_to/Exampleapp.ipk Exampleapp]
}}

==General News==

Most important and change making mails on the mailing lists, blogs etc.. Coolest hacks, screenshots, themes etc..

==Event News==

* '''2011-01-24''' Mobile FOSS MiniConf at LCA2011 announced a [http://mobilefoss.jamespurser.com.au/Call_For_Papers call for papers] that closes on Friday 22nd October 2010. So submit something about OpenMoko today!

* '''2011-02-05/06''' [[Fosdem_2011]] visitors guide for Openmoko related topics started

* '''2010-mm-dd''' [http://example.url.xom Example event] | add your event here

[[Category:Community Update]]

FOSDEM 2011

2010-12-09T17:01:06Z

Hns: /* Visitors */

= FOSDEM 2011 =
Unfortunately the request for a dedicated Devroom was declined.
So let's collect interesting talks and attendents. I.e. create sort of a "Visitors Guide".

The official FOSDEM agenda is here: http://www.fosdem.org/2011/

For reference, here is the page from last year: [[Fosdem_2010]]

= Main Talks =
tbd.

= Lightning Talks =
tbd.

= Stands =

Makerbot?
OpenEmbedded?

= Devrooms =

* Embedded: http://lists.fosdem.org/pipermail/fosdem/2010-December/001098.html
* Open Source Telephony: http://lists.fosdem.org/pipermail/fosdem/2010-November/001058.html

= Visitors =
Yes, I will be there

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
! '''Who''' !! '''Saturday''' !! '''Sunday''' !! '''Comment''
|-
| [[User:Hns]] || x || x || Trying to give a Lightning Talk or Embedded Devroom Talk
|-
|}

FOSDEM 2011

2010-12-09T17:00:49Z

Hns: /* Visitors */

= FOSDEM 2011 =
Unfortunately the request for a dedicated Devroom was declined.
So let's collect interesting talks and attendents. I.e. create sort of a "Visitors Guide".

The official FOSDEM agenda is here: http://www.fosdem.org/2011/

For reference, here is the page from last year: [[Fosdem_2010]]

= Main Talks =
tbd.

= Lightning Talks =
tbd.

= Stands =

Makerbot?
OpenEmbedded?

= Devrooms =

* Embedded: http://lists.fosdem.org/pipermail/fosdem/2010-December/001098.html
* Open Source Telephony: http://lists.fosdem.org/pipermail/fosdem/2010-November/001058.html

= Visitors =
Yes, I will be there

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
! '''Who''' !! '''Saturday''' !! '''Sunday''' !! '''Comment''
|-
| [User:Hns]] || x || x || Trying to give a Lightning Talk or Embedded Devroom Talk
|-
|}

FOSDEM 2011

2010-12-09T17:00:00Z

Hns: New page: = FOSDEM 2011 = Unfortunately the request for a dedicated Devroom was declined. So let's collect interesting talks and attendents. I.e. create sort of a "Visitors Guide". The official FOS...

Open HW SW Event/de

2010-12-04T09:41:07Z

Hns: /* Vortrags- und Schulungsmaterial */

= Erstes deutsches Open-HW&SW-Event =
== Zusammenfassung ==
* Ort: Amalienstr. 17, 80333 München
* Datum: 4. und 5. Dezember 2010 (zweiter Advent)
* Uhrzeit: 9:30 - ca. 18:30
* Workshops/Vorträge: siehe Agenda
* Mailingliste: http://lists.goldelico.com/mailman/listinfo/open-hard-software-event
* Live-Stream: http://www.ustream.tv/channel/oshw-workshop

== Note to English Speakers ==
It will be ok if you give your presentation in English, but discussions and other activities will be in German. So please decide yourself if you can follow German discussions well enough that you can take something home. The event is not thought just to be a stage for presentations, but for working together (discussions, workshops, having lunch&fun).

= Beschreibung =

Auf verschiedenen Treffen und Diskussionen ist immer wieder die Frage aufgetaucht, ob sich nicht mal alle an offenen Phones und Plattformen Interessierten (d.h. nicht nur die Openmoko-Fans) einen gemeinsamen Workshop/Treffen/Event irgendwo treffen können. Denn auf anderen Events wie [[http://www.fosdem.org FOSDEM]] oder [[http://www.linuxtag.org LinuxTag]] ist alles so groß und unüberschaubar, daß irgendwie zu wenig Austausch (Diskussion, Kennenlernen) stattfindet.

== Themen ==
Und zwar könnte es um alles rund um Projekte für offene Hardware und Software gehen. Themen könnten sein (ohne Anspruch auf Vollständigkeit):
* [[Openmoko]]
* [http://www.arduino.cc Arduino]
* [http://en.qi-hardware.com/wiki/Ben_NanoNote Nanonote]
* [http://openpandora.org OpenPandora]
* [[Freerunner Navigation Board v2]]
* [http://beagleboard.org BeagleBoard]
* [[SHR]]
* [[QtMoko]]
* [[FSO]]

Deshalb haben wir das neulich auf dem Forum www.freeyourophone.org in Angriff genommen: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794
Dabei entstand eine Meinungsumfrage die großes Interesse und Themenvielfalt zeigte: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794&hilit=event&start=15

Wer teilnehmen möchte und/oder etwas vortragen bitte auf der Mailingliste registrieren und Wünsche äußern.

== Ort ==
Wir haben nun einen Veranstaltungsort gefunden:

Ludwig-Maximilians-Universität München
LFE Medieninformatik
Amalienstr. 17
80333 München
http://www.medien.ifi.lmu.de
[http://maps.google.de/maps?f=q&hl=de&geocode=&time=&date=&ttype=&q=amalienstr.+17+m%C3%BCnchen&ie=UTF8&hq=&hnear=Amalienstra%C3%9Fe+17,+M%C3%BCnchen+80333+M%C3%BCnchen,+Bayern&ll=48.147053,11.576141&spn=0.000771,0.000923&t=h&z=20 Google Maps], [http://www.nucleo.com.es/maps/ inkl. Raumübersicht], [http://www.openstreetmap.org/?lat=48.14677&lon=11.576166&zoom=18&layers=M OSM]

Es stehen zwei Seminarräume (A105 und A107) sowie ein kleinerer Raum (A103) zur Verfügung. Außerdem können wir den Gang davor nutzen.

==== Kapazität ====
* '''A105''': 20-30 Zuhörer (mit Tischen) bis max 50 (ohne Tische), oder 8 Tische mit je 2-4 Bastlern
* '''A107''': 15-20 Zuhörer (mit Tischen) bis max. 30 (ohne Tische), oder 5 Tische mit je 2-4 Bastlern
* '''A103''': ruhiger Arbeitsraum für max. 5 Personen

Außerdem können wir noch max. 3 Tische mit je 1-2 Bastlern im Gang an die Wand stellen.

Maximalkapazitäten sind wirklich maximal :)

== Zeit ==

Es gab 18 Voranmeldungen (auf http://www.doodle.com/93cu86vm2s69zsxc) und das Wochenende des 4. Dezembers hat als Rekord 17 Teilnehmer erbracht. Daher haben wir die Räume für diesen Termin reserviert.

== Agenda ==

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Samstag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| Sa || 09:30-10:00 || alle || Vorstellrunde und Kennenlernen || 30 min || falls jemand zu knapp eintrifft
|-
| Sa || || || || || Projekte
|-
| Sa || 10:00-11:30 || [[User:Cmair]], [[User:MicVM]], Alexander Lehmann || Vortrag || 90 min || Vorstellung des [[FRNBv2]], Grundlagen inertialer Navigation
(Precision und Accuracy, Fehlerquellen, Sampling Frequency, Sensorbandbreite, SNR (Signal to Noise Ratio), Gyro-Integration / Rotationsreihenfolge / Euler vs. Quats, Quadratischer Fehler bei der Positionsbestimmung (Demo), Schwellwert, (Gleitender) Mittelwert, Tiefpass, Kalman)
|-
| Sa || 11:30-12:30 || Evil Dragon || Vortrag || 60 min || Evil Dragon ein Entwickler der Pandora wird in diesem Vortrag über die bewegende Geschichte der Pandora (http://www.openpandora.de) erzählen
|-
| Sa || 12:30-13:15 || Dieter Spaar || Vortrag || 45 min || OsmocomBB, der Open Source GSM Stack (http://bb.osmocom.org/trac/)
|-
| Sa || 13:15-14:15 || || Pause || 60 min ||
|-
| Sa || 14:15-15:15 || [[User:Hns]] || Vortrag, Demo || 60 min || 1. Der OMAP-Board-Zoo - ein kleiner Überblick und Starthilfe
2. [[Openmoko Beagle Hybrid]] - oder wie stopft man ein neue CPU (OMAP3) in einen Freerunner?
|-
| Sa || || || || || Grundlagen
|-
| Sa || 15:15-16:45 || Jörg Eesmann || Vortrag || 90 min || Microcontroller (nicht nur AVR), Einführung in Interfaces ( CAN, I2S, SPI, PWM, ADC, Interrupts (Prioritaeten, Nesting...), Echtzeitsysteme, Reaktionszeiten, Prioritaetsinversion)
|-
| Sa || 16:45-17:45 || Florian Boor || Vortrag, Demo || 60 min || Einführung in Open Embedded (wie installiere, konfiguriere ich mein eigenes Image oder meine Distribution)
|-
| Sa || 17:45-18:45 || Mickey Lauer || Vortrag || 60 min || Einführung in [[FSO]]
|}

 

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Sonntag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| So || || || || || parallele Workshops
|-
| So || 09:30-12:30 || [[User:Cmair]] || Workshop || 3h (180 min) || [[FRNBv2]]: Lötsession HW & SW Integration
Freerunner und evtl. Lötkolben mitbringen!

Mögliche Themen:
* Wie schreibe ich einen Kerneltreiber für I2C-Geräte?
* Hands-on-Sensors: Experimente mit Kompass, Gyroskop und Luftdruckmesser
* Wir bauen mit dem FRNBv2 eine IR Fernbedienung.
* ...
|-
| So || 11:00-13:00 || Juergen Neumann || Vortrag / Workshop || 120 min || OHANDA - Open Source Hardware and Design Alliance - Ready to register? http://www.ohanda.org
Kurze Vorstellung der Idee und des Status Quo. Diskussion und ggf. Ausarbeitung der nächsten Schritte.
|-
| So || ca. 13:00 || || individuelle Pause || || in Absprache mit den Workshopteilnehmern
|-
| So || 13:00-17:00 || ? Mickey Lauer, [[User:Cmair]] || ? Workshop || || Vorschlag: Code-Sprint für FRNB-Integration in FSO
|-
| So || 13:00-18:00 || Rene Leitner || Workshop || 5 h (300 min) || SDL Für Einsteiger. Du wolltest schon immer anfangen zu programmieren, hast aber nie den Weg dazu gefunden. Du möchtest gerne wissen wie du mit C/C++ und SDL ein kleines Spiel Programmieren kannst? In diesen Workshop werden all deine Fragen versucht zu beantworten, von C bis SDL wird alles Anfänger freundlich erklärt und diskutiert, um am Ende des Tages ein kleines Spiel programmiert zu haben.

Bringt bitte euren Rechner mit, das Betriebssystem ist egal. Wenn ihr schon was vorbereiten möchtet dann ladet euch das folgende runter:
Linux Ubuntu:
sudo apt-get install build-essential codeblocks

Windows:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05mingw-setup.exe

MacOS:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05-p1-mac.dmg

Falls ihr ein anders OS nutzt, schaut bitte hier:
http://www.codeblocks.org/downloads
|-
|}

= Vortrags- und Schulungsmaterial =
Die Vorträge können direkt hier in das Wiki hochgeladen werden. Verwendet dazu einfach diesen [[Special:Upload|Upload]]-Link und benutzt in der Tabelle den Dateinamen in einem ''Media''-Link. Der erste Eintrag in der Tabelle demonstriert das beispielhaft. ''Media''-Links auf noch nicht hochgeladene Objekte führen automatisch zu einem Uploadformular.

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Vortrag/Workshop'''
|- bgcolor="#c0e0e0"
| align="center" | '''Referent(en)'''
| align="center" | '''Name der Session'''
| align="center" | '''Material'''
|-
|''Anton Beispiel''
|''Zeigen wie es geht''
|[[Media:Beispieldokument.pdf|PDF]]
|-
|[[User:Cmair]], [[User:MicVM]], Alexander Lehmann
|Vorstellung des [[FRNBv2]]
|
[http://chonyota.net/freerunner/OpenMoko_Vortrag.pdf]
[http://chonyota.net/freerunner/FRNB-History.pdf]
|-
|[[User:Cmair]]
|[[FRNBv2]]: Lötsession HW & SW Integration
|
|-
|Evil Dragon
|Entwicklung der Pandora
|
|-
|Florian Boor
|Einführung in OpenEmbedded
|
|-
|Mickey Lauer
|Einführung in [[FSO]]
|[http://www.linuxtogo.org/~mickeyl/misc/Einstieg-in-FSO.pdf]
|-
|[[User:Hns]]
|Überblick und Starthilfe zum Texas Instruments-Hardwarezoo
|[http://download.goldelico.com/default/Presentations/20101204_OMAP-Zoo.pdf]
|-
|[[User:Hns]]
|[[Openmoko Beagle Hybrid]] - neue CPU in einen Freerunner
|[http://download.goldelico.com/default/Presentations/20101204_Openmoko_Beagle_Hybrid.pdf]
|-
|Jörg Eesmann
|Microcontroller (nicht nur AVR)
|
|-
|Dieter Spaar
|[http://bb.osmocom.org/trac/ OsmocomBB] - der Open Source GSM Stack
|
|-
|Juergen Neumann
|OHANDA - Open Source Hardware and Design Alliance - Ready to register?
|
|-
|Mickey Lauer(?), [[User:Cmair]]
|Vorschlag: Code-Sprint für FRNB-Integration in FSO
|
|-
|Rene Leitner
|SDL Für Einsteiger
|
|}

= Mailingliste / Anmeldungen =
Fragen, Anregungen, Kritik bitte die Mailingliste http://lists.goldelico.com/mailman/listinfo/open-hard-software-event schreiben.

Außerdem sollten sich alle (potenziellen) Teilnehmer dort anmelden um eventuelle Änderungen mitzubekommen.

Open HW SW Event/de

2010-12-03T16:26:15Z

Hns: /* Agenda */

= Erstes deutsches Open-HW&SW-Event =
== Zusammenfassung ==
* Ort: Amalienstr. 17, 80333 München
* Datum: 4. und 5. Dezember 2010 (zweiter Advent)
* Uhrzeit: 9:30 - ca. 18:30
* Workshops/Vorträge: siehe Agenda
* Mailingliste: http://lists.goldelico.com/mailman/listinfo/open-hard-software-event

== Note to English Speakers ==
It will be ok if you give your presentation in English, but discussions and other activities will be in German. So please decide yourself if you can follow German discussions well enough that you can take something home. The event is not thought just to be a stage for presentations, but for working together (discussions, workshops, having lunch&fun).

= Beschreibung =

Auf verschiedenen Treffen und Diskussionen ist immer wieder die Frage aufgetaucht, ob sich nicht mal alle an offenen Phones und Plattformen Interessierten (d.h. nicht nur die Openmoko-Fans) einen gemeinsamen Workshop/Treffen/Event irgendwo treffen können. Denn auf anderen Events wie [[http://www.fosdem.org FOSDEM]] oder [[http://www.linuxtag.org LinuxTag]] ist alles so groß und unüberschaubar, daß irgendwie zu wenig Austausch (Diskussion, Kennenlernen) stattfindet.

== Themen ==
Und zwar könnte es um alles rund um Projekte für offene Hardware und Software gehen. Themen könnten sein (ohne Anspruch auf Vollständigkeit):
* [[Openmoko]]
* [http://www.arduino.cc Arduino]
* [http://en.qi-hardware.com/wiki/Ben_NanoNote Nanonote]
* [http://openpandora.org OpenPandora]
* [[Freerunner Navigation Board v2]]
* [http://beagleboard.org BeagleBoard]
* [[SHR]]
* [[QtMoko]]
* [[FSO]]

Deshalb haben wir das neulich auf dem Forum www.freeyourophone.org in Angriff genommen: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794
Dabei entstand eine Meinungsumfrage die großes Interesse und Themenvielfalt zeigte: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794&hilit=event&start=15

Wer teilnehmen möchte und/oder etwas vortragen bitte auf der Mailingliste registrieren und Wünsche äußern.

== Ort ==
Wir haben nun einen Veranstaltungsort gefunden:

Ludwig-Maximilians-Universität München
LFE Medieninformatik
Amalienstr. 17
80333 München
http://www.medien.ifi.lmu.de
[http://maps.google.de/maps?f=q&hl=de&geocode=&time=&date=&ttype=&q=amalienstr.+17+m%C3%BCnchen&ie=UTF8&hq=&hnear=Amalienstra%C3%9Fe+17,+M%C3%BCnchen+80333+M%C3%BCnchen,+Bayern&ll=48.147053,11.576141&spn=0.000771,0.000923&t=h&z=20 Google Maps], [http://www.nucleo.com.es/maps/ inkl. Raumübersicht], [http://www.openstreetmap.org/?lat=48.14677&lon=11.576166&zoom=18&layers=M OSM]

Es stehen zwei Seminarräume (A105 und A107) sowie ein kleinerer Raum (A103) zur Verfügung. Außerdem können wir den Gang davor nutzen.

==== Kapazität ====
* '''A105''': 20-30 Zuhörer (mit Tischen) bis max 50 (ohne Tische), oder 8 Tische mit je 2-4 Bastlern
* '''A107''': 15-20 Zuhörer (mit Tischen) bis max. 30 (ohne Tische), oder 5 Tische mit je 2-4 Bastlern
* '''A103''': ruhiger Arbeitsraum für max. 5 Personen

Außerdem können wir noch max. 3 Tische mit je 1-2 Bastlern im Gang an die Wand stellen.

Maximalkapazitäten sind wirklich maximal :)

== Zeit ==

Es gab 18 Voranmeldungen (auf http://www.doodle.com/93cu86vm2s69zsxc) und das Wochenende des 4. Dezembers hat als Rekord 17 Teilnehmer erbracht. Daher haben wir die Räume für diesen Termin reserviert.

== Agenda ==

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Samstag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| Sa || 09:30-10:00 || alle || Vorstellrunde und Kennenlernen || 30 min || falls jemand zu knapp eintrifft
|-
| Sa || || || || || Projekte
|-
| Sa || 10:00-11:30 || [[User:Cmair]], [[User:MicVM]], Alexander Lehmann || Vortrag || 90 min || Vorstellung des [[FRNBv2]], Grundlagen inertialer Navigation
(Precision und Accuracy, Fehlerquellen, Sampling Frequency, Sensorbandbreite, SNR (Signal to Noise Ratio), Gyro-Integration / Rotationsreihenfolge / Euler vs. Quats, Quadratischer Fehler bei der Positionsbestimmung (Demo), Schwellwert, (Gleitender) Mittelwert, Tiefpass, Kalman)
|-
| Sa || 11:30-12:30 || Evil Dragon || Vortrag || 60 min || Evil Dragon ein Entwickler der Pandora wird in diesem Vortrag über die bewegende Geschichte der Pandora (http://www.openpandora.de) erzählen
|-
| Sa || 12:30-13:15 || Dieter Spaar || Vortrag || 45 min || OsmocomBB, der Open Source GSM Stack (http://bb.osmocom.org/trac/)
|-
| Sa || 13:15-14:15 || || Pause || 60 min ||
|-
| Sa || 14:15-15:15 || [[User:Hns]] || Vortrag, Demo || 60 min || 1. Der OMAP-Board-Zoo - ein kleiner Überblick und Starthilfe
2. [[Openmoko Beagle Hybrid]] - oder wie stopft man ein neue CPU (OMAP3) in einen Freerunner?
|-
| Sa || || || || || Grundlagen
|-
| Sa || 15:15-16:45 || Jörg Eesmann || Vortrag || 90 min || Microcontroller (nicht nur AVR), Einführung in Interfaces ( CAN, I2S, SPI, PWM, ADC, Interrupts (Prioritaeten, Nesting...), Echtzeitsysteme, Reaktionszeiten, Prioritaetsinversion)
|-
| Sa || 16:45-17:45 || Florian Boor || Vortrag, Demo || 60 min || Einführung in Open Embedded (wie installiere, konfiguriere ich mein eigenes Image oder meine Distribution)
|-
| Sa || 17:45-18:45 || Mickey Lauer || Vortrag || 60 min || Einführung in [[FSO]]
|}

 

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Sonntag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| So || || || || || parallele Workshops
|-
| So || 09:30-12:30 || [[User:Cmair]] || Workshop || 3h (180 min) || [[FRNBv2]]: Lötsession HW & SW Integration
Freerunner und evtl. Lötkolben mitbringen!

Mögliche Themen:
* Wie schreibe ich einen Kerneltreiber für I2C-Geräte?
* Hands-on-Sensors: Experimente mit Kompass, Gyroskop und Luftdruckmesser
* Wir bauen mit dem FRNBv2 eine IR Fernbedienung.
* ...
|-
| So || 11:00-13:00 || Juergen Neumann || Vortrag / Workshop || 120 min || OHANDA - Open Source Hardware and Design Alliance - Ready to register? http://www.ohanda.org
Kurze Vorstellung der Idee und des Status Quo. Diskussion und ggf. Ausarbeitung der nächsten Schritte.
|-
| So || ca. 13:00 || || individuelle Pause || || in Absprache mit den Workshopteilnehmern
|-
| So || 13:00-17:00 || ? Mickey Lauer, [[User:Cmair]] || ? Workshop || || Vorschlag: Code-Sprint für FRNB-Integration in FSO
|-
| So || 13:00-18:00 || Rene Leitner || Workshop || 5 h (300 min) || SDL Für Einsteiger. Du wolltest schon immer anfangen zu programmieren, hast aber nie den Weg dazu gefunden. Du möchtest gerne wissen wie du mit C/C++ und SDL ein kleines Spiel Programmieren kannst? In diesen Workshop werden all deine Fragen versucht zu beantworten, von C bis SDL wird alles Anfänger freundlich erklärt und diskutiert, um am Ende des Tages ein kleines Spiel programmiert zu haben.

Bringt bitte euren Rechner mit, das Betriebssystem ist egal. Wenn ihr schon was vorbereiten möchtet dann ladet euch das folgende runter:
Linux Ubuntu:
sudo apt-get install build-essential codeblocks

Windows:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05mingw-setup.exe

MacOS:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05-p1-mac.dmg

Falls ihr ein anders OS nutzt, schaut bitte hier:
http://www.codeblocks.org/downloads
|-
|}

= Vortrags- und Schulungsmaterial =
Die Vorträge können direkt hier in das Wiki hochgeladen werden. Verwendet dazu einfach diesen [[Special:Upload|Upload]]-Link und benutzt in der Tabelle den Dateinamen in einem ''Media''-Link. Der erste Eintrag in der Tabelle demonstriert das beispielhaft. ''Media''-Links auf noch nicht hochgeladene Objekte führen automatisch zu einem Uploadformular.

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Vortrag/Workshop'''
|- bgcolor="#c0e0e0"
| align="center" | '''Referent(en)'''
| align="center" | '''Name der Session'''
| align="center" | '''Material'''
|-
|''Anton Beispiel''
|''Zeigen wie es geht''
|[[Media:Beispieldokument.pdf|PDF]]
|-
|[[User:Cmair]], [[User:MicVM]], Alexander Lehmann
|Vorstellung des [[FRNBv2]]
|
|-
|[[User:Cmair]]
|[[FRNBv2]]: Lötsession HW & SW Integration
|
|-
|Evil Dragon
|Entwicklung der Pandora
|
|-
|Florian Boor
|Einführung in OpenEmbedded
|
|-
|Mickey Lauer
|Einführung in [[FSO]]
|
|-
|[[User:Hns]]
|Überblick und Starthilfe zum Texas Instruments-Hardwarezoo
|
|-
|[[User:Hns]]
|[[Openmoko Beagle Hybrid]] - neue CPU in einen Freerunner
|
|-
|Jörg Eesmann
|Microcontroller (nicht nur AVR)
|
|-
|Dieter Spaar
|[http://bb.osmocom.org/trac/ OsmocomBB] - der Open Source GSM Stack
|
|-
|Juergen Neumann
|OHANDA - Open Source Hardware and Design Alliance - Ready to register?
|
|-
|Mickey Lauer(?), [[User:Cmair]]
|Vorschlag: Code-Sprint für FRNB-Integration in FSO
|
|-
|Rene Leitner
|SDL Für Einsteiger
|
|}

= Mailingliste / Anmeldungen =
Fragen, Anregungen, Kritik bitte die Mailingliste http://lists.goldelico.com/mailman/listinfo/open-hard-software-event schreiben.

Außerdem sollten sich alle (potenziellen) Teilnehmer dort anmelden um eventuelle Änderungen mitzubekommen.

Open HW SW Event/de

2010-12-03T16:19:56Z

Hns: /* Agenda */

= Erstes deutsches Open-HW&SW-Event =
== Zusammenfassung ==
* Ort: Amalienstr. 17, 80333 München
* Datum: 4. und 5. Dezember 2010 (zweiter Advent)
* Uhrzeit: 9:30 - ca. 18:30
* Workshops/Vorträge: siehe Agenda
* Mailingliste: http://lists.goldelico.com/mailman/listinfo/open-hard-software-event

== Note to English Speakers ==
It will be ok if you give your presentation in English, but discussions and other activities will be in German. So please decide yourself if you can follow German discussions well enough that you can take something home. The event is not thought just to be a stage for presentations, but for working together (discussions, workshops, having lunch&fun).

= Beschreibung =

Auf verschiedenen Treffen und Diskussionen ist immer wieder die Frage aufgetaucht, ob sich nicht mal alle an offenen Phones und Plattformen Interessierten (d.h. nicht nur die Openmoko-Fans) einen gemeinsamen Workshop/Treffen/Event irgendwo treffen können. Denn auf anderen Events wie [[http://www.fosdem.org FOSDEM]] oder [[http://www.linuxtag.org LinuxTag]] ist alles so groß und unüberschaubar, daß irgendwie zu wenig Austausch (Diskussion, Kennenlernen) stattfindet.

== Themen ==
Und zwar könnte es um alles rund um Projekte für offene Hardware und Software gehen. Themen könnten sein (ohne Anspruch auf Vollständigkeit):
* [[Openmoko]]
* [http://www.arduino.cc Arduino]
* [http://en.qi-hardware.com/wiki/Ben_NanoNote Nanonote]
* [http://openpandora.org OpenPandora]
* [[Freerunner Navigation Board v2]]
* [http://beagleboard.org BeagleBoard]
* [[SHR]]
* [[QtMoko]]
* [[FSO]]

Deshalb haben wir das neulich auf dem Forum www.freeyourophone.org in Angriff genommen: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794
Dabei entstand eine Meinungsumfrage die großes Interesse und Themenvielfalt zeigte: http://freeyourphone.de/portal_v1/viewtopic.php?f=71&t=1794&hilit=event&start=15

Wer teilnehmen möchte und/oder etwas vortragen bitte auf der Mailingliste registrieren und Wünsche äußern.

== Ort ==
Wir haben nun einen Veranstaltungsort gefunden:

Ludwig-Maximilians-Universität München
LFE Medieninformatik
Amalienstr. 17
80333 München
http://www.medien.ifi.lmu.de
[http://maps.google.de/maps?f=q&hl=de&geocode=&time=&date=&ttype=&q=amalienstr.+17+m%C3%BCnchen&ie=UTF8&hq=&hnear=Amalienstra%C3%9Fe+17,+M%C3%BCnchen+80333+M%C3%BCnchen,+Bayern&ll=48.147053,11.576141&spn=0.000771,0.000923&t=h&z=20 Google Maps], [http://www.nucleo.com.es/maps/ inkl. Raumübersicht], [http://www.openstreetmap.org/?lat=48.14677&lon=11.576166&zoom=18&layers=M OSM]

Es stehen zwei Seminarräume (A105 und A107) sowie ein kleinerer Raum (A103) zur Verfügung. Außerdem können wir den Gang davor nutzen.

==== Kapazität ====
* '''A105''': 20-30 Zuhörer (mit Tischen) bis max 50 (ohne Tische), oder 8 Tische mit je 2-4 Bastlern
* '''A107''': 15-20 Zuhörer (mit Tischen) bis max. 30 (ohne Tische), oder 5 Tische mit je 2-4 Bastlern
* '''A103''': ruhiger Arbeitsraum für max. 5 Personen

Außerdem können wir noch max. 3 Tische mit je 1-2 Bastlern im Gang an die Wand stellen.

Maximalkapazitäten sind wirklich maximal :)

== Zeit ==

Es gab 18 Voranmeldungen (auf http://www.doodle.com/93cu86vm2s69zsxc) und das Wochenende des 4. Dezembers hat als Rekord 17 Teilnehmer erbracht. Daher haben wir die Räume für diesen Termin reserviert.

== Agenda ==
Es wird ein Mischung aus (Plenar-)Vorträgen und Workshops/Hands-On-Sessions geben. Eventuell am ersten Tag Vorträge für alle, so dass jeder alle Themen kennenlernen kann und dann am zweiten Tag an 2-3 Workshops teilnehmen.

Weitere Vorschläge für Referenten (und Themen) sind willkommen. Bitte einfach auf der Mailingliste anmelden und neue Themen vorschlagen.

Die Liste hier ist noch vorläufig und wird bis zum Workshop laufend angepaßt. Also bitte immer wieder reinschauen.

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Samstag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| Sa || 09:30-10:00 || alle || Vorstellrunde und Kennenlernen || 30 min || falls jemand zu knapp eintrifft
|-
| Sa || || || || || Projekte
|-
| Sa || 10:00-11:30 || [[User:Cmair]], [[User:MicVM]], Alexander Lehmann || Vortrag || 90 min || Vorstellung des [[FRNBv2]], Grundlagen inertialer Navigation
(Precision und Accuracy, Fehlerquellen, Sampling Frequency, Sensorbandbreite, SNR (Signal to Noise Ratio), Gyro-Integration / Rotationsreihenfolge / Euler vs. Quats, Quadratischer Fehler bei der Positionsbestimmung (Demo), Schwellwert, (Gleitender) Mittelwert, Tiefpass, Kalman)
|-
| Sa || 11:30-12:30 || Evil Dragon || Vortrag || 60 min || Evil Dragon ein Entwickler der Pandora wird in diesem Vortrag über die bewegende Geschichte der Pandora (http://www.openpandora.de) erzählen
|-
| Sa || 12:30-13:15 || Dieter Spaar || Vortrag || 45 min || OsmocomBB, der Open Source GSM Stack (http://bb.osmocom.org/trac/)
|-
| Sa || 13:15-14:15 || || Pause || 60 min ||
|-
| Sa || 14:15-15:15 || [[User:Hns]] || Vortrag, Demo || 60 min || 1. Der OMAP-Board-Zoo - ein kleiner Überblick und Starthilfe
2. [[Openmoko Beagle Hybrid]] - oder wie stopft man ein neue CPU (OMAP3) in einen Freerunner?
|-
| Sa || || || || || Grundlagen
|-
| Sa || 15:15-16:45 || Jörg Eesmann || Vortrag || 90 min || Microcontroller (nicht nur AVR), Einführung in Interfaces ( CAN, I2S, SPI, PWM, ADC, Interrupts (Prioritaeten, Nesting...), Echtzeitsysteme, Reaktionszeiten, Prioritaetsinversion)
|-
| Sa || 16:45-17:45 || Florian Boor || Vortrag, Demo || 60 min || Einführung in Open Embedded (wie installiere, konfiguriere ich mein eigenes Image oder meine Distribution)
|-
| Sa || 17:45-18:45 || Mickey Lauer || Vortrag || 60 min || Einführung in [[FSO]]
|}

 

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Programm für Sonntag'''
! '''Tag''' !! '''Zeit''' !! '''Referent''' !! '''Art''' !! '''Zeitbedarf (inc. Diskussion)''' !! '''Thema'''
|-
| So || || || || || parallele Workshops
|-
| So || 09:30-12:30 || [[User:Cmair]] || Workshop || 3h (180 min) || [[FRNBv2]]: Lötsession HW & SW Integration
Freerunner und evtl. Lötkolben mitbringen!

Mögliche Themen:
* Wie schreibe ich einen Kerneltreiber für I2C-Geräte?
* Hands-on-Sensors: Experimente mit Kompass, Gyroskop und Luftdruckmesser
* Wir bauen mit dem FRNBv2 eine IR Fernbedienung.
* ...
|-
| So || 11:00-13:00 || Juergen Neumann || Vortrag / Workshop || 120 min || OHANDA - Open Source Hardware and Design Alliance - Ready to register? http://www.ohanda.org
Kurze Vorstellung der Idee und des Status Quo. Diskussion und ggf. Ausarbeitung der nächsten Schritte.
|-
| So || ca. 13:00 || || individuelle Pause || || in Absprache mit den Workshopteilnehmern
|-
| So || 13:00-17:00 || ? Mickey Lauer, [[User:Cmair]] || ? Workshop || || Vorschlag: Code-Sprint für FRNB-Integration in FSO
|-
| So || 13:00-18:00 || Rene Leitner || Workshop || 5 h (300 min) || SDL Für Einsteiger. Du wolltest schon immer anfangen zu programmieren, hast aber nie den Weg dazu gefunden. Du möchtest gerne wissen wie du mit C/C++ und SDL ein kleines Spiel Programmieren kannst? In diesen Workshop werden all deine Fragen versucht zu beantworten, von C bis SDL wird alles Anfänger freundlich erklärt und diskutiert, um am Ende des Tages ein kleines Spiel programmiert zu haben.

Bringt bitte euren Rechner mit, das Betriebssystem ist egal. Wenn ihr schon was vorbereiten möchtet dann ladet euch das folgende runter:
Linux Ubuntu:
sudo apt-get install build-essential codeblocks

Windows:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05mingw-setup.exe

MacOS:
http://prdownload.berlios.de/codeblocks/codeblocks-10.05-p1-mac.dmg

Falls ihr ein anders OS nutzt, schaut bitte hier:
http://www.codeblocks.org/downloads
|-
|}

= Vortrags- und Schulungsmaterial =
Die Vorträge können direkt hier in das Wiki hochgeladen werden. Verwendet dazu einfach diesen [[Special:Upload|Upload]]-Link und benutzt in der Tabelle den Dateinamen in einem ''Media''-Link. Der erste Eintrag in der Tabelle demonstriert das beispielhaft. ''Media''-Links auf noch nicht hochgeladene Objekte führen automatisch zu einem Uploadformular.

{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Vortrag/Workshop'''
|- bgcolor="#c0e0e0"
| align="center" | '''Referent(en)'''
| align="center" | '''Name der Session'''
| align="center" | '''Material'''
|-
|''Anton Beispiel''
|''Zeigen wie es geht''
|[[Media:Beispieldokument.pdf|PDF]]
|-
|[[User:Cmair]], [[User:MicVM]], Alexander Lehmann
|Vorstellung des [[FRNBv2]]
|
|-
|[[User:Cmair]]
|[[FRNBv2]]: Lötsession HW & SW Integration
|
|-
|Evil Dragon
|Entwicklung der Pandora
|
|-
|Florian Boor
|Einführung in OpenEmbedded
|
|-
|Mickey Lauer
|Einführung in [[FSO]]
|
|-
|[[User:Hns]]
|Überblick und Starthilfe zum Texas Instruments-Hardwarezoo
|
|-
|[[User:Hns]]
|[[Openmoko Beagle Hybrid]] - neue CPU in einen Freerunner
|
|-
|Jörg Eesmann
|Microcontroller (nicht nur AVR)
|
|-
|Dieter Spaar
|[http://bb.osmocom.org/trac/ OsmocomBB] - der Open Source GSM Stack
|
|-
|Juergen Neumann
|OHANDA - Open Source Hardware and Design Alliance - Ready to register?
|
|-
|Mickey Lauer(?), [[User:Cmair]]
|Vorschlag: Code-Sprint für FRNB-Integration in FSO
|
|-
|Rene Leitner
|SDL Für Einsteiger
|
|}

= Mailingliste / Anmeldungen =
Fragen, Anregungen, Kritik bitte die Mailingliste http://lists.goldelico.com/mailman/listinfo/open-hard-software-event schreiben.

Außerdem sollten sich alle (potenziellen) Teilnehmer dort anmelden um eventuelle Änderungen mitzubekommen.