[Tinyos-help] unable to receive UART frame

Urs Hunkeler urs.hunkeler at epfl.ch
Mon Nov 1 23:47:10 PDT 2010

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.


The format to exchange packets with motes running TinyOS over the serial 

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

More information about the Tinyos-help mailing list