>I'm glad to hear someone (or two) is working on this.
>It would be nice if these projects were easier to track down.
>(These is something gratifying (to me) with seeing physical
representations.)
>At this point I hope it's not for TOS 1.x... (yes, I'm a zealot trying
>to get people to switch)
The GUI I'm working in for TOSSIM-T2.

>This actually sounds like it is almost entirely the task I've been
>doing this little inquiry research on. Is the code available anywhere?
>This seems like it'd be a rather useful feature. I'd much rather just
>report that this feature has currently been implemented and work on
>something else.

>How do you handle time synchronization with the motes/execution
>environment and data? (Just the stream makes it sound like it simple
>reads the next value in the stream.) With a full C/python Read
>interface it seems like the data could be any generic f(t), continuous
>or otherwise.

It is very generic in that you pass it a file pointer or a value to store.
For a file pointer it will read in all the values and loop through them as
you call read.  It allows for Read or ReadStream interfaces to be connected
to it.  As it stand rite now for time synchronization is done by making a
new event in the TOSSIM-T2 event queue.  Each mote will have its own values
or file pointer you can send to it by having a sensor array added to the
mote object in TOSSIM.  This allows for in the python script to set an open
and close gate or a new file stream when you want the sensor to activate.
So yes generic f(t), continuous or otherwise data just modifiable after
compile time during simulation time.  Anything beyond this will require some
more coding in python.  As for available code there isn't any posted yet.
I'm still trying to find the proper location to put this code and how to
make the array the correct size dynamic in the sensor object.

>>  I made it very specific so far making it only work with the
>>  HamamatsuS1087Par sensor rite now.  I'm currently reading trying to find
a
>>  way to imbed it more with the ADC to allow for a more dynamic design for
>>  more platforms.
>
>Is there a reason it needs to be sensor-specific if it uses the Read
>interface? If not, what am I missing?

Currently I've only had time to dig as far as the surface of the ADC modules
in TOSSIM.  Because of this I made it work with the HamamatsuS1087Par module
since I could easily change that code.  I'm working on finding the proper
location to bind it to.  There seems to be a link with the AdcReadClientC,
AdcReadNowClientC, and AdcReadStreamClientC.  That then moves onto reading
from particular chips.  If this is incorrect please tell me before I start
looking feature into added the functionality there.

Raymond

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to