huh, how odd...am I the only one who keeps getting bit by
these slight incompatibilities?
Or, more likely, just the only one that is clueless?
thanks, I'll try out the suggestions and let you know the results.
MS
David Gay wrote:
On 1/9/06, 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.
Yes, and see below.
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,
You would hope, but owing to what I think is a rather broken decision,
Crossbow decided to make micaz packets look like mica2 ones (it does
some rewriting of packets in the serial layer to achieve this).
Strangely, this isn't reflected all the way through, so when you
specify micaz in your MOTECOM environment variable or in serial
forwarder, it expects regular CC2420 packets. There's three basic
fixes:
- specify mica2 as the mote platform
- remove the FramerM.nc file from platform/micaz (this removes the
packet rewriting)
- remove the #define MICA2MSGTYPE from the start of FramerM.nc (same
effect as removing FramerM.nc, but maybe easier to switch around)
David Gay
_______________________________________________
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
