tinyos - Passing data on to packet for transmission using readstream -

i using readstream interface sample @ 100hz, have been able integrate interface oscilloscope application. have doubt in way pass on buffer value on packet transmitted . how doing :

uint8_t i=0; 

event void readstream.bufferdone( error_t result,uint16_t* buffer, uint16_t count )

 {  if (reading < count  )   i++;  local.readings[reading++] = buffer[i];  } 

i have defined buffer size of 50, not sure way noticing 1 sample per packet though have set nreadings=2. sampling rate not seem 100 samples/second when check.i not doing right in way pass data packet transmitted.

i think need clarify few things according questions , comments.

reading single sample accelerometer on micaz motes works follows:

1. turn on accelerometer.
2. wait 17 milliseconds. according adxl202e (the accelerometer) datasheet, startup time 16.3 ms. because particular hardware capable of providing first reading not after being powered on, delay. if decrease delay, wrong reading, however, behavior undefined, may correct reading or result may depend on environment conditions, such ambient temperature. changing 17-ms delay lower value bad idea.
3. read values (in 2 axes) analog digital converter (adc), mcu component converts analog output voltage of accelerometer digital value (an integer). speed @ adc can sample independent parameters of accelerometer: piece of hardware.
4. turn off accelerometer.

this happens when call read.read() in code. see maximum frequency @ can sample once every 17 ms, is, 58 samples per second. may bit smaller because of overhead mcu or inaccuracy of timers. true when sample calling read.read() in loop or every fixed interval, because call lasts no less 17 ms (i mean delay between command , event).

what may want is:

1. turn on accelerometer.
2. wait 17 ms.
3. perform series of reads.
4. turn off accelerometer.

if so, have 1 17-ms delay set of samples instead of such delay each sample. important, these steps have nothing interface use performing readings. may call read.read() multiple times in application, however, cannot same implementation of read command implemented accelerometer, because existing implementation responsible turning on , off accelerometer, , waits 17 ms before reading each sample. convenience, may implement readstream interface instead , call once in application.

moreover, wrote readstream used microsecond timer , independent 17-ms settling time of adc. sentence wrong. first of all, cannot interface uses or not use timer. interface set of commands , events without definitions. particular implementation of interface may use timers. read , readstream interfaces may implemented multiple times on different platforms various hardware components, such accelerometers, thermometers, hygrometers, magnetometers, , on. secondly, 17-ms settling time refers accelerometer, not adc. , no matter interface use, read or readstream, , timers driver uses, milli- or microsecond, the 17-ms delay required after powering on accelerometer. mentioned, want make delay once per multiple reads instead of once per single read.

it seems tinyos source code contains implementation of accelerometer driver providing readstream interface allows sample continuously. @ accelxstreamc , accelystreamc components (in tos/sensorboards/mts300/).

the readstream interface consists of 2 commands. postbuffer(val_t *buf, uint16_t count) called provide buffer samples. in accelerometer driver, val_t defined uint16_t. may post multiple buffers, 1 one. command not yet start sampling , filling buffers. purpose, there read(uint32_t usperiod) command, directs device start filling buffers sampling specified period (in microseconds). when buffer full, event bufferdone(error_t result, val_t *buf, uint16_t count) , component starts filling next buffer, if any. if there no buffers left, additionally event readdone(error_t result, uint32_t usactualperiod), passes application parameter usactualperiod, indicates actual sampling period , may different (especially, higher) period requested when calling read due hardware constraints.

so solution use readstream interface provided accelxstreamc , accelystreamc (or maybe higher-level components use them) , pass expected period in microseconds read command. if actual period lower 1 expect, means sampling @ higher rate impossible either due hardware constraints or because not implemented in adc driver. in second case, may try fix driver, although requires knowledge of low-level programming. adc driver source code platform located in tos/chips/atm128/adc.