date:20061130

On 11/30/06 7:42 PM, "Robert Michel" <[EMAIL PROTECTED]> wrote:

> But you remind us ;)) that dual-sim is an intereting feature and
> Sean still haven'd answerd:
>>> 
>>> #Will the Neo1973 support "dual-SIM" with SPST?#
>>> 
> This is needed to use products like from simore.ch or dual-sim.com
> would work.

I'll check tomorrow at work!

-Sean


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Please think about incrementel sync Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone

2006-11-30 Thread Ole Tange


On 11/30/06, Robert Michel <[EMAIL PROTECTED]> wrote:


A little bit the same with normal files. How do you think that a file
will make a diff with itself (the modification) before it is modificated
and save the modicated version + all diffs since last replication with
the server.


Wouldn't rsync solve that? Use the backup option and -e ssh.

/Ole

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Will the Neo1973 support Dual-SIM with SPST? Re: Using UART/SPI... for swithing 2-8 SIM-cards Re: [Neo1973] Hardware access: additional solder points ; )

2006-11-30 Thread Thomas MARCHESSEAU


Sean Moss-Pultz wrote:

On 11/30/06 7:42 PM, "Robert Michel" <[EMAIL PROTECTED]> wrote:

  

But you remind us ;)) that dual-sim is an intereting feature and
Sean still haven'd answerd:



#Will the Neo1973 support "dual-SIM" with SPST?#



This is needed to use products like from simore.ch or dual-sim.com
would work.



I'll check tomorrow at work!
  
:) 


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Text entry

2006-11-30 Thread Christopher Heiny

On Thursday 30 November 2006 00:17, Alexander Steinert scribbled in crayon 
on the back of a kid's menu:
> What do you think about T9? Touching instead pressing keys could
> speed up the process noticable. And the user has the option to fit the
> geometry of keys to his fingers.

Another option is JetKeys
   http://www.jet-way-tech.com/home.html
(sorry about the annoying infinitely repeating Flash demo) although I don't 
know if it is subject to IP issues or not.

There is IBM's ShapeWriter (aka Shark) that I mentioned previously.  I don't 
recall if that there's any IP on that one, either.
http://www.almaden.ibm.com/u/zhai/shapewriter.htm

Jumpx (aka Fitaly) already has an open source implementation at
   http://jumpx.sourceforge.net/
Though it is stylus oriented in the current implementation.

Apparently the Xerox patent on single stroke character recognition (the one 
that pushed Graffiti out of PalmOS) was ruled invalid a couple of years ago 
(just discovered that today - doh!), making something like Graffiti an 
option.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Text entry

2006-11-30 Thread Christopher Heiny

And another one...

Quickwriting is stylus based, but might be converted to fingers.
http://mrl.nyu.edu/~perlin/demos/quikwriting.html
The bottom of the page mentions "licensing for commercial use".  However, 
since it's been around for 8 years now without any apparent commercial 
implementations, they might be willing to release it to the OS world.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On Thu, 2006-11-30 at 09:48 +0100, Sven Neuhaus wrote:
> Sean Moss-Pultz wrote:
> > > On 11/30/06 3:32 AM, "Robert Michel" <[EMAIL PROTECTED]> wrote:
> >> >> But this light sensor could also combined with localisation, time and
> >> >> provile (or movement sensor)
> >> >> E.g. when I'm at home and the light sensor detects light at 2 o'clock
> >> >> in the morning, I will still be reachable for calls from my frinds.
> > >
> > > Combined with automatically switching profiles (AGPS stuff) this is
> > > really an amazing idea.
> 
> Agreed - fascinating possibilities! FYI, the Motorola L2 phone has a light
> sensor (it toggles the keypad light), so it's been done already, but - of
> course - the closed software on that phone doesn't fully utilize it...

I'm assuming that acquiring/monitoring the microphone input doesn't come
for free.. but ambient noise level could also be used as an indicator of
activity - either polling for one second every minute or so, or (if the
ADC can be directed to acquire at a lower data rate) a continuous sample
over a longer period of time -- you don't require too much resolution to
monitor the presence of ambient noise.

You would want to base it on an probabilistic analysis in either case,
else it might pick up car headlights swinging across the window, a
neighbours security light being triggered by raccoons, etc.

Oh wait, that wouldn't work... if you had the phone in the bedroom it
would allow incoming calls if you were snoring.

Bah.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Software Development

2006-11-30 Thread Terrence


Koen,

Interesting, thanks. We'll have a look at it.

-- Terrence

Koen Kooi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Terrence schreef:

The Java Mobile & Embedded Community (www.mobileandembedded.org)
is very interested in getting Java ME ported to OpenMoko.


You can start right now by adding phoneme and javac to openembedded
(www.openembedded.org), which would make phoneme available to distributions like
openzaurus, openezx and angstrom as well.
Unfortunately I'm not allowed to share my recipes and patches for cvm I did 2 
years ago,
but I can hint that can't use the existing .mk files, since most of their 
assumptions are
wrong.

regards,

Koen

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFbrprMkyGM64RGpERAmRQAJ4w3OODEFfF+sCo3KOVwvqKZB9r0wCfUB8Y
CT3qmtcwtCEZn8zcaPuGmlY=
=ay08
-END PGP SIGNATURE-

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Mesh networking with Openmoko

2006-11-30 Thread Evgeny


Hello
Thanks for releasing such a good alternative phone.
After WiFi enter in the picture in v2 (crossed fingers), Neo1973 platform
will turn most suitable piece of hardware to run some kind of mesh
networking protocol.
I'll try Netsukuku http://netsukuku.freaknet.org/
Some reasons pro:
minimalistic in processor & memory consumption
there is already an netsukuku-internet gateway
just dreaming on possibility to when I'll get close to my friend with
Neo (netsukuku included) two netsuskuku daemons on the phones will
decide automatically, decision will be based on AGPS data, to switch
from Internet/Intranet
gateway connectivity to physical network.
Then my call (data transfer) will switch from VoIP to VoP2P
(or data connection will turn much _faster_).
The same thing when I'll came home: syncing with desktop/laptop
will turn on automatically on _fast_ WiFi line
On you work meting phones will create mesh network it will be possible
to run presentation from one Neo on many.
And so on.

I'll post on netsukuku mail list list concerning Neo1973/Openmoko
as a new promising platform

any comments or fresh Ideas?

P.S. Second thought, I want packet radio to, for long distance network
connects but not in the phone, standalone.

Nice day to all
Evgeny

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Mesh networking with Openmoko





On Thu, 30 Nov 2006, Evgeny wrote:


Hello
Thanks for releasing such a good alternative phone.
After WiFi enter in the picture in v2 (crossed fingers), Neo1973 platform
will turn most suitable piece of hardware to run some kind of mesh
networking protocol.


Very clever idea. I look forward to learning more in the sure-to-follow
discussion.


P.S. Second thought, I want packet radio to, for long distance network
connects but not in the phone, standalone.


With the USB host port, you can plug your Neo to the
Universal Software Radio Peripheral, an implementation of Gnu Radio Hardware:

  http://comsec.com/wiki?UniversalSoftwareRadioPeripheral

Then you run GNU radio on the Neo.

I know, it's huge. But just an example of what's possible, and of course it
could be made smaller if there was the demand.

Michael

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

23C3 27.-30.12. 2006 Berlin -- Chaos Computer Club conference with interesting program ; )

2006-11-30 Thread Robert Michel

Salve!

Today the CCC.de published the "Fahrplan" the program for their
23. conference, called 23C3:
https://events.ccc.de/congress/2006/Fahrplan/

First quick view to show several lectures that would be very interesting 
for us ;)))
Ok this is a long list - I will not only make you think
that it would be fine to go to Berlin or to see the video
tapes in January - before the 23C3 we could also 
- discuss interesting parts 
- find out who of us will go there
- collect interesting quetions
- and maybe have an OpenMoko/Neo1973 community meeting in Berlin 

Ok - just an overview - add when an interesting lecture is missing
and try split our discussion to seperate lectures ;)



Harald Welte - 
   Project Sputnik
Project Sputnik is the real-time in-building location tracking system
present at the 23C3. The Sputnik is a small active 2.4GHz RF Beacon,
whose signal is picked up by one or multiple of the 20+ Sputnik base 
stations installed in the event venue (bcc). Attendees of the 23C3 are 
able to voluntarily participate in this system by purchasing an 
inexpensive Sputnik transponder which they can carry with them 
during the whole event.   
  
In order to make this project attractive to hackers, the Sputnik
hardware schematics and firmware source code will be published on the
first day of the event,enabling hackers to enhance/replace the exiting 
firmware, and to add new applications such as peer-to-peer communication
between multiple Sputniki.
  
The location data (both raw and processed) will be available to the
public via the congress network. This means that everyone has access to
all data.  
  
The intention of the project is mainly to demonstrate what kind of
surveillance is possible using off-the-shelf inexpensive technology, and
to make hackers interested into exploring potential positive use cases for it. 
https://events.ccc.de/congress/2006/Fahrplan/events/1736.en.html
http://www.openbeacon.org/


Andreas Bogk, Hannes Mehnert -
   Design and Implementation of an object-oriented, secure TCP/IP Stack
We present a domain-specific language (DSL) capable to describe
ad-hoc defined protocols like TCP/IP. Additionally we developed other
libraries, like a flow graph for packet processing and a layering mechanism 
for protocol stacking, to get a complete TCP/IP stack.  
[...]
https://events.ccc.de/congress/2006/Fahrplan/events/1656.en.html 
 

pallas -
   How To Design A Decent User Interface
Take a look at software from a user's point of view and improve your
applications Prepare to be brainwashed! This talk wants you to switch from the
developer's perspective to that of an average user to design better UIs.  
[...]
http://events.ccc.de/congress/2006/Fahrplan/events/1433.en.html


tof (Christof Vollrath) -
   Java wird Groovy 
Eine Einführung in die neue, dynamische Sprache für das
Java-Ökosystem 
Groovy ist eine neue, dynamische Sprache für die Java-VM. Sie greift
Konzepte von Smalltalk, Python und Ruby auf und integriert Sie nach
Java. Die Integration ist leichtgängig, da die Syntax hinreichend ähnlich 
zu Java ist und reibungslos bestehende Java-Bibliotheken genutzt werden können. 
 

(New dynamic languages for the Java-VM. Integreation of concepts
of smalltalk, python and ruby into Java.)
[...]
https://events.ccc.de/congress/2006/Fahrplan/events/1419.en.html


Steven J. Murdoch -
   Detecting temperature through clock skew
Hot or Not: Defeating anonymity by monitoring clock skew to remotely
detect the temperature of a PC
By requesting timestamps from a computer, a remote adversary can find
out the precise speed of its system clock. As each clock crystal is
slightly different, and varies with temperature, this can act as a 
fingerprint of the computer and its location. 
[...]
https://events.ccc.de/congress/2006/Fahrplan/events/1513.en.html 


Melanie Rieback -
   A Hacker's Toolkit for RFID Emulation and Jamming
Radio Frequency Identification (RFID) tags are remotely-powered data
carriers, that are often touted as a "computer of the future", bringing
intelligence to our homes and offices, optimizing our supply chains, and 

keeping a watchful eye on our pets, livestock, and kids.  
  
However, many RFID systems rely upon the integrity of RFID tag data
for their correct functioning. It has never been so easy to interfere
with RFID systems; we have built a handheld device that performs RFID 
tag emulation and selective RFID tag jamming (sortof like a personal
RFID firewall). Our device is compatible with the ISO 15693/14443A 
(13.56 MHz) standards, and fits into a shirt pocket.
This presentation will explain the "nuts and bolts" of how tag spoofing
and selective RFID jamming work, and will conclude by demonstrating this 
functionality. 
[...]
https://events.ccc.de/congress/2006/Fahrplan/events/1597.en.html 


Andreas Krennmair -
   Secure Network Server Programming on Unix 
[...]
https://events.ccc.de/congress/2006/Fahrplan/events/1446.en.html
https://events.ccc.de/congress/2006/Fahrplan/attachments/1119-tr

Re: Light sensor

On 11/30/06, Richard Franks <[EMAIL PROTECTED]> wrote:

On Thu, 2006-11-30 at 09:48 +0100, Sven Neuhaus wrote:
> Sean Moss-Pultz wrote:
> > > On 11/30/06 3:32 AM, "Robert Michel" <[EMAIL PROTECTED] >
wrote:
> >> >> But this light sensor could also combined with localisation, time
and
> >> >> provile (or movement sensor)
> >> >> E.g. when I'm at home and the light sensor detects light at 2
o'clock
> >> >> in the morning, I will still be reachable for calls from my
frinds.
> > >
> > > Combined with automatically switching profiles (AGPS stuff) this is
> > > really an amazing idea.
>
> Agreed - fascinating possibilities! FYI, the Motorola L2 phone has a
light
> sensor (it toggles the keypad light), so it's been done already, but -
of
> course - the closed software on that phone doesn't fully utilize it...

I'm assuming that acquiring/monitoring the microphone input doesn't come
for free.. but ambient noise level could also be used as an indicator of
activity - either polling for one second every minute or so, or (if the
ADC can be directed to acquire at a lower data rate) a continuous sample
over a longer period of time -- you don't require too much resolution to
monitor the presence of ambient noise.

You would want to base it on an probabilistic analysis in either case,
else it might pick up car headlights swinging across the window, a
neighbours security light being triggered by raccoons, etc.

Oh wait, that wouldn't work... if you had the phone in the bedroom it
would allow incoming calls if you were snoring.

Bah.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

It almost sounds like we should make a plugin framework for availability
detection, with plugins for the light sensor, PIM calendar, microphone (can
we set an interrupt if the ADC receives a level greater than X?) and so on
and so forth as people figure out other ways to detect it

--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Sensors

2006-11-30 Thread Paul Jimenez


I read the thread about a light sensor and think it's really a good
idea for several reasons, not the least of which are that photodiodes
are both simple to interface to and cheap, so the price/performance
tradeoff here if even one or two reallly good applications for it 
are found (and several ideas have been presented) is really good.

Thinking about other similar inputs that might also be good, I came
up with:

  * Temperature sensor - It might be able to figure out if it was in
  your pocket vs. in your hand vs. sitting on the desk.  Again though,
  this is such a simple and cheap thing to add that it could, I think,
  be included just on the off chance someone will come up with a great
  use for it.

  * Motion sensor - lots of potential uses: shake your phone to rapidly
  to get to the main menu. Tilt scrolling, and application switching
  by tapping the sides of the phone (ala the 'Smackbook Pro' hack at
  http://blog.medallia.com/2006/05/smacbook_pro.html).  Or maybe it should
  scream when you drop it to make sure you know you've dropped it so you
  don't leave it behind.

  * Consumer-level IR - too late for v1 probably, but maybe v2 ? - useful
  not only for docking/interfacing with printers, etc, but also for
  turning your phone into the ultimate TV remote :)  The Agenda handheld
  had this feature and I've heard of people who are using the little thing
  for nothing *but* this - they've replaced their pile of remotes with a
  (now fairly dated) ~$100 linux palmtop that never loses its IR settings.

  * some number of plain old LEDs - useful for message-waiting
  indicators (for voicemail, SMS, email, and IM) for example, without
  having to power up the display. Bonus points for multi-color LEDs.

Oh, and I was glad to hear there will be vibrate-mode hardware, but what
about speakerphone? 

And is the touch-screen a multitouch type? or single? I've gotten
quite used to the 'point with one finger, scroll with two' features on
my Macbook Pro.

PS: Add my vote for bluetooth.

  --pj


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor


<...snip...>


 You would want to base it on an probabilistic analysis in either case,
 else it might pick up car headlights swinging across the window, a
 neighbours security light being triggered by raccoons, etc.

 Oh wait, that wouldn't work... if you had the phone in the bedroom it
 would allow incoming calls if you were snoring.



It almost sounds like we should make a plugin framework for availability
detection, with plugins for the light sensor, PIM calendar, microphone (can
we set an interrupt if the ADC receives a level greater than X?) and so on
and so forth as people figure out other ways to detect it


Yes, plugin framework is a great idea. Perhaps someone will develop a quick
audio analysis filter that could tell the difference between snoring (don't
ring), office noise (ok to ring) and a baby's cry (don't ring).

Temperature sensor would be another sensor. Perhaps even moisture sensor? Be
alerted if you leave your Neo out in the rain or put it in the laundry.

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

On Thu, 2006-11-30 at 12:00 +0800, Sean Moss-Pultz wrote:
> On 11/30/06 6:12 AM, "Richard Franks" <[EMAIL PROTECTED]>
> wrote:
> 
> > Unless it already exists, I'll do some research tonight.. anyone
> > interested in joining the coding/design effort?
> 
> CC me. I'd love to follow your work. I have very limited time now, but I'll
> see if there is anything we can do to support your efforts.

Hi,
  any spare(ish) cycles you have I'd vote for using them to put up a
basic community wiki - makes it easier for project ideas to get off the
ground when there's a common source for information, not least with
relation to the ability to upload design diagrams + status tracking.

Yup - it could become an incoherent jumble, but as a stop-gap until the
repositories/tracking are in place, it would be ideal.

Thanks,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

2006-11-30 Thread Koen Kooi

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard Franks schreef:
> On Thu, 2006-11-30 at 12:00 +0800, Sean Moss-Pultz wrote:
>> On 11/30/06 6:12 AM, "Richard Franks" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Unless it already exists, I'll do some research tonight.. anyone
>>> interested in joining the coding/design effort?
>> CC me. I'd love to follow your work. I have very limited time now, but I'll
>> see if there is anything we can do to support your efforts.
> 
> Hi,
>   any spare(ish) cycles you have I'd vote for using them to put up a
> basic community wiki - makes it easier for project ideas to get off the
> ground when there's a common source for information, not least with
> relation to the ability to upload design diagrams + status tracking.
> 
> Yup - it could become an incoherent jumble, but as a stop-gap until the
> repositories/tracking are in place, it would be ideal.

You could use the http://www.linuxtogo.org/gowiki/ wiki for that till the 
official wiki
goes live in 2007.

regards,

Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFby8AMkyGM64RGpERApACAJ9Dp1IhIMBjsKplFdvOgcH94fyq7ACcCcRA
e2EV4o5DmwPQ8tFPs+v7hMc=
=ij9f
-END PGP SIGNATURE-

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room


Hi,
 any spare(ish) cycles you have I'd vote for using them to put up a
basic community wiki - makes it easier for project ideas to get off the
ground when there's a common source for information, not least with
relation to the ability to upload design diagrams + status tracking.

Yup - it could become an incoherent jumble, but as a stop-gap until the
repositories/tracking are in place, it would be ideal.


I second the motion.

If Sean won't have the time for a while, does it make sense to stick up such a
wiki in some temporary space, e.g. at openmoko or something? Heck, I could
even host it on my home server if no one else wants to.

Michael

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: 23C3 27.-30.12. 2006 Berlin -- Chaos Computer Club conference with interesting program ; )

2006-11-30 Thread Michael 'Mickey' Lauer

My health permitting (I have a hell of a stomach flu at the moment),
I'll be in Berlin for the 23c3, if anyone of you want to meet Harald
and me for an OpenMoko Q/A and brainstorming session, I'm all ears.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: (re)charging control

2006-11-30 Thread Stefan Schmidt

Hello.

On Wed, 2006-11-29 at 21:43, Stefan Schmidt wrote:
> 
> Personally I would even like a dock/craddle.
> 
> 1. It should have connector for both, charging and data. (Should be no
> problem at the neo as it charges over usb.)
> 
> 2. Slot for second battery charging.
> 
> 3. It should be robust. Something like the palm docks.
> 
> 4. Not sure about a button which can trigger an action. We should be
> able to automate the sync with udev anyway).

5. Two-color-LED for indicate if the battery is already fully charged.
If we also have a battery charging bay, we need a second LED on the
back for the second battery.

regards
Stefan Schmidt


signature.asc
Description: Digital signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

On Thu, 2006-11-30 at 20:20 +0100, Koen Kooi wrote:

> >   any spare(ish) cycles you have I'd vote for using them to put up a
> > basic community wiki - makes it easier for project ideas to get off the
> > ground when there's a common source for information, not least with
> > relation to the ability to upload design diagrams + status tracking.
> > 
> > Yup - it could become an incoherent jumble, but as a stop-gap until the
> > repositories/tracking are in place, it would be ideal.
> 
> You could use the http://www.linuxtogo.org/gowiki/ wiki for that till the 
> official wiki
> goes live in 2007.

I see this as an issue of centralisation vs. fragmentation. I'd prefer
to have one source to go to for all things Moko. :-)

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote:
>
> It almost sounds like we should make a plugin framework for
> availability detection, with plugins for the light sensor, PIM
> calendar, microphone (can we set an interrupt if the ADC receives a
> level greater than X?) and so on and so forth as people figure out
> other ways to detect it

I'd prefer something a little more generic.. how about considering it as
a network of transforms? Where each transform is a simple plugin, of the
sink/process/source variety?

For example, the physical hardware would be a series of available
datasources, I'll start with the simplest:

(microphone voltage sample)

So a voice recording utility could subscribe to the (microphone voltage
sample) for a duration of its choosing - and it now has a recording.

Except, you may want to filter out snaps and crackles.. so you load the
filtering transform:

(microphone voltage sample) -> (snap and crackle filter) -> (processed
microphone sample)

The application above can now subscribe to the (processed microphone
sample) instead of the raw voltage sample, if it chooses.

Now say we want to know what the average volume is over one second. We
load another transform (average amplitude), and pass it the parameter
duration:1000ms:

(microphone voltage sample) ->  (average amplitude) -> (average
amplitude:1000ms)

You could have another application which wants to know what the average
is over two seconds.. so now the (average amplitude) transform is
servicing two datasources:
(average amplitude)
  -> (average amplitude:1000ms)
  -> (average amplitude:2000ms)

So in the end, the (activity-monitoring) transform would be built from:

(microphone voltage sample) -> (average amplitude) -> (input1)
(light sensor value) -> (average amplitude) -> (input2)
(time of day) -> (schedule comparison) -> (input3)
(time since last user activity) -> (input4)
etc etc..

But in the end, you have system-wide consensus with regards whether the
user is active, and each application which cares just has to subscribe
to the (activity-monitoring) data-source to find out.

There's a *lot* of implementation details I've skipped over, but in
essence I think such a system gives the power to grant conceptual
abstraction and system-wide consistency, with simplified and less
redundant development.

Er, in other words, I can't think of another way in which we could avoid
the scenario whereby you have two similar applications which come to
separate conclusions based upon the same inputs - one concludes the user
is awake, the other concludes that the user is not.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On 11/30/06, Richard Franks <[EMAIL PROTECTED]> wrote:

On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote:
>
> It almost sounds like we should make a plugin framework for
> availability detection, with plugins for the light sensor, PIM
> calendar, microphone (can we set an interrupt if the ADC receives a
> level greater than X?) and so on and so forth as people figure out
> other ways to detect it

I'd prefer something a little more generic.. how about considering it as
a network of transforms? Where each transform is a simple plugin, of the
sink/process/source variety?

For example, the physical hardware would be a series of available
datasources, I'll start with the simplest:

(microphone voltage sample)

So a voice recording utility could subscribe to the (microphone voltage
sample) for a duration of its choosing - and it now has a recording.

Except, you may want to filter out snaps and crackles.. so you load the
filtering transform:

(microphone voltage sample) -> (snap and crackle filter) -> (processed
microphone sample)

The application above can now subscribe to the (processed microphone
sample) instead of the raw voltage sample, if it chooses.

Now say we want to know what the average volume is over one second. We
load another transform (average amplitude), and pass it the parameter
duration:1000ms:

(microphone voltage sample) ->  (average amplitude) -> (average
amplitude:1000ms)

You could have another application which wants to know what the average
is over two seconds.. so now the (average amplitude) transform is
servicing two datasources:
(average amplitude)
  -> (average amplitude:1000ms)
  -> (average amplitude:2000ms)

So in the end, the (activity-monitoring) transform would be built from:

(microphone voltage sample) -> (average amplitude) -> (input1)
(light sensor value) -> (average amplitude) -> (input2)
(time of day) -> (schedule comparison) -> (input3)
(time since last user activity) -> (input4)
etc etc..

But in the end, you have system-wide consensus with regards whether the
user is active, and each application which cares just has to subscribe
to the (activity-monitoring) data-source to find out.

There's a *lot* of implementation details I've skipped over, but in
essence I think such a system gives the power to grant conceptual
abstraction and system-wide consistency, with simplified and less
redundant development.

Er, in other words, I can't think of another way in which we could avoid
the scenario whereby you have two similar applications which come to
separate conclusions based upon the same inputs - one concludes the user
is awake, the other concludes that the user is not.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

ok, I was thinking more like /dev/random pulls seeds from all the devices
registered with it, or the way that mythtv detects commercials based on
plugins, create a virtual device that returns a read of 0-255 based on the
probability that you're available... as each device(light sensor, etc) is
added, it would register with /dev/available as a detection device, and
provide a function to return another byte value of what it thinks the user's
doing.  the available device would perform some kind of heuristic on this.
then when a call comes in, the receiver daemon checks with /dev/available,
then uses the value returned to decide what to do.  different events could
have different values (e.g. the girlfriend calls, it'll ring if the value is
greater than 3 (basically not dead... probably from a VOC sensor) but if the
bill collectors call, the value better be 250+ or I'm not getting bothered)

--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On Thu, 2006-11-30 at 13:47 -0700, Jeff Andros wrote:


> ok, I was thinking more like /dev/random pulls seeds from all the
> devices registered with it, or the way that mythtv detects commercials
> based on plugins, create a virtual device that returns a read of 0-255
> based on the probability that you're available... as each device(light
> sensor, etc) is added, it would register with /dev/available as a
> detection device, and provide a function to return another byte value
> of what it thinks the user's doing.  the available device would
> perform some kind of heuristic on this.  then when a call comes in,
> the receiver daemon checks with /dev/available, then uses the value
> returned to decide what to do.  different events could have different
> values ( e.g. the girlfriend calls, it'll ring if the value is greater
> than 3 (basically not dead... probably from a VOC sensor) but if the
> bill collectors call, the value better be 250+ or I'm not getting
> bothered)

As a matter of personal preference, I'd prefer to avoid sticking
abstracted concepts into /dev - start with /dev/available and you end up
with 100's of entries
including /dev/probability-of-the-user-feeling-like-a-grilled-cheese-sandwich 
-- it's not as scalable.

A 'plugin' is a high-level user concept - the transforms I described
also work as 'plugins', but I think we're talking about the same thing..
so written down in transforms, what you describe would be:

[multiple sinks] =>  -> (user availability) 

And whether or not the phone rings when a call comes in:

Sinks:
(caller)
(user availability) 

Process:
compares scores

Sources:
(ring/silent notification/vibrate/ignore)


The difference in implementation is moving away from a rigid rule-based
system (there was an article posted a day or so ago describing these) as
with rules, each component decides too much upon its own, and it has no
way to deal with rule-conflicts as each application is left to construct
its own closed-decision-chain. In this system, each application doesn't
have to waste system resources (read:battery life) reinventing the
wheel.

>From your example, say 'availability' was a datasource between 0-255,
with user-defined cutoffs (e.g. 250 = anyone but smelly john can call
me) then the application still has the freedom to override the
system-consensus, but such deviations are explicit.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

2006-11-30 Thread Ivan Lucas

On Thursday 30 November 2006 18:51, Jeff Andros wrote:
> It almost sounds like we should make a plugin framework for availability
> detection, with plugins for the light sensor, PIM calendar, microphone (can

Talking about using the Microphone as a sensor reminded me of an idea I had 
some time ago, I'm regularly in noisy places such as crowded railway stations 
or bars.  Wouldn't it be good if the neo1973 could check the ambient noise 
level before it started to ring, adjusting the ring tone volume to be heard 
over the background noise.  i.e. ring nice and quietly (or on vibrate) when 
I'm in a library, or ring at full volume when I'm in a noisy bar.

-Ivan

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

A plea for reasonable thread names (was RE: Please think about incrementel sync Re: Another idea for anapplication for the Neo: Instant sync to web page duplicatinginfo on phone

2006-11-30 Thread Ken Yale

Hello,

The thread name:
"RE: Please think about incrementel sync Re: Another
 idea for anapplication for the Neo: Instant sync to
 web page duplicatinginfo on phone"
is too long, and has drifted from the point.

Can you rename the thread when appropriate, and shorten it, please?

(The new thread name of this message is a good example why the change is
needed).

Thanks,
Ken

-Original Message-
From: Ole Tange [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 30, 2006 07:49
To: Openmoko List
Subject: Re: Please think about incrementel sync Re: Another idea for
anapplication for the Neo: Instant sync to web page duplicatinginfo on
phone

On 11/30/06, Robert Michel <[EMAIL PROTECTED]> wrote:

> A little bit the same with normal files. How do you think that a file 
> will make a diff with itself (the modification) before it is 
> modificated and save the modicated version + all diffs since last 
> replication with the server.

Wouldn't rsync solve that? Use the backup option and -e ssh.

/Ole

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On 11/30/06, Richard Franks <[EMAIL PROTECTED]> wrote:

On Thu, 2006-11-30 at 13:47 -0700, Jeff Andros wrote:

> ok, I was thinking more like /dev/random pulls seeds from all the
> devices registered with it, or the way that mythtv detects commercials
> based on plugins, create a virtual device that returns a read of 0-255
> based on the probability that you're available... as each device(light
> sensor, etc) is added, it would register with /dev/available as a
> detection device, and provide a function to return another byte value
> of what it thinks the user's doing.  the available device would
> perform some kind of heuristic on this.  then when a call comes in,
> the receiver daemon checks with /dev/available, then uses the value
> returned to decide what to do.  different events could have different
> values ( e.g. the girlfriend calls, it'll ring if the value is greater
> than 3 (basically not dead... probably from a VOC sensor) but if the
> bill collectors call, the value better be 250+ or I'm not getting
> bothered)

As a matter of personal preference, I'd prefer to avoid sticking
abstracted concepts into /dev - start with /dev/available and you end up
with 100's of entries
including
/dev/probability-of-the-user-feeling-like-a-grilled-cheese-sandwich -- it's
not as scalable.

I hadn't thought about this, I figured since most of the sources should be
other devices, we wouldn't get filled up, simply put each device would
provide a pointer to a method extending the standard character driver from
within the device driver, and we'd include this functionality within the
kernel, but you're right, if we have to implement more than just one virtual
device, we'd better find another place to stick this functionality

A 'plugin' is a high-level user concept - the transforms I described

also work as 'plugins', but I think we're talking about the same thing..
so written down in transforms, what you describe would be:

[multiple sinks] =>  -> (user availability)

And whether or not the phone rings when a call comes in:

Sinks:
(caller)
(user availability)

Process:
compares scores

Sources:
(ring/silent notification/vibrate/ignore)

The difference in implementation is moving away from a rigid rule-based
system (there was an article posted a day or so ago describing these) as
with rules, each component decides too much upon its own, and it has no
way to deal with rule-conflicts as each application is left to construct
its own closed-decision-chain. In this system, each application doesn't
have to waste system resources (read:battery life) reinventing the
wheel.

so you're suggesting that each application have access to the raw feeds from
each notification device?  there are definite  advantages, and you'd have a
more flexible system. I'm just thinking of a more asymetric system where
each device notifies /dev/available device when something changes... this
would also put us into kernel mode for computing (I'm not sure if this is
good or bad... or both).  raw access to the sensor feeds would be excellent
because I could differentiate between laying on the desk in the light in the
library (I'm probably across the room... ring louder, don't vibrate) or in
my pocket in my car.  the problem with doing it this way, is you'd need some
way to notify each application of all the sensors available at runtime, or
you re-compile each availability sensitive app for every combination of
sensors (having that many versions of software is sure to turn off Sean's
dad) there's definately more to think about on this one

From your example, say 'availability' was a datasource between 0-255,
with user-defined cutoffs (e.g. 250 = anyone but smelly john can call
me) then the application still has the freedom to override the
system-consensus, but such deviations are explicit.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Open Moko - GPL?

On 11/28/06, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote:

On 11/28/06 4:34 AM, "Steve Salazar" <[EMAIL PROTECTED]> wrote:

> 2. MicroSD:  Why?  Is the area used by full SD that much larger?   To me
> this seems like a huge tradeoff because for full size SD there are so
many
> amazing cards available, not just storage and they are fully compatible
with
> the form factor of many other devices without requiring an adapter.  I
won't
> be able to put a wifi adaptor in my openmoko phone just to save a couple
mm
> of card space?  I don't know if it is that simple, that is why I am
asking.

It's really not that simple. We're using a SD/SIM combo card to save
space.
It as design decision make very early on in our development cycle.
Largely,
based on the idea that we thought mini-SD was going to be a bump in the
road
to micro-SD. At this point the vendors making micro-SD cards are not
pushing
the size limits as fast as we had predicted. So for our second generation
device, we will review this again.

So does this mean that a standard SIM card won't work? Is it one of those
things where you have to cut up your sim card (wonder what do I tell
cingular when I bring THAT in)? or are we just talking about some kind of
combo system on the bus?
--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

2006-11-30 Thread Alexander Steinert


> Talking about using the Microphone as a sensor reminded me of an idea I had 
> some time ago, I'm regularly in noisy places such as crowded railway stations 
> or bars.  Wouldn't it be good if the neo1973 could check the ambient noise 
> level before it started to ring, adjusting the ring tone volume to be heard 
> over the background noise.  i.e. ring nice and quietly (or on vibrate) when 
> I'm in a library, or ring at full volume when I'm in a noisy bar.

I like this idea very much! Simple but really helpful, like light sensor
--> backlight.

Thumbs up!

Stony


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

2006-11-30 Thread Rod Whitby

Alexander Steinert wrote:
> 
>> Talking about using the Microphone as a sensor reminded me of an idea I had 
>> some time ago, I'm regularly in noisy places such as crowded railway 
>> stations 
>> or bars.  Wouldn't it be good if the neo1973 could check the ambient noise 
>> level before it started to ring, adjusting the ring tone volume to be heard 
>> over the background noise.  i.e. ring nice and quietly (or on vibrate) when 
>> I'm in a library, or ring at full volume when I'm in a noisy bar.
> 
> I like this idea very much! Simple but really helpful, like light sensor
> --> backlight.

See http://treoware.com/brightcam.html for a great example of how this works on 
the Treo 650 via a
third party utility which measures brightness through the camera, and sound 
levels through the
microphone.

This utility does everything mentioned in this thread so far I think.

-- Rod

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

External VGA output: What resources would this require? What applications does this enable?


I've always thought it would be useful to be able to plug a head mounted
display into my PDA. If nothing else, this would allow me to use smaller fonts
and still be able to read them.

Most head mounted displays take standard VGA input, and all PDAs (and smart
phones) use LCDs which of course are digital and thus completely different
from the analog raster/scan interface of VGA.

But I wonder: If the smart phone has a USB 2.0 host port (I know v1 is only
USB 1.0), then one could connect a USB video adapter, and then plug the the
head mounted display into that.

If we had such an ability, what cool applications and use cases would this
enable, that might justify it?

Interesting? Useful? Silly? Practical?

Michael

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

2006-11-30 Thread Alexander Steinert


> See http://treoware.com/brightcam.html for a great example of how this
> works on the Treo 650 via a third party utility which measures
> brightness through the camera, and sound levels through the
> microphone.
> 
> This utility does everything mentioned in this thread so far I think.

Hm, maybe the ambient noise around the phone is not enough info for the
ring volume. I could be in another room. If I had an AGPS-Mic-WiFi
implant, the neo could measure my distance and ambient noise and adjust
its ring volume accordingly. An alternative would be the an
AGPS-WiFi-Vibra implant.

Stony ;-)


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: External VGA output: What resources would this require? What applications does this enable?


On 11/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


I've always thought it would be useful to be able to plug a head mounted
display into my PDA. If nothing else, this would allow me to use smaller
fonts
and still be able to read them.

Most head mounted displays take standard VGA input, and all PDAs (and
smart
phones) use LCDs which of course are digital and thus completely different
from the analog raster/scan interface of VGA.

But I wonder: If the smart phone has a USB 2.0 host port (I know v1 is
only
USB 1.0), then one could connect a USB video adapter, and then plug the
the
head mounted display into that.

If we had such an ability, what cool applications and use cases would this
enable, that might justify it?

Interesting? Useful? Silly? Practical?

Michael

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community




It wouldn't help for HMD's, but the possibility of exporting application
displays out over USB networking (uhg) or something faster is intriguing as
well, you could have a full size keyboard and monitor for your app, without
worrying about any connections other than network.  I know this
functionality is built into X, but I've only used it for GUIs from a big bad
solaris box... don't know about from an embedded guy

--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

2006-11-30 Thread Tim Newsom

the problem with doing it this way, is you'd need some way to notify 
each application of all the sensors available at runtime, or you 
re-compile each availability sensitive app for every combination of 
sensors (having that many versions of software is sure to turn off 
Sean's dad) there's definately more to think about on this one


Are you thinking of not only notifying each application on the number of 
sensors.. (That would be easy enough in the api) but also to let them 
have access to the setup/configure api for each one?


Enumerating over each sensor that is active would be fairly easy using 
the plugin mechanism previously described...  If every plugin had the 
same output ranges... Say 0 to 255 or whatever and using the probability 
scenario he talked about the application would only need to know one 
interface, I.e. Availability.   As I understand the proposal, and I 
might be wrong, it would end up a heirarchy.  Lower level plugins could 
be accessed at any level but the common usage would be to build 
behaviors going up from the sensors and applications would interface 
with that... Is that right?


With that in mind, each plugin would register with some service which 
handles the interface to applications.  Each behavior created would do 
the same and gain access to the sensors available.  Then a control panel 
could be created to enable/disable some but not all plugins at the will 
of the user, though that would modify the behaviors, they would then act 
on the information currently available.


Seems like a fairly interesting concept.  Do I understand the concepts 
or am I missing something?


--Tim

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On 11/30/06, Tim Newsom <[EMAIL PROTECTED]> wrote:

> the problem with doing it this way, is you'd need some way to notify
> each application of all the sensors available at runtime, or you
> re-compile each availability sensitive app for every combination of
> sensors (having that many versions of software is sure to turn off
> Sean's dad) there's definately more to think about on this one

Are you thinking of not only notifying each application on the number of
sensors.. (That would be easy enough in the api) but also to let them
have access to the setup/configure api for each one?

Enumerating over each sensor that is active would be fairly easy using
the plugin mechanism previously described...  If every plugin had the
same output ranges... Say 0 to 255 or whatever and using the probability
scenario he talked about the application would only need to know one
interface, I.e. Availability.   As I understand the proposal, and I
might be wrong, it would end up a heirarchy.  Lower level plugins could
be accessed at any level but the common usage would be to build
behaviors going up from the sensors and applications would interface
with that... Is that right?

With that in mind, each plugin would register with some service which
handles the interface to applications.  Each behavior created would do
the same and gain access to the sensors available.  Then a control panel
could be created to enable/disable some but not all plugins at the will
of the user, though that would modify the behaviors, they would then act
on the information currently available.

Seems like a fairly interesting concept.  Do I understand the concepts
or am I missing something?

--Tim

yeah, I'm still trying to understand Richard's concept.  It sounds really
efficient, therefore cool, but I'm missing stuff

--
--Jeff
What DO you call whitewater when you live in the desert?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Bluetooth, WiFi, Australian Market

2006-11-30 Thread Ben

On 11/30/06, Joel Newkirk <[EMAIL PROTECTED]> wrote:

Ben wrote:

> I'm not sure what it's like in the rest of the world, but in Australia
> the price of mobile data (ie. GPRS/3G/etc.) is incredibly high.
> Relying on GPRS or quad band based methods of data access and
> synchronisation would push the phone into the too expensive category
> for many.

I'm in the eastern US, with T-Mobile. I get unlimited GPRS/EDGE data as
a $20/mo add-on. That's an unusual plan though - T-Mo don't offer it
anymore. (Internet3-VPN plan, FWIW) Speeds in the US have increased the
past few years, but so have average prices.

Damn! That's a nice price

Vodafone's pricing for 3G/GPRS (in rough USD equivalent):
5MB $16
100MB $24
300MB $40
1GB $80
http://tinyurl.com/fotzb
http://www.vodafone.com.au/business/bussol/databundle/databundle.jsp?gs=business&hd=bussol&st=databundle

Telstra's GPRS pricing (in rough USD equivalent):
2MB $20
5MB $44
10MB $68
http://www.telstra.com.au/mobile/networks/info/gprs.htm

Optus's doesn't seem to have GPRS pricing (they have a GSM/3G/WiFi
plan that is only for PCMCIA laptop cards). Vodafone, Optus and Three
are all pushing 3G, while Telsta is pushing NextG which is not worth
worrying about.

I too would be a sure sell with wifi and bluetooth, interested but
uncertain without. (with those two, it would replace both my zaurus and
my cell) I'd really like to see EDGE support too, but the 33k average I
get via GPRS is still quite useful.

EDGE hasn't really taken off in Australia, but 3G support would be
handy as it would give more options for carrier. WiMax is supposedly
going to be coming here at some stage, but no real sign of it yet.

Currently wifi VOIP handsets range in price from $200 to $600 USD. Food
for thought - that's solely a wifi phone. The ability to seamlessly and
automatically switch among various carrier options like
VOIP-over-wifi/VOIP-over-GPRS/GSM would be quite a selling point IMHO.

That would be a carrier dependent option, and one that would not be
smiled upon by most carriers as it would cut their revenue...
although, Optus' mobile internet option roams between WiFi, 3G and
GSM, however, it is priced at rate per MB comparable to other 3G
plans.

I'm happy to work out what the call goes through, I'd just like to
have the option to put it through something other than GSM.

Ben

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Text entry

On 12/1/06 12:27 AM, "Christopher Heiny" <[EMAIL PROTECTED]> wrote:

> Jumpx (aka Fitaly) already has an open source implementation at
>http://jumpx.sourceforge.net/
> Though it is stylus oriented in the current implementation.

I found this guy's idea quite interesting a while back:

http://www.strout.net/info/ideas/hexinput.html

-Sean


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On 12/1/06 12:05 AM, "Richard Franks" <[EMAIL PROTECTED]>
wrote:

> I'm assuming that acquiring/monitoring the microphone input doesn't come
> for free.. but ambient noise level could also be used as an indicator of
> activity - either polling for one second every minute or so, or (if the
> ADC can be directed to acquire at a lower data rate) a continuous sample
> over a longer period of time -- you don't require too much resolution to
> monitor the presence of ambient noise.

What do you mean "doesn't come for free"?

-Sean


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Open Moko - GPL?

On 12/1/06 7:45 AM, "Jeff Andros" <[EMAIL PROTECTED]> wrote:

> So does this mean that a standard SIM card won't work? Is it one of those
> things where you have to cut up your sim card (wonder what do I tell cingular
> when I bring THAT in)? or are we just talking about some kind of combo system
> on the bus? 

Hehe...if I made it so I standard SIM didn't work in this phone, I should be
publicly hanged. Don't worry, your Cingular SIM will work fine ;-)

-Sean

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Text entry

2006-11-30 Thread David Ormsbee

Hi folks,

So when I first heard about this phone, I mocked up this idea:

http://dave.hereticmonkey.com/musings/phone_keyboard.html

I had originally wanted to make something that would be compatible
with phones that have physical buttons (hence the 3x4 grid), but I'm
beginning to think that I should just give up on that and put a giant
spacebar button on the side.  Also, I never thought about making
capital letters by the way you slid your fingers off of a key before
reading this thread.  It sounds like an awesome idea.

I haven't tried mocking this up on any physical device yet, though I
will probably do so when I get back home in a few weeks.

Just my two cent idea.  Criticisms/improvements are certainly welcome.

Take care.

Dave

On 12/1/06, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote:

On 12/1/06 12:27 AM, "Christopher Heiny" <[EMAIL PROTECTED]> wrote:

> Jumpx (aka Fitaly) already has an open source implementation at
>http://jumpx.sourceforge.net/
> Though it is stylus oriented in the current implementation.

I found this guy's idea quite interesting a while back:

http://www.strout.net/info/ideas/hexinput.html

-Sean

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Light sensor

On 11/30/06, Tim Newsom <[EMAIL PROTECTED]> wrote:

> the problem with doing it this way, is you'd need some way to notify
> each application of all the sensors available at runtime, or you
> re-compile each availability sensitive app for every combination of
> sensors (having that many versions of software is sure to turn off
> Sean's dad) there's definately more to think about on this one

Are you thinking of not only notifying each application on the number of
sensors.. (That would be easy enough in the api) but also to let them
have access to the setup/configure api for each one?

Yes - each transform (raw audio, touch screen state, last user
activity time, user availabity,etc) can decide on its own how to
handle subscription requests -- e.g. for when >1 application makes a
request to the same datasource.

Also, another bonus is that you don't need to recompile anything
whenever the transform-network changes - it would change quite often.

When a transform handles its last 'unsubscription', it could unload
itself -- this way resources are saved, and the dead branches of the
network are pruned. When an application tries to subscribe to that
transform next time, the transform-factory which handles the request
can instantiate it - that way you have:
1) User opens 'voice recorder'
2) Application loads, and request is made for (filtered audio:44k)
3) transform-manager creates (filtered audio) with given parameters
4) (filtered audio) makes a request for (raw audio:44k)
5) transform-manager creates (raw audio) with given parameters -
direct hardware interface
6) Another Application makes a request for (raw audio:22k)
7) Transform-manager passes request onto existing (raw audio) with parameters
8) The (raw audio) interface can be written to multiplex its output to
both Applications or create another instance of (raw audio) with the
22k parameter

Enumerating over each sensor that is active would be fairly easy using
the plugin mechanism previously described...  If every plugin had the
same output ranges... Say 0 to 255 or whatever and using the probability
scenario he talked about the application would only need to know one
interface, I.e. Availability.   As I understand the proposal, and I
might be wrong, it would end up a heirarchy.  Lower level plugins could
be accessed at any level but the common usage would be to build
behaviors going up from the sensors and applications would interface
with that... Is that right?

Yup - and because >1 application can share the same logical
processing, you save CPU cycles too.

With that in mind, each plugin would register with some service which
handles the interface to applications.  Each behavior created would do
the same and gain access to the sensors available.  Then a control panel
could be created to enable/disable some but not all plugins at the will
of the user, though that would modify the behaviors, they would then act
on the information currently available.

The flexibility and security of the network both become especially
crucial when you start referencing external nodes:

homepc:(user availability)
bobsneo:(user availability)
tomsneo:(microphone audio)

Upon a subscription to the last one, a dialog would be displayed upon
Toms neo1973 asking whether he accepted that level of security access.
It would then appear in that control panel if it was a brand new
connection.

The higher-risk security vulnerabilities should be a compile-out
option for the cautious ;-)

Although, that would make it very simple to write a little program to
make a walkie-talkie over GPRS.

Seems like a fairly interesting concept.  Do I understand the concepts
or am I missing something?

I think you did a better job than me of describing the idea :-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Text input.

2006-11-30 Thread Daniel Savage


Just curious with all the discussion of different text input methods .. is a
stylus a part of the standard Neo package planned with the touch pad?
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community

Re: Text input.