Light sensor

[Jeff Andros]

On 11/30/06, Richard Franks <richard.franks at drdc-rddc.gc.ca> 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 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061130/2cef9095/attachment.htm