David's suggestions (or more like solutions) should work.
This has been an issue since the first release of MicaZ,
and identical issue is appied to telos-series also.
Here is a note that I had a year ago:
==============================================
TOS_Msg Packet format in CC2420 (MicaZ and TelosB)
----------------------------------------------------
A. currently there are two TOSMessage formats/structures:
-MICA2 family (Mica, Mica2, Mica2dot), (tos/type/AM.h)
-CC2420 family (MicaZ / Telos), (tos/platform/micaz/AM.h,
tos/platform/msp430/AM.h)
B. Legacy/MICA2 Users ----> This is what we are doing!
-Use host side tools (SerialForwarder, Surge gui etc) specifying MICA2
"mode" (eg. SerialForwarder [EMAIL PROTECTED]:mica2 )
-make micaz using maintree tos/platform/micaz.
In this configuration
All UART traffic to/from host is in MICA2 family TOSMsg format. Host
applications process messages using MICA2 format. The platform/micaz
"FramerM.nc" adapts UART traffic between the message types .
Host application works directly across all platforms (mixed MICA2,
MICAZ)
C. TELOS/MICAZ Only Users
-Must rebuild host side tools and use java tools specifying micaz
"mode"
-make micaz using maintree tos/platform/micaz AFTER removing the local
"FramerM.nc" module. The tos/system "FramerM.nc" module handles
MICAZ TOSMsg
structure UART traffic.
In this configuration
All UART traffic to/from host is in MICAZ family TOSMsg format. Host
applications process messages using MICAZ/telos format.
Host application works in single platform (MICAz) network.
* There are two 'FramerM' files in the tinyos tree.
1. tinyos-1.x/tos/system/FramerM.nc
o This is the 'normal' file
2. tinyos-1.x/tos/platform/micaz/FramerM.nc
o This file changes the Micaz/telos TOS_Msg header to
Mica2 header ONLY WHEN sending over the UART.
* If you want to use the latter to work, copy the latter to
"tinyos-1.x/tos/lib/CC2420/"
* If you want to go back to the native formats, the just remove the
file (which will use the former)
==============================================
Thanks.
Jeongyeup Paek
Graduate Student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California.
http://enl.usc.edu/~jpaek
--
Michael Schippling wrote:
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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
