A good introduction to HDLC can be found at HDLC<http://en.wikipedia.org/wiki/High-Level_Data_Link_Control>
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 <http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html>. > 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 > [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
