[Tinyos-help] 802.15.4

Daniel Schnit daniel.schnit at gmail.com
Fri Nov 26 18:23:05 PST 2010


Hi ppl,

i'm read in TKN papers, and i'm a little confused. in tinyOs the unslotted
csma/ca is implemented?

Bye

On Fri, Nov 26, 2010 at 12:47 PM, Pablo Marcos <pablo.marcos.oltra at 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.oltra at 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 <hauer at tkn.tu-berlin.de>
>>
>> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
>>> <pablo.marcos.oltra at 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 <aitorhh at 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.oltra at 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 <aitorhh at 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.oltra at 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 <aitorhh at 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.oltra at 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 <hauer at 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 <
>>> aitorhh at 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 at millennium.berkeley.edu
>>> >>>>>>>> >
>>> >>>>>>>> >
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>> >>>>>>>> >
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> Tinyos-help mailing list
>>> >>>>>>>> Tinyos-help at 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 at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101127/9f4ab48c/attachment-0001.htm 


More information about the Tinyos-help mailing list