*Michael , *Thanks for your help.
The data length of our packet is 74 bytes. 10 is the size of a message
header after TOSMsg header. Therefore, normally all packets should have
data length no less than 10 bytes.
I made a mistake in my former test. Sorry for that. The problem is not
related to UART. Before they are sent to UART, the packet length is
already not correct. Also, besides the sink, some intermediate nodes
also detect wrong data length.
But it is a bit confusing that althought data length is wrong(this means
the packet is corrupted), crc field in TOSMsg header is true. This is
why it passes crc check in AMStandar.nc and isn't discarded.
I will do some more test on it.
On 3/6/08, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
OK, I'm confused again...
The debug messages you originally sent showed that you
expected to get 10 byte payloads but were only getting 9,
or did I misinterpret it?
But you said below that your data length is 74 bytes?
Also you believe that the length is always correct when the
message is passed to the UART code on the base-station mote.
And that the CRC is always correct at the Packetizer receiver.
So that means that the UART sender (or other code) is modifying
the length prior to the start of a message send, and then calculating
the CRC using that length (or else we are getting the 1::2^16
probability of a bad/good CRC...).
If that's the case then a good close read of the UART framing
code is probably called for. It _should_ be the same on all
platforms because the actual UART driver _ought_ to be the
only difference, but you never know...
Do you see any pattern in the changed length, like certain
bits modified? Or perhaps something is modifying your UART
buffer prior to the actual send? You do have some kind of
lock on the buffer until it's done transmitting, right?
Any possibility of a rogue pointer in the rest of your
base-station code?
MS
renjie huang wrote:
>
>
> On 3/6/08, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> 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.
>
>
> The data length of Our packet is 74. In fact, almost all
corrupted
> packets have a payload of 5 bytes. Sometimes it is 9 or others.
>
> 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.
>
>
> In my test, when corrupted packets are detected, it seems
that crc
> check is correct. If the length is wrong, crc check should not pass,
> since length is also taken into account when calculation.
>
> 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.
>
>
> Just now, in my test, it shows that before packets are sent to UART,
> the packet length is correct(Led is turn on). On the contrary, in
UART
> some packets have wrong length. Therefore, UART may be the true
reason.
> But if it is related to UART, why it only happen to Telosb and
Imote2,
> but not micaz.
>
>
> 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]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[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]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[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
>
>
>
>
> --
>
> Renjie
--
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Sensor board: homebrew
--
Renjie
