Hi *Michael * In fact, I do not do my own CRC check in java code. The problem is that my java program occasionally receive some corrupted packets, which cause some exception when java program processes them. In my test , the crc check in Packetizer is correct although the packet is corrupted.
Since crc check is done, they should be discarded. I don't know where the corrupted packets come from and where they are corrupted. On 3/6/08, Michael Schippling <[EMAIL PROTECTED]> wrote: > > Are you doing your own CRC check in your Java code after receiving > a message via Packetizer? I would think Packetizer should catch > bad CRC's so your own check would be redundant. If you have written > your own CRC code that's a likely culprit... > > MS > > renjie huang wrote: > > Our java program occasionally receives some corrupted packet as > > following. I think there are two possible places where a packet is > > corrupted. > > 1. CC2420RadioM > > Our case is a bit similar to that is reported by > > > http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2006-August/018704.html > . > > Our data rate is also high, and we also use CC2420 radio chip(on > iMote2). > > But the difference is that we don't use TOSBase. When the sink forwards > > packets that are received from radio to UART, there is a crc check in > > AMStandard.nc. So if the packet is corrupted, it should be thrown away, > > but not forwarded to UART. Therefore it seems that it may be not a > > corrupted packet from CC2420. > > > > 2. UART transmission > > I check the code of FrameM.nc, crc calculation is done in > > async event result_t ByteComm.txByteReady(bool LastByteSuccess) , > > In Packetizer.java, crc is also checked. Therefore it also seems that > > the packet is not corrupted in UART. > > > > I am very confused about this. Is it because CRC is not reliable to > > check corrupted packets? But in our experiment, it seems that corrupted > > packets are received only when packet rate is high. Thanks. > > > > > > Dropping com.oasis.message.NetworkMsg (AM type 129): invalid length (too > > short), template.length=10, real length=9 Received message:09 21 08 49 > > FF FF 7E 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 Dropping > > com.oasis.message.NetworkMsg (AM type 129): invalid length (too short), > > template.length=10, real length=9 Received message:09 21 08 49 FF FF 7E > > 00 81 7D 0A 00 08 00 02 00 01 9D A5 > > > > > > > > -- > > > > Renjie > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Tinyos-help mailing list > > Tinyos-help@millennium.berkeley.edu > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > -- > Platform: WinXP/Cygwin > TinyOS version: 1.x, Boomerang > Programmer: MIB510 > Device(s): Mica2, MicaZ, Tmote > Sensor board: homebrew > > -- Renjie
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
