On Thursday 14 June 2007 08:48:07 Pedro Almeida wrote:
> Hello, Steve;
>
> I am using an application that came with the MicaZ CD, called "Terminal
> v1.9b by Bray++". I can use it to read/write to the serial port.
> If I indeed read it with the java Listen, I dont get those encapsulation
> bytes. But the purpose of this app is to be read in a Windows environment,
> where the USB ports are converted into virtual serial ports, and in my app
> I do get the encapsulation bytes when reading from the "serial" port.
Ah. Then you should look at the C SDK @ $TOSROOT/support/sdk/c. It can
handle the the serial protocol for you; you get to read and write serial
active messages and dispense with the framing/ack/crc stuff. Highly
recommended; I use it in a couple of systems. The sdk also provides tools to
get/set header fields and arbitrary payload fields that are defined by your
application. There's been a couple of discussions about the C SDK on this
list in the last few months.
You might also want to look at the MultiHopOscilloscope app, included in
TinyOS-2.0.1, which uses the Collection interface. The PC side code uses the
Java SDK, but I'd imagine it's a good source of information.
All the best,
Steve
>
> Thanks,
>
> Pedro
>
> On 6/14/07, R. Steve McKown <[EMAIL PROTECTED]> wrote:
> > HI Pedro,
> >
> > How did you generate your original hex string? TestNetwork appears to be
> > set
> > up to use the C serial forwarder sf, so if I program some motes, start sf
> > on
> > the serial port and tn-listener on the port opened by sf, I get active
> > message frames output without the serial frame encapsulation. Are you
> > connecting to the serial port directly?
> >
> > On Wednesday 13 June 2007 19:39:21 Pedro Almeida wrote:
> > > Hello all;
> > >
> > > After reading the TEP provided by David, it greatly helped, yet some
> >
> > things
> >
> > > still don't match. It is said that:
> > >
> > > typedef nx_struct SerialAMHeader {
> > > nx_am_addr_t addr;
> > > nx_uint8_t length;
> > > nx_am_group_t group;
> > > nx_am_id_t type;
> > > } SerialAMHeader;
> > >
> > > and the frame like
> > >
> > > ____________________________________________
> > >
> > > |_|_|_|_|_______________________________|__|_|
> > >
> > > F P S D Payload CR F
> > > F = Framing byte, denoting start of packet: HdlcTranslateC
> > > P = Protocol byte: SerialP
> > > S = Sequence number byte: SerialP
> > > D = Packet format dispatch byte: SerialDispatcherC
> > > Payload = Data payload (stored in SerialDispatcherC): SerialDispatcherC
> > > CR = Two-byte CRC over S to end of Payload: SerialP
> > > F = Framing byte denoting end of packet: HdlcTranslateC
> > >
> > > would give something like
> > > 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
> > > (explanation: For example, a platform independent AM packet of type 6,
> > > group 0x7d, and length 5 to destination 0xbeef with a payload of 1 2 3
> > > 4
> >
> > 5.
> >
> > > Note that the group 0x7d is escaped to 0x7d 0x5d. The protocol field
> > > (P)
> >
> > is
> >
> > > 0x40 (64), corresponding to SERIAL_PROTO_ACK (in Serial.h).)
> > >
> > > yet what i read is (mind only the beggining and end now)
> > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80 00 00
> >
> > 00
> >
> > > 00 20 00 00 53 63 7E
> > >
> > > so there's some bytes missing, and the start has more similarities with
> > > this struct than the SerialAMHeader:
> > >
> > > typedef nx_struct serial_header {
> > > nx_am_addr_t dest;
> > > nx_am_addr_t src;
> > > nx_uint8_t length;
> > > nx_am_group_t group;
> > > nx_am_id_t type;
> > > } serial_header_t;
> > >
> > > So if i disregard the
> > >
> > > D = Packet format dispatch byte: SerialDispatcherC
> > >
> > > it actually starts out nicely. Still do decide if the last 2 bytes
> >
> > before
> >
> > > the 0x7E are the 2 byte CRC (which are not even showing up in the
> >
> > example
> >
> > > sequence from the TEP) or the rssi+fcsCheck.
> > >
> > > So, doing it all again and completing with new information:
> > >
> > > 7E : Framing byte, denoting start of packet
> > > 45 : Protocol Byte (0x45 = SERIAL_PROTO_PACKET_NOACK = 69 from
> > > Serial.h) 00 : Sequence Number Byte (from the #define NO_TX_SEQNO in
> > > SerialP.nc)
> >
> > ??
> >
> > > FF FF : destination address (from UART)
> > > 00 00 : source address (root node)
> > > 13 : length ?
> > > 00 EE : Collection ID (from CTP) ?? / Type ?? / Destination PAN
> >
> > Identifier
> >
> > > (from MAC Header) ??
> > > 00 : ????
> > > 01 : hopcount (seems out of place, but sure looks like it) ????
> > > 00 00 : Destination Address (root ID=0) (from MAC Header) ???
> > > 00 07 : Source Address (from the MAC Header) ????
> > > 80 : sendCount ??? (this field increments like the seqno below)
> > > EE : Collection ID (from CTP) ?? / Type ??
> > > 00 07 : source
> > > 00 80 : seqno
> > > 00 00 : parent
> > > 00 00 : metric
> > > 20 00 : data
> > > 00 : ???
> > > 53 63: rssi+fcsCheck / CRC ??
> > > 7E : Framing byte, denoting end of packet
> > >
> > > Thanks everyone for helping with this "research"!
> > >
> > > Pedro
> > >
> > > On 6/13/07, David Moss <[EMAIL PROTECTED]> wrote:
> > > > I haven't been following this discussion much, but if you haven't
> > > > done
> >
> > so
> >
> > > > already, take a look at TEP 113, second 3.6:
> > > >
> > > >
> > > >
> > > > http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html
> > > >
> > > >
> > > >
> > > > Some of your unknown bytes are explained there in the serial HDLC
> >
> > header,
> >
> > > > which I don't believe is documented explicitly in a struct.
> > > >
> > > >
> > > >
> > > > [HDLC header][Serial Header][Payload][HDLC Footer]
> > > >
> > > >
> > > >
> > > > The length byte in the serial header is the length of only the
> > > > message payload I believe. There should be no radio message_t
> > > > metadata information transmitted by default as part of the serial
> > > > payload.
> > > >
> > > >
> > > >
> > > > http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
> > > >
> > > >
> > > >
> > > > -David
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > *From:* [EMAIL PROTECTED] [mailto:
> > > > [EMAIL PROTECTED] *On Behalf Of *Pedro
> >
> > Almeida
> >
> > > > *Sent:* Wednesday, June 13, 2007 2:50 PM
> > > > *To:* R. Steve McKown
> > > > *Cc:* tinyos-help@Millennium.Berkeley.EDU
> > > > *Subject:* Re: [Tinyos-help] Documentation regarding exact contents
> > > > of the MACProtocol Data Unit frame
> > > >
> > > >
> > > >
> > > > Hello, Steve!
> > > >
> > > > Things are starting to look less blurry now. Some still sound
> > > > strange, though.
> > > > If the 13 (19 in decimal) was the length, then the payload would end
> > > > (unless it doesn't start counting in the byte immediately after the
> >
> > 13)
> >
> > > > right after the byte with "20", which is a 2 byte field.
> > > >
> > > >
> > > > Here's the line again:
> > > >
> > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80 00
> >
> > 00
> >
> > > > 00 00 20 00 00 53 63 7E
> > > >
> > > > About that 20 and the "0xCAFE", it's because I have changed the
> > > > struct for my app, and now the 2 byte field "data" in the struct is
> > > > now split
> >
> > in
> >
> > > > 2, datah and datal, each with 1 byte (datah is the "20", datal is the
> > > > "00"). So the 19 count cannot (unless i'm wrong) end in the "20".
> > > >
> > > > The payload struct looks like this:
> > > >
> > > > typedef nx_struct TestNetworkMsg {
> > > > nx_am_addr_t source;
> > > > nx_uint16_t seqno;
> > > > nx_am_addr_t parent;
> > > > nx_uint16_t metric;
> > > > nx_uint8_t datah;
> > > > nx_uint8_t datal;
> > > > nx_uint8_t hopcount;
> > > > nx_uint16_t sendCount;
> > > > nx_uint16_t sendSuccessCount;
> > > > } TestNetworkMsg;
> > > >
> > > > How about the "+4" in
> > > > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength(msg) +
> >
> > 4)
> >
> > > > == SUCCESS), can it influence anything? It does add more bytes to
> > > > what
> >
> > I
> >
> > > > get.
> > > >
> > > > typedef nx_struct serial_header {
> > > > nx_am_addr_t dest;
> > > > nx_am_addr_t src;
> > > > nx_uint8_t length;
> > > > nx_am_group_t group;
> > > > nx_am_id_t type;
> > > > } serial_header_t;
> > > >
> > > > So far, i've ran more tests to try and figure the fields out. Here's
> >
> > how
> >
> > > > I understand it so far, with your help and using the structs above:
> > > >
> > > > 7E : Sync
> > > > 45 00 : ????
> > > > FF FF : destination address
> > > > 00 00 : source address (root node)
> > > > 13 : length ?
> > > > 00 EE : Collection ID (from CTP) ?? / Type ?? / Destination PAN
> > > > Identifier (from MAC Header) ??
> > > > 00 : ????
> > > > 01 : hopcount (seems out of place, but sure looks like it) ????
> > > > 00 00 : Destination Address (root ID=0) (from MAC Header) ???
> > > > 00 07 : Source Address (from the MAC Header) ????
> > > > 80 : sendCount ??? (this field increments like the seqno below)
> > > > EE : Collection ID (from CTP) ?? / Type ??
> > > > 00 07 : source
> > > > 00 80 : seqno
> > > > 00 00 : parent
> > > > 00 00 : metric
> > > > 20 00 : data
> > > > 00 : ???
> > > > 53 : rssi ?
> > > > 63 : fcs check ?
> > > > 7E : Sync
> > > >
> > > > Almost there, but still unclear. How does it look?
> > > >
> > > > Many thanks for all the help so far on this,
> > > >
> > > > Pedro
> > > >
> > > > On 6/13/07, *R. Steve McKown* <[EMAIL PROTECTED] > wrote:
> > > >
> > > > On Tuesday 12 June 2007 18:22:41 Pedro Almeida wrote:
> > > > > Thank you, Steve McKown and Alexander Becher for your replies.
> > > > >
> > > > > Thanks to your help I more or less figured out how many bytes there
> > > > > were from the Address Information to be included in the MAC Header.
> > > > >
> > > > > According to:
> > > > >
> > > > > typedef nx_struct cc2420_header_t {
> > > > > nxle_uint8_t length;
> > > > > nxle_uint16_t fcf;
> > > > > nxle_uint8_t dsn;
> > > > > nxle_uint16_t destpan;
> > > > > nxle_uint16_t dest;
> > > > > nxle_uint16_t src;
> > > > > /** I-Frame 6LowPAN interoperability byte */
> > > > > #ifdef CC2420_IFRAME_TYPE
> > > > > nxle_uint8_t network;
> > > > > #endif
> > > > > nxle_uint8_t type;
> > > > > } cc2420_header_t;
> > > > >
> > > > > I then have 9 bytes from the MHR, adding to 1 from length (PHR) and
> > > > > the 5 from the Synchronization Header
> > > > > (SHR), assuming (I don't think I'm mistaken here) the I-frame is
> > > > > not
> >
> > in
> >
> > > > > use, giving a total of 15 bytes. The type byte is include in the
> > > > > payload
> > > > >
> > > > > (according to Steve).
> > > >
> > > > In terms of the 802.15.4 frame format, section 14.2 of the CC2420
> > > > data sheet
> > > > shows that the data received into software from the radio. The SHR
> >
> > are
> >
> > > > never
> > > > received by software, so it can't be part of the data you are trying
> >
> > to
> >
> > > > decode. The data returned is a length byte, the MPDU bytes, an RSSI
> >
> > byte
> >
> > > > and
> > > > an FCScheck/corr byte (note the 2-byte FCS is replaced by RSSI and
> > > > FCScheck/coor on receive). Also, if you look at CC2420.h and
> > > > CC2420ActiveMessageP.nc , you'll see that the last 2 bytes
> > > > (MAC_FOOTER_SIZE)
> > > > are not calculated as part of the length field returned to the upper
> > > > layers
> > > > of software on a receive. Instead, the data in the last two bytes
> > > > are placed
> > > > in the metadata structure.
> > > >
> > > > So, I don't think SHR and FCS can be part of the packet format you
> > > > are trying
> > > > to decode.
> > > >
> > > > > The payload, from the TestNetwork application, is
> > > > >
> > > > > typedef nx_struct TestNetworkMsg {
> > > > > nx_am_addr_t source;
> > > > > nx_uint16_t seqno;
> > > > > nx_am_addr_t parent;
> > > > > nx_uint16_t metric;
> > > > > nx_uint16_t data;
> > > > > nx_uint8_t hopcount;
> > > > > nx_uint16_t sendCount;
> > > > > nx_uint16_t sendSuccessCount;
> > > > > } TestNetworkMsg;
> > > > >
> > > > > since nx_am_addr_t is 2 bytes, this struct is 15 bytes. Adding the
> > > > > 1
> > > >
> > > > from
> > > >
> > > > > the type (as seen above), there's 16 bytes in payload.
> > > > > Since
> > > > >
> > > > > typedef nx_struct cc2420_footer_t {
> > > > > } cc2420_footer_t;
> > > > >
> > > > > and according to Steve, "The current radio stack has the cc2420
> > > > > generate the FCS (crc) automatically", so I presume it's not
> >
> > included.
> >
> > > > > This totals 31 bytes, and I read 32! If FCS was indeed included (2
> > > >
> > > > bytes),
> > > >
> > > > > i'd get 33 bytes!!
> > > > >
> > > > > Please notice i'm using a representation such as this
> >
> > http://www.eng.yale.edu/enalab/courses/eeng460a/homeworks/hw1_results/d
> >
> > > > >ataf
> > > > >
> > > > >rame.gifto try and figure it out.
> > > > >
> > > > > This application uses CTP. Can it have anything to do with it?
> > > > > According
> > > >
> > > > to
> > > >
> > > > > TEP-123 (http://www.tinyos.net/tinyos-2.x/doc/html/tep123.html ),
> > > > >
> > > > > The CTP data frame format is as follows (check the URL for correct
> > > > > formatting):
> > > > > 1
> > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > |P|C| reserved | THL |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > | ETX |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > | origin |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > | seqno | collect_id |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > | data ...
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > But I don't know how to understand that, so it doesnt help me much.
> > > > > Also, I don't understand why the frame starts and ends with 0x7E.
> > > > > Is
> >
> > 7E
> >
> > > > > both preamble and last byte in payload?
> > > > >
> > > > > Here's one example sequence again:
> > > > >
> > > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80
> > > > > 00
> >
> > 00
> >
> > > > 00
> > > >
> > > > > 00 20 00 00 53 63 7E
> > > >
> > > > This is output from tn-listener, right? 0x7E is the serial sync
> > > > byte. I'm
> > > > not sure about the next 2 bytes, but the serial header starts at the
> > > > fourth
> > > > byte. Look at $TOSDIR/lib/serial/Serial.h and they'll match up:
> > > >
> > > > typedef nx_struct serial_header {
> > > > nx_am_addr_t dest;
> > > > nx_am_addr_t src;
> > > > nx_uint8_t length;
> > > > nx_am_group_t group;
> > > > nx_am_id_t type;
> > > > } serial_header_t;
> > > >
> > > > dest: FFFF - the dest addr as set by UARTSend.send(), as you note
> > > > below.
> > > > src: 0000 - the src addr of the sending mote. May be the PC
> > > > connected mote itself.
> > > > length: 13 (decimal 19)
> > > >
> > > > The next 19 bytes are CTP data, and I don't know the format so
> >
> > well. It
> >
> > > > looks
> > > > like there's an initial byte, 2 8-byte entries, and a 2-byte footer,
> >
> > but
> >
> > > > I'm
> > > > guessing.
> > > >
> > > > Note that tn-listener.c seems to have some problems. For example, it
> > > > accesses
> > > > packet after it has been freed. The data you are seeing could be
> > > > corrupt,
> > > >
> > > > since there's a malloc() after packet is freed and the space could
> >
> > have
> >
> > > > been
> > > > reused. The safe thing to do would be to move the free(packet) to
> >
> > just
> >
> > > > under
> > > > the free(myPacket). I'm thinking there may be corruption because the
> > > > second
> > > > CTP unit is supposed to have a 16-bit constant value that should read
> >
> > "ca
> >
> > > > fe"
> > > > in the raw data stream (see TestNetworkC.nc).
> > > >
> > > > Because the link to the PC is a serial link, the mote is sending a
> >
> > serial
> >
> > > > active message to the PC, which is the payload wrapped in the serial
> > > > frame.
> > > > This is why you don't see any of the CC2420/802.15.4 frame formatting
> >
> > in
> >
> > > > the
> > > > data you are trying to match.
> > > >
> > > > Cheers,
> > > > Steve
> > > >
> > > > > I believe the EE is the Collection ID, as seen from TestNetworkC.h,
> > > > > which might relate to the CTP frame
> > > > > (
> >
> > http://www.tinyos.net/tinyos-2.x/apps/tests/TestNetwork/TestNetworkC.h
> >
> > > > ),
> > > >
> > > > > but I'm not sure that helps. The FF FF could also be from, but I
> >
> > can't
> >
> > > > be
> > > >
> > > > > sure:
> > > > >
> > > > > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength(msg)
> >
> > +
> >
> > > > > 4)
> > > >
> > > > ==
> > > >
> > > > > SUCCESS)
> > > > >
> > > > > Many thanks and sorry for the confusing posts!
> > > > > Hope you help me figure this out byte by byte and make sense out of
> >
> > it.
> >
> > > > > Very best regards,
> > > > >
> > > > > Pedro
> > > > >
> > > > >
> > > > >
> > > > > /**
> > > > > * CC2420 Packet Footer
> > > > > */
> > > > > typedef nx_struct cc2420_footer_t {
> > > > > } cc2420_footer_t;
> > > > >
> > > > > On 6/11/07, Steve McKown <[EMAIL PROTECTED] > wrote:
> > > > > > On Friday 08 June 2007 13:21, Pedro Almeida wrote:
> > > > > > > Hello;
> > > > > > >
> > > > > > > I'm trying to look for documentation where I can understand the
> > > >
> > > > exact
> > > >
> > > > > > > contents, byte by byte, of the MPDU. I've looked into the TEPs
> >
> > and
> >
> > > > the
> > > >
> > > > > > > source files themselves, butI wasn't completely clear.
> > > > > > >
> > > > > > > I'm using now the TestNetwork demo, where I receive 32 bytes
> > > > > > > per
> > > > > >
> > > > > > message,
> > > > > >
> > > > > > > of which I know little about, except for the contents of the
> > > >
> > > > message_t
> > > >
> > > > > > > itself:
> > > > > > >
> > > > > > > typedef nx_struct TestNetworkMsg {
> > > > > > > nx_am_addr_t source;
> > > > > > > nx_uint16_t seqno;
> > > > > > > nx_am_addr_t parent;
> > > > > > > nx_uint16_t metric;
> > > > > > > nx_uint16_t data;
> > > > > > > nx_uint8_t hopcount;
> > > > > > > nx_uint16_t sendCount;
> > > > > > > nx_uint16_t sendSuccessCount;
> > > > > > > } TestNetworkMsg;
> > > > > > >
> > > > > > > That are not, by far, 32 bytes.
> > > > > > > So far I understood the MPDU is made of
> > > > > > >
> > > > > > > 2 bytes - Frame Control
> > > > > > > 1 byte - Data Sequence Number
> > > > > > > 4 to 20 bytes - Address Information
> > > > > > > n bytes - Data Payload
> > > > > > > 2 bytes - Frame Check Sequence
> > > > > > >
> > > > > > > which adds 5 bytes of the SHR and 1 byte of the PHR. So what
> > > > > > > exactly are those 32 bytes??? Which ones are the payload (MSDU)
> >
> > and
> >
> > > > > > > which
> > > >
> > > > ones
> > > >
> > > > > > > are
> > > > > >
> > > > > > not
> > > > > >
> > > > > > > (and what are they?)?
> > > > > > >
> > > > > > > An example of the 32 bytes is as follows:
> > > > > > >
> > > > > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00
> >
> > 80
> >
> > > > > > > 00
> > > >
> > > > 00
> > > >
> > > > > > 00
> > > > > >
> > > > > > > 00 20 00 00 53 63 7E
> > > > > >
> > > > > > The data above looks like an active message (AM) delivered via a
> > > >
> > > > serial
> > > >
> > > > > > physical layer. The hint are the 0x7E bytes, which are sync
> > > >
> > > > bytes. If
> > > >
> > > > > > this
> > > > > > output came from the PC, then you should be able to map it to the
> > > > > > serial_packet_t in $TOSDIR/lib/serial/Serial.h. The payload are
> > > > > > delivered within the frame appropriate for the link on which the
> >
> > data
> >
> > > > is
> > > >
> > > > > > sent. Hence,
> > > > > > one sees the serial headers and not the radio headers.
> > > > > >
> > > > > > I haven't played with Collection or the TestNetwork app, so I
> >
> > can't
> >
> > > > help
> > > >
> > > > > > out
> > > > > > there. But I can provide some info on how the CC2420 component
> > > >
> > > > populates
> > > >
> > > > > > the
> > > > > > 802.15.4 compatible frame. You can see the mapping in the
> > > > > > cc2420_header_t structure in $TOSDIR/chips/cc2420/CC2420.h. The
> > > >
> > > > physical
> > > >
> > > > > > radio frame looks
> > > > > > like this:
> > > > > >
> > > > > > preamble + sfd + cc2420_header_t + app_data + FCS (crc)
> > > > > >
> > > > > > In terms of 802.15.4, the second field of cc2420_header_t, fcf,
> > > > > > is the
> > > > > >
> > > > > > first
> > > > > > field of the MAC header. The last field of cc2420_header_t,
> > > > > > type,
> >
> > is
> >
> > > > > > actually part of the MAC payload. The current radio stack has
> > > > > > the
> > > >
> > > > cc2420
> > > >
> > > > > > generate the FCS (crc) automatically.
> > > > > >
> > > > > > In terms of addressing, short addresses with the 802.15.4 PAN ID
> > > > > > Compression
> > > > > > is set, so the address info consists of pan_id + dest_addr +
> > > >
> > > > source_addr.
> > > >
> > > > > > You can see these fields in the cc2420_header_t structure. The
> >
> > fcf
> >
> > > > > > is
> > > > > >
> > > > > > set in
> > > > > > CC2420CsmaP.nc's Send.send() implementation, where length, dsn
> > > > > > and
> > > >
> > > > source
> > > >
> > > > > > are
> > > > > > also set (destination has already been set in the header by this
> > > >
> > > > time).
> > > >
> > > > > > All the best,
> > > > > > Steve
> > > > > >
> > > > > > > Help!
> > > > > > >
> > > > > > > Thank you!!!
> > > > > > >
> > > > > > > Pedro
>
> !DSPAM:4671561a153541336712104!
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
