Hi Joaquín, Do you use the Java program that comes with TestSerial, or did you write your own program?
You probably have to follow the same approach as Mario did. Copy the relevant files from $TOSROOT/tos/lib/serial to your local application folder and insert debugging statements (e.g., turn on an LED when a packet is received, then later turn on an LED if the packet is passed to the next protocol layer, etc.). I started writing a description of the serial interface in TinyOS. Maybe this can help you, it's currently just a draft. Cheers, Urs ---------------- The format to exchange packets with motes running TinyOS over the serial port The nesC code handling the serial protocol on the motes is located in the subdirectory $TOSROOT/tos/lib/serial. Constants are defined in Serial.h. The serial interface is by nature a stream interface, while TinyOS handles packets. To know when packets start and end, TinyOS uses above the physical layer first a framing protocol. The framing protocol is handled mainly in HdlcTranslateC.nc. The end of a frame and the beginning of a new frame is indicated with a single byte with the reserved value 0x7E. Special characters can be escaped with a byte with the reserved value 0x7D. An escape sequence is always two bytes long, the escape byte (0x7D) followed by the escaped byte. Presumably, a byte with the original value 0x7E or 0x7D needs to be escaped to avoid confusion in the protocol. The transmitted byte value is obtained by xoring the original value with 0x20, and reversely, the original byte value of an escape sequence can be obtained by xoring the escaped value with 0x20. The behavior of the protocol implementation is undefined if the escaped value is either 0x7E or 0x7D. The next protocol in the protocol hierarchy is the framer-level dispatcher implemented in SerialP.nc. A framer-level packet consists of one byte with the framer-level protocol type, one byte with a sequence number, the actual data bytes, and finally two bytes with the CRC sum. Theoretically, the protocol stack could handle different types of serial data. In the current implementation, the stack only receives serial protocol packets that need to be acknowledged (protocol byte value 68), and it will send either acknowledge frames (protocol byte value 67) or serial protocol packets that do not need to be acknowledged (protocol byte value 69). The sequence number seems to be used exclusively to acknowledge successfully received packets (a mote only accepts packets that it has to acknowledge). The cyclic redundancy check (CRC) sum is calculated as an ITU-T conform 16-bit running CRC (also known as CRC-16-CCITT or CRC-CCITT). For implementation details look e.g., at the file $TOSROOT/tos/system/crc.h. The checksum is calculated over all the bytes of the framer-level packet, including the protocol byte and the sequence number byte, but excluding the two trailing checksum bytes. The checksum calculated over the packet must match the checksum provided at the end of the packet. Please note that the CRC is not a cryptographic hash. Its purpose is to detect transmission errors due to noise. Even if the CRCs match, there is a small error probability left (i.e., the data can be modified to give the same checksum, and both data and checksum could be modified to match). The CRC is not suitable to detect manipulation by an intelligent adversary, as the adversary can easily calculate collisions (different data with the same checksum) or simply replace the checksum. ---------------- On 10/31/10 12:37 PM, Joarod wrote: > > Hi again. First at all, thanks for your answer. > > And first at all again, I haven't give enough data. Sorry for this. > > I'm a Spanish student working in a thesis about sensors networks. The > hardware is a mote based on a ZigBit900 module from Atmel. You can find more > technical specifications at: > > http://cv.uoc.edu/app/mediawiki14/wiki/P%C3%A0gina_principal > http://cv.uoc.edu/app/mediawiki14/wiki/Inici > http://cv.uoc.edu/app/mediawiki14/wiki/Hardware_COU_1_1 > > Trying to test Mote-PC communication and following the tutorial indications > for TestSerial, I cannot see any leds blinking (like Mario initially). Then, > when comment all lines of the event Receive.receive to ensure that only the > red led gets on, still no blinking. So I concluded that this event doesn't > execute. > > Communication mote --> PC is ok. I can see the received packets on a > terminal. I cannot figure what's happen for the other way PC --> mote, and > why this event doesn't work normally. Are the mote discarding packets > because a CRC error, for example? It's a baudrate (57600) problem? May be a > problem about USB port? > > I have seen that some people had this problem, but no solutions were > revealed. > > I will appreciate any help. > > Regards, > Joaquín _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
