Hi Guys, Keep in mind that TEP113 has some small errors and lacks some important information:
-I think the CRC is calculated from the protocoll byte, not the sequence number (but I'm not sure about that) -The example on the bottom completly forgets the CRC and the destination address, and it says that "The protocol field (P) is 0x40 (64), corresponding to SERIAL_PROTO_ACK (in Serial.h).", but SERIAL_PROTO_ACK is actually 0x44 (68). -Calling the message type "dispatch byte" is quite misleading -There's no words about what should be in the protocoll field -There's no words about how the ACK algorithm works and how the ACK packets looks like -There's no words about how the CRC is calculated (I know it's in some standard, but the TEP should mention this) Andris On Wed, Oct 17, 2012 at 1:06 AM, Saeid Yazdani <[email protected]> wrote: > Dear Erik, > > Thanks for your time again, you pointed me to locations that would take lots > of time for me to find by myelf. Yeah you are right I really don't know a > lot about networking. I will try to learn more! > > Bests, > Sean. > > > On 17-10-2012 0:43, Eric Decker wrote: > > > A good introduction to HDLC can be found at HDLC > > > On Tue, Oct 16, 2012 at 3:25 PM, Saeid Yazdani <[email protected]> wrote: >> >> Thanks for your comments Eric > > >> >> These bytes, I directly write them to serial port of PC, I mean they are >> inside a byte array, so I guess it should be counted as serial line. > > > No . If you have them inside the byte array and you write them to the port > you use to talk to the serial port, they may or maynot be the bytes that > show up on the serial line. Depends on what is running below the interface > you are using. > > The mote (on the other end of the serial line) is running HDLC at the lowest > layer. This means you need to have a protocol engine running that knows > how to talk HDLC on the serial line. > >> >> I am really confused with these layer stuff. > > > These are WSNs we are dealing with. Wireless Sensor Networks. Which > means you should understand basic networking. When you connect two devices > up, one needs to define how they communicate. This is called a protocol. > As data moves up the different layers, the layers implement different > functionality, different protocols are used to provide that functionality. > The whole thing is called a protocol stack. > > It seems that you dont understand what I am talking about. And this list > isn't the place to fix that. I'd recommend you take a basic networking > class and fill in the blanks. > >> >> What do you mean if it is coming from upper layer (I mean what is upper >> layer?) it is bad? I think since this is directly being written into serial >> port so I guess it is the serial line you mentioned. > > > See above. > >> >> >> It at least toggles the Led0 of telosb motes > > > unclear exactly what that means. It probably means that it received a > packet. > >> >> , I reviewed the code for BaseStation app and I think if a packet being >> transmitted in , maybe!, correct format the BaseStation app toggles that >> LED. > > > If you are sending those bytes exactly as written, then you are effectively > faking a properly formatted HDLC packet so the mote will receive it and the > app on the mote (top layer) will blink the led because it is happy. > > But the PC side of what you are doing is not running the HDLC protocol and > it won't get you very far as far a general communications with the mote. > >> >> In TEP113 there are two bytes '7d 5d', I assume this is a case of >> delimiter usage (so when converting to integer or ascii to it should be >> treaded as a single byte '7d' I guess). > > > Got look at the HDLC reference I sent above. To answer your question what > is going on is the original data in the payload is indeed 0x7d, this is > getting escaped to 0x 7d 5d. If the data were 0x7e that also would be > escaped to 0x7d 0x5e. > >> >> >> Would you mind giving some comments about my new discoveries!! if you >> mind?! > > > It is really important when dealing with this technology that you have a > good foundation. Seriously, go take a good networking course. > > Learn about simple serial point to point protocols. > >> >> >> Regards, >> Sean. >> >> On 17-10-2012 0:04, Eric Decker wrote: >> >> >> >> On Tue, Oct 16, 2012 at 3:22 AM, Sean Dekker <[email protected]> wrote: >>> >>> Hello, >>> >>> If anyone remember I was asking for serial packet format quite a while >>> ago. I managed to make a packet and send it to BaseStation app, by sending >>> this packet, the Led0 (Red LED) of the telosb mote toggles. I assume this >>> means the packet has been transfred from PC to mote in correct format. Is >>> this right? >>> >>> Here is the packet I managed to make: >> >> >> Where are you observing these bytes? >> >> 7e is an hdlc start/end delimiter, 7d is the hdlc escape that is used to >> escape both 7e and 7d which can't occur in the body of the packet. >> >> If you are sending this bytes from an upper layer then it is wrong. If >> this is what you are observing on the serial line then that is much better. >> >> I'm not sure where you are getting your data from. Take a look at the >> bottom of TEP 113. The format you have listed below is wrong. Its close >> though. >> >> The sequence number is 1 byte. It is followed by what they call the >> dispatch byte but really is packet format identifier. 00 says the packet >> payload is in the AM format (Active Messaging). >> >> >>> >>> 7E 44 00 00 FF FF 00 00 02 06 00 00 64 7B 7E >>> >>> byte[0] = 0x7E //start bit >>> byte[1] = 0x44 //Message Type >>> byte[2,3] = 0x0000 //Sequence number >>> byte[4,5] = 0xFFFF //Destination Address (AM_BROADCAST = 65535) >>> byte[6,7] = 0x0000 //Source Address >>> byte[8] = 0x02 //Payload size, in this case payload is 2 bytes both zero >>> byte[9,10] = 0x0000 //My messege (payload) to be sent >>> byte[11,12] = 0x647B //Calculated CRC from byte[1] to byte [10] >>> byte[13] = 0x7E //end bit >>> >>> >>> Can somone please confirm that I am making a correct packet and if it is >>> accodring to the format? also is the byte[2,3] really the Sequence Number!? >>> What are they being used for? How can I take care of escape sequence? Does >>> somone have a C/C# code for this case?! >>> >>> Regards, >>> Sean. >>> >>> >>> _______________________________________________ >>> 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 > > > > > -- > 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
