[Tinyos Core WG] Meeting: 5/30
Martin Turon
mturon at xbow.com
Thu May 31 09:48:33 PDT 2007
Sounds good.
> > (3) The whole thing with setting up a struct and having the generic
> > component fill it in in the proper order seems a bit messy
One idea for the resulting packet format:
Add extra generic parameters to GroupedSensorsC:
<uint8_t max_reading_size>
Then, GroupedRead returns a Sensor header followed by an array of readings interpreted either as a buffer of byte[], or an array of {uint8_t sensor_id; uint16_t sensor_reading}:
[Header]
0x0000 Version (uniquely identify this packet as GroupedSensor version 2.x)
0x0001 Flags / Details (sensor_id = 1 byte, readings = 2 bytes, ...)
[Payload]
Address Value
0x0000 sensor_1_id
0x0001 sensor_1_value_H
0x0002 sensor_1_value_L
0x0003 sensor_2_id
0x0004 sensor_2_value_H
0x0005 sensor_2_value_L
0x0006 sensor_3_id
0x0007 sensor_3_value_H
0x0008 sensor_3_value_L
...
It is really handy to be able to parse the packet format without a ton of a priori knowledge about the nodes on the network. If there are too many sensors, add transport layer fragmentation/defragmentation of larger data objects.
Martin
-----Original Message-----
From: Kevin Klues [mailto:klueska at gmail.com]
Sent: Thu 5/31/2007 9:29 AM
To: Martin Turon
Cc: Philip Levis; TinyOS Core WG
Subject: Re: [Tinyos Core WG] Meeting: 5/30
So its not really a system yet -- its still just a discussion at this
point. Something similar to what you suggest is what I hinted at in the
last email though. Specifically, a way to pass the list of sensor_ids to
GroupedRead is definitely something that would be needed.
Kevin
On 5/31/07, Martin Turon <mturon at xbow.com> wrote:
>
>
> Oh, I didn't realize your system allowed this level of granularity. If
> you can truly build a runtime query system with this, that's great!
>
> I don't think I fully understand how the GroupedSensors interface and
> parameterized pieces overlap yet. What functionality is the GroupedSensors
> interface providing if the individual sensors themselves are parameterized?
> Is there someway to pass the list of sensor_ids to GroupedRead?
>
> Martin
>
>
> -----Original Message-----
> From: Kevin Klues [mailto:klueska at gmail.com <klueska at gmail.com>]
> Sent: Thu 5/31/2007 9:20 AM
> To: Martin Turon
> Cc: Philip Levis; TinyOS Core WG
> Subject: Re: [Tinyos Core WG] Meeting: 5/30
>
> If you wanted something like TinyDB where you had the flexibility to
> choose
> which sensors you wanted to access at runtime, then you would have to
> include them all in your application at compile time, and allow them to be
> configured as well as powered up and down based on the queries supplied by
> a
> user at runtime.
>
> Using my approach, this would mean instantiating the GroupedSensors
> component to include all the sensors available on a platform and adding in
> interfaces that allow you to specify which ones should actually be grouped
> together for the next query. This could be done through parameterized
> interfaces, where each sensor is given a unique ID, and that id is
> associated with both its Resource and its Read/ReadStream interfaces.
> Specifying a query for a group of sensors (2,5,6) would mean telling the
> GroupedSensors component to sample sensors 2,5,6 by calling the
> parameterized instances of Resource.request() and Sensor.read() on those
> sensors only.
>
> Kevin
>
> On 5/30/07, Martin Turon <mturon at xbow.com> wrote:
> >
> >
> > Hi Kevin,
> >
> > This idea of grouping sensors is a good one. The main problem with the
> > outlined approach is that it requires hard-coding those groupings in
> nesC.
> > This will limit the ultimate scalability of the approach. Users
> definitely
> > want to group their sensors. They also are likely to want to group them
> in
> > an ad hoc/configurable way. I think TinyDB took the right approach
> here.
> > The only problem was that their method was very RAM intensive (for a
> mote),
> > and was still pretty hard-coded under the hood.
> >
> > Martin
> >
> > -----Original Message-----
> > From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU on behalf of
> Kevin
> > Klues
> > Sent: Wed 5/30/2007 8:51 AM
> > To: Philip Levis
> > Cc: TinyOS Core WG
> > Subject: Re: [Tinyos Core WG] Meeting: 5/30
> >
> > I was thinking a bit about the Read/ReadStream problem and was wondering
> > what everyone thought about creating some sort of generic component that
> > allowed multiple sensors to be grouped together in such a way that it
> > would
> > be guaranteed that they were sampled simultaneously. A user would still
> > need to wire in the HAL implementations of their sensors (in order to
> get
> > access to their Resource interfaces), but wouldn't have to mess with
> > writing
> > the code that handled the arbitration:
> >
> > generic configuration GroupedSensorsC(typedef val_t, uint8_t numSensors)
> {
> > provides {
> > interface ReadRef<val_t> as GroupedRead;
> > interface ReadStreamRef<val_t> GroupedReadStream;
> > }
> > uses {
> > interface Resource as SensorResources[uint8_t id];
> > interface Read<val_t> as SensorReads[uint8_t id];
> > interface ReadStream<val_t> as SensorReadStreams[uint8_t id];
> > }
> > implementation {
> > components new GroupedSensorsP(val_t, numSensors);
> > }
> >
> > A struct would need to be created which held all of the sensor values
> that
> > get sampled simultaneously. This struct will be passed to calls of
> > GroupedRead.read(val_t* sensorValues).
> >
> > A call to GroupedRead.read( sensorValues ) (or GroupedReadStream.read(
> > sensorValues )) in GroupedSensorsP would then cycle through "numSensors"
> > requests in a for loop for all connected Resource interfaces, waiting
> for
> > them all to be granted before issuing a read() command on all of them
> > concurrently. Only once all readDone() events came back would a
> > GroupedRead.readDone() event be signalled with the values placed into
> the
> > location pointed to by the "sensorValues" variable accordingly.
> >
> > A user would only need to create a component that used GroupedSensorsC
> and
> > wire in the chip specific sensors (as if they were using their HALs),
> but
> > not have to worry about rewriting the code that handles all the
> > arbitration,
> > etc.
> >
> > #define UQ_ACCEL_XY "AccelerometerXY.GroupedSensors"
> > typedef struct accel_xy {
> > uint16_t x;
> > uint16_t y;
> > } accel_xy_t;
> > configuration AccelXandY {
> > provides interface ReadRef<uint16_t>;
> > provides interface ReadStreamRef<uint16_t>;
> > }
> > implementation {
> > components new GroupedSensorsC(uint16_t, 2);
> > components SomeAccelerometerHalC;
> >
> > enum {
> > ACCEL_X = unique(UQ_ACCEL_XY),
> > ACCEL_Y = unique(UQ_ACCEL_XY).
> > }
> >
> > GroupedSensorsC.SensorResources[ACCEL_X)] ->
> > SomeAccelerometerHalC.ResourceX;
> > GroupedSensorsC.SensorResources[ACCEL_Y] ->
> > SomeAccelerometerHalC.ResourceY;
> >
> > GroupedSensorsC.SensorReads[ACCEL_X] -> SomeAccelerometerHalC.ReadX;
> > GroupedSensorsC.SensorReads[ACCEL_Y] -> SomeAccelerometerHalC.ReadY;
> >
> > GroupedSensorsC.SensorReadStreams[ACCEL_X] ->
> > SomeAccelerometerHalC.ReadStreamX;
> > GroupedSensorsC.SensorReadStreams[ACCEL_Y] ->
> > SomeAccelerometerHalC.ReadStreamY;
> > }
> >
> > Problems I see with this approach...
> > (1) Different Read / ReadStream interfaces have different val_t
> > parameters.
> > Only sensors with the same val_t would be able to be grouped together
> > (2) I'm not sure how well the current design will allow for something
> like
> > this to be easily implemented.....
> > (3) The whole thing with setting up a struct and having the generic
> > component fill it in in the proper order seems a bit messy
> >
> > Kevin
> >
> >
> > On 5/29/07, Philip Levis <pal at cs.stanford.edu> wrote:
> > >
> > > Wednesday, May 30, 2007, 09:30 AM US Pacific Time
> > > Bridge: 3, Passcode: 7486633
> > >
> > > US: 1-916-356-2663 or 1-888-875-9370 (non-Intel)
> > > UK: +44 1793 402663
> > > Denmark: +45 4527 5090
> > >
> > > Agenda:
> > >
> > > Fred Jiang and John Regehr
> > >
> > > TEP Progress (1, 102, 109, 114, 117, etc.)
> > > - Shepherding
> > > - Steering Committee/Alliance WG
> > >
> > > Power management of sensors: ReadStream vs. Read vs. ReadNow
> > >
> > > Communication
> > > - AM group
> > > - Packet metadata (ToA, RSSI)
> > > - TEP 125: Frame format (attached)
> > > - 2.1?
> > >
> > > Phil
> > >
> > >
> > > _______________________________________________
> > > Tinyos-2.0wg mailing list
> > > Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> > >
> >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
> > >
> > >
> >
> >
> > --
> > ~Kevin
> >
> >
>
>
> --
> ~Kevin
>
>
--
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070531/6ee57772/attachment.html
More information about the Tinyos-2.0wg
mailing list