Light sensor

Jeff Andros whitedrought at
Thu Nov 30 21:47:36 CET 2006

On 11/30/06, Richard Franks <richard.franks at> 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 at

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)

What DO you call whitewater when you live in the desert?
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the community mailing list