[Tinyos-help] Excitation Voltage
Hi everybody. How do I enable excitation voltage (pin with 2.5V, 3.3V and 5.0V) in MDA300CA sensorboard? My gateway is MIB520 and my wireless module is IRIS XM2110. I use TinyOS 2.1.0. I noticed that in TinyOS 1.x there is TOSH_SET_xx_PIN macro, while in TinyOS 2.x (in tos/chips/atm1281/atm128hardware.h file) there is SET_BIT(port,bit) macro. Is it the right macro? However, what are port and bit values for excitation pins? How can I identify them? Thanks. -- Francesco Ficarola francesco.ficarola_at_gmail_dot_com Presidente LUG-PV (http://lugpv.netsons.org) Mailing List: lugpv_at_lists.linux_dot_it [GPG KeyID: 0xDBA99D92] http://lugpv.netsons.org/gpgkeys/francesco_ficarola.asc Il nuovo modo di fare ricerca: www.tradoogle.it signature.asc Description: OpenPGP digital signature ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] receiving different sample intervals
Hi All, I'm using tinyos-2.x and micaz platform and I'm having problems with my microphone sample application, the thing is simple, three motes are waiting for receiving a start sample command from BS and once they receive it they will start immediately the sampling process. Each mote timestamps the start and the end of this process in order to compute the sample interval. The problem is that theoretical the three intervals should be equal because they use the same buffer length and sample at 4kHz, but I always got different sample intervals (with a STDEV of 601.1724757, 325.9728201 and 472.9102405 for the three motes). I'm using CounterMicro32C component and Counter.get() command to timestamp the events. Could anyone please suggest any idea about how can I improve these results. Thanks in advance, Omar ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Simple Time Sync
Hello, I am trying to implement a simple time synchronization by sending the current time of a periodic timer from a master node using command getNow() of the Timer interface. Is it possible that the slave nodes set this value as the current time of their periodic timer? I imagine having motes that have blinking LEDs at the same time (not that precise) while booting at different times. What command and interface can I use to overwrite the current time of a timer? Thanks for your help. - JC de Dios ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] timesync
Hi Ted, On Sun, Aug 22, 2010 at 1:54 AM, Ted Herman her...@cs.uiowa.edu wrote: Miklos Maroti wrote: Yes, that is true. Somehow it would be necessary to know which packets contain embedded time stamps and which do not, so for example the Basestation could work without changes. For AM message we have used one of the AM types. Time Sync messages already have 1+4 byte shorter payload (1 byte for the embedded new AM type, 4 bytes for the even time). Actually, I found it so hard to use this level of the interfaces that I abandoned trying to follow that part of the code in the current TinyOS, instead just using the parts in transmit and receive, modifying them to look for new metadata switches. Formerly I did work on things at the higher layer of abstraction, but with the newest version, I just gave up because I ran out of headache pills. When I switched to just working with transmit and receive, my headache disappeared! You are correct, this shifts the burden to the application rather than doing so much in the system/stack. But of course this is an old theme in system development (if you've tried recently to work with I2C on the Linux/driver side you probably know what I mean). I think the old interface and implementation of timesync was poor. I think timestamping is good as it is. Regarding the embedded AM type, this seems to be more ambitious than I would want to suppose by default and enforce on everybody, but I guess you guys have found that this saves labor, at least for now :) -- you may be painting yourself into a corner ... Embedded AM type was a hack and that is what I wanted to remove, so for example the Basestation and any other application would work with timesync messages without a problem (no more tweaking of the layout of the packet, etc.) True. This was the intent. However, on most platforms the binary microsecond clock is stopped when the mote sleeps, so one has to be careful with this. Well, already I have been using the hybrid strategy you mention in a later email. The true binary microsecond clock is not used in all cases, just the microsecond standard of expressing time, in my case. On a Telos, using the microsecond clock had such marginal benefits in my experiments (because you have to limit its use to periods of 15ms for stability). But with mixed Telos/MicaZ networks, things are better. The hardware is still evolving and in another year or two when we are all working on ARM Cortex processors, maybe things will be different. This is true. I can live with the microsecond precision only, i.e. leave the standard as it is and avoid introducing the TMilli variant. The most important thing is to recognize that a message has embedded timesync value and remove the embedded am type. Yes, maybe ARM Cortex will be the standard, but I fear that if we move to more powerful chips, then TinyOS will become irrelevant and will be overtaken by stripped down linux. We will see. Also, I had to add fields for microsecond-based timestamps in the metadata plus new interfaces for that. Why cannot you use the PacketTimeStamp interface already provided? I only added a setmicro() command to PacketTimeStamp so that, in addition to set() there would be a microsecond field for times; I did this because set() might still be needed for the lower resolution uses somewhere else in the stack. I see. True. What I have seen that someone wanted to get the senders's TMilli time on the receiver side. He set the event time to 0, and then read the event time on the receiver. This works, but since the delay in the message is in microseconds, this method does not work, at least the TMilli value returned is truncated (the top 10 bits is incorrect). OK, yes, maybe the goal is to foolproof the timestamping implementation. Maybe if you keep things like the proposed overhead fields at a higher level than transmit/receive, that won't have any effect on what I am doing. Sort of like HAL/HIL distinctions. The proposed overhead field would not be an overhead compared to the current state of affairs, since we would eliminate the embedded AM-type. Something needs to be done, a proper way for the radio stack to identify incoming timesync messages without relying on a specific am-type. This would allow raw Ieee 802.15.4 time synchronization as well. Miklos ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] SBT80 Multi-Modality Sensor Board for TelosB
Hello, I have a question to the SBT80 Multi-Modality Sensor Board for TelosB wireless motes: http://www.easysen.com/support/SBT80v2/DatasheetSBT80v2.pdf here the source code: http://www.easysen.com/support/SBT80v2/ The acceleration sensors (X and Y axis) have an analog outputs and are connected to ADC6_PORT and ADC7_PORT of the telosb? does the telosb have such a lot adc channels? bye Gerald -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Dissemination Protocols Comparison
Hello, I'm looking to compare the dissemation protocols provided with tinyos, DIP, DHV, DRIP. i have papers n DIP and DHV to read, is there any good documentation on Drip? thanks, -- Paul ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Dissemination Protocols Comparison
The DIP paper explains Drip; Drip allocates a separate Trickle timer per item. Phil On Aug 22, 2010, at 11:08 AM, Paul Gildea wrote: Hello, I'm looking to compare the dissemation protocols provided with tinyos, DIP, DHV, DRIP. i have papers n DIP and DHV to read, is there any good documentation on Drip? thanks, -- Paul ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos- help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] [tinyos-help] Usart and BLIP
Hi... Anyone has used UART0 from U2 (expansio port, Telosb) with BLIP? I can take the Resource but I can not release it... Thanks in advance ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP simulation
Hi All, I am trying to test CTP (TEP 123), each time I run the simulation for around 30 mint, I get different tree structure. I dont understand this behaviour. Why should the tree structure be changed? is there something I dont know about meyer-short.txt or its this the usual behaviour? Kind Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
