good point....I will double check it. The escaping should be
handled in the Listen code, but it could be the result of version-foo.
thanks
MS
Sankar Gorthi wrote:
Just to be sure,
http://www.google.com/search?hs=v16&hl=en&lr=&client=opera&rls=en&q=deciphering+tinyos+serial+packets&btnG=Search
From the text:
The raw data packet uses an escape byte of 0x7D. This is needed in
case a byte of
payload data is the same as a reserved byte code, such as the frame
synch byte
0x7E. In such a case, the payload data will be preceded by the escape
byte and
the payload data itself will be exclusively OR’ed with 0x20. For
example, a
payload data byte of 0x7E would appear in the data packet as 0x7D 0x5E.
If that wasn't the problem you were after, I tried -shrug-.
Sankar.
On Mon, 09 Jan 2006 18:54:18 -0600, Michael Schippling
<[EMAIL PROTECTED]> wrote:
As a followup to my previous whine about trying to upgrade to
TOS1.1.14...
The _reason_ I was so brazen, was that I just started trying to use
the micaz's
(to continue on my radio communications testing pogrom). With TOS1.1.7 I
was getting errors in message length at the host, even though the 'Z
TOSBase
and re-Mote seemed to be talking just fine.
Now that I've been through the mill and am hanging over the
no-uisp-in-.14
chasm, I believe that it isn't an upgrade issue, but rather some
confusion
in translating the Zigbee radio message to the TOSMsg UART format.
Specifically I have programmed the re-Mote with CntToLedsAndRfm and
can see
that the base station is receiveing the count messages and trying to pass
them on. But when I use java Listen on the host side I get complaints
from
lower levels that the message is too long. Using the .14 version of
the java
tree I do get a message about trying to correct the error which I
didn't get
in .7, but it's not very confidence inspiring...
Using ListenRaw I see this coming from TOSBase:
7E 42 FF FF 04 7D 5D 04 33 00 01 00 F9 73
7E
7E 42 FF FF 04 7D 5D 04 34 00 01 00 D4 22
7E
7E 42 FF FF 04 7D 5D 04 35 00 01 00 60 54
7E
where this 5D ^^^^ seems to be superflous. I think it is this
value
that is being mis-interpreted as the data length field -- which should
be 04.
I am using [EMAIL PROTECTED]:micaz which I would hope sets the code
up, but
I haven't debugged into the rest of the tools/java yet. Does someone have
a quick answer for this before I have to perform another pointless
exercise
in reverse engineering?
thanks
MS
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
