On Mon, Apr 16, 2012 at 5:14 AM, Daniel Bimschas < [email protected]> wrote:
> Hi list, > > I've read http://www.tinyos.net/tinyos-2.1.0/doc/html/tep113.html and I > want to make sure that I understood everything correctly / ask some > questions: > > 1) SerialP CRC field: The guide says "CR = Two-byte CRC over S to end of > Payload: SerialP". Does this mean that the CRC includes the S (sequence > number) field? > That was my understanding but from taking a close look at the source code, it looks like it also includes the Proto byte in front of the sequence field. And the CRC should include the PROTO byte too. Phil is that correct? > 2) The SerialP documentation states that PC-to-mote communication can/does > use acknowledgements. > I've never understood the SerialP ack implementation. Not sure exactly what it does or how it works. > a) Are acknowledgements mandatory or optional? > >From what I've seen they are optional. I've got serial communications (transmit only from the mote) and there is nothing on the other side that is sending asks back. b) I can't find out how the acknowledgments are represented in the packet > format (3.6). How do you request an acknowledgment? Are they always send? > c) How does the actual acknowledgment message look like (packet format)? > Not sure but I suspect that it uses just the Proto field and the sequence number. If they are actually used, it would be good if it were properly documented. 3) The SerialP description states "SerialP uses SerialFrameComm to send a > delimiter between frames". Does this mean that a fragmented packet on > application layer will result in several packets encapsulated in > HdlcTranslateC, using different sequence number fields in the SerialP > payload of HdlcTranslateC? > SerialP and the AM layer does not do any fragmentation. There is no fragmentation implemented. It is one of the reasons I'm interested in the 6lowpan IPv6 implementation. The problem is IPv6 is rather fat and I'm almost out of space on my mote. > 4) The SerialP description states "SerialP uses SerialFrameComm to send a > delimiter between frames, a serial-level type field, [...]". > a) Is the "serial-level type field" the same field as "P = Protocol byte: > SerialP" in "3.6 Packet Format"? Or is this referring to "D = Packet format > dispatch byte: SerialDispatcherC"? > I believe the "serial-level type field" being referred to is the type field that is part of the payload. If D is 0 then the Payload is an Active Message packet and the payload looks like dst src len grp type data The example packet in the TEP is wrong. It says that the packet looks like: 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e It is missing the SRC field which is normally is included. And it is also missing the CRC. Given a dispatch byte of 00 the following data is an AM packet and should have dst, src, len, grp, am_type, data. The low level serial encapsulation doesn't have any inherent addressing. So as soon as the example starts to talk about a destination address and given that the dispatch byte is a 0, it is talking about the AM encapsulation. > b) In case the "serial-level type field" is not the same as "P = Protocol > byte: SerialP": What's the purpose of P? What values can it take? > P is different than the serial-level type field. It can have... 67 PROTO_ACK 68 PROTO_PACKET_ACK 69 PROTO_PACKET_NOACK The whole protocol is underspecified so I have no idea how it works or what these values do. The only one that seems to currently be implemented is PROTO_PACKET_ACK. But like I said above it is unclear to me how the ack mechanism works. I think it is used as flow control in one direction only.... (host to mote, ie. when the mote receives). > > ======= > Some background why I'm asking these questions: > > I'm currently developing TinyOS support for the WISEBED wireless sensor > network testbeds (see. http://wisebed.eu). The specific function is that > the testbed backend shall be able to read individual packets from the nodes > stream and forward the individual packets to the remote experimenter using > the testbed. > Okay. I don't see why you want to expose yourself to the low level serial protocols on the mote or going between the host and mote. It is really ugly and was a quick and dirty implementation to get simple communications working. It isn't well documented nor very well specified. Rather it looks like you probably want to actually start at a higher level and want to interface to a gateway function of some sort. Check out TinyOS's SerialForwarder, support/sdk/c/sf. I've also reimplemented using sockets in motenet. Motenet can be found in support/sdk/c/motenet but you have to get it from the tinyprod sources located at github.com/tp-freeforall/prod(motenet-rel) [README]<https://github.com/tp-freeforall/prod/blob/motenet_rel/support/sdk/c/motenet/README> . Motenet provides a sockets interface to AM packets on the motenet/host gateway. > > As our testbed backend implementation (see > https://github.com/itm/testbed-runtime) is based on Java and uses > framing/deframing algorithms implemented using the Netty framework (see > http://netty.io) I need to re-implement the (de-)framing algorithms used > for the TinyOS serial communication. > I don't understand your conclusion. Actually it seems to me that you need to be able to receive frames from the motenet and be able to inject packets into the motenet. What does that have to do with reimplementing framing/deframing algorithms? Look at the serial forwarder and take a look at motenet (libmotenet, support/sdk/c/motenet). Perhaps you'll see what I'm getting at. > ======= > > Best regards, > Daniel Bimschas > > -- > Daniel Bimschas, M.Sc. > > > UNIVERSITÄT ZU LÜBECK > INSTITUT FÜR TELEMATIK > > Ratzeburger Allee 160 > 23538 Lübeck > > Tel +49 451 500 5387 > Fax +49 451 500 5382 > [email protected] > > http://www.itm.uni-luebeck.de/users/bimschas > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
