[Tinyos-devel] ctp vs other radio clients

Philip Levis pal at cs.stanford.edu
Mon Oct 27 18:28:57 PDT 2008


On Oct 27, 2008, at 5:36 PM, Branislav Kusy wrote:

> guys,
>
> is it allowed to use the radio (ie ActiveMessageC) while using Ctp? if
> not, should it be allowed? most of my applications require it...
>
> i couldn't find anything about this in tep123, but i found this  
> comment
> in CtpForwardingEngineP.nc,v1.17:
>
> line 487:
>       subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
> ....
> lines 509-519:
>       else if (subsendResult == EBUSY) {
> 	// This shouldn't happen, as we sit on top of a client and
>         // control our own output; it means we're trying to
>         // double-send (bug). This means we expect a sendDone, so just
>         // wait for that: when the sendDone comes in,  we'll try
>         // sending this packet again.	
> 	dbg("Forwarder", "%s: subsend failed from EBUSY.\n", __FUNCTION__);
>         // send a debug message to the uart
>         call CollectionDebug.logEvent(NET_C_FE_SUBSEND_BUSY);
>       }
>
> if there are other radio clients, subsendResult may be EBUSY even if  
> we
> don't double send. therefore, we should just call
> 	startRetxmitTimer();
>
> if we don't do this, ctp basically hangs forever.
>
> i've had this problem for a long time - ctp hanging on me for no good
> reason. my test application can reproduce it in a few seconds. i  
> tested
> calling startRetxmitTimer() from the EBUSY case and it fixed the
> problem. i'm not sure if it didn't introduce any other problems,  
> though.

Hrm. That's weird. Please read TEP 116: send should  return EBUSY iff  
it has returned SUCCESS to a prior call and has not yet signaled  
sendDone.

This suggests that it's a bug in CTP where it calls send multiple times.

Phil


More information about the Tinyos-devel mailing list