> Message: 5
> Date: Tue, 10 Jan 2006 08:14:14 -0800
> From: David Gay <[EMAIL PROTECTED]>
> Subject: Re: [Tinyos-help] Micaz UART message length problem
> To: TINYOS HELP <[email protected]>
> Message-ID:
>         <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
> 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

David,

Do you know how this affects the way the signal strength is reported
through something like TOSBase on the micaz?  Since the CC2420
reports an 8 bit number for RSSI and in the mica2 TOS_Msg, it is
16 bits, I've done a bit of fiddling with things. Before the packet is
rewritten and forwarded over the serial port, I modified TOSBase
such that it takes the micaz reported signal strength and overwrites
8bits of the data portion of the packet and is therefore not changed
even if the packet is rewritten.

I have not been successful in getting the old format, even following
your above fix of commenting out the define line in FramerM.nc.
It's strange to me, because the reported signal strength of the micaz
is nowhere to be found in the rewritten packet (except the data portion
as per above).  Where do you suppose they're getting the bits that
are being displayed as RSSI in the converted packet?  I cannot determine,
even after going though FramerM.nc.

Anyone else have any ideas?

On a last note, I'm 99% sure that my RSSI bits are correct.  They stay
the same while the distance between sending and receiving mote
does not change, and when I move the motes closer, the values get
closer to 0xFF and while I move them apart, they fall down to around
0xD2 before failing to receive packets at all.

--
Sam Pierson

_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to