http://openmoko.org/api.php?action=feedcontributions&user=Wisp&feedformat=atomOpenmoko - User contributions [en]2024-03-29T12:52:29ZUser contributionsMediaWiki 1.19.24http://openmoko.org/wiki/Talk:Compulab_EM-X270Talk:Compulab EM-X2702007-11-07T18:41:55Z<p>Wisp: /* Case */</p>
<hr />
<div>==open-source drivers==<br />
is there any word on the openness of drivers? a big part of the appeal of the neo is that the majority of the drivers (where legal) are open-source. any widespread adoption of these modules will probably stall straight away if there are no open drivers/useful documentation available [[User:Myfanwy|myfanwy]] 00:59, 7 November 2007 (CET)<br />
<br />
They provide the Angstrom Linux which is based on Open Embedded. So I would assume that drivers are the standard drivers of the Linux kernel. Well, WiFi, Bluetooth, GPS and GSM may only be available as (USB) serial data interfaces to some black-box modules. [[User:Hns|hns]] 17:37, 7 November 2007 (GMT)<br />
<br />
Last I checked, the wifi was non-functional under Linux. Unfortunately, that suggests that it doesn't have open drivers, but perhaps it was only a temporary situation. [[User:Wisp|wisp]] 19:20, 7 November 2007 (CET) -- apparently I was wrong. Support is now planned for December http://www.compulab.co.il/x270em/html/x270-em-os-support.htm [[User:Wisp|wisp]] 19:35, 7 November 2007 (CET)<br />
<br />
== emulation ==<br />
<br />
in lieu of developing on actual hardware, an emulator would be mighty useful. does one exist for the compulab hardware? is it much of a process to put one together? [[User:Myfanwy|myfanwy]] 01:22, 7 November 2007 (CET)<br />
<br />
== Case ==<br />
<br />
The device is a "pure" module with everything except a case. To get one, we will need<br />
# someone who can make a mechanical construction<br />
# someone who can nicely design it (and decide about colors, materials, haptics)<br />
# someone who can produce low quantities at a reasonable price (< $50 per units)<br />
<br />
Ideas? Proposals? Links? Friends? Volunteers?<br />
[[User:Hns|hns]] 17:37, 7 November 2007 (GMT)<br />
<br />
What would really be the best is if we could find a company who built a touchscreen phone based on this (with case and all) - purchase and reflash :)<br />
[[User:Wisp|wisp]] 19:41, 7 November 2007 (CET)</div>Wisphttp://openmoko.org/wiki/Talk:Compulab_EM-X270Talk:Compulab EM-X2702007-11-07T18:35:55Z<p>Wisp: /* open-source drivers */</p>
<hr />
<div>==open-source drivers==<br />
is there any word on the openness of drivers? a big part of the appeal of the neo is that the majority of the drivers (where legal) are open-source. any widespread adoption of these modules will probably stall straight away if there are no open drivers/useful documentation available [[User:Myfanwy|myfanwy]] 00:59, 7 November 2007 (CET)<br />
<br />
They provide the Angstrom Linux which is based on Open Embedded. So I would assume that drivers are the standard drivers of the Linux kernel. Well, WiFi, Bluetooth, GPS and GSM may only be available as (USB) serial data interfaces to some black-box modules. [[User:Hns|hns]] 17:37, 7 November 2007 (GMT)<br />
<br />
Last I checked, the wifi was non-functional under Linux. Unfortunately, that suggests that it doesn't have open drivers, but perhaps it was only a temporary situation. [[User:Wisp|wisp]] 19:20, 7 November 2007 (CET) -- apparently I was wrong. Support is now planned for December http://www.compulab.co.il/x270em/html/x270-em-os-support.htm [[User:Wisp|wisp]] 19:35, 7 November 2007 (CET)<br />
<br />
== emulation ==<br />
<br />
in lieu of developing on actual hardware, an emulator would be mighty useful. does one exist for the compulab hardware? is it much of a process to put one together? [[User:Myfanwy|myfanwy]] 01:22, 7 November 2007 (CET)<br />
<br />
== Case ==<br />
<br />
The device is a "pure" module with everything except a case. To get one, we will need<br />
# someone who can make a mechanical construction<br />
# someone who can nicely design it (and decide about colors, materials, haptics)<br />
# someone who can produce low quantities at a reasonable price (< $50 per units)<br />
<br />
Ideas? Proposals? Links? Friends? Volunteers?<br />
[[User:Hns|hns]] 17:37, 7 November 2007 (GMT)</div>Wisphttp://openmoko.org/wiki/Talk:Compulab_EM-X270Talk:Compulab EM-X2702007-11-07T18:20:33Z<p>Wisp: /* open-source drivers */</p>
<hr />
<div>==open-source drivers==<br />
is there any word on the openness of drivers? a big part of the appeal of the neo is that the majority of the drivers (where legal) are open-source. any widespread adoption of these modules will probably stall straight away if there are no open drivers/useful documentation available [[User:Myfanwy|myfanwy]] 00:59, 7 November 2007 (CET)<br />
<br />
They provide the Angstrom Linux which is based on Open Embedded. So I would assume that drivers are the standard drivers of the Linux kernel. Well, WiFi, Bluetooth, GPS and GSM may only be available as (USB) serial data interfaces to some black-box modules. [[User:Hns|hns]] 17:37, 7 November 2007 (GMT)<br />
<br />
Last I checked, the wifi was non-functional under Linux. Unfortunately, that suggests that it doesn't have open drivers, but perhaps it was only a temporary situation. [[User:Wisp|wisp]] 19:20, 7 November 2007 (CET)<br />
<br />
== emulation ==<br />
<br />
in lieu of developing on actual hardware, an emulator would be mighty useful. does one exist for the compulab hardware? is it much of a process to put one together? [[User:Myfanwy|myfanwy]] 01:22, 7 November 2007 (CET)<br />
<br />
== Case ==<br />
<br />
The device is a "pure" module with everything except a case. To get one, we will need<br />
# someone who can make a mechanical construction<br />
# someone who can nicely design it (and decide about colors, materials, haptics)<br />
# someone who can produce low quantities at a reasonable price (< $50 per units)<br />
<br />
Ideas? Proposals? Links? Friends? Volunteers?<br />
[[User:Hns|hns]] 17:37, 7 November 2007 (GMT)</div>Wisphttp://openmoko.org/wiki/Talk:November_6,_2007_Community_UpdateTalk:November 6, 2007 Community Update2007-11-06T03:29:12Z<p>Wisp: </p>
<hr />
<div>How many of you must have 850 MHz support, and would be satisfied with an 850/1800/1900MHz variant, and how many of you must have full quad-band?<br />
<br />
Note that by asking this question we do not promise to provide these options.<br />
<br />
Please put your answers below:<br />
<br />
'''Must have an 850/1800/1900MHz variant'''<br />
* --[[User:ShakataGaNai|ShakataGaNai]] 03:34, 6 November 2007 (CET)<br />
* --[[User:Aking|Aking]] 21:55 EST, 2007-11-05 [live/work in an 850 only zone]<br />
* --[[User:Matt|Mattdawg]] 19:57 MST, 6 November 2007<br />
* --[[User:Writchie|Wally Ritchie]] 10:02 EST, 6 November 2007<br />
* -- [[User:Digger|Digger]] 04:15, 6 November 2007 (CET) But for the money would prefer quad-band<br />
* -- [[User:Wisp|wisp]] 04:29, 6 November 2007 (CET) But for the money would greatly prefer quad-band <br />
<br />
'''Is OK with the current 900/1800/1900MHz variant'''<br />
* --(most of Europe? From my quick bit of research, it seems 850Mhz is only needed for the US, Canada, Anguilla, Ecuador, Montserrat, Panama, St. Kitts and Nevis, Turks and Caicos Islands )<br />
<br />
'''Must have full quad-band support'''<br />
* --[[User:Elektrolott|Elektrolott]] 18:45 (PST), 2007-11-05<br />
* --[[User:ClashTheBunny|ClashTheBunny]] 04:03, 6 November 2007 (CET) - Right now I live on the North Shore of Boston and most places are 850<br />
* --[[User:Sagacis|Sagacis]] 04:16, 6 November 2007 (CET) The phone is a brick to me without 850. International travel means I need all four bands.</div>Wisphttp://openmoko.org/wiki/IpkgIpkg2007-10-03T15:07:53Z<p>Wisp: restructured ipkg-link section</p>
<hr />
<div>The practical way to install software on OpenMoko is with the [http://handhelds.org/moin/moin.cgi/Ipkg Ipkg package manager], possibly via the graphical [[Application Manager]]. Naturally, you need to have obtained an OpenMoko system by other means initially.<br />
<br />
For the latest ipk package files from buildhost put the following lines in your /etc/ipkg/base-feed.conf:<br />
src/gz all http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/ipk/all/<br />
src/gz armv4t http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/ipk/armv4t/<br />
src/gz fic-gta01 http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/ipk/fic-gta01/<br />
<br />
In the shell, "ipkg update" will update the list of available packages, "ipkg upgrade" will download and install all packages that have a newer version available and "ipkg install new-app" will download and install "new-app".<br />
<br />
== History ==<br />
<br />
Ipkg re-implements for embedded systems the Debian tools dpkg, apt, and apt-get. For example, it uses much less disk space for the package metadata.<br />
<br />
== Ipkg Breaks Kernels ==<br />
<br />
Unfortunately, ipkg has a bug; it tries to install kernels (and does actually install the kernel modules), but the kernel is on a separate partition that isn't normally mounted. So when you do "ipkg upgrade" and kernel packages get installed, your system breaks (the modules no longer match the kernel). For example, sound no longer worked for me.<br />
<br />
To fix this, you have to find a kernel image somewhere else (I don't know how to tell you how to find that -- on IRC, mentax suggested installing http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/uImage-2.6.22.5-moko11+svnr2937-r2-fic-gta01.bin<br />
(but that advice is probably obsolete by the time you read it.) Once you have a kernel partition image that matches the modules installed by ipkg, you can install the kernel by powering off the phone and following the advice in [[Flashing_openmoko]].<br />
<br />
It seems to me that ipkg should be able to flash the kernel partition -- but nobody's made it do so, yet.<br />
<br />
== Installing Packages to the Memory Card ==<br />
<br />
You can use ipkg to install packages to a folder on the memory card. To do this you'll need the following:<br />
<br />
=== Ext2 Formatted Memory Card ===<br />
<br />
By default, the memory card comes formated with VFAT (Windows Format). You need to re-format the card with EXT2. You will not be able to view the files on the card using a windows system after this.<br />
<br />
To check if your card is using vfat or ext, run the 'mount' command, and look for: /dev/mmcblk0p1 on /media/card.<br />
<br />
On the NEO, run the following:<br />
''' This will erase everything on your memory card '''<br />
<br />
umount /media/card<br />
fdisk /dev/mmcblk0<br />
t 83<br />
w<br />
q<br />
mke2fs /dev/mmcblk0p1<br />
mount /media/card<br />
<br />
=== Entry in ipkg.conf File ===<br />
<br />
In your ipkg.conf file, after "dest root /" add a new line:<br />
dest card /media/card/ipkg<br />
<br />
Create /media/card/ipkg folder<br />
mkdir /media/card/ipkg<br />
<br />
=== Installing Packages on the Card ===<br />
<br />
When installing a package, use the -d option to have in installed on the card:<br />
ipkg install -d card python-core<br />
<br />
This will put all files (binaries and libraries) on the card, under the folder specified in the ipkg.conf file.<br />
<br />
=== Linking/Using Packages on the Card ===<br />
<br />
Your system will not be able to see the packages that you just added to your card. There are two ways to remedy this. <br />
The better solution is to use ipkg-link from the 'ipkg-utils' package, but 'better' is always subjective - YMMV.<br />
<br />
==== 1: Ipkg Utils and ipkg-link ====<br />
<br />
Ipkg-utils is a package that provides some additional functionality for ipkg. A very useful tool is ipkg-link, which creates symbolic lynks for packages installed in non-root locations (such as a card) back to the root file system.<br />
<br />
To get ipkg-utils, run:<br />
ipkg install ipkg-utils<br />
<br />
To create symbolic links to your root system for a specific package, run: ipkg-link add <package>. For example, for python-core use:<br />
ipkg-link add python-core<br />
<br />
To create symbolic links for all packages installed in a location, run:<br />
ipkg-link mount /media/card/ipkg<br />
<br />
The ''ipkg-link remove'' and ''ipkg-link unmount'' commands remove the symlinks for a package or all packages.<br />
<br />
There is a list of the options for the ipkg command under "How do I use it?" [http://handhelds.org/moin/moin.cgi/Ipkg here.]<br />
<br />
==== 2: Adding the card PATH and LIB directories to your path ====<br />
Another way to add bin and lib files to your system is by modifying your environment variables in /etc/profile as follows:<br />
<br />
On the line that defines the PATH variable, add:<br />
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin:/media/card/ipkg/usr/bin<br />
<br />
Then, before the 'export' line add:<br />
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/card/ipkg/usr/lib<br />
<br />
Then modify the 'export' line and add LD_LIBRARY_PATH to the end.<br />
<br />
This will let the system see the binary and library files, but it will not see other resources, such as images, configuration files, desktop files, etc. For this reason, ipkg-link is preferred.<br />
<br />
[[Category:OpenMoko]]<br />
[[Category:Implemented]]</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-18T17:53:26Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
if(release > init){<br />
value = null; // no backward dialing or dialing past the fingerstop<br />
}elseif((init - release - 1) <= 0){<br />
value = null; // not enough mojo (moko?) in your stroke - try again.<br />
}elseif((init - release - 1) == 10){<br />
value = 0; // necessary substitution<br />
}else{<br />
value = init - release - 1; // allows for old-school dialing, where it didn't<br />
// actually matter where your finger was - it only mattered how much it moved.<br />
}<br />
<br />
with these area values:<br />
:black type = display value<br />
:(num) = positional value ''(if different)''<br />
<br />
It would be '''really cool''' (tm) if it moved under your finger and snapped back after you released.</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-18T04:55:58Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
if(release > init){<br />
value = null; // no backward dialing<br />
}elseif((init - release - 1) <= 0){<br />
value = null; // not enough mojo (moko?) in your stroke - try again.<br />
}elseif((init - release - 1) == 10){<br />
value = 0; // necessary substitution<br />
}else{<br />
value = init - release - 1; // allows for old-school dialing, where it didn't<br />
// actually matter where your finger was - it only mattered how much it moved.<br />
}<br />
<br />
with these area values:<br />
:black type = display value<br />
:(num) = positional value ''(if different)''<br />
<br />
It would be '''really cool''' (tm) if it moved under your finger and snapped back after you released.</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T22:43:20Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
if(release > init){<br />
value = null; // no backward dialing<br />
}elseif((init - release - 1) <= 0){<br />
value = null; // not enough mojo (moko?) in your stroke - try again.<br />
}elseif((init - release - 1) == 10){<br />
value = 0; // necessary substitution<br />
}else{<br />
value = init - release - 1; // allows for old-school dialing, where it didn't actually matter where your finger was - it only mattered how much it moved.<br />
}<br />
<br />
with these area values:<br />
:(num) = positional value ''(if different)''<br />
:black type = display value<br />
<br />
It would be '''really cool''' (tm) if it moved under your finger and snapped back after you released.</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T22:36:35Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
if(release > init){<br />
value = null; // no backward dialing<br />
}elseif((init - release - 1) <= 0){<br />
value = null; // not enough mojo (moko?) in your stroke - try again.<br />
}elseif((init - release - 1) == 10){<br />
value = 0; // necessary substitution<br />
}else{<br />
value = init - release - 1; // allows for old-school dialing, where it didn't actually matter where your finger was - it only mattered how much it moved.<br />
}<br />
<br />
with these area values:<br />
:(num) = positional value ''(if different)''<br />
:black type = display value</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T22:33:49Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
if(release > init){<br />
value = null; // no backward dialing<br />
}elseif((init - release - 1) <= 0){<br />
value = null; // not enough mojo (moko?) in your stroke - try again.<br />
}elseif((init - release - 1) == 10){<br />
value = 0; // necessary substitution<br />
}else{<br />
value = init - release - 1;<br />
}<br />
<br />
with these area values:<br />
:(num) = positional value ''(if different)''<br />
:black type = display value</div>Wisphttp://openmoko.org/wiki/File:Rotarydial.pngFile:Rotarydial.png2007-09-17T22:28:47Z<p>Wisp: </p>
<hr />
<div>apologies for multiple revisions - I can't delete them - requires sysop.<br />
<br />
I made this graphic - released under GNU Free Documentation License 1.2 --[[User:Wisp|wisp]] 00:28, 18 September 2007 (CEST)</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T22:25:45Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
<br />
if((init - release - 1) <= 0){<br />
value = null;<br />
}elseif((init - release - 1) == 10){<br />
value = 0;<br />
}else{<br />
value = init - release - 1;<br />
}<br />
<br />
with these area values:<br />
:(num) = positional value ''(if different)''<br />
:black type = display value</div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T21:43:56Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
<br />
if((init - release - 1) <= 0){<br />
value = null;<br />
}elseif((init - release - 1) == 10){<br />
value = 0;<br />
}else{<br />
value = init - release - 1;<br />
}<br />
<br />
with these area values:<br />
:(num) = positional value<br />
:black type = display value</div>Wisphttp://openmoko.org/wiki/File:Rotarydial.pngFile:Rotarydial.png2007-09-17T21:38:30Z<p>Wisp: </p>
<hr />
<div></div>Wisphttp://openmoko.org/wiki/Wishlist/Rotary_DialerWishlist/Rotary Dialer2007-09-17T21:38:09Z<p>Wisp: </p>
<hr />
<div>So, this is mainly a joke, but it would be an interesting dispay app for the capabilities of the touchscreen environment and is a departure from the standard 'mouse' behavior of most touchscreens.<br />
<br />
[[Image:rotarydial.png]]<br />
<br />
pseudo-code:<br />
<br />
if((init - release - 1) <= 0){<br />
value = null;<br />
}elseif((init - release - 1) == 10){<br />
value = 0;<br />
}else{<br />
value = init - release - 1;<br />
}<br />
<br />
with these area values:<br />
(num) = positional value<br />
black type = display value</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-17T21:32:45Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming.<br />
<br />
I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
see also: [[Wishlist:Set_Local_Time]], [[Clock]], [[Clocks]]<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).<br />
<br />
and just for fun: [[Wishlist:Rotary_Dialer]]</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-12T06:07:40Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming.<br />
<br />
I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
see also: [[Wishlist:Set_Local_Time]], [[Clock]], [[Clocks]]<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-12T06:07:28Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming.<br />
<br />
I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
see also: [[Wishlist:Set_Local_Time]], [[Clock]], [[Clocks]]<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).<br />
test edit</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-11T15:51:15Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming.<br />
<br />
I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
see also: [[Wishlist:Set_Local_Time]], [[Clock]], [[Clocks]]<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-11T06:27:27Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming. I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
see also: [[Wishlist:Set_Local_Time]]<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).</div>Wisphttp://openmoko.org/wiki/Wishlist/Set_Local_TimeWishlist/Set Local Time2007-09-11T06:26:49Z<p>Wisp: </p>
<hr />
<div>{{Wishlist}}<br />
Using GPS the phone should adjust the timezone of the phone automatically. When first entering a new timezone the phone should ask if you want to change time zone and adjust the time accordingly.<br />
<br />
This requires both a timezone map, and a list of times of changing from summer to wintertime.<br />
It also needs to automatically update, whenever legislation in various countries changes.<br />
<br />
You can also get the time from the cell tower. It is called "Network Operator Time".<br />
<br />
This doesn't necessarily require GPS at all (or any maps) - the Network Operator Time (called out above) is _local time_ - it can therefore be used to calculate a timezone offset from your current settings (assuming a difference in hours with a low error threshold (error >5min unacceptable and requires user input??).<br />
Also, all internal events (calendar, etc...) should be stored in UTC so that they display properly to the user when the timezone changes --[[User:Wisp|wisp]] 08:26, 11 September 2007 (CEST)<br />
<br />
[[Category:GPS]]</div>Wisphttp://openmoko.org/wiki/User:WispUser:Wisp2007-09-11T06:19:29Z<p>Wisp: </p>
<hr />
<div>I work in Information Technology as a Systems Engineer and have some background in application interface design and lightweight programming. I am particularly interested in location-aware/context-aware applications. I also think that time/date/locale can be handled in a very intuitive way on a GSM platform (that I have not before seen used) -- Basically:<br />
* local time is available via GSM (cell tower broadcast)<br />
* device time should be stored in UTC<br />
* difference between GSM local time and device time (UTC) can be used to compute device locale/time zone settings<br />
* calendar should store entries internally in UTC (device time) and render to the user with a translation to local time (whatever that happens to be).<br />
<br />
If I fly to NY from SF, my locale (timezone) should be updated with the 3 hour difference when I get there, not the internal clock (in UTC) (the internal clock could be updated if less than 5 minutes - more than 5 minutes off the hour and user intervention would be required (5 min is a line in the sand))<br />
<br />
I will be purchasing the 'consumer model' as soon as it is released - not because I am bothered by the current lack of software - I hacked linux onto my iPaq h2210, but because I want the updated hardware (mainly wifi).</div>Wisphttp://openmoko.org/wiki/Openmoko_Local_Groups:_San_FranciscoOpenmoko Local Groups: San Francisco2007-09-11T06:09:00Z<p>Wisp: </p>
<hr />
<div>Are there any other OpenMoko community members here?<br />
<br />
{|border=1<br />
!Name<br />
!Skills<br />
!Interest<br />
!Location<br />
!Has Device<br />
!Has Debug Board<br />
|-<br />
|[http://www.asheesh.org/ Asheesh Laroia]<br />
|Programming, sysadminning<br />
|Whatever it takes to enjoy using it every day ;-)<br />
|San Francisco, CA (live and work in the city)<br />
| [[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:captain_morgan|Morgan]]<br />
|programming/some hardware<br />
|Hardware development<br />
|Mountain View/Oakland, CA<br />
|<br />
|<br />
|-<br />
|[[User:codyl|J.Cody]]<br />
|programming<br />
|Application development<br />
|Mountain View, CA<br />
|<br />
|<br />
|-<br />
|[[User:csnellman|Carl Snellman]]<br />
|Programming<br />
|Application development/Location based services<br />
|Palo Alto, CA<br />
|<br />
|<br />
|-<br />
|[[User:krid|Dirk Bergstrom]]<br />
|programming<br />
|"Procmail" for incoming calls/messages; GPS tracking<br />
|Mountain View, CA<br />
|<br />
|<br />
|-<br />
|[[User:xyphus|Marco Barreno]]<br />
|programming<br />
|Power user/app development<br />
|Berkeley, CA<br />
|<br />
|<br />
|-<br />
|[[User:Elektrolott|Lothar]]<br />
|programming<br />
|Waiting for GTA02<br />
|Morgan Hill, CA<br />
|<br />
|<br />
|-<br />
|[[User:rabble|Rabble]]<br />
|programming<br />
|App Development & Geowanking<br />
|San Francisco, CA<br />
|<br />
|<br />
|-<br />
|[[User:rtyler|R. Tyler Ballance]]<br />
|Development<br />
|Mobile Mono Applications<br />
|San Francisco, CA<br />
| [[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:cfl|Cfl]]<br />
|Software/Architecture<br />
|Mobile Applications<br />
|San Jose, CA<br />
| [[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Pdesai|Pranav]]<br />
|programming, linux, sysadmin.<br />
|Applications, GPS, bluetooth<br />
|Sunnyvale, CA<br />
| [[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Michaelshiloh|Michael Shiloh]]<br />
|Programmer, teacher<br />
|Developer Relations and Evangelist for OpenMoko<br />
|San Francisco, CA (live and work in the city)<br />
| [[Image: Moko.jpg|center]]<br />
| [[Image: MokoBox.jpg|center]]<br />
|-<br />
|[[User:Maratgothix|Omar Green]]<br />
|Architect/Technologist<br />
|H/W, S/W, Intelligent services<br />
|San Francisco, CA<br />
| [[Image: Moko.jpg|center]]<br />
| [[Image: MokoBox.jpg|center]]<br />
|-<br />
|[[User:mgoff|Michael Goff]]<br />
|Software Programmer<br />
|Applications<br />
|San Francisco, CA<br />
| [[Image: Moko.jpg|center]]<br />
| [[Image: MokoBox.jpg|center]]<br />
|-<br />
|[[User:wisp|Joshua Layne]]<br />
|Programming<br />
|GPS/mapping/location aware apps, intelligent time/date mgmt<br />
|Half Moon Bay, CA<br />
|<br />
|<br />
|-<br />
<br />
[[Category:Community]]</div>Wisphttp://openmoko.org/wiki/Neo_1973_GPSNeo 1973 GPS2007-09-11T05:57:35Z<p>Wisp: /* Possible GPS programs */</p>
<hr />
<div>The Neo1973 device contains an integrated GPS. The particular device<br />
is marketed as an AGPS, and there is some [[Hardware:AGPS |<br />
discussion]] available as to what significance that "A" might have.<br />
<br />
All purchased phones do not include the GPS binary driver. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html]<br />
<br />
In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included <br />
in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device). <br />
<br />
There is an ongoing effort to write a Free Software<br />
program that could be used instead of this binary-only program. <br />
<br />
See<br />
[[Hammerhead/Protocol]] for details and the latest status.<br />
<br />
Some scripts for those with the binary are on [[GPS_scripts]]<br />
<br />
=== Possible GPS programs ===<br />
<br />
As people develop more sophisticated GPS applications, please note them here.<br />
<br />
Here are some ideas for possibilities:<br />
<br />
* Cairo-based mapping<br />
* Routing<br />
* [[Openstreetmap]] a map viewer, annotation, and editing system.<br />
* [[GPS-Trail]] a simple trail logger.<br />
* [[GPS_Navigation#roadmap|roadmap]] mapping system using freely available maps (census tiger, DGLib, shapefiles).<br />
<br />
* [http://lists.openmoko.org/pipermail/community/2007-July/007252.html collection of ideas]<br />
<br />
[[Category:GPS]]</div>Wisphttp://openmoko.org/wiki/Neo_1973_GPSNeo 1973 GPS2007-09-10T18:33:52Z<p>Wisp: /* Possible GPS programs */</p>
<hr />
<div>The Neo1973 device contains an integrated GPS. The particular device<br />
is marketed as an AGPS, and there is some [[Hardware:AGPS |<br />
discussion]] available as to what significance that "A" might have.<br />
<br />
All purchased phones do not include the GPS binary driver. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html]<br />
<br />
In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included <br />
in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device). <br />
<br />
There is an ongoing effort to write a Free Software<br />
program that could be used instead of this binary-only program. <br />
<br />
See<br />
[[Hammerhead/Protocol]] for details and the latest status.<br />
<br />
Some scripts for those with the binary are on [[GPS_scripts]]<br />
<br />
=== Possible GPS programs ===<br />
<br />
As people develop more sophisticated GPS applications, please note them here.<br />
<br />
Here are some ideas for possibilities:<br />
<br />
* Cairo-based mapping<br />
* Routing<br />
* [[Openstreetmap]] a map viewer, annotation, and editing system.<br />
* [[GPS-Trail]] a simple trail logger.<br />
* [[roadmap]] mapping system using freely available maps (census tiger, DGLib, shapefiles).<br />
<br />
* [http://lists.openmoko.org/pipermail/community/2007-July/007252.html collection of ideas]<br />
<br />
[[Category:GPS]]</div>Wisp