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 <[email protected]>
> 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 <[email protected]>
>
> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
>> <[email protected]> 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 <[email protected]>
>> >>
>> >> 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
>> >> <[email protected]> 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 <[email protected]>
>> >>>>
>> >>>> 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
>> >>>> <[email protected]> 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 <[email protected]>
>> >>>>>>
>> >>>>>> 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
>> >>>>>> <[email protected]> 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 <[email protected]>
>> >>>>>>>>
>> >>>>>>>> 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 <
>> [email protected]>
>> >>>>>>>> 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
>> >>>>>>>> > [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
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> 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
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
