Dear all. I am trying to install the driver for Blip 2.0 in a computer with constrained resources in order to communicate it with the mote BaseStation (telosb). I managed to run Blip 1.0 with sheevaplug (based on ARM) but for Blip 2.0 is a bit complicated. So I have a question.
The pppd come by default with tinyos-2.x or my computer must have installed it before run Blip 2.0? According to the tutorials, I can't do : pppd debug passive noauth nodetach 115200 /dev/ttyUSB0 nocrtscts nocdtrcts lcp-echo-interval 0 noccp noip ipv6 ::23,::24 Thanks in advance, Alejandro. > 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 _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
