[Tinyos Core WG] Issue with sampling multiple sensors

[David Gay]

On 5/23/07, Philip Levis <pal at cs.stanford.edu> wrote:
> On May 22, 2007, at 2:09 PM, David Gay wrote:
>
> > The thread that starts with
> > http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-May/
> > 024986.html
> > ("I can't sample X&Y acceleration at more than 31Hz!") brings up a
> > limitation of ReadStream:
> > how can one sample a group of sensors at high rates?
> >
> > It's easy enough to sample one sensor at a high rate, or several
> > sensors in succession. But if I want 200Hz sampling of X&Y
> > acceleration simultaneously, there doesn't seem to be a very good
> > answer?
> >
> > Possible current solutions:
> > - go low level, using Resource to reserve both sensors and ReadNow to
> > sample them (i.e., do ReadStream by hand) - this requires the
> > sensorboard to make *Now versions of each sensor available (the mts300
> > doesn't...)
> >
> > - have the sensor provide all reasonable sensor groups (e.g., X, Y and
> > X&Y) - painful for more than two sensors
> >
> > Possible future solutions:
> > - some interface to sampling groups of sensors? could be icky...
>
> Your example raises two separate issues:
>
> 1) Can I sample multiple sensors at a high rate?
> 2) Can I sample multiple sensors with low jitter between the readings?
>
> I think that 1) is reasonably solvable in this case. In theory, a
> ReadStream should know the warmup times of a sensor and
> correspondingly control whether it goes to sleep. Currently, Accel
> uses a SplitControlPowerManager, so it powers down the sensor
> immediately on idle.

Not sure what relevance ReadStream has here (are you thinking two
ReadStream's in succession?) Anyway, the "power-down/power-up" latency
problem is fixable if the second
request comes before the first completes - this does require two
ReadStream interfaces though.

The same can be done with Read...

> 2) is a very different problem. Unlike 1), there isn't enough
> information from the application layer to infer this relationship.
> The ADC very well may interleave other ADC readings between the two.
> I'd therefore agree with Jan and Vlado on this one.

I think this is a non-sequitur. If the HIL provides a
ReadStream-of-multiple-sensors interface, then it's its job to prevent
the ADC from doing bad things during this operation, in the same way
that the current ReadStream must ensure that (i.e., by reserving the
ADC resource). This may well imply that ReadStream-of-multiple-sensors
shouldn't be applicable to a random collection of sensors, as the
resource reservation issues might become intractable.

However, all this is getting into the realm of "how would we do this?"
I was only asking the "Is this important?" question...

David