I think the following patch fixes the problem in the correct way... (Not completely tested but initial testing is positive)
/RogerL -- Roger Larsson, Research Engineer Division of Mobile Networking and Computing Luleå University of Technology SE-931 87 Skellefteå ________________________________________ Från: [email protected] [[email protected]] för Miklos Maroti [[email protected]] Skickat: den 10 februari 2011 23:04 Till: Roger Larsson Ämne: Re: rf230 BaseStation stuck on sending with fresh svn versions (r5427, mulle, rfxlink) Hi Roger, On Thu, Feb 10, 2011 at 11:10 AM, Roger Larsson <[email protected]> wrote: > Done some further testing... > > Attached my oscilloscope.py as this is the program that sends parameter > change requests. > - when it noticed that a report has the wrong parameters it sends an update > (debug change - it sends only once...) > > So when a measurement is reported and has wrong interval a message will be > sent out. > > The BaseStation will forward this successfully but application will get error > code FAIL, causing > message to get stuck in the out queue. The retries will also get error code > FAIL. Stuck until reset. > BaseStation still receives messages from radio and forwards them - but it > looses many. > > I have tried to recompile with CFLAGS=-DPACKET_LINK did not help... I see. > What we know > - when the message that causes fail is sent the radio should be in RX_ON or > possibly RX_AACK_ON > it could also be actively sending an AACK (acknowledging the measurement > data) > but I added a delay before sending the new parameters to make sure it has > left any BUSY*AACK > no success Are you using HW acks? > - since sending WORKS, it did manage to get from this state into sending - > and actually deliver the message > hmm... mulle is using a rather slow software spi, wonder what happens if it > can not keep up for the complete message (UR) > several bytes are don't care when sending... Yes, that could be related, but do not see exactly why that happens, since if it passes through the first few checks in the send path, then it is bound to return SUCCESS even if there is an UR (that will be silently ignored, we do not and cannot handle it). > - there should be no incoming messages at this time to interfere (tried with > measurement interval of 15 seconds) > - but the BaseStation fail... (Verified again that it works with older > BaseStation code and the same peer Oscilloscope mote) > > " then try using the old pacetlink code" - I guess you mean packet link code. > Only using older code for this sub system. But it does not work completely > without it either... so... I copied the old packetlink code what I meant. This is the only real change in all these reorganizations. Can you give it a try with CFLAGS=-DPACKET_LINK make mulle Best, Miklos > > /RogerL > > -- > Roger Larsson, Research Engineer > Division of Mobile Networking and Computing > Luleå University of Technology > SE-931 87 Skellefteå > ________________________________________ > Från: [email protected] [[email protected]] för Miklos Maroti > [[email protected]] > Skickat: den 10 februari 2011 08:18 > Till: Roger Larsson > Kopia: Henrik Mäkitaavola; [email protected] > Ämne: Re: rf230 BaseStation stuck on sending with fresh svn versions (r5427, > mulle, rfxlink) > > Hi Roger, > > The only big change is that I removed the packetlink layer from the > default configuration. By default, the PACKET_LINK was enabled in > Radiocounfig.h. This I have removed. Also, there were some logic > problems in the old PacketLinkLayerP, where it would enable ACKS even > if you did not request them. This is also fixed. > > Try compiling with CFLAGS=-DPACKET_LINK enabled. If this does not fix > the problem, then try using the old pacetlink code. Let me know how > this works. > > Best, > Miklos > > On Thu, Feb 10, 2011 at 7:29 AM, Roger Larsson <[email protected]> wrote: >> Correct, >> >> sendDone returns FAIL or some other error (i.e. not SUCCESS) >> but the message was delivered >> only one other mote running (multichannel) Oscilloskope - sending data at >> regular intervals >> the base station does receive messages and forward them to PC. >> >> This has worked earlier - something has happened... >> >> /RogerL >> >> -- >> Roger Larsson, Research Engineer >> Division of Mobile Networking and Computing >> Luleå University of Technology >> SE-931 87 Skellefteå >> ________________________________________ >> Från: [email protected] [[email protected]] för Miklos Maroti >> [[email protected]] >> Skickat: den 10 februari 2011 01:08 >> Till: Roger Larsson >> Kopia: Henrik Mäkitaavola; [email protected] >> Ämne: Re: rf230 BaseStation stuck on sending with fresh svn versions (r5427, >> mulle, rfxlink) >> >> Hi Roger! >> >> If I understand correctly, then the problem is that sendDone returns >> FAIL even though the message is transmitted. As a result, the >> Basestation gets into an infinite loop trying to send the same message >> over and over. >> >> Does there any other traffic going on? Can the Basestation still >> receive messages (i.e. did the whole radio lock up or just the send >> path)? >> >> How can I check this out? The Basestation seems to work on our motes, >> but we will double check it. >> >> Best, >> Miklos >> >> On Tue, Feb 8, 2011 at 10:24 AM, Roger Larsson <[email protected]> wrote: >>> [Probably this is rfxlink related, the changes in revision r5202 moved >>> mulle over to using rfxlink but did not fix the local copy of rf230 files... >>> Notice the local copies in %T/platforms/mulle/chips/rf230 they were not >>> modified in the same process...] >>> >>> Anyway a description on what happens >>> - using the apps/BaseStation to relay messages to from a PC >>> - sensor motes running a variant of apps/Oscilloscope >>> - whenever changing sample period it will change >>> This worked well in november (15 th) >>> >>> Back to do some TinyOS work i updated svn, compiled and downloaded. >>> Everything looks OK. Samples are received from sensors. >>> >>> But when trying to change parameters (sample period) only the first >>> modification works. >>> After a reset of BaseStation one more change works... >>> Got a clue when noticing that the red led was flashing fast on the >>> BaseStation... >>> >>> Some kind of error? Searched the sources and found some questionable code. >>> Whenever sendDone does not indicate SUCCESS the message remains in the >>> queue and is immediately retried. >>> Modifying this to only failBlink and always go on in the queue is a work >>> around. >>> (More correct would be to not remove when EAGAIN) >>> Note: the message did get through as the parameter change is reported back >>> correctly! >>> >>> --- tinyos-main-read-only/apps/BaseStation/BaseStationP.nc 2011-02-08 >>> 09:05:27.742687259 +0100 >>> +++ tinyos-main-read-only.rlsave/apps/BaseStation/BaseStationP.nc >>> 2011-02-07 16:54:03.149003205 +0100 >>> @@ -299,7 +299,7 @@ >>> event void RadioSend.sendDone[am_id_t id](message_t* msg, error_t error) { >>> if (error != SUCCESS) >>> failBlink(); >>> - else >>> +// else >>> atomic >>> if (msg == radioQueue[radioOut]) >>> { >>> >>> With this modification the BaseStation now works again. >>> Reverted to r5158, applied my mulle specific patches - that old version >>> works too (without this patch) >>> >>> Miklos could you try this test case (without the patch) - if it works for >>> you I would suspect the mulle platform local rf230 copy... >>> >>> /RogerL >>> >>> -- >>> Roger Larsson, Research Engineer >>> Division of Mobile Networking and Computing >>> Luleå University of Technology >>> SE-931 87 Skellefteå >>> >> >
rfxlink.patch
Description: rfxlink.patch
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
