> Suppose that I have 2 motes sending messages. Mote one send one message
with preamble, and the second mote start sending message on top of mote 1.
The result is that the 2 messages are corrupted. I was looking in the code
and it seems that on file CC2420LowPowerListeningP.nc you send one message
(task send) with CCA and then resend (task resend) with no CCA. The problem
is that call SubSend.send(currentSendMsg, currentSendLen) (line 447) return
SUCESS even if call CC2420Transmit.sendCCA( m_msg ) (file CC2420CsmaP.nc)
return FALSE. The consequence is that the resend doesn't use CCA.

 
Hi Miguel - 
 
I have done some testing with multiple transmitters to a single receiver.
The test setup involved 1 Rx mote with a 1000 ms sleep interval, and 3 Tx
motes transmitting full 28 byte payloads to the Rx mote. After each sendDone
event, the Tx motes would wait 500 ms before attempting the next send.
 
With the CC2420 stack as it is right now, it samples the channel at least
one time before sending a packet.  This is bad, as you've pointed out:  the
Tx mote could be sampling in a quiet acknowledgement gap of another
transmitter, and get a clear-to-send without the channel really being clear.
Two+ motes will transmit simultaneously and most likely cause collisions.
We'll call this method the "default CCA" method.
 
I made some modifications to the clear channel assessment in CC2420TransmitP
that allows the mote to sample the channel many times before determining
that the channel is clear.  If at any point during the assessment it finds
the channel is not clear, it sets the backoff timer and tries the whole
advanced CCA check from the beginning after the backoff timer fires.  This
way, there's less probability that two motes will be transmitting at the
same time.  We'll call this method the "advanced CCA" method.
 
Here are my results for two 3-minute runs using telosb's:
 
Default method
  Average Packets Received:  104.3
  Average Packets Dropped: 17
 
Advanced CCA method
  Average Packets Received:  101.3
  Average Packets Dropped: 19.6
 
 
Now, it could be that three minutes is not long enough to give a good sample
- but the results here show that the default method is actually more
reliable than the advanced CCA method.  Kind of counter-intuitive - motes
sending messages on the same channel simultaneously actually produces better
results than longer CCA checks.  The advanced CCA check method actually
seemed to make some motes hog the channel as well. It also seems to decrease
throughput.   Looking at the packets dropped, it could be that some motes
are still transmitting simultaneously (but visually looking at the Led's
shows this is not true most of the time)
 
We're still seeing a little less than 20% packet loss with multiple
transmitters, which is bad.  I'd like to continue by testing the impact of
adding in CCA checks on each send, instead of resending without CCA.  Maybe
this will make the receive check period too long, which would also be bad.
Maybe it will increase reliability.  The only way to tell is to implement it
and try it out.  
 
If anybody wants to test out other methods, I'd love to hear your results.
 
Thanks,
-David
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Miguel
Pereira
Sent: Thursday, December 07, 2006 1:18 PM
To: [email protected]
Subject: [Tinyos-help] Doubts on CC2420_lpl


Hi David,

Thanks for your help and for your ideas. I have in mind one thing a little
bit different. I tell you more when I will have some results.
Just like I said before I trying to create a new MAC. In last days I'm doing
some tests and I have some problems. 
First it seems that after receiving a message the radio couldn't make more
ack......which is strange. On receiver I have call
LowPowerListening.setLocalSleepInterval(500) and the sender send the first
message very well with ack but after that the ack doesn't work any
more....and I'm sending messages call
LowPowerListening.setRxSleepInterval(&packet, sendInterval) with
sendInterval > 500. It is important to report that with Normal Radio (no
lpl) the program works well... Maybe I have some mistake on
links........here my code for that: 
components CC2420ActiveMessageC as LplRadio;
  App.SubReceive -> ActiveMessageC.Receive[240];
  App.SubAMSend -> ActiveMessageC.AMSend[240];
  App.LowPowerListening -> LplRadio;
  App.Packet -> LplRadio; 
  App.PacketAcknowledgements -> LplRadio;
  App.AMPacket -> LplRadio;

Second, instead of using ActiveMessageC.Receive[240] and
ActiveMessageC.AMSend[240] I shouldn't use the LplRadio.Receive[240] and
LplRadio.AMSend [240]? But in application TestLpl which came with TinyOS 2.0
you  have link to ActiveMessageC.

Third, in my shorts experiences I have some problems with CCA. Suppose that
I have 2 motes sending messages. Mote one send one message with preamble,
and the second mote start sending message on top of mote 1. The result is
that the 2 messages are corrupted. 
I was looking in the code and it seems that on file
CC2420LowPowerListeningP.nc you send one message (task send) with CCA and
then resend (task resend) with no CCA. The problem is that call
SubSend.send(currentSendMsg, currentSendLen) (line 447) return SUCESS even
if call CC2420Transmit.sendCCA( m_msg ) (file CC2420CsmaP.nc) return FALSE.
The consequence is that the resend doesn't use CCA.

Sorry for my english, is not the best.........

Thanks for any help

Miguel Pereira


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

Reply via email to