oops....I see, you are getting the wrong length,
now that I try to read the debug lines of you message...
I've run "as fast as I can" using micaz and T1, but
not tmotes so I've never seen this happen.
Can you tell from the data if you are missing the last
byte of your packet? Can you try looking into the receive
loop to see how many bytes you really get? I think the
user level buffer may be allocated to the 'length' size
and copied, but you might find your missing byte in
the underlying code.
I don't remember clearly and I'm too lazy to go look, but
I think the receiving code uses the length from the message
as the number of bytes to receive and put into the buffer
you get. So two (or more) things would seem to be going wrong,
A) the actual message length gets changed from 10 to 9,
B) the 'extra' byte is either not transmitted, or is somehow
silently dropped in the receiver without a "resync" complaint.
You seem to have validated that the message is good as it
leaves the sending UART, and perhaps even at the receiver.
If there's some way to really check that your message has
the correct length prior to UART send, that would nail it.
Then putting trace messages in strategic locations of
Packetizer is probably the only way to chase it down.
not much use, I know...
MS
renjie huang wrote:
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]
<mailto:[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
> [email protected]
<mailto:[email protected]>
>
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
--
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Sensor board: homebrew
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
