It seems like the ScanP component was calling Radio.off() at a time,
when it didn't own the radio token (anymore). Looking at the code,
this is likely because the ScanTimer is not stopped after the
realignment frame was received. I committed a fix to SVN, please
retry.
Thanks,
Jan
On Fri, Nov 26, 2010 at 3:47 PM, Pablo Marcos
<pablo.marcos.ol...@gmail.com> wrote:
> HI all again,
> I have been adding functionality to my application, and apart of other
> things, I have tried to resynchronize the devices with the MLME_ORPHAN. I
> noticed that after sending with the coordinator the realignment, the device
> wasn't re-synchronizing at all, and was still lost. So, apart from my own
> printf's, I compiled in TKN154_DEBUG mode, and I got this (take note that my
> own printf's appear always before the TKN154_DEBUG ones):
> Coordinator:
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
> BeaconTransmitP:502:Beacon Tx scheduled for 162567148
> BeaconTransmitP:518:Beacon Tx (bsn: 61) success at 162567146
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 7711
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
> Device 847425747 Orphaned. It is on my assocList, so I send a response
> Orphan Response succesfully sent to 0
> BeaconTransmitP:502:Beacon Tx scheduled for 162597866
> BeaconTransmitP:518:Beacon Tx (bsn: 62) success at 162597866
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 776677711
> Device:
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
> BeaconSynchronizeP:421:Got beacon - bsn: 61, offset to last: 30718
> BeaconSynchronizeP:447:Handing over to CAP.
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30116
> Device 0 SYNC LOST for 1 time with aMaxLostBeacons 1 because of E0. Telling
> coordinator that I am Orphan
> Orphan Request succesfully
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 81
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
> BeaconSynchronizeP:385:Missed a beacon (total missed: 1).
> BeaconSynchronizeP:395:MLME_SYNC_LOSS!
> ScanP:176:MLME_SCAN.request -> result: 0
> BeaconSynchronizeP:228:Stop tracking.
> ScanP:255:Scanning channel 20...
> ScanP:363:Received coordinator realignment frame.
> ScanP:302:MLME_SCAN.confirm()
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> ...
> I thought that although the coordinator was sending the re-alignment command
> successfully, the device wasn't getting it, but after seeing this, it seems
> that after getting it, it gets some error. It seems the MLME_SCAN.confirm()
> is not completed, and so, the device is not re-aligning with the
> coordinator.
> I have checked the error lines un RadioControlImp as well:
> async command error_t MacRadioOff.off[uint8_t client]()
> {
> if (client == call ArbiterInfo.userId())
> return call PhyRadioOff.off();
> else {
> ASSERT(0);
> return EBUSY;
> }
> }
> but I have no idea why is getting an error in the ASSERT.
> Does anyone have an idea of why this is happening?
> Thanks in advance.
> Regards,
> Pablo
>
> 2010/11/23 Pablo Marcos <pablo.marcos.ol...@gmail.com>
>>
>> Thanks a lot Jan.
>> The problem is that each time I try to use the default printf in the
>> coordinator, my application loses sync. So right now, the only way I know
>> about getting results is using another node as sniffer (using
>> TestPromiscuous), which seems to work fine and cannot lose sync cause it is
>> not associated and is just listening packets. The problem is that for
>> instante, if you want to know how much packets the coordinator has rx, you
>> cannot guarantee that using another node, obviously.
>> For what Aitor said, it seems the dbg_serial is a lot better than the
>> default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
>> dbg_serial, but do with the default printf), so I was wondering if it would
>> be any way to make the dbg_serial work without having all the TKN154
>> dbg_serial's by default, just the ones that I write "by hand" in my own app.
>> Regards,
>> Pablo
>> 2010/11/23 Jan Hauer <ha...@tkn.tu-berlin.de>
>>>
>>> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
>>> <pablo.marcos.ol...@gmail.com> wrote:
>>> > Hi,
>>> > About the TKN154_DEBUG mode, I couldn't get the coordinator compiled
>>> > correctly because of the lack of memory in some tests. I someone faces
>>> > the
>>> > same problem, should try the -Os option to optimize the code and add as
>>> > well
>>> > these few lines to disable in the coordinator some functionalities:
>>> > CFLAGS += -I$(shell pwd)/.. \
>>> > -DIEEE154_SCAN_DISABLED \
>>> > -DIEEE154_BEACON_SYNC_DISABLED \
>>> > -DIEEE154_PROMISCUOUS_MODE_DISABLED \
>>> > This way, there is no error compiling in debug mode. Anyway, does
>>> > anyone
>>> > know how to print using the dbg_serial the TKN has implemented without
>>> > having the default printfs the TKN is showing?
>>>
>>> When TKN154_DEBUG is defined you can also use printf("...") to output
>>> your debug info over serial, but keep in mind that you should be in
>>> sync context (in async command/event handlers you can use
>>> tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
>>> you only want your own debug messages, then don't define TKN154_DEBUG,
>>> instead use printf library as described in the tutorial
>>> (http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
>>> disable / remove all your debug printf-statements later you can do
>>> something like this:
>>>
>>> #define printf(...)
>>>
>>> > And what about how to know
>>> > how much energy the CC2420 is consuming? It has to be some way to
>>> > measure
>>> > how much time the radio is in each mode, and using the datasheet, know
>>> > how
>>> > much energ is consuming.
>>> > Thanks in advance.
>>> > Regards,
>>> > Pablo
>>> > 2010/11/19 Aitor Hernandez <aito...@kth.se>
>>> >>
>>> >> Hi,
>>> >> I've tried your app, and it is working with 6 motes + coordinator
>>> >> during
>>> >> ~15min. I don't understand which could be the problem in your case.
>>> >> You
>>> >> could try to change the mote that plays the coordinator role. If your
>>> >> motes
>>> >> are old, it could be a problem.
>>> >> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again
>>> >> after the MLME_SYNC_LOSS but it is not a good idea, because then you
>>> >> won't
>>> >> see this kind of problems.
>>> >> I want to remark what you said about the printf and debug. The printf
>>> >> introduces a lot of delay, around 9x{backoff period}, but if is
>>> >> possible to
>>> >> use TKN154_4, the dbg_serial takes around one backoff period (20
>>> >> symbols).
>>> >> Hence, it is really important to disable them if they are not
>>> >> completely
>>> >> necessary. These values are approximations :P
>>> >> Best regards,
>>> >> Aitor
>>> >>
>>> >> On 18 November 2010 22:48, Pablo Marcos Oltra
>>> >> <pablo.marcos.ol...@gmail.com> wrote:
>>> >>>
>>> >>> Hi,
>>> >>> Thank you very much for your response Aitor. I had two motes running
>>> >>> for
>>> >>> 3 days with BO=14 and I had no problems of sync using the TestSync
>>> >>> application. Not even one beacon was missed. This was the first test
>>> >>> I ran
>>> >>> to check if I was about to have clock drift problems in later
>>> >>> experiments.
>>> >>> I'm currently using channels 19 and 20 because in my building there
>>> >>> are just
>>> >>> a few spare channels to use (20 are mainly being used right now).
>>> >>> Besides,
>>> >>> I always set up BO and SO < 7, using usually 5, but not even that way
>>> >>> works
>>> >>> properly.
>>> >>> Anyway, I don't really know if it has something to do with using
>>> >>> timers,
>>> >>> but I have noticed that the losing of the sync is kind of
>>> >>> periodically. I
>>> >>> have noticed today as well that both devices lose sync even if they
>>> >>> don't
>>> >>> even start at the same time (I was hoping a different periodicity for
>>> >>> each
>>> >>> one), but they both were losing the same beacons. Hence, I'm thinking
>>> >>> right
>>> >>> now about the possibility that it has something to do with the
>>> >>> coordinator,
>>> >>> cause the other two devices are not even tx packets, just trying to
>>> >>> me sync
>>> >>> with the coordinator.
>>> >>> I sent another mail a few days ago to the tinyos-help list cause I
>>> >>> thought that maybe the problems were cause because I was using printf
>>> >>> to
>>> >>> debug the application, but without using it is losing sync as well,
>>> >>> so...
>>> >>> now I'm the one that is lost :S.
>>> >>> Could you please check if the application attached is working for
>>> >>> you? It
>>> >>> is just the original TestData but with a Timer that once is fired
>>> >>> sends the
>>> >>> packets. When I try that, the device loses sync after a while.
>>> >>> Thank you very much in advance.
>>> >>> Regards,
>>> >>> Pablo
>>> >>> 2010/11/18 Aitor Hernandez <aito...@kth.se>
>>> >>>>
>>> >>>> Hi,
>>> >>>> We have been using this implementation for several wireless process
>>> >>>> and
>>> >>>> we made a performance evaluation of it. We haven't found any problem
>>> >>>> with
>>> >>>> the timers (used to start a transmission, or something else). The
>>> >>>> idea that
>>> >>>> comes up is that maybe there are some interferences on the same
>>> >>>> channel that
>>> >>>> you are using or you have a high beacon order.
>>> >>>> As we have seen, if we receive packets on the period where we are
>>> >>>> waiting the beacon, we could miss them. Moreover I've just realized
>>> >>>> that by
>>> >>>> using a high beacon order (> 10) some motes could have problems to
>>> >>>> synchronize with the beacon. I guess that I could be due to the
>>> >>>> clock drift,
>>> >>>> but Jan can clarify this point.
>>> >>>> What I recommend you, is to use a BO=6 and a SO =5,6 with this
>>> >>>> values
>>> >>>> you shouldn't have any problems.... Furthermore, try to change the
>>> >>>> channel
>>> >>>> and see if the problem persists. Channels between 22 and 26 don't
>>> >>>> have any
>>> >>>> overlapping with WiFi channels.
>>> >>>> At the moment, there is nothing else in my mind. I hope it will work
>>> >>>> for
>>> >>>> you.
>>> >>>> Good luck!
>>> >>>>
>>> >>>> On 18 November 2010 16:27, Pablo Marcos Oltra
>>> >>>> <pablo.marcos.ol...@gmail.com> wrote:
>>> >>>>>
>>> >>>>> I found the error and the UserButton is now working in my test
>>> >>>>> application. So, I wait for 3 nodes to have synchronization and
>>> >>>>> then I push
>>> >>>>> all of their buttons and they start tx data. However, after a
>>> >>>>> while, they
>>> >>>>> lose sync, as always, and I don't know why.
>>> >>>>> Aitor, have you ever used timers that once they're fired they send
>>> >>>>> the
>>> >>>>> data (for example, to send data every minute or so)? Cause I'm
>>> >>>>> having
>>> >>>>> trouble with that (even with just one device), and don't if that
>>> >>>>> could be
>>> >>>>> something related with the problem you told us a few mails ago.
>>> >>>>> Regards,
>>> >>>>> Pablo
>>> >>>>> 2010/11/18 Aitor Hernandez <aito...@kth.se>
>>> >>>>>>
>>> >>>>>> In my case, I just program all the motes at the same time by using
>>> >>>>>> "&"
>>> >>>>>> function on the shell, something like:
>>> >>>>>> $ make tmote
>>> >>>>>> $ make tmote reinstall,1 bsl,/dev/ttyUSB1 & make tmote
>>> >>>>>> reinstall,2 bsl,/dev/ttyUSB2
>>> >>>>>> By the way, I've been using the UserButton for some time, and I've
>>> >>>>>> never noticed the behaviour you explain, with or without
>>> >>>>>> TKN154_DEBUG
>>> >>>>>> enabled.
>>> >>>>>> Best,
>>> >>>>>> Aitor
>>> >>>>>>
>>> >>>>>> On 18 November 2010 13:28, Pablo Marcos Oltra
>>> >>>>>> <pablo.marcos.ol...@gmail.com> wrote:
>>> >>>>>>>
>>> >>>>>>> May I add other option to the Aitor ones?
>>> >>>>>>> I thought about letting the motes synchronize first, and then
>>> >>>>>>> start
>>> >>>>>>> sending packets once they're all synchronized. How could you do
>>> >>>>>>> this? I have
>>> >>>>>>> tried doing that with the telosb user button, hence once you
>>> >>>>>>> pressed it you
>>> >>>>>>> change a flag that starts sending packets. The problem is that I
>>> >>>>>>> have just
>>> >>>>>>> been able to do that with the TKN154_DEBUG enabled, otherwise,
>>> >>>>>>> the event
>>> >>>>>>> void Notify.notify( button_state_t state ) is not working.
>>> >>>>>>> You can see an example of how to use the telosb user button in
>>> >>>>>>> $TOSROOT/apps/tests/telosb.
>>> >>>>>>> Regards,
>>> >>>>>>> Pablo
>>> >>>>>>> 2010/11/18 Jan Hauer <ha...@tkn.tu-berlin.de>
>>> >>>>>>>>
>>> >>>>>>>> yes - I can reproduce the problem and also believe that it is
>>> >>>>>>>> due to
>>> >>>>>>>> wrong (beacon) timestamps. will look into it and try to fix it
>>> >>>>>>>> asap.
>>> >>>>>>>>
>>> >>>>>>>> thanks,
>>> >>>>>>>> jan
>>> >>>>>>>>
>>> >>>>>>>> On Thu, Nov 18, 2010 at 10:02 AM, Aitor Hernandez
>>> >>>>>>>> <aito...@kth.se>
>>> >>>>>>>> wrote:
>>> >>>>>>>> > Hi guys,
>>> >>>>>>>> > I've seen this problem with TKN15.4. It is possible to
>>> >>>>>>>> > synchronize
>>> >>>>>>>> > N nodes
>>> >>>>>>>> > with TKN15.4 the problem is that they need to start the app at
>>> >>>>>>>> > the
>>> >>>>>>>> > same
>>> >>>>>>>> > time. From my experience I've realized that the problem comes
>>> >>>>>>>> > from
>>> >>>>>>>> > the
>>> >>>>>>>> > cc2420_tkn154 (maybe it happens with the default cc2420
>>> >>>>>>>> > implementation as
>>> >>>>>>>> > well).
>>> >>>>>>>> > If we have a network with N nodes running and transmitting
>>> >>>>>>>> > data
>>> >>>>>>>> > between
>>> >>>>>>>> > them, when we try to add another node we could have this
>>> >>>>>>>> > problem.
>>> >>>>>>>> > As far as
>>> >>>>>>>> > we have the radio enabled for reception for a long period
>>> >>>>>>>> > (Scan
>>> >>>>>>>> > period), the
>>> >>>>>>>> > cc2420 receives the beacons but data packets as well. Once it
>>> >>>>>>>> > detects that
>>> >>>>>>>> > the received packet is a beacon, it sets the timestamp, but
>>> >>>>>>>> > sometimes the
>>> >>>>>>>> > timestamp is wrong, due to the data packets, and then we lost
>>> >>>>>>>> > the
>>> >>>>>>>> > next
>>> >>>>>>>> > beacons.
>>> >>>>>>>> > Possible solutions:
>>> >>>>>>>> >
>>> >>>>>>>> > Check the CC2420ReceiveP.nc and the m_timestamp_queue. I guess
>>> >>>>>>>> > that the
>>> >>>>>>>> > problem should be there. I did some modifications on
>>> >>>>>>>> > the CC2420ReceiveP.nc to solve this problem, but I haven't
>>> >>>>>>>> > test it
>>> >>>>>>>> > properly.
>>> >>>>>>>> > If we lost the synchronization, scan again
>>> >>>>>>>> > with MLME_SCAN.request(). It is a
>>> >>>>>>>> > "fake" solution, because the problem is still there, but for
>>> >>>>>>>> > some
>>> >>>>>>>> > app it
>>> >>>>>>>> > will work.
>>> >>>>>>>> > Start the nodes at the same time. It is not possible in a real
>>> >>>>>>>> > deployment.
>>> >>>>>>>> >
>>> >>>>>>>> >
>>> >>>>>>>> > --
>>> >>>>>>>> > Aitor Hernandez
>>> >>>>>>>> > KTH | Automatic Control
>>> >>>>>>>> > Research engineer
>>> >>>>>>>> > Stockholm
>>> >>>>>>>> > Phone: +46 (0)704 26 87 99
>>> >>>>>>>> >
>>> >>>>>>>> > _______________________________________________
>>> >>>>>>>> > 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
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> Aitor Hernandez
>>> >>>>>> KTH | Automatic Control
>>> >>>>>> Research engineer
>>> >>>>>> Stockholm
>>> >>>>>> Phone: +46 (0)704 26 87 99
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Aitor Hernandez
>>> >>>> KTH | Automatic Control
>>> >>>> Research engineer
>>> >>>> Stockholm
>>> >>>> Phone: +46 (0)704 26 87 99
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Aitor Hernandez
>>> >> KTH | Automatic Control
>>> >> Research engineer
>>> >> Stockholm
>>> >> Phone: +46 (0)704 26 87 99
>>> >
>>> >
>>
>
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
