sun compass with multi-touch sensor or multiple light sensors Re: Light sensor
Salve! Could the multi-touch sensor be used as light sensor? Would it work in two direction (two sides of the display with on corner) even better 2D (4 sides of the display)? Then no additional sensor would be necessery (instead of the additional sensor would be less power consumpting) and the direction where the most light came from could be used as well: Hold the Neo1973 into direct sun light. Based on the time (and longitude informaion) it could be used as sun-compass. Hacking the multi-touch sensor software for rotating maps - such a sun compas would let routate the map automaticaly in North-South direction (the same as a electronical compas would work) The sun compass could use to calibrate or check the magneticaly one. Or use it as Sextant :) Hang up your Neo1973 and fix it vertical with sun on your display. Calculate the cenit position and time for the sun. Messure the time between sunrise and sundown and use this for calculating time or/and position. When the sensor is sensitive enough - do it with the moon as well. In case that the multi-touch sensor isn't sensitive enough - use two seperate light sensors. And when you know your position and time with AGPS, the two high sensitive light sensors could use to calculate the inclination. A third (or more) high sensitive sensor could help to use the sun compass in all ways you hold your Neo1973 into the sun. To do some old style navigation with the neo would be - fun - instructive (to learn to navigate without GPS) - and would be a fall back in case that GPS is switched of Wish you to have sun this weekend! rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
On Friday 01 December 2006 02:03, Sean Moss-Pultz wrote: > What do you mean "doesn't come for free"? I for one would expect it to need more power than just sit there in idle mode? pgpaDV9SWeyFG.pgp Description: PGP signature ___ 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
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: 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: Light sensor
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
> 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: Light sensor
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
Re: Light sensor
> 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
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: Light sensor
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
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
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 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
<...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: 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
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: Light sensor
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... -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
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. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
Hi Rob, Yeah, the light sensor is interesting! Kind of reverse - some mobile phones have a flash light. So that probably might be interesting too. :) BTW: for the next device - that will have a camera - modern cameras can also see in the Infrared light, not only in the visible spectrum. You can try it - use a TV/etc remote control and point the diode into a mobile phone with a camera, enter pictures/video section and when you press a button on remote control you will see in mobile phone that the diode lights up a bit. So, if an Infrared lamp will be added to mobile phone it could become a night vision device :) But the infrared light source should be powerful enough (tried with a simple diode a few days ago - it didn't really light up the area). Also, just thought - newest Motofone has an E-ink screen, maybe that could be interesting - imagine - face side is normal touch-screen, and the whole back side - another screen, with all the advantages of E-ink (very good for e-book readers for example, and personalization - like your own picture on the whole phone). But that could be expensive at the moment... Best wishes, Alex -Original Message- From: Robert Michel <[EMAIL PROTECTED]> To: OpenMoko Date: Wed, 29 Nov 2006 20:32:14 +0100 Subject: Light sensor > > Salve, > > I already wrote that a light sensor could avoid that the > backlight is on, when it is not necessary: > http://lists.openmoko.org/pipermail/community/2006-November/000263.html > > 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. > > They could have a signalisation that I'm still awak. > > Maybe quantitiy and colour analysing of this sensor would be interesting > as well - I think there are cheap sensors called "camera". > > But that would consume CPU power and battery power, > so a photo diode or LED would be better. > > A this could be integrated into the multi-coloured-touch screen > this will have light sensors - when it could analyse other light > as well - it could swith the backlight > and could give informations to the programmes. > > With the colours of the light (anlysing) could it also possible to detect > in which room the Neo1973 is at the moment. (Dependances of window > orientation, type of electricaly light, wall colour - things inside...) > > So at last an smart backlight managment would be a "must have" > and whis such a sensor would be possibel to do other nice things > > rob > > > ___ > 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
