Openmoko - User contributions [en]

Wiki design suggestions

2008-12-06T08:33:33Z

Emesee: started.. just some thoughts - nice skin already... but... is anything really perfect?

This is brain storming on how to improve the look and feel of the OpenMoko wiki. Some of this may be subjective; different people have different tastes. Ideally however, if we can change the design in a way that we all find aesthetically pleasing to a greater degree, then perhaps we have both made the world a little more pleasant to see, and also improved the brand capital of OpenMoko.

==Suggestions==
* Increase the default font size in edit boxes.
* Make the font size just a hair bigger on the sidebar - less than any more than a bit
* perhaps increase the bottom margins of the boxes on the left by just a hair...
** or maybe try removing the boxes, or just having a vertical line on the right...

OpenMoko

2008-11-23T23:54:19Z

Emesee: Redirecting to Main Page

#REDIRECT [[Main Page]]

Daemon

2008-11-10T22:44:49Z

Emesee: Redirecting to Daemons

#REDIRECT [[Daemons]]

Daemons

2008-11-10T22:44:08Z

Emesee: started

The following are daemons for the OpenMoko platform.

* [[PyPhonelog]]

==External links==
* [http://en.wikipedia.org/wiki/Daemon_(computer_software) Daemon] (at Wikipedia)

User talk:Emesee

2008-11-10T20:53:19Z

Emesee:

[[Special:Recentchanges]]

User:Emesee

2008-10-12T19:56:16Z

Emesee: Removing all content from page

User:Emesee

2008-09-29T21:27:55Z

Emesee:

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Mokopedia]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

Could the free runner theoretically run Ubuntu? Practically?

==External links==
[[Image:SimpleComponentDiagram.jpg|500px|right|thumb]]
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] [http://wiki.laptop.org/go/User:Remi OLPC] 
</center>

http://www.appropedia.org/User:Remi

----

http://risto.kurppa.fi/blog/?p=226

Openmoko:Requested pages

2008-09-08T07:21:29Z

Emesee: started with minimal content...

[[State of the phones]] - Gives a simple user friendly synopsis of where things stand.

Wish List

2008-08-12T00:39:40Z

Emesee: /* Other */ "permission-free development" - this could go underdevelopment - but i'm not sure which subcategory of it..

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation ("apt-get install openmoko" as in [http://blog.leggewie.org/?p=39 apt-get'able Openembedded])
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

kd8ikt says a modded dialer with IAX/SIP (VOIP) or a stand alone VOIP client/dialer as an asterisk/FWD/IAXTEL/teliax stuff, i mainly just care about being able to connect to my own asterisk server in turn i can setup my asterisk server to route where ever i want i think one hardcore digium guy already ported iaxclient to arm so now i guess it needs a gui http://projects.openmoko.org/projects/mokoiax/ it wouldnt suprise me if underneath their UMA setup is a network of asterisk servers

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

==== Virtual picture viewer ====
I believe you could display pictures larger than the FR screen by using the accelerometer data to simulate the physical screen as a window into a larger pic.

You would use the accelerometer data to figure out the current FR location & orientation relative to when the pic was loaded, then display the part of the picture that the window overlaps. Then you could flick the neo back & forth and see an image bigger than the screen.

I haven't done any calculations to see what the accuracy would be like, but my wild ass guess is that if you moved it quickly enough it would overwhelm the error margin of the accelerometer. I'm also not sure if the refresh rate is fast enough to make it look good, but again my guess is that it would be.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant)
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other applications (GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).
* Id like the GPS location of the phone at the time the contact was made to be stored. This would be displayed along with a map of know n locations, eg, at hom on the train, at work.
* Id like the date I created a contact to be stored, and the ability to search by date. I know I put that estate agent in last saturday, but I cant remember his name!

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

===== Scientific Functions =====

For lab and desktop use. ln x / ex, sin x / cos x / tan x, statistical capabilities, etc. . .

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.) '''in openembedded'''

==== Interactive Sky Map ====
Application that displays the current sky map. Using GPS, the application determines the direction over ground
and rotates the map appropriately. Furthermore, when the phone is tilted, the map is also moved appropriately.
If everything works fine, you should have the impression that you can lift the phone over your head and
"look through" it and see the stars at the correct positions.

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

[http://www.freeswitch.org/ Freeswitch] is also well worth a look -- it's a project started by a long time contributor to Asterisk, and seems to be more scalable on similar hardware, so might well scale down to small hardware quite nicely.

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
[http://www.dcs.gla.ac.uk/~jhw/shoogle/index.html Shoogle] [http://www.dcs.gla.ac.uk/~jhw/audioclouds/ Audioclouds] [http://www.dcs.gla.ac.uk/~rod/dynamics.html Dynamics]

==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may not have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Tapping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.

==== "Spirit" Level ====
The accelerometers don't just detect movement, they also detect the direction of gravitational force. Because the sides of the case are straight, the phone could be used as a torpedo level to determine vertical plumb or horizontal level. The back is flat as well, allowing for two-axis leveling.

The phone should switch automatically between vertical, horizontal single axis (holding the side of the phone against the top of a beam) and horizontal dual-axis (laying the phone flat on a surface) modes.

Along the same lines, it could be used as a leveling protractor, to determine slope.

==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful. '''in openembedded'''

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

==== OpenRemote ====
Support an [http://openremote.org/ OpenRemote] controller interface.

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

=== Soft Sim Cloning ===

The ability to clone and store sim cards internally as soft sims and be able to switch between them would be handy. The sim cloning can be done on either the phone itself or on a computer and then transfered to the phone. Software already exists for sim cloning on PCs such as [http://www.download.com/GSM-SIM-Utility/3000-7242_4-10396246.html GSM SIM Utility 5.15]. It would pose a security risk if someone got their hands on your soft sims but it wouldn't be a problem if you were just soft siming pre paid cards and still using your hard sim slot for any contract sim cards.

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

====Phone subsidies====
Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

===="permission-free development"====
"Meanwhile, Shuttleworth said he hopes to see the industry move to an environment of "permission-free development," where developers are free to jump in and write code off of core open-source projects without seeking permissions." [http://www.eweek.com/c/a/Linux-and-Open-Source/Shuttleworth-Make-Desktop-Linux-Better-than-Apple/]

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
* '''GPS proxy''' - allowing other people to use and share GPS data from NEO over bluetooth {{Main|Wishlist:Software:GPS proxy}}
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== 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.

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 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.

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).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

: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.

===USB Monitor===
Have a few different models of monitors, maybe 7 inch, 14 in and 19 inches... be able to plug the Openmoko into one, and then use it like a desktop. Then be able to plug other peripherals into the monitor (keyboard, laser mouse, thumb drive, camera, etc.) and use those. Better yet, be able to use Bluetooth for the keyboard, mouse, thumb drive, camera, and so forth.

===Firefox Mobile UI===
Integrate the whole interface with this Firefox mobile concept: [http://azarask.in/blog/post/firefox-mobile-concept-video/]. 
Eg. Kernel->OS->Browser->Webapps/Dailer/Contacts.. 
More info om this concept here: FennecVision [http://wiki.mozilla.org/Mobile/FennecVision]

[[Category:User]]
[[Category:Ideas| ]]

User:Emesee

2008-07-20T04:29:28Z

Emesee: appropedia

User:Emesee

2008-07-05T22:22:26Z

Emesee: olpc

Wish List

2008-07-05T20:53:41Z

Emesee: /* USB Monitor */

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Taping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.
==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

====Phone subsidies====
Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== 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.

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 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.

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).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

: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.

===USB Monitor===
Have a few different models of monitors, maybe 7 inch, 14 in and 19 inches... be able to plug the Openmoko into one, and then use it like a desktop. Then be able to plug other peripherals into the monitor (keyboard, laser mouse, thumb drive, camera, etc.) and use those. Better yet, be able to use Bluetooth for the keyboard, mouse, thumb drive, camera, and so forth.

[[Category:User]]
[[Category:Ideas| ]]

Wish List

2008-07-05T20:52:47Z

Emesee: /* USB Monitor */

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Taping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.
==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

====Phone subsidies====
Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== 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.

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 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.

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).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

: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.

===USB Monitor===
Have a few different models of monitors, maybe 7 inch, 14 in and 19 inches... be able to plug the Openmoko into one, and then use it like a desktop. Then be able to plug other peripherals into the monitor (keyboard, laser mouse, thumb drive, camera, etc.) and use those.

[[Category:User]]
[[Category:Ideas| ]]

Wish List

2008-07-05T20:51:56Z

Emesee: /* Hardware */ USB monitor with peripheral support

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Taping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.
==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

====Phone subsidies====
Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== 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.

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 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.

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).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

: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.

===USB Monitor===
Have a couple monitors, maybe 7 inch, 14 in and 19 inches... be able to plug the Openmoko into it, and then use it like a desktop. Then be able to plug other peripherals into the monitor (keyboard, laser mouse, thumb drive, camera, etc.). (is this currently technologically feasible?)

[[Category:User]]
[[Category:Ideas| ]]

Wish List

2008-07-05T20:49:03Z

Emesee: /* Other */ phone subsidies.. Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Taping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.
==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

====Phone subsidies====
Get carriers to give you an Openmoko like they will give away other phones when you sign a contract.

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== 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.

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 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.

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).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

: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.

[[Category:User]]
[[Category:Ideas| ]]

Talk:Input Method

2008-07-05T04:24:30Z

Emesee: R

== A method from pocket pc ==

I've tried using this:
http://www.spbsoftwarehouse.com/products/fsk/screenshots.html

It works quite well. [[User:EsbenDamgaard|EsbenDamgaard]] 15:17, 21 March 2007 (CET)

== A method from Agenda VR3 ==

The [http://www.agendawiki.com Agenda VR3] was a linux-based PDA, also with no keyboard. Their solution was to provide an onscreen keyboard, but in addition to the A/a/1 buttons to have a button that opened up a pad for handwriting recognition. Early versions used something called 'scribble' but later versions used [http://www.hellkvist.org/software/ XMerlin]. So that might be an interesting idea.

== Some ideas ==

What about to use fonts for the Input metod? is it hard?
I think that the widget-keyboard could be dynamic.
Connect the input with the orphographic vocabulary,
so 5 most probable letters will have bigger area( enough for the finger)
(fonts are scalable sometimes)
As a transparent widget was shown,the bigger-letters can be on the background
of the whole keyboard - each letter on its place.
And you can find a little place for the button with the most probable word
(may be form with variants).

Maybe a landscape QWERTY-Keyboard with one preview text-line would be the best to input text. - maybe later as a transparent version without the textline...

The keyboard should use the accelerometers to automatically detect if a standard or landscape keyboard should be used.
Plus, I think that a "tab" key is really usefull when writing in a terminal, so I think it should be placed near the space key (left side).

== Handwriting ==

[http://wiki.openmoko.org/wiki/User:KlaymenDK KlaymenDK] says: I don't want to mess things up, so I keep to the Talk page. Here's my issue:
This page seems to be the only one even mentioning handwriting. The article page states that the Input Method Widget supports "''both handwriting recognition, and keyboards''", yet the rest of the article seems to not discuss handwriting ''at all''.

I propose creating a section called "Handwriting" to contain this topic.

Being a happy user of a Palm T3 with TealScript, I am quite fond of using the stylus for text input, especially in the "write everywhere" mode where one can use the entire screen as an input area.

I believe that handwriting is worthy of consideration because:
* IMVHO, it is the most ''efficient method for fast input on small devices''.
* It is ''agnostic of keyboard layouts and special language variants'' (I use Norwegian Dvorak).
* It ''consumes no screen real estate'' at all!
* It ''does not preclude the use of an ad-hoc on-screen keyboard''.
* It can be used without a stylus (just use a fingernail).

As I see it, there are two main issues:
# '''Is the OpenMoko actually capable of supporting online handwriting recognition?''' Here I mean in terms of processing power and real-time stroke resolution. This is a fundamental and technical aspect I have no way of answering.
# '''Are there any legal blocks to using handwriting recognition?''' It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://tomoe.sourceforge.jp Tomoe], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]). My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm TealScript]) holds any patents on ''user-configurable'' strokes.

Another issue could be '''how to actually integrate the handwriting mode into the user interface'''. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).

== Keyboard ==

Can a keyboard be hooked up to the FreeRunner? [[User:Emesee|Emesee]] 04:23, 5 July 2008 (UTC)

Talk:Input Method

2008-07-05T04:23:09Z

Emesee: /* Keyboard */ new section

== A method from pocket pc ==

I've tried using this:
http://www.spbsoftwarehouse.com/products/fsk/screenshots.html

It works quite well. [[User:EsbenDamgaard|EsbenDamgaard]] 15:17, 21 March 2007 (CET)

== A method from Agenda VR3 ==

The [http://www.agendawiki.com Agenda VR3] was a linux-based PDA, also with no keyboard. Their solution was to provide an onscreen keyboard, but in addition to the A/a/1 buttons to have a button that opened up a pad for handwriting recognition. Early versions used something called 'scribble' but later versions used [http://www.hellkvist.org/software/ XMerlin]. So that might be an interesting idea.

== Some ideas ==

What about to use fonts for the Input metod? is it hard?
I think that the widget-keyboard could be dynamic.
Connect the input with the orphographic vocabulary,
so 5 most probable letters will have bigger area( enough for the finger)
(fonts are scalable sometimes)
As a transparent widget was shown,the bigger-letters can be on the background
of the whole keyboard - each letter on its place.
And you can find a little place for the button with the most probable word
(may be form with variants).

Maybe a landscape QWERTY-Keyboard with one preview text-line would be the best to input text. - maybe later as a transparent version without the textline...

The keyboard should use the accelerometers to automatically detect if a standard or landscape keyboard should be used.
Plus, I think that a "tab" key is really usefull when writing in a terminal, so I think it should be placed near the space key (left side).

== Handwriting ==

[http://wiki.openmoko.org/wiki/User:KlaymenDK KlaymenDK] says: I don't want to mess things up, so I keep to the Talk page. Here's my issue:
This page seems to be the only one even mentioning handwriting. The article page states that the Input Method Widget supports "''both handwriting recognition, and keyboards''", yet the rest of the article seems to not discuss handwriting ''at all''.

I propose creating a section called "Handwriting" to contain this topic.

Being a happy user of a Palm T3 with TealScript, I am quite fond of using the stylus for text input, especially in the "write everywhere" mode where one can use the entire screen as an input area.

I believe that handwriting is worthy of consideration because:
* IMVHO, it is the most ''efficient method for fast input on small devices''.
* It is ''agnostic of keyboard layouts and special language variants'' (I use Norwegian Dvorak).
* It ''consumes no screen real estate'' at all!
* It ''does not preclude the use of an ad-hoc on-screen keyboard''.
* It can be used without a stylus (just use a fingernail).

As I see it, there are two main issues:
# '''Is the OpenMoko actually capable of supporting online handwriting recognition?''' Here I mean in terms of processing power and real-time stroke resolution. This is a fundamental and technical aspect I have no way of answering.
# '''Are there any legal blocks to using handwriting recognition?''' It does not seem so; at least, several open source recognition toolkits exist ([http://lipitk.sourceforge.net/ LipiTK], [http://playground.sun.com/pub/multimedia/handwriting/hre.html HRE], [http://www.linux.com/feature/120867 CellWriter], [http://tomoe.sourceforge.jp Tomoe], [http://www.google.co.uk/search?hl=en&q=open+source+handwriting+recognition others]). My main concern is if single-stroke characters are covered by [http://en.wikipedia.org/wiki/Graffiti_%28Palm_OS%29 Graffiti] patents, and if TealPoint Software ([http://www.tealpoint.com/softscrp.htm TealScript]) holds any patents on ''user-configurable'' strokes.

Another issue could be '''how to actually integrate the handwriting mode into the user interface'''. I think that the way it works on Palm/TealScript is quite nice, if not outright ideal. Basically, the way it works is: a tap is regarded as a tap if it's quick or if it's obviously a tap-and-hold. But a tap with a "running start" is regarded as a stroke and interpreted as a character, which is then sent to the application (that is, field input or command character).

== Keyboard ==

Can a keyboard be hooked up to the Freerunner? [[User:Emesee|Emesee]] 04:23, 5 July 2008 (UTC)

User:Emesee

2008-07-04T05:51:59Z

Emesee:

User:Emesee

2008-07-04T05:49:13Z

Emesee: Mokopedia

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Mokopedia]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

Could the free runner theoretically run Ubuntu? Practically?

==External links==
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

----

User:Emesee

2008-07-04T05:46:42Z

Emesee: small

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

Could the free runner theoretically run Ubuntu? Practically?

==External links==
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

----

User:Emesee

2008-06-30T06:23:32Z

Emesee: Practically?

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

Could the free runner theoretically run Ubuntu? Practically?

==External links==
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

----

User:Emesee

2008-06-30T06:23:15Z

Emesee: Could the free runner theoretically run Ubuntu?

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

Could the free runner theoretically run Ubuntu?

==External links==
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

----

Talk:Discussion Forums

2008-06-20T03:01:57Z

Emesee: on-wiki sign

Where is appropriate to discuss things on-wiki? --[[User:Emesee|Emesee]] 03:01, 20 June 2008 (UTC)

Talk:Discussion Forums

2008-06-20T03:01:44Z

Emesee: on wiki discussion?

Where is appropriate to discuss things on Wiki?

Hardware:Neo1973:Alternate Cases:Solar power

2008-06-12T00:22:55Z

Emesee: /* Interest */ ~~~

Alternate case for the Neo1973, with a solar panel for recharging the battery.

==Design options==
The panel could be mounted on some or all of the six sides of the phone, depending upon the amount of power needed, the environment and the power produced by the panel.

Trickle PV charger integrated into a back case may be feasible. Chances are it would not significantly lengthen daily operations, unless it was left in the sun for extended periods of time, and the other problem is that while it sits in the sun you can't really easily use it as a phone w/o a headset. In addition, It's unclear how hot the phone might get (from absorbing the other bands IR etc.. while sitting in the sun), and whether that might be a problem for the phone electronics or the battery in some hotter climates.

To fully power and charge the device, plugging in a small PV module to the USB port is an option. If you integrate the PV module with a Li-ion battery, charging circuit, and a USB hub, It could make sense for extended computing operations outdoors or places without power. For people roaming about the wilderness/bush this might be an option. If it weren't for the GPS, I might even ask the person why they would bring the phone with them, particularly if there were no cells/wifi hotspots around.

For the sake of a high end usage calculation, figure 2.5A @ 5V nominal for this application (12.5 Watt nominal) depending on what peripherals you want to power (500mA @ 5V on 2 usb ports, and charging the hub battery, powering the hub itself, and 500mA @ 5V for the phone running and charging).

> arbitrary chosen polycrystal
> solar cell 100mm x 100mm: 0.47V, max current (short circuit) 2.6A
> (www.conrad.de, #112135-99)

''(you actually won't get 0.47V and 2.6 Amps at the same time. As stated above, 2.6 Amps is the current you get @ 0 Volts.)''

So we could figure 1 string of 12 cells in series to give us the 5V and 2.5A. arranging them in a 4x3 pattern for 12 total we have a size of 300mm x 400mm for powering and charging everything directly from the sun. This assumes perfect alignment of the panel with the sun and a clear sky. The panel will only be able to provide this power and charging for a normalized number of solar-hours/day (4 or 5 where I live). Minimally this panel, battery, and hub could probably fold to something around 320mm by 120mm by 38 mm, making its folded footprint still about 5 times as large as the phone in area and over twice the thickness.

Taking into account the rules of thumb for the energy available (out of the original ~1kW/m^2) in various scenarios:.. the available energy is further reduced.

full sun, panel square to sun: 100%
full sun, panel at 45 degree angle to sun: 71%
light overcast: 60-80%
heavy overcast: 20-30%
inside double pane window, both window & module square to sun: 84%
inside double pane window, both window & module at 45 degree angle to sun: 64%
indoor office light at desktop: 00.4%
indoor light store display: 01.3%
indoor light home: 0.2%

If you want to charge the device by laying it or a panel down on the ground in the sun, understand that you are going to lose about 30% of the available energy just in not having it positioned perfectly. Of course, the part of the earth's surface you are on is rotating away from or towards the sun, changing the angle of the incident radiation. So even if you position the phone or panel perfectly, it won't be "perfect" all through the day, unless the light is already being scattered by cloudy or overcast situations. Indoors is simply a no go situation, even for trickle charging.

After taking the 30% of the available energy away from our panel due to imperfect conditions, it leaves us with 825mA @ 5V.

To just trickle charge the phone at the 100mA @ 5V through the usb in imperfect conditions, we can reduce the area of the cells by about a factor of 8. 120000mm^2 then shrinks to 15000mm^2 or about twice the phone footprint if you assume it is a 62mm x 120mm rectangle. You would still need 12 cells in series, each with an area of 1250mm^2. 30mm 40mm might be a workable size cell, as about 6 would cover the phone, and another six could fold out.. this would definitely add some bulk.

To go even further, we could interface directly with the battery in the case and provide different currents at a slightly lower voltage, meaning fewer cells in series, larger area, and we might cut out some of the in- efficiencies of the onboard charger. The fully charged neo battery has a 4.2 V open circuit voltage, and a nominal voltage of 3.7 volts. This suggests at an absolute minimum 10 cells @ 0.47V to be able to reliably charge anything (4.7V). The footprint of these polycrystalline cells is still larger than the phone footprint.

If we just said, OK, we just have the non-curvy back of the phone portion as area to use, about 50mm x 80mm, and we are going to use 10 cells for 4.7V to directly charge the battery, 4000mm^2 of cell area divided by 10 gives us a 400mm^2, which points to a rectangular cell size of 8mm x 50mm. this gives us 1/25th of the original cell (100mm x 100mm) area and correspondingly about 1/25th of the current. this is about 104mA under perfect conditions. If we derate it by 30% for non perfect conditions, alignment, etc. we are looking at a charge current of just 63mA @ 4.7 V for 10 cells in series.

So if you can get the phone to draw nothing when it is off, and charge for the full length of the normalized solar day (say 6 hrs.) with the trickle charger in the last example you would get (optimistically) on average, somewhere between 378mAh and 624mAh per day, or about 30 to 50 percent of a battery charge a day. In climates with lower normalized solar hours, you get less, In climates with more you'd get more. I should stress again that these normalized solar hours are NOT the number of hours of sunlight you get per day, you need to look them up on a chart for your region, and then leave your phone outside all day!

What is obvious is that -->Power Management is Important!!!<-- and that you probably won't solve power management problems by sticking some PV cells on the back of your phone. However, the better your power management and device efficiency, the farther the cells you could put on the back of your phone go in meeting some sort of auxiliary charging function.

other stuff:

Voltage of a cell is related to the underlying physics of the cell and its manufacturing process,(crystalline, polycrystalline, amorphous, printed etc.., its particular junction type, and dopants used to make the junction). (This is measured Volts open circuit) more cells in series, more voltage. Cells and modules then have different responses to the effect of ambient temperature on the voltage of the cells, depending on their manufacturing process. Usually there is a slight voltage drop at higher temperatures with all types, but is often more pronounced with Amorphous.

Current of a cell is proportional to the surface area of the cell that faces the light source. (This is measured Amps short-circuit current) Larger area, more current. Cells linked together in series string should be of the same or extremely close surface areas. The smallest surface area limits current and can cause overheating and damage within the module.

modules that have to deal with shading should have bypass diodes. modules should be accompanied by some sort of charge control that has a blocking diode to prevent current leakage from the battery in periods of darkness.

Last but not least, the cell and/or module efficiency of terrestrial cells should be between a low of 9% and high of 17% conversion of incident radiation to electrical current.

Hopefully I haven't made any embarrassing mistakes. Feel free to correct me if you find anything, thanks. HTH

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==
Solar panel

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick !!
|-
|1. [[User:Tetraden|Tetraden]]
|-
|2. [[User:ruskie|ruskie]]
|-
|3. [[User:Denis std|Denis]]
|-
|4. [[User:sin|sin]]
|-
|5. [[User:Filippo|Filippo]]
|-
|6. [[User:Deedend|Deedend]]
|-
|7. [[User:Wedge|Wedge]]
|-
|8. [[User:Fradeve11|Fradeve11]]
|-
|9. [[User:Aeshaettr|Aeshaettr]]
|-
|10. [[User:Madoon|Madoon]]
|-
|11. [[User:larstobi|larstobi]]
|-
|12. [[User:KlaymenDK|KlaymenDK]]
|-
|13. [[User:oz1lln|oz1lln]]
|-
|14. [[User:Aztlek|Aztlek]]
|-
|15. [[User:Kelvan|Kelvan]] Maybe there is a option to make changeable solar cover.
|-
|16. [[User:Tommy|Tommy]] That would be wonderful. I'd rather buy a first version without the solar panel quick and then also buy the next version, than have to wait even more if you were to include the solar panel on the first mass market version. But if you could hire someone else to do it for you and the decision would only affect the price and not the release date I would want you to include it in the first mass market version.
|-
|17. [[User:pokazene_maslo|pokazene_maslo]] Seems interesting, but I'm sceptic about it.
|-
|18. [[User:gwylim|gwylim]] That would be cool, but I'll buy it without anyway.
|-
|19. [[User:yorick|yorick]] That would be very interesting, if it could generate enough power. Otherwise I might go for a kinetic charger.
|-
|20. [[User:subtwo|subtwo]] I would really like to see where this is heading, it sounds amazing! I want one!
|-
|21. [[User:Frafra|frafra]] Very intresting. This could be an innovative and intelligent choice.
|-
|22. [[User:Theocrite|Theocrite]] Very interesting.
|-
|23. [[User:Emesee|Emesee]]
|-
|}

[[Category:Hardware ]]
[[Category:Hardware Support]]
[[Category:Neo1973 Hardware]]
[[Category:Neo1973_alternate_cases]]

User:Emesee

2008-06-11T06:07:57Z

Emesee: reorg

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

==External links==
* [http://www.open80211s.org/ Open 802.11s]

 
<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

----

User:Emesee

2008-06-03T18:34:21Z

Emesee: rc

<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

<big>

{{column list|3|
* [[Special:Recentchanges]]
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

==External links==
* [http://www.open80211s.org/ Open 802.11s]

User:Emesee/Workspace

2008-05-27T04:19:36Z

Emesee: New page: http://zero-install.sourceforge.net/

http://zero-install.sourceforge.net/

User:Emesee

2008-05-27T04:00:50Z

Emesee: cross wiki

<center> [http://en.wikiversity.org/wiki/User:Remi Wikiversity] 
</center>

<big>

{{column list|3|
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

==External links==
* [http://www.open80211s.org/ Open 802.11s]

Wish List - Hardware

2008-05-26T21:18:48Z

Emesee: /* Integrated solar charger */ with a matching color. :)

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.

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.
==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.

===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

==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.
*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]]

===="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 [[Neo1973 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==

===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.

===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.

===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

===Accelerometer===
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.
*Attempt to use to stabilise any future camera.

This feature is scheduled for inclusion in the phase 2 Neo1973, GTA02.

===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.

===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

===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 altidude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)

===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.

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

===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.

=== 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 etc.
* 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.

====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.

====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, [http://wiki.openmoko.org/wiki/Wish_List#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).

===[[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.

=== [[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]]

=== 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.

=== 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.

=== 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!

=== 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. :)

==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).

===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)

===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.

===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.

=== 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.

'''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]

[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.

=== 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.

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

[[Category:Hardware ideas| ]]
[[Category:User]]

Wish List - Hardware

2008-05-26T21:15:16Z

Emesee: /* =Integrated solar charger */ =

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.

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.
==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.

===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

==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.
*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]]

===="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 [[Neo1973 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==

===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.

===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.

===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

===Accelerometer===
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.
*Attempt to use to stabilise any future camera.

This feature is scheduled for inclusion in the phase 2 Neo1973, GTA02.

===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.

===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

===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 altidude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)

===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.

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

===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.

=== 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 etc.
* 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.

====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.

====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, [http://wiki.openmoko.org/wiki/Wish_List#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).

===[[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.

=== [[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]]

=== 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.

=== 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.

=== 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!

=== 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].

==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).

===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)

===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.

===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.

=== 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.

'''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]

[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.

=== 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.

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

[[Category:Hardware ideas| ]]
[[Category:User]]

Wish List - Hardware

2008-05-26T21:15:03Z

Emesee: /* Casing */

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.

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.
==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.

===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

==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.
*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]]

===="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 [[Neo1973 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==

===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.

===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.

===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

===Accelerometer===
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.
*Attempt to use to stabilise any future camera.

This feature is scheduled for inclusion in the phase 2 Neo1973, GTA02.

===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.

===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

===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 altidude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)

===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.

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

===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.

=== 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 etc.
* 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.

====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.

====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, [http://wiki.openmoko.org/wiki/Wish_List#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).

===[[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.

=== [[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]]

=== 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.

=== 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.

=== 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!

=== 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].

==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).

===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)

===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.

===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.

=== 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.

'''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]

[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.

=== 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.

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

[[Category:Hardware ideas| ]]
[[Category:User]]

Headset

2008-05-23T05:15:24Z

Emesee: formatting

==Test Scope==
To test Headset functionality

==Test Duration==

==Test Environment==
# Neo FreeRunner plus April Software Update
# FIC GTA02 battery
# SIM card
# Headset AP

==Test Cases==
===Test Case #1===

Headset

2008-05-23T05:15:09Z

Emesee: formatting

==Test Scope==
To test Headset functionality

==Test Duration==

==Test Environment==
# Neo FreeRunner plus April Software Update 
# FIC GTA02 battery 
# SIM card 
# Headset AP 

==Test Cases==
===Test Case #1===

Openmoko Local Groups: Portland

2008-05-16T22:36:48Z

Emesee: tech oriented

Portland has many technology oriented organizations. I hope to get a moko developers meeting going soon.
The dorkbot group and possibly dc503 would be interested.

[[Category:Community]]
[[Category: OpenMoko Local Groups| ]]

Wifi

2008-05-16T22:30:11Z

Emesee: redirect to WiFi support in Openmoko

#REDIRECT [[WiFi support in Openmoko]]

Category:Hardware

2008-05-16T22:25:13Z

Emesee: formatting

Hardware include all hardware stuff.
It's subcategory includes :
==[[:category:Hardware|Hardware]]==

:[[:category:Adapt|Adapt]]
:[[:category:Audio|Audio]]
:[[:category:Bluetooth|Bluetooth]]
:[[:category:Chip|Chip]]
:[[:category:Development Board|Development]]
:[[:category:Flash|Flash]]
:[[:category:GPS|GPS]]
:[[:category:Hardware Support|Support]]
::[[:category:GTA02 Hardware|GTA02]]
::[[:category:Neo1973 Hardware|GTA01]]
::[[:category:Neo1973 Phase 0 related|Neo1973 Phase 0 related]]
::[[:category:Neo1973 Phase 1 related|Neo1973 Phase 1 related]]
::[[:category:Neo1973 Hardware Debugging|Neo1973 Hardware Debugging]]
::[[:category:Neo1973 alternate cases|Neo1973 alternate cases]]
::[[:category:Neo1973 and external hardware|Neo1973 and external hardware]]
:[[:category:Power|Power]]
:[[:category:Power button|Power Button]]
:[[:category:USB|USB]]

[[category:categories]]

User:Emesee

2008-05-16T22:23:03Z

Emesee:

{{column list|3|
* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]
}}

==External links==
* [http://www.open80211s.org/ Open 802.11s]

User:Emesee

2008-05-16T22:21:53Z

Emesee:

Template:Column list

2008-05-16T22:21:09Z

Emesee: fork of - GFDL'd - http://en.wikipedia.org/w/index.php?title=Template:Columns-list&oldid=195813098

<includeonly><div {{#if: {{{1|}}}| style="-moz-column-count:{{{1}}}; -webkit-column-count:{{{1}}}; column-count:{{{1}}} }};">{{{2}}}</div></includeonly>
<noinclude>
== Documentation ==

<nowiki>{{</nowiki>columns-list|''number of columns''|
''text (usually a list)''
<nowiki>}}</nowiki>

Based on [[Template:Reflist]], but different in that the text to be displayed is manually created rather than a list of references. Also different from [[Template:Columns]] in that this template is intended to be used in a list in the article itself, rather than in a navigation template like [[Template:Navbox]].

[[category:Table and column templates]]
</noinclude>

Wishlist/Mesh Networking

2008-05-16T22:18:54Z

Emesee: external link started - Open 802.11s

{{Wishlist}}

== Introduction ==

Mesh networking allows communication with others without the need for network
infrastructure such as cellular base stations or wireless access points.
A mesh network treats everyone's computer as a wireless router and learns about
the links in the network, computes paths between all users, and updates the IP
routing tables so that you can send packets to anyone else who is part
of the mobile ad-hoc network (MANet).

== Hardware ==

The minimal requirement to run Mesh networking is having at least one network interface configured.
A WLAN or Bluetooth network interface can be used for this (actually you could use a wired
interface but you won't be very mobile then!).

Latest developments in mesh technology is to use multiple radio interfaces to establish the network. As the Neo1973 offers multiple radios, this platform is an excellent vehicle to develop next generation mobile mesh networking capabilities!

== Software ==

There is different software out there supporting Mesh networking.

=== Netsukuku ===

[http://netsukuku.freaknet.org/ Netsukuku] is a mesh network or a p2p net system that generates and sustains
itself autonomously. It is designed to handle an unlimited number of nodes
with minimal CPU and memory resources.

Note: from the [http://netsukuku.freaknet.org/files/doc/misc/Ntk_features_list Ntk features list]
The design of Netsukuku prioritises the stability of net.
For this reason, it isn't specifically suitable for mobile nodes.
However if the mobile nodes are inside an area covered by static Netsukuku
nodes, there aren't any problems. It is also possible to use other mesh
network protocols designed for mobility in conjunction with Netsukuku

=== Mobile Mesh ===

[http://www.mitre.org/work/tech_transfer/mobilemesh/ Mobile Mesh] has been developed for mobile
ad-hoc routing protocols. Mobile Mesh is developed part of a research project at The MITRE Corporation.

=== LUNAR ===

[http://core.it.uu.se/core/index.php/LUNAR LUNAR] stands for Lightweight Underlay Network Ad-hoc Routing
and implements a bare-bones on-demand route discovery protocol with broadcast dampening and reconfigures
communications paths typically within 3 seconds. LUNAR includes automatic IP gatewaying and supports
IP unicast and broadcast. A dedicated [http://core.it.uu.se/core/index.php/LUNAR_over_Bluetooth LUNAR over Bluetooth] version is available running over a Bluetooth network using BlueZ.

== Routing protocols ==

=== AODV ===
[http://moment.cs.ucsb.edu/AODV/aodv.html AODV] is a routing protocol very light in term of power and energy consumption; it provides at the support for mobility.
It is a proactive algorithm, so it does not send any message if you don't need, and that is good for comsumption

=== B.A.T.M.A.N. ===
[http://open-mesh.net/batman/doc/Overview B.A.T.M.A.N.] is the latest routing protocol developed by enthusiasts around the world. Initial algorithm design was done by Elektra from the [http://berlin.freifunk.net freifunk.net community Berlin].

Each B.A.T.M.A.N (better approach to mobile ad-hoc networking) node stores routing information about the neighbouring node it can reach. If because of packet loss etc. another node cannot be reached it will not be part of the local node's routing information.

B.A.T.M.A.N Advanced is the next generation implementation that works on the Ethernet layer instead of the IP layer. That way the mesh-net can be seen as an ethernet switch allowing easier node to node setups and providing services ''inside'' the mesh-net.

A German article can be found [http://de.wikipedia.org/wiki/B.A.T.M.A.N. here].

=== 802.11s ===
[http://en.wikipedia.org/wiki/IEEE_802.11s 802.11s] is a draft IEEE 802.11 amendment for mesh networking, defining how wireless devices can interconnect to create an ad-hoc network. It extends the IEEE 802.11 MAC standard by defining an architecture and protocol that support both broadcast/multicast and unicast delivery using "radio-aware metrics over self-configuring multi-hop topologies." There is a project creating an open-source implementation: http://open80211s.org.

== Companies ==

Here some companies who offer mesh networking services and/or products. Guess they see a true business case in this technology ;-)

=== Terranet ===
[http://www.terranet.se Terranet] is a company based in Lund, Sweden and offers technology to enable long distance VoIP calls. Their techonology offering is unknown; it seems the protocol appears to be proprietary and closed.

=== Motorola ===
[http://www.motorola.com/mesh/ Motorola] bought in 2004 MeshNetworks, one of the first companies offering wireless mesh networking technology called MAE (Mobility Enabled Access). The protocol appears to be proprietary and closed. Motorola also developed a dedicated radio technology at the physical layer (PHY) for this.

=== MeshDynamics ===
[http://www.meshdynamics.com/voip-results.html MeshDynamics] offers a multi-radio multi-channel radio solution using 802.11 for wireless mesh networking. They also did a performance analysis of three competing Mesh Architectures [http://www.meshdynamics.com/performance-analysis.html here].
=== OLPC ===
[http://laptop.org One Laptop Per Child] implements a mesh network. All of their code is open source.

==External links==
* [http://www.open80211s.org/ Open 802.11s] - 1 Goal: "To connect all the Linux devices in the world to One Big Mesh."

User:Emesee

2008-03-27T20:34:35Z

Emesee: Business Development

* [[Wishlist:More/Custom Input Method Widgets]]

* [[USB Networking]]

* [[Explaining carriers versus phones]]

* [[License]]

* [[OpenMoko Wiki Editing Guidelines]]
* [[How to run OpenMoko Apps on PC]]
* [[Toolchain]]
* [[Boot sound]]

* [[Wishlist:Wikipedia Mirror]]
* [[OpenMoko Core Applications]]

* [[Neo1973]]
* [[Neo1973 hardware]]
* [[Neo1973 Battery]]
* [[Hardware]]

* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware Specification]]

* [[GTA01Standby]]

* [[Snapshot review/2008-02-20]]

* [[WiFi support in OpenMoko]]
* [[OpenLab]]
* [[Kernel]]
* [[Bootloader]]
* [[:Category:Neo1973 Hardware]]
* [[Wiki Issues]]
* [[OPENMOKO WIKI Official Index Page]]

* [[Business Development]]

User:Emesee

2008-02-25T07:37:28Z

Emesee: OPENMOKO WIKI Official Index Page

Talk:Can I become a distributor?

2008-02-22T23:27:48Z

Emesee: merge :)

This is an honest question, and many people want to know -- especially in countries that don't have the other FIC phone yet (GT118A) -- how to buy thousands of Neo1973s and redistribute them. Please, do not mark for deletion again.
--[[User:Massa|Massa]] 11:37, 22 August 2007 (CEST)

:Right, this is a honest question, but I think that fits better in the FAQ or into another page instead of a single one. [[User:Kresp0|kresp0]] 16:17, 22 August 2007 (CEST)

::Well to be honest this is a question I've been wanting to ask and would really like an answer to, but don't want to disturb the devs during an obviously busy time for them. It probably does deserve to be fit into an FAQ of some sort, but I think FAQs generally contain answers to question, rather than questions without answers. Why don't we leave the page here until we find an answer, then move it into the FAQs? --[[User:Awrowe|Awrowe]] 19:17, 22 August 2007 (CEST)

:::That would be great for me. --[[User:Massa|Massa]] 20:44, 22 August 2007 (CEST)
::::yah, merge. :) --[[User:Emesee|Emesee]] 00:27, 23 February 2008 (CET)

Talk:Can I become a distributor?

2008-02-22T23:27:11Z

Emesee: maybe instead of delete

This is an honest question, and many people want to know -- especially in countries that don't have the other FIC phone yet (GT118A) -- how to buy thousands of Neo1973s and redistribute them. Please, do not mark for deletion again.
--[[User:Massa|Massa]] 11:37, 22 August 2007 (CEST)

:Right, this is a honest question, but I think that fits better in the FAQ or into another page instead of a single one. [[User:Kresp0|kresp0]] 16:17, 22 August 2007 (CEST)

::Well to be honest this is a question I've been wanting to ask and would really like an answer to, but don't want to disturb the devs during an obviously busy time for them. It probably does deserve to be fit into an FAQ of some sort, but I think FAQs generally contain answers to question, rather than questions without answers. Why don't we leave the page here until we find an answer, then move it into the FAQs? --[[User:Awrowe|Awrowe]] 19:17, 22 August 2007 (CEST)

:::That would be great for me. --[[User:Massa|Massa]] 20:44, 22 August 2007 (CEST)

== maybe instead of delete ==

it could be merged somewhere --[[User:Emesee|Emesee]] 00:27, 23 February 2008 (CET)

Wishlist/Carrier subsidies

2008-02-22T23:23:52Z

Emesee: started

It would be nice if when people sign up or renew their contract with cellphone voice/data providers that they could have the option of getting an OpenMoko phone for 40-100 dollars.

User:Emesee

2008-02-22T23:20:34Z

Emesee: added

User:Emesee

2008-02-22T23:10:39Z

Emesee: org

User:Emesee

2008-02-21T07:05:11Z

Emesee:

User:Emesee

2008-02-21T07:05:01Z

Emesee: Toolchain

User:Emesee

2008-02-20T21:44:52Z

Emesee: Snapshot review/2008-02-20