Hi Qiao, Wiring to the ActiveMessageC.Packet interface should not result in EBUSY. What other components do you use? I would like to know more about this issue. Brano, what error code did you see?
This problem has come up previously when the RF230 was retuning EBUSY and CTP was not prepared for this, but this was because another component (FTP) was using ActiveMessageC directly and not through the AMSenderC component (since it had to use the time sync send interface). This has been fixed. Miklos On Thu, Feb 25, 2010 at 5:53 PM, Qiao Xiang <[email protected]> wrote: > Hi Brano, > > Sorry to bother you again. I checked my code and the only wire to > ActiveMessageC I used is to wire to its Packet interface. And I wired Send > interface to CollectionSenderC component, and Receive interface to > CollectionC component. Is this Packet interface wire to ActiveMessageC also > affecting the radio serialization? My opinion is it is not cause both Send > and Receive interfaces are not wired to ActiveMessageC. If I am correct, > then why would it still have this hanging over issue? Thank you for your > advice. > > Best wishes > Qiao Xiang > > On Wed, Feb 24, 2010 at 10:49 PM, Qiao Xiang <[email protected]> wrote: >> >> Hi Brano, >> >> Thank you very much for your timely feedback. I also sent my question to >> Professor Levis earlier today and I really appreciate you guys' help. I >> checked my code and you are right. I used the same wrong wire as you did. I >> will fix it and do the experiment again to see how it goes. >> >> Before I got your email, I tried to call the startRetrxtimer function when >> EBUSY is returned from Subsend.send. And I use SENDDONE_FAIL as the window >> and offset parameters. As you described early in the archive, there is no >> hanging over on EBUSY. But the total number of transmissions increases. I >> wonder if the reason is that overusing the RetrxTimer to post sendtask() >> eliminate this hanging over issue by increasing the total number of >> transmissions? Or is it because I should use other parameters for the >> startREtrxtimer function to hack this problem? >> >> Best wishes >> Qiao Xiang >> >> On Wed, Feb 24, 2010 at 9:43 PM, Brano Kusy <[email protected]> >> wrote: >>> >>> Hi Qiao, >>> >>> the problem was that I was wiring ActiveMessageC comonent, rather than >>> AMSenderC in my application, so the access to the radio wasn’t properly >>> serialized. So just make sure that your application and all system services >>> that you use are wired through AMSenderC. >>> >>> On the other hand, if you’re using RF2xx radio, I’ve come across the same >>> problem recently, even if properly using AMSender. You can just simply call >>> “post sendTask();” in the case the subsend fails (line 478 of >>> CtpForwardingEngineP.nc). >>> >>> I’m cc-ing Om and Phil to comment more about conclusions on this issue. >>> >>> Cheers, >>> Brano >>> >>> >>> On 25/02/10 12:15 PM, "Qiao Xiang" <[email protected]> wrote: >>> >>> Hi Mr. Kusy, >>> >>> How do you do? My name is Qiao Xiang and I am currently a PhD student in >>> Wayne State University working on sensor networks. >>> >>> Recently I am doing some experiments on our sensor testbed NetEye using >>> TinyOS 2.x as the platform. I encountered a similar problem as you met with >>> CTP. During my experiment, some nodes call Subsend.send in >>> CtpForwardingEngineP but always return an EBUSY value. From the TinyOS-devel >>> archives I found that you reported this problem and have some discussion >>> with other guys. You mentioned that you can hack this problem by adding a >>> call of startRetxmitTimer function when the Subsend.send command returns >>> EBUSY. Woudl you please tell me in more details on how you did this, i.e., >>> what parameters you used when calling this function? Is it a SENDDONE_OK >>> parameter, a SENDDONE_NOACK parameter, or a SENDDONE_FAIL parameter? >>> >>> I also noticed that in the mailing list archive there is no final >>> conclusion on how to get rid of this problem. Thus I am also writing to ask >>> whether you and other guys have found a way to solve this issue. >>> >>> Thank you very much for your help and I am looking forward to your >>> answer. >>> >>> Best wishes >>> Qiao Xiang >> >> >> >> -- >> Qiao Xiang >> PhD student >> Computer Science Department >> Wayne State University >> 225 State Hall, 5143 Cass Ave, Detroit, 48202, MI > > > > -- > Qiao Xiang > PhD student > Computer Science Department > Wayne State University > 225 State Hall, 5143 Cass Ave, Detroit, 48202, MI > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
