If I understand correctly, disabling CCA means removing only the 'CA' part of the 'CSMA-CA' algorithem, while CSMA is still performed, isn't it? I ask this is because if carrier sensing always persists, there is no way to solve exposed terminal problem.
You also mentioned that if a mote keeps sending with CCA disabled, "the mote wouldn't last long". Did you mean that the sender stops sending, or the receiver cannot receive correctly?
Many thanks,
-Tie
On 10/26/06, David Moss <[EMAIL PROTECTED]> wrote:
Hi Tie,In TinyOS 2.x, there are two interfaces: CsmaControl and CsmaBackoff. The CC2420 radio stack currently uses the CsmaBackoff interface in CC2420CsmaP and CC2420TransmitP, but no CsmaControl interface. Take a look at CC2420Transmit interface - it has the option to send the message with or without clear channel assessments. CC2420CsmaP actually makes the call to use CCA or no-CCA when it tells TransmitP to send.The CC1000 stack provides both the CsmaControl and CsmaBackoff inside CC1000CsmaP.With either stack, right now it may take a little bit of hacking to adjust the backoffs and clear channel assessments how you want them. In my case, I have several components throughout a system that require different backoff periods, so I made the stack provide a CsmaBackoff[am_id_t amId] parameterized interface to direct the backoff request to the component that controls it based on am type.By securing the channel ahead of time, I meant that as a 'good idea' - not necessarily something that needs to be done. By checking the channel to see if anybody else is transmitting before streaming a bunch of CCA-disabled packets, you reduce the risk of collisions and lost data. After you know nobody else is transmitting, you can have your mote take over the channel by transmitting as long as it wants with no backoffs.And finally, in TinyOS 2.x, I have edited the line in CC2420CsmaP that reads "call CC2420Transmit.sendCCA( m_msg );" to "call CC2420Transmit.send( m_msg );". This sends the message without performing a clear channel assessment. Sending a bunch of rapid messages this way - i.e. by posting a task to send() from a sendDone() event in your application - I noticed originally that the mote wouldn't last long. This was probably due to not receiving an SFD. According to Phil, this has since been solved by resetting the backoff timer if no SFD is received within a millisecond of TXACTIVE.Hope that clears things up,-David-----Original Message-----
From: Tie Luo [mailto: [EMAIL PROTECTED]]
Sent: Wednesday, October 25, 2006 7:09 AM
To: David Moss
Cc: [email protected]
Subject: Re: [Tinyos-help] CSMA-CA on CC2420micazMany thanks to David for your excellent inputs.
According to what you said as quoted below: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.1) Were you refering to 1.x? I did not found MacControl and CsmaControl in 2.x.2) From "but requires one mote to secure the channel ahead of time", does that mean, if channel is busy, a mote will still backoff even if CCA is disabled? If I really want a node to send even if channel is busy ( e.g. imagine in the exposed terminal problem a node can still send), what can I do?3) The last question is, what do you mean by "Sometimes this crashes the mote"?Perhaps three questions are too many. Thanks a ton in advance.Rgds,Tie
On 9/22/06, David Moss <[EMAIL PROTECTED]> wrote: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-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Tie Luo
Sent: Wednesday, September 20, 2006 10:47 PM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Tinyos-help] CSMA-CA on CC2420micazI have the same concern about the CSMA implementation in TinyOS 2.0.Details are especially preferred. Thanks in advance.
On 9/21/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:Hi,
My question follows the same line as that of Daniel, but I'm working on
MICA2 motes, not MICAZ.
What is not very clear to me is exactly what MAC is implemented in TinyOS
1.1 for MICA2 motes. I saw there was something called S-MAC (for a
description, u can see "Enery-efficient MAC Protocol for Wireless Sensor
Networks" by John Heidemann and Deborah Estrin), but again a frnd of mine who
has worked on it claims that the MAC is something called B-MAC, developed by
some Berkley guys. I'm going thru a paper named "Versatile Low Power Media
Access for Wireless Sensor Networks" by Polastre et al, but this paper on B-
MAC mentions some interfaces like MacControl, MacBackoff and
LowPowerListening, which unfortunately I'm yet unable to locate in my
installation of TinyOS 1.x version.
Can anyone tell me something exactly how to use the MAC features that are
already existing, and how they handle message collision, RTS-CTS exchange,
etc? Does anyone know any good document that teaches on application-layer
protocol design for sensor motes using the exisiting MAC?
Thanks and regards
> As far as I understand it the micaz uses a simple CSMA, where it listens
> for a radio signal above a "squelch" value just before transmitting. If
> it hears anything it does a randomized backoff/retry.
>
> For power voltage, I run on regulated 3.3v. I looked at the spec sheets
> for the chips (actually the mica2 w/ CC1000) and it "seems" that 5v is OK,
> but have not tried it. Let me know if you get smoke...
>
> MS
>
>
> Munaretto, Daniel wrote:
> > Dear all,
> > i would like to ask you some questions about CC2420 and micaz
energy consumption.
> > I read, from reports and data sheets, that the Basic RF library in CC2420
contains only a small subset of the 802.15.4 standard: beacons is not
implemented, no defined coordinator/device roles,
> > it does not check CCA twice , it does not retransmit packets, it cannot
communicate with other networks.
> > 1)I would like to understand if, by default, any collision avoidance
mechanism is implemented or may be available for motes, as our micaz, which
have this chipcon (for example, in the CC2420 folder in TinyOS 1.x, is it
implemented a simple CSMA or a CSMA-CA?).
> > Because my research group needs to know if and how to provide a "good"
collision avoidance mechanism on our micaz motes.
> > 2)Exactly, what are the bounds of "the limited ability of the user" on
defining the MAC layer by TinyOS code? i mean, what can i modify, if possible,
in the MAC layer and how/where?
> > 3)I've just discovered that using the flash on our motes, so reading and
writing on flash, the batteries are insufficient. I was using 1.3 V
rechargeble batteries, but it seems i need more power.
> > Is it a known problem?is it possible to source the mote over 3V?because,
it is written 1.5 V on the motes...
> >
> > Thanks for your availability, any further help will be really appreciated
> > cheers
> > Daniele Munaretto
> >
> >
> >
> >
> > _______________________________________________
> > 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
--
Regards,
Tie
--
Regards,
Tie
--
Regards,
Tie
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
