ambient light sensor
Am Sa 8. März 2008 schrieb joerg: Great news! Now it seems simple to add a photodiode and a capacitor to have ambient light controlled backlight. :-) Only someone of OM has to disclose which testpoint is connected to 50633, pin32(LEDAMB) For GTA02A5 this testpoint is labeled H-TP1705. Maybe should be same label for printing on circuit board of GTA02 to be available soon. Wolfgand Spraul wrote: joerg, Don't you have the schematics? This is such a small detail, if you know the answer feel free to publish it. [...] thanx jOERG ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/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 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
Ivan Lucas, Thu 2006-11-30 23:34 CET 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
Alexander Steinert wrote: Ivan Lucas, Thu 2006-11-30 23:34 CET 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
Rod Whitby, Fri 2006-12-01 00:56 CET 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
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: 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 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
