[Tinyos-help] unable to receive UART frame
urs.hunkeler at epfl.ch
Mon Nov 1 23:47:10 PDT 2010
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:
> 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
> 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
> I will appreciate any help.
More information about the Tinyos-help