Hi David, On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski <tin...@zeroflag.eu> wrote: > Hi Miklos, > > I do not get failures, send returns just fine. I am also releasing the > packets back to the pool after sondDone occurs.
No, you do NOT put back the message after a sendDone(FAIL) even or a send command which fails. > The packets from the pool are only manipulated after I get them from the pool > and before I release them to the pool again, so I think even if they get > corrupted in the pool they should be properly setup again before sending > them. I am not using Packet.clear though. I'll try that and see whether it > has any influence on my results. You should call Packet.clear(). I suppose, that the MessagePool maintains a linked list of entries and stores pointers and that corrupts the internal layout, so you have to call Packet.clear() for each message. Best, Miklos > > Thanks for your input. > David > > Am 19.06.2011 um 23:45 schrieb Miklos Maroti: > >> Hi David, >> >> Do you see any failures? (send fails or sendDone fails?) If any of >> those occur, then you have to put the message back to the pool. >> >> Another thing you should do: call Packet.clear before you set up the >> data in the message. The values in the pool can be corrupted. I think >> this is the source of your problems. >> >> Best, >> Miklos >> >> On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski <tin...@zeroflag.eu> >> wrote: >>> Hello again, >>> >>> I did some more investigations on the ACK error I described in my previous >>> mail. It seems like I had quite the same error about a year ago but since >>> then I used tossim quite a lot and the error did not show up there. >>> >>> I have written a small example application that shows the error I have. The >>> application has a fixed message_t variable and a pool from which it gets >>> another message_t. It then sends the fixed message_t and the message_t from >>> the pool alternately over and over again. Upon reception the receiving node >>> lights the received message on its LED. The nodes print some debugging >>> information out on the screen showing which kind of message_t they are >>> actually sending and if it is acknowledged. >>> >>> Depending on the size of the pool used I get different behavior when it >>> comes to acknowledgements. For me the configuration of the program appended >>> yields no ack for packets that come from the pool but the packets not >>> coming from the pool all get acknowledgements. Other pool sizes yield other >>> results. In several (maybe all?) configurations the first two packets never >>> get acknowledged independent of whether they come from the pool or not. >>> Another thing to notice is that although the packets are not acknowledged, >>> they have been properly received, which is signaled by the blinking LEDs. >>> In some configurations the behaviour of ACKs changes between resets of the >>> node. >>> >>> I am really searching for some advice on this. The actual program I am >>> working on is using at least two pools, which I suspect are the reason why >>> I never get an ack there although all the messages sent are received and >>> everything is working flawless in tossim. >>> >>> Thanks, David. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> Tinyos-help@millennium.berkeley.edu >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>> > > _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
