Thanks very much for your explanation. So you confirm the version of Xbow, that
CSMA-CA is in micaz by default.
BTW, during my tests, it seems true that there is a conflict between flash and
radio on micaz.
In fact now they "survive" after the reading-from-flash phase and they last for
several consecutive tests, until the batteries of one of them fall down at 1.3
V.
But the number of received and decoded packets, when i use the readings from
flash, is less than the one when i don't use readings.
So really it seems that in some cases, while you're using the flash, you cannot
use the radio properly...
quite unpredictable..
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Thu 9/21/2006 6:03 PM
To: 'Tie Luo'; [EMAIL PROTECTED]; Munaretto, Daniel
Cc: [email protected]
Subject: RE: [Tinyos-help] CSMA-CA on CC2420micaz
Collision avoidance is implemented differently on the two different
radios.
To start with Daniel's questions - the CC2420 2.4 GHz radio has a CCA
pin on the chip that can be sampled to determine if another node is
transmitting. How it determines this is defined in a control register - you
can sample the channel energy, valid 802.15.4 data, or both. When the CCA pin
shows that no other mote is transmitting, and the proper backoffs have
executed, the radio can send the message. From the definitions I understand,
this is a CSMA-CA scheme.
The CC2420 has more limitations on the MAC layer than the CC1000. This
is because a lot of the processing can take place on the chip. The
synchronization header, and packet header are defined in the CC2420 datasheet,
and the TinyOS message header for the CC2420 reflects this. You can get access
to modifying some of these things - like auto acknowledgements, CRC checking,
preamble length, etc. by modifying registers on the CC2420. All of this is
available in the software radio stack, so if you want to hack, go for it.
For Mica2 motes on TinyOS 1.x, you can find the Mac interfaces in the
CC1000RadioC.nc configuration:
configuration CC1000RadioC
{
provides {
interface StdControl;
interface BareSendMsg as Send;
interface ReceiveMsg as Receive;
interface CC1000Control;
interface RadioCoordinator as RadioReceiveCoordinator;
interface RadioCoordinator as RadioSendCoordinator;
interface MacControl;
interface MacBackoff;
}
}
The LowPowerListening interface in TinyOS 1.x is actually split up into
explicit commands inside CC1000RadioIntM.nc. This is improved in TinyOS 2.x,
as well as the TinyOS 1.x Rincon CC1000 stack - get it in the TinyOS 1.x CVS
under /contrib/rincon/tos/lib/CC1000Radio.
Whereas the CC2420 radio checks for a clear channel automatically using
the CCA pin, the CC1000 must do it in software using an ADC reading from the
RSSI pin on the CC1000 chip. Through a simple running average algorithm (that
has the possibility of improvement in the default TinyOS 1.x implementation -
see the rincon CC1000 radio stack) the microcontroller can determine the RSSI
noise level, and therefore be able to know when someone is transmitting by
comparing sampled values.
Changing the backoff period is very useful because it allows one mote
to secure the channel and transmit as fast as possible. Look for interfaces
like MacBackoff or CsmaBackoff in the radio stack to do this. When a
transmission starts, the radio stack sends out an initial or congestion backoff
event to request a backoff interval. If your application responds to that
event with a specified backoff period, fantastic. Otherwise, the default radio
stack values are used. The backoff period is probably the number one thing
that affects data throughput and accessing the channel fairly - those two are
inversely proportional.
Using the MacControl or CsmaControl interfaces, you can completely
disable CCA (clear channel assessment). This will make your motes transmit as
fast as possible, but requires one mote to secure the channel ahead of time to
avoid interference and collisions. Sometimes this crashes the mote, depending
on which software version you're using.
When it comes to acknowledgements, the CC2420 takes care of them
automatically if that register is set (which it should be in TinyOS). The
CC1000 does it manually by flipping the receiver into a transmitter and the
transmitter into a receiver very briefly, and the receiving mote sends out a
few bytes of acknowledgement. If an ack was received, the ack byte will be set
to 1 (or TRUE) in the transmitted packet's metadata.
What else?
-david
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help